[Ohrrpgce] Quarterly Stable Releases?

[Michael Kidder]

Yeah I just realized bug fix centric are redundant in a "short lived
version" scenario, good point there.

On Sat, Jul 15, 2017 at 10:45 PM, Ralph Versteegen <teeemcee at gmail.com>
wrote:

>
>
> 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-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/20170716/762bb128/attachment-0001.htm>