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.
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. On Sat, Jul 15, 2017 at 4:32 PM, James Paige <b...@hamsterrepublic.com> wrote: > > > On Sat, Jul 15, 2017 at 7:48 AM, Ralph Versteegen <teeem...@gmail.com> > wrote: > >> >> >> On 13 July 2017 at 22:14, James Paige <b...@hamsterrepublic.com> wrote: >> >>> >>> >>> On Thu, Jul 13, 2017 at 5:55 PM, Ralph Versteegen <teeem...@gmail.com> >>> wrote: >>> >>>> >>>> >>>> On 14 July 2017 at 02:15, James Paige <b...@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 <teeem...@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 <b...@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@lists.motherhamster.org >>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherh >>>>>>> amster.org >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Ohrrpgce mailing list >>>>>> ohrrpgce@lists.motherhamster.org >>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherh >>>>>> amster.org >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Ohrrpgce mailing list >>>>> ohrrpgce@lists.motherhamster.org >>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Ohrrpgce mailing list >>>> ohrrpgce@lists.motherhamster.org >>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >>>> >>>> >>> >>> _______________________________________________ >>> Ohrrpgce mailing list >>> ohrrpgce@lists.motherhamster.org >>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >>> >>> >> >> _______________________________________________ >> Ohrrpgce mailing list >> ohrrpgce@lists.motherhamster.org >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >> >> > > _______________________________________________ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > >
_______________________________________________ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org