[Ohrrpgce] Quarterly Stable Releases?

[Ralph Versteegen]

On 15 July 2017 at 16:32, James Paige <Bob at hamsterrepublic.com> wrote:

>
>
> 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
>

All the bugs I've listed are new in the last half a year or so. (In fact I
probably introduced all of them!)
I think that the default wall error message was introduced at the same time
that I changed loadrecord's handling of partially missing records. I see
that what I changed was what loadrecord returns in that case (as well as
adding an error message). I haven't investigated this yet.


>
>
>> -fridge racer graphics completely broken when compiled with scons
>> debug=3!!!
>>
>
> What is our default debug level for releases?
>
debug=0. But I have learnt from experience that unexpected bugs are often
indicative of bigger underlying problems that haven't been noticed yet. A
bug that only appears with debug=3 is probably a Heisenbug, and Heisenbugs
never really go away, they just hide from view!

>
>
>> -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?
>>
>
My plan to fix this was just to remove the ability to take multiple
screenshots by holding down F12. It was such a waste of time to implement
that.
Still, cmd.exe windows shouldn't be popping up at all; probably I'm
spawning gifsicle in the wrong way. Obviously not a blocker.


> -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.
>

Yes, it always used to work correctly. I still remember getting it working
back in 2010.
I think this is a combination of later OSX versions working a bit
differently, the engine now attempting to resize the window when entering
the game,  the way gfx_sdl selects zoom being bad, and maybe my recent
changes.

>
>
>> -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?
>

suspendboxadvance stops the use key from selecting one of the choices, but
doesn't block the up/down/etc keys, which is rather weird. Especially if
there's also a menu up.

>
>
>> -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.
>

Having an option for different modes could be added any time, so that's not
a blocker anyway.

"Finalise limits" referred to whether we want to make max_search default to
more than 1000 now that it's faster.

I expected that there would be various experiments or tweaks we might want
to do.

This reminds me of an example. In the swarm maps in a-star.rpg, if you're
surrounded by slimes only the immediately adjacent ones animate, walking
into you. Why is that? How do 'dumb' Chase NPCs behave?

Another thing. I was wondering whether the way 'consolidation' tile picked
is the right way to go. Currently it picks a tile that's the closest to the
target. But maybe it should take into account how long the path to that
tile is. E.g. if you're currently 4 tiles from the destination, but could
go around a long way to get within 3 tiles, should you move? Maybe it
depends on whether max_search was hit?

>
>
>> -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
>

Yes, I agree. Unless they go in the 'Stuff for Developers'

>
>

>
>> -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.
>

Yes, it will definitely want tuning, so best to have time to do that.

>
> 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.
>

You may want to force the steps to 1 if the path is short (and therefore
cheap to compute anyway), to keep it optimal.
Having done that, it may be feasible to default to 2-4 instead.

>
>
>>
>>
>>> 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-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/32d74ecd/attachment-0001.htm>