[Ohrrpgce] Quarterly Stable Releases?

James Paige Bob at hamsterrepublic.com
Sat Jul 15 14:32:27 PDT 2017 

On Sat, Jul 15, 2017 at 7:48 AM, Ralph Versteegen <teeemcee at gmail.com>
wrote:

>
>
> On 13 July 2017 at 22:14, James Paige <Bob at hamsterrepublic.com> wrote:
>
>>
>>
>> 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!
>>
>
> Well, this isn't a RC yet, is it? Might have be a teeny bit early since
> there's a bunch of stuff to do. I'm hoping I'll be free within a week to do
> significant OHR work. I'm trying to finish my thesis right now.
>
>
No, not yet, just soon-ish.

And don't let this distract you from your thesis! We are officially adding
Thesises to the list of valid reasons to delay a release ;)


> I've trimmed down my TODO list for Dwimmercrafty. Here's what's left,
> including a bunch of nearly-finished features which I expect to be able to
> finish off in a couple days:
>
> Serious bugs:
> -fix broken frameskipping dropping frames as you get near 60fps. Causes
> Mac to run at 30fps.
>  And bad fps setting interaction with vsync, should tweak dowait a little
> (still true?). No problem in fullscreen
> -"! Unsupported default tile passability format" on e.g. POWERXE.RPG week
> 383 map 107 Botsmir Forest
>  Also happens in the OHRCEtutorial2017.rpg file Lisa sent 21/6/17
>  Seems to indicate data loss?
>

I if all of those existed in callipygous, they don't need to be
dwimmercraftly blockers-- but yes, they do sound very important


> -fridge racer graphics completely broken when compiled with scons
> debug=3!!!
>

What is our default debug level for releases?


> -update innosetup for data/ (.exe installer doesn't install correct)
>

If you haven't started already, I can that that one.


> -fix new zone corruption bug (and finish zone testcases)
> -some serious Ctrl-F12 bug on windows. With gifsicle present, lots of
> cmd.exe windows
>  pop up and F12 remains stuck until interact with window. gfx_sdl.
> --Problem holding down F12 for a second: "Saved  and 60 more" Only happens
> first time?
> -merge forgotten elemental_fix dataloss bugfix
> -fix various gdebug loadrecord errors (may cause corruption due to now
> refusing to read?)
> --in particular at end of file when importing scripts
>
> Other bugs:
> -finish fixing total joystick brokenness
> -mac fullscreen zoom selection wonkiness (WillyElectrix)
>

Do we know if fullscreen has ever worked correct on Mac? I can't actually
remember if I ever tested it.


> -finish/merge fix for the glitched text colour in the slice collection
> editor
> -fix find_file_portably to disallow varous filename characters
> --more checks on filenames in rungame(), and check both .rpg and .rpgdir
>
> Other:
> -set "Touch textboxes" on by default.
>

I'll do that one, it has been on my own to-do list a few weeks


> -make suspendboxadvance stop choicebox controls too
>

That seems strange to me. What is the reason for that one?


> -pref bitset to close textbox with esc
>

I can do that one.


> -finalise a* limits and npc obstr handling
>

I'll definitely finalize the ability to support different modes of
obstruction handling, but we don't have to finish every mode, since we can
add other modes later.


> -whatsnew: mention Custom mouse improvements
> -whatsnew: mention NPC pathfinding options
> -whatsnew: mention FreeBSD
> -whatsnew: zzo38's attack options?
>

Probably best to leave those unmentioned until they have some gui hooked up
to them


> -find out why windows builds now much larger
> -upload hsdecmpl and chgpal
>
> Nearly finished features:
> -merge git branches:
> --browse32
> --bmp import stuff
> --better minimap
> --mouse wheel script commands
> --better unicode input
> --script warnings/plotdict improvements
> --ui colour constants
> ---change various script commands to allow them
> --new equip merge formula
> --scrolling in show_help and multiline editor
>
>
>
>>
>>
>>>
>>>
>>>>
>>>> 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)
>>
>
> Ah. I wasn't sure whether those other modes would be useful. Having
> branches in the code to support worse ways to do pathfinding seems a lot
> like backcompat cruft.
>

Well, I have been reading various tutorials about A*, and one thing I have
learned is that there definitely is no possible one-size-fits-all ideal way
to handle obstruction from moving units. Most of what I have read
recommends one or the other extreme, hence the first two modes.

For the smarter mode that considers how long a unit has been stationary,
there is a lot of room for fine tuning. At the bare minimum, I think that
one is going to require at least one more configuration option. I expect
that this mode won't be ready before dwimmercrafty, but I'll definitely get
the other two implemented.

I like the way the current mode obstructs, and I think it will be a good
default, even if it isn't right for every purpose.


> But I perhaps sometimes you want your little slimes to run back and forth
> helplessly confused!
> Another potential mode was to be smart about not throwing away and
> recomputing paths every step (which I would have hoped would be the
> default).
>

Oh! Thank you for reminding me.

I think it will be called "Pathfind steps at a time:" and default to 1.

The NPC instance will keep a small vector of planned steps and use them
before it pathfinds again. if it collides with anything, it can throw them
away and try again

I'll also need an argument for "pathfind npc to" that sets this.

This sounds fun, hopefully I'll have time to do it soon.


>
>
>> 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.
>>
>
> I actually suspected that the previous wrong way would look better, since
> if you have a row of NPCs stuck after each other, each would begin to move
> after the one in front has moved after a step. In theory. Actually, it's
> hard to see the difference.
>

Agreed. It is a pretty subtle difference


>
>
>>
>>
>>
>>> 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-motherh
>>>>>> amster.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
>>>
>>>
>>
>> _______________________________________________
>> 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/20170715/4f71e0ac/attachment-0001.htm>

More information about the Ohrrpgce mailing list