[Ohrrpgce] Quarterly Stable Releases?

Thu Jul 13 20:14:34 PDT 2017

On Thu, Jul 13, 2017 at 5:55 PM, Ralph Versteegen <teeemcee at gmail.com>
wrote:

>
>
> On 14 July 2017 at 02:15, James Paige <Bob at hamsterrepublic.com> wrote:
>
>> I agree that potential backcompat problems also belongs in the category
>> of reaons-to-delay-a-release
>>
>> Lets work for a 3-month release schedule. i won't fix it to specific
>> months, I'll just set up reminders for the next one 3 months after each
>> time we actually do a release.
>>
>
> Sounds agreeable, and hopefully we'll have better discipline than we've
> had for the last decade!
>

I have a good feeling about it this time :D

>
>
>>
>> I would like to still aim for an RC in the first week of August, if
>> possible.
>>
>
> I'll be in Australia for two weeks from August 7th, and though I'll take
> my netbook it would be better if the RC were earlier rather than later.
>

Duly noted! Earlier rather than later!

>
>
>>
>> I am not worried about finishing the hero mouse controls before
>> Dwimmercrafty. I don't expect them to be ready to move out of the spam menu
>> by then, but I don't feel the need to disable them any further either.
>>
>> I actually feel pretty good about NPC pathfinding right now. Good enough
>> to remove the "EXPERIMENTAL" from the menu caption in the NPC editor. Are
>> there any other aspects of it you would like to see me clean up before
>> dwimmercrafty, especially in the avoiding-backcompat-problems department?
>>
>
> Hero pathfinding isn't any problem. I was just concerned about finalising
> how NPC pathfinding works, in particular the treatment of other NPCs as
> obstacles. You added NPCInst.stillticks but it's used only for
> pathfindnpcto/npcchasesnpc's stop after still ticks. I thought the idea was
> to also use it to set the penalty for pathing through that NPC.
>

Ah, yes. Well, I want to be able to choose between different modes, and the
current mode of treating all npcs like moving walls is definitely one of
those modes. I also want a mode that treats all NPCs as completely
passable. That will often lead to getting stuck, but I think for some
purposes it will be just what you want. A smarter mode that increases path
cost for NPCs in the way is definitely needed also.

I don't think all those modes need to be finished before dwimmercrafty. I
don't see any backcompat problems because the current mode will still exist
as an option even after the other modes are added, and the
tread-everything-as-walls mode is probably the most intuitive default (even
if it happens to be less optimal)

> Also, the npc_ccache is populated by placing each NPC at the nearest tile,
> which is different from how collision checking actually works (which is to
> add x/ygo to get the tile being moved to), and I wonder whether that
> matters.
>

Oh! Good catch. I'll fix that. Probably doesn't break anything being the
way it is, but better to make it more correct.

> Also, there were one or two more optimisations I wanted to make (though
> I'm mostly done with that). Unfortunately anything that changes tile
> breaking or max-search handling even slightly is a potential change to
> behaviour in edge cases.
>

That is true. I think that the documentation for pathfinding will need to
mention the possibility that exact paths calculated aren't guaranteed to be
identical in different versions.

>
>
>>
>> I know vehicle pathfinding and pushing-npcs still need work, but those
>> are both hero-pathfinding issues, not NPC pathfinding issues.
>>
>> On Wed, Jul 12, 2017 at 10:35 PM, Ralph Versteegen <teeemcee at gmail.com>
>> wrote:
>>
>>> I trust you saw my reply on SS already.
>>> My two comments were that first, I'm not sure about a strict schedule,
>>> and second that we should also hold up releases for anything that could
>>> cause backcompat problems. Although as you say, we're generally good about
>>> keeping unfinished features disabled or out of sight. For example right now
>>> I would refuse a release until pathfinding is better nailed down.
>>>
>>> Also, doing release candidates is a good. So the actual release date is
>>> whenever the RC is ready.
>>>
>>> Although we've been really active the last 7 months or so, we have
>>> sometimes gone couple month without doing any substantial work on the
>>> engine. Sometimes no commits for over a month. At our current activity
>>> level a 3 month release cycle could even be too long, while other times
>>> there wouldn't anything to release.
>>> Lets take a look..
>>> http://tmc.castleparadox.com/ohr/gitstats/activity.html
>>>
>>> And what if we want to release in less than 3 months after the last
>>> release? Sometimes we might want to release while things are stable, before
>>> starting on something destabilising.
>>>
>>> I was hoping that we would release Dwimmercrafty this month, but
>>> actually with only two weeks left even a RC at the end of the month may be
>>> unlikely.
>>>
>>> I don't remember if we've ever set a schedule for a release "X months
>>> from now" rather than just near-term ones like "2 weeks from now". I think
>>> being able to see from months away when we want the next release to occur
>>> will be very helpful, and that we can manage to stick to it.
>>>
>>> On 13 July 2017 at 06:40, James Paige <Bob at hamsterrepublic.com> wrote:
>>>
>>>> I mentioned this once already in a thread on on slimesalad, but I
>>>> thought this might be a better place to discuss the idea.
>>>>
>>>> I was thinking we should switch to a quarterly stable release schedule,
>>>> rather than a whenever-we-feel-everything-im
>>>> portant-that-we-wanted-to-add-has-been-finished schedule.
>>>>
>>>> We could do an August/November/February/May rotation, where I would
>>>> branch and upload the stable release some day on the first full week of
>>>> each of those months.
>>>>
>>>> I can set up a calendar alert that goes to this mailing list to warn us
>>>> when the next release is 1 and 2 weeks away, so we have time to wrap up
>>>> last minute stuff.
>>>>
>>>> The only things that would block a release would be critical or
>>>> datalossy bugs, or other substantial problems that would make a new stable
>>>> release measurably less stable than the previous one.
>>>>
>>>> Half finished features would not be an excuse to delay a release,
>>>> because honestly, this whole program is a big beautiful muddy wad of
>>>> half-finished features, and it always has been and it always will be, and I
>>>> wouldn't have it any other way ;)
>>>>
>>>> I think we have actually been doing a pretty good job of keeping the
>>>> nightly wip versions safe and stable, keeping the unfinished stuff more or
>>>> less comfined to the "spam" menu, so I think this change is pretty low-risk.
>>>>
>>>> Thoughts?
>>>>
>>>> _______________________________________________
>>>> Ohrrpgce mailing list
>>>> ohrrpgce at lists.motherhamster.org
>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Ohrrpgce mailing list
>>> ohrrpgce at lists.motherhamster.org
>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>
>>>
>>
>> _______________________________________________
>> Ohrrpgce mailing list
>> ohrrpgce at lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>
>>
>
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20170713/89551a7b/attachment-0001.htm>