<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 13, 2017 at 5:55 PM, Ralph Versteegen <span dir="ltr"><<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On 14 July 2017 at 02:15, James Paige <span dir="ltr"><<a href="mailto:Bob@hamsterrepublic.com" target="_blank">Bob@hamsterrepublic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>I agree that potential backcompat problems also belongs in the category of reaons-to-delay-a-release<br><br></div>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.<br></div></div></blockquote><div><br></div></span><div>Sounds agreeable, and hopefully we'll have better discipline than we've had for the last decade!<br></div></div></div></div></blockquote><div><br></div><div>I have a good feeling about it this time :D<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div>I would like to still aim for an RC in the first week of August, if possible.<br></div></blockquote><div><br></div></span><div>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.<br></div></div></div></div></blockquote><div><br></div><div>Duly noted! Earlier rather than later!<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div class="gmail_extra"><br></div><div class="gmail_extra">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.<br><br></div><div class="gmail_extra">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?<br></div></div></div></div></div></div></blockquote><div><br></div></span><div>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.<br></div><div></div></div></div></div></blockquote><div><br></div><div>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.<br><br></div><div>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)<br></div><div><br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.<br></div></div></div></div></blockquote><div><br></div><div>Oh! Good catch. I'll fix that. Probably doesn't break anything being the way it is, but better to make it more correct.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>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.<br></div></div></div></div></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div><div class="h5"><div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div class="gmail_extra"><br></div><div class="gmail_extra">I know vehicle pathfinding and pushing-npcs still need work, but those are both hero-pathfinding issues, not NPC pathfinding issues.<br></div><div><div class="m_7782540340255752690m_-9097074179382597885h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 12, 2017 at 10:35 PM, Ralph Versteegen <span dir="ltr"><<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>I trust you saw my reply on SS already.<br></div><div>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.<br><br></div><div>Also, doing release candidates is a good. So the actual release date is whenever the RC is ready.<br></div><br></div>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.<br></div>Lets take a look..<br><a href="http://tmc.castleparadox.com/ohr/gitstats/activity.html" target="_blank">http://tmc.castleparadox.com/o<wbr>hr/gitstats/activity.html</a><br><br></div><div>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.<br></div><div><br></div>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.<br><div><br></div><div>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.<br></div><div><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_7782540340255752690m_-9097074179382597885m_2907592014669427610h5">On 13 July 2017 at 06:40, James Paige <span dir="ltr"><<a href="mailto:Bob@hamsterrepublic.com" target="_blank">Bob@hamsterrepublic.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="m_7782540340255752690m_-9097074179382597885m_2907592014669427610h5"><div dir="ltr"><div><div><div><div><div><div><div>I mentioned this once already in a thread on on slimesalad, but I thought this might be a better place to discuss the idea.<br><br></div>I was thinking we should switch to a quarterly stable release schedule, rather than a whenever-we-feel-everything-im<wbr>portant-that-we-wanted-to-add-<wbr>has-been-finished schedule.<br><br></div>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.<br><br></div>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.<br><br></div>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.<br><br></div>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 ;)<br><br></div>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.<br><br></div>Thoughts?<br></div>
<br></div></div>______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org" target="_blank">ohrrpgce@lists.motherhamster.o<wbr>rg</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.org<wbr>/listinfo.cgi/ohrrpgce-motherh<wbr>amster.org</a><br>
<br></blockquote></div><br></div></div></div></div></div></div></div>
<br>______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org" target="_blank">ohrrpgce@lists.motherhamster.o<wbr>rg</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.org<wbr>/listinfo.cgi/ohrrpgce-motherh<wbr>amster.org</a><br>
<br></blockquote></div><br></div></div></div></div></div></div></div></div>
<br>______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org" target="_blank">ohrrpgce@lists.motherhamster.o<wbr>rg</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.org<wbr>/listinfo.cgi/ohrrpgce-motherh<wbr>amster.org</a><br>
<br></blockquote></div></div></div><br></div></div>
<br>______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org">ohrrpgce@lists.motherhamster.<wbr>org</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.<wbr>org/listinfo.cgi/ohrrpgce-<wbr>motherhamster.org</a><br>
<br></blockquote></div><br></div></div>