[Ohrrpgce] Quarterly Stable Releases?

Sat Jul 15 20:45:28 PDT 2017

On 15 July 2017 at 21:59, Michael Kidder <mkidder at gmail.com> wrote:

> I'm not a developer on this project but something more of a cadence would
> help. I've noticed a lot of people think the engine is actually in
> dead-development even though it's actively developed, since only the
> technically inclined or curious are going to be subscribed to this mailing
> list.
>

Right; Callipygous was the worst; any project that doesn't release or post
any news on its website for 3 years is obviously dead!

It would be nice to update the News page more regularly, but I don't know
what to put there. RC announcements too, maybe. There's not much happening
on the wiki to report.

>
> A 3 month cadence would sound pretty good.. you could even alternate it as
> "feature release" "bugsmash release" so in-the-oven stuff isn't perpetually
> blocking. That's the way I like doing things. (I'm definitely not a fan of
> the new "sprint/agile" methodology.. just feels like perpetual crunch)
>
> This also might reduce stress since you wouldn't have to spend a year
> getting to RC, then release it, and then rush to find that weird bug and
> release a + version 2 weeks later. In a 3 month cadence, "bad versions"
> wouldn't live long anyway. You'd just point people that want a quickfix to
> the nightly version while awaiting the next release.
>

I expect we'll still do extra unscheduled bugfix releases, and there might
even be more of them per year than before, because changes will be released
in stable releases after a shorter lag (less testing) than before. With
frequent releases there's no need for regular bugfix releases.

>
> On Sat, Jul 15, 2017 at 4:32 PM, 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
>>
>>
>>> -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-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/648f7519/attachment-0001.htm>