Open sprunk opened 1 year ago
I've been told about a potential pain point. Apparently QTPFS only checks raw move once, at start or an order, and never updates once obstacles are moved around so in the example above it won't ever raw move (because A-B is blocked). ZK Lua raw move will poll periodically and thus start raw-moving sometime just past X. I'm unsure how important this is because the short "combat micro" style movement should still produce raw moves. It may be something to keep in mind though.
That doesn't sound like a huge issue. I observed the following as the most important features of movement, for practical purposes.
Not being noticeably and repeatable sub-optimal after the first few seconds of movement is good too. There are of course sufficiently bad pathfinders that would be rejected on this basis. But a small issue is unlikely to be a problem.
105-2031
These units are stuck here forever.
These units were told to go to the left hill and are stuck on the right forever.
They are even stuck with raw move.
This happens forever. Also happens with default pathfinder.
Also with 1831. Nobody has complained so sending units into blatantly blocked areas is probably fine. I'll still add a fix gadget-side.
I heard QTPFS doesn't consider going down a steep ramp to have a low cost. It seems like the default pathfinder doesn't either. I tried contriving a situation where this mattered (with ZK pathing parameters) and couldn't do it.
Claims to be much improved (not just compared to previous implementation to QTPFS but also to default PF). Don't forget to check what happens without gameside raw move.
https://github.com/beyond-all-reason/spring/releases/tag/spring_bar_%7BBAR105%7D105.1.1-2031-gd4526bf or later.
https://beyond-all-reason.github.io/spring/changelogs/running-changelog#qtpfs for the list of modrules to configure.