Check out new QTPFS

[sprunk]

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.

[sprunk]

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.

[GoogleFrog]

That doesn't sound like a huge issue. I observed the following as the most important features of movement, for practical purposes.

• The first few seconds of movement should look optimal. This is what players see directly after ordering a move order, after all. It also encompasses "the entire movement should look optimal" for short move orders. This is the problem with the old zig zag movement. Note that ignoring speed modifiers due to slopes tends to look more optimal than not.
• The unit has to arrive at its destination, or a "reasonable" fallback for an unreachable destination. Searching for units that you thought you sent somewhere is a part of the RTS experience, especially for new players. Finding out that they became permanently stuck along the way is the other big generator of the "pathing sucks" feeling. Note that this includes multiple queued commands, and things like making a line of buildings.

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.

[GoogleFrog]

105-2031

These units are stuck here forever.

[GoogleFrog]

These units were told to go to the left hill and are stuck on the right forever.

[GoogleFrog]

They are even stuck with raw move.

[GoogleFrog]

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.

[GoogleFrog]

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.