[Ohrrpgce] Quarterly Stable Releases?

James Paige Bob at hamsterrepublic.com
Tue Jul 18 12:07:30 PDT 2017 

On Tue, Jul 18, 2017 at 9:55 AM, Ralph Versteegen <teeemcee at gmail.com>
wrote:

>
>
> On 17 July 2017 at 10:16, James Paige <Bob at hamsterrepublic.com> wrote:
>
>>
>>
>> On Sun, Jul 16, 2017 at 6:22 PM, Ralph Versteegen <teeemcee at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On 16 July 2017 at 15:15, James Paige <Bob at hamsterrepublic.com> wrote:
>>>
>>>>
>>>>
>>>> On Sat, Jul 15, 2017 at 8:28 PM, Ralph Versteegen <teeemcee at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>
>>>> Yeah, that is good. holding down F12 is 100% obsoleted by CTRL+F12
>>>> animated gifs, no need to keep it around.
>>>>
>>>>
>>>>
>>>>> -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.
>>>>>
>>>>
>>>> Oh, yeah, now I understand.
>>>>
>>>> Okay, I can take care of 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.
>>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>> 1000 seems pretty good, I am okay with it.
>>>> That was another limit I was thinking about being able to set on and
>>>> npc-by-npc basis
>>>>
>>>>
>>>>>
>>>>> 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?
>>>>>
>>>>
>>>> I think colliding with the hero doesn't stop them from trying to
>>>> complete the movement. Colliding with walls and other npcs makes them give
>>>> up.
>>>>
>>>> I'll have to check what dumb chase ncps do.
>>>>
>>>> Probably it would be more correct for pathfinding npcs to stop
>>>> animating when they reach the hero, just like when they hit other
>>>> obstructions.
>>>>
>>>>
>>>>>
>>>>> 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?
>>>>>
>>>>
>>>> Oh... Hmmm. I don't know.
>>>>
>>>> I think the current behavior is okay-- and if we come up with some
>>>> other alternatives, we can add a choice of "Consolation tile algorithm"
>>>>
>>>
>>> Pathing to a 'reasonable' tile instead of the absolute-closest-to-target
>>> should also reduce the behaviour of crowds of slimes dithering between two
>>> extremes. The problem is that the consolation behaviour is sort of
>>> inconsistent with the behaviour when there is a path: it doesn't care at
>>> all about how long the path is (aside from as tie-break), even though it's
>>> meant to be an algorithm to find the shortest path! Well, to be fair,
>>> exactly the same thing would happen if you're currently 2 tiles away
>>> because an NPC is in the way and you can go around a long way to get within
>>> 1 tile.
>>> Actually, both cases could be handled the same way: use "path length +
>>> closest achievable distance to goal * 10" as the cost.
>>>
>>
>> So if I understand correctly, in the consolation tile code, instead of
>> using best_closed_node->p as the consolation tile, I should instead do one
>> more sort of the closedlist based on "path length + closest achievable
>> distance to goal * 10" where closest achievable distance from goal is the
>> number of tiles between best_closed_node->p and the goal, right?
>>
>
> The closed list isn't explicitly stored anymore. If you want to change
> which node gets picked as consolation, you need to change
> closed_node_compare().
>
> Also note that while closed_node_compare currently uses cost_after_squared
> (aka dist_squared), you can't mix the squared distance with the cost_before
> distance without doing a squareroot, which would be way too slow. So just
> switch to cost_after. There's no real need to use distance squared; that's
> more important as a tiebreak when comparing open nodes to ensure diagonal
> paths are taken.
>
>
That makes sense.


> Oh! I just noticed a bug: the best consolation tile isn't picked while
> taking map wrapping into account. Which means an NPC might actually path to
> the furthest away tile instead of the nearest! cost_after and dist_squared
> are meant to be nearly the same, except one involves squares. (Actually,
> they're so similar that it would be simpler and faster to compute them at
> the same time)
> Ok, so I went and did that. And then tried out consolation tile picking in
> the a-star.rpg wrapping map using F11. And to my horror, when I walked into
> a wall, the NPC pathed to the furtherest away tile from the hero, every
> time! the very bug I thought I just fixed! It turns out that there was a
> second bug.
>
> Anyway after trying it out, I definitely think that "being lazy" should be
> a pathfinding behavioural option (i.e not pathing a long distance just to
> get slightly closer). And using dist_squared only makes it worse, since the
> consolation tile is often not closer, but just "more diagonal"! People
> typically aren't going to want this.
>

I haven't figured out the implementation, but I know the labelling now ;)

Get Close to Unreachable Targets: Lazy
Get Close to Unreachable Targets: Dogged



>
>>
>>
>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>> -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.
>>>>>
>>>>
>>>> Good idea!
>>>>
>>>> I could actually have 2 options,
>>>>
>>>> Pathfind X steps at a time if path is longer than Y steps
>>>>
>>>
>>> This is starting to sound like far too many settings! I don't want to
>>> overload people with technical details. The settings should aim to be for
>>> the behaviour of the NPCs, not how that is accomplished; I'd rather err on
>>> the side of not exposing parameters that aren't very useful. Useful
>>> behaviour settings include for example bunching behaviour (whether to bunch
>>> up on one side of a bottle neck, or split up and try to surround the player
>>> from every side) and how hard to search for a path (max_search). Pathing X
>>> steps at a time was meant to be an optimisation which changes the behaviour
>>> as little as possible. The only visible effect it should have is how often
>>> an NPC changes direction if a path opens/closes. I'm not sure that matters.
>>>
>>
>> Yeah, perhaps "Pathfind X steps at a time if path is longer than Y steps"
>> doesn't make a good user-exposed option. I could implement it with some
>> guesses at good values (maybe "Pathfind 4 steps at a time if path is longer
>> than 40 steps")
>>
>
> X=2 already halves the amount of computation, and it's diminishing returns
> from there. *shrug*
>

Noted


>
>> If anybody finds a good reason they need some other behavior, we can add
>> an option to override that later.
>>
>>>
>>>
>>> When pathing X steps at a time, we could recompute the path if an
>>> unexpected obstacle is hit OR the map changes OR the target moves, where
>>> "the map changes" can include the movement of previously obstructing NPCs.
>>> For example we could record a list of NPCs encountered (probably limited to
>>> nearby ones) and their positions in a vector and pass it back. Checking
>>> whether they've moved is hugely cheaper than recomputing the path. However
>>> it makes it likely that the path will be thrown away. Which means this is a
>>> lot of work for an optimisation that's going to provide no speed up at all
>>> when things go wrong.
>>>
>>>
>> I was already planning to recompute if an unexpected obstacle is hit, or
>> if the target moves.
>>
>> checking if a previously obstructing npc has moved sounds like more
>> trouble than it is worth, I don't think I will attempt that.
>>
>
> It certainly is a lot of trouble. (Reminds me that I once spent a month
> working an incredibly overcomplicated optimised A*  which precomputed all
> deadends and the paths between them... and deadends can be inside other
> deadends, etc. I learnt my lesson!)
>
> A very simple but maybe not too useful alternative is for pathfinding to
> record how far it was to the nearest obstructing NPC, and then reduce X to
> no more than this. This would force it to recompute the path each step when
> circling around NPCs which might have already moved out of the way, causing
> ''laggy dodging".
>
>>
>>
>>
>>
>>> Just occurred to me that tweaking pathfinding will break replays. Which
>>> were always going to break between different engine versions anyway, but I
>>> was hoping they would break infrequently.
>>> (But we don't want the extra shackles of trying to keep replays working!)
>>>
>>
>> Yeah, I can live with that. For me, the most important feature of replays
>> is being able to (A) detect unplanned changes between two subsequent
>> versions, and (B) visualize the consequences of planned changes between two
>> versions.
>>
>
> I'm actually surprised by those reasons. But that will definitely be
> useful.
>
>>
>> I am already resigned to the fact that I will need to re-create new
>> recordings frequently (another reason I love the idea of having robust
>> save/load supporting replays that I can record by default every time I am
>> playing just for fun)
>>
>>
>>>
>>> I think a lot of the settings ought to be per-map rather than per-NPC,
>>> because how you adjust them would depend on the complexity of pathing on
>>> that map.
>>>
>>
>> Possibly so. For the "NPC pathfinding obstruction rules" that I am
>> working on right now, I should make a per-map default and an per-npc
>> override.
>>
>> It isn't that much work to do both, since general map data and npc def
>> data are both relatively painless to extend.
>>
>
> I see you prefer flexibility over "worse is better" simplicity!
>

*I am but mad north-north-west. When the wind is southerly, I know a hawk
from a handsaw. *;)


>
>>
>>
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> 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-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/20170718/bd6dc707/attachment-0001.htm>

More information about the Ohrrpgce mailing list