[Spoiler]

That hill has always been bad. I think its ramp is too thin and close to the map edge for low resolution pathfinding to find it. Or perhaps the right side of the cliff is too thin.

It is an unfortunate bug but ultimately, in competitive play, people should pay more attention to their units. Pathfinding with complicated terrain is a thing to take into account.

Yes but ZK itself cannot do much about it. Pathing is an engine thing.

Problems with my super-steep-narrow-edge-of-map hills? Must be user error

lol, spring's pathfinder is an overcomplicated piece of trash that wastes tremendous amounts of space (and time) storing and loading useless cached costs. Honestly it should be burned in a fire, but that requires someone who both knows how to C++ and who knows why the current implementation is wrong.

The first reason is that the costs are invalidated rapidly once the game actually starts. Buildings, blocking features, features added by featureplacer, etc all invalidate the cached costs since those only account for map terrain.

The second reason is that the cost calculation is really only something like

quote: 10 * (slope/maxSlope)

which is extremely trivial to calculate. Accessing the slopemap or a cached cost array on the other hand typically costs about 200 cycles because the array access is essentially random and not amenable to hardware prefetching. Accessing the slopemap plus a map representing crush resistance of features and such is still 200 cycles since the separate accesses can be performed out-of-order, except that it takes less memory than storing that plus a bunch of cached cost arrays (that will be shortly invalid anyway).

There's also a third reason why cached costs are stupid, which is that it's only caching based on movedefs when pathing is also affected by crush strength (which in turn mainly affects features which are not cacheable). Even if you could cache for both crush strength and move defs the memory cost would become untenable and defeat the purpose.

It's technically possible to cache entire paths from commonly-used points on a map, but that also assumes that the map is static and that it's actually possible to choose sensible points to cache paths to and from, neither of which applies to spring. If spring sorted units that needed pathing calculations by unit type it would technically be possible to cache path costs on a per-unit-type basis, for one frame only, and then erase it when a new unit type is encountered, but that's all the caching that really makes any sense.

I guess I should mention that it's also stupid to use a coarser grid for long-distance pathing, since that can lead to incorrect paths, as in this case, or no path at all even if a valid path exists (which btw happens on stronghold). I've read some things that hint that it might be possible to speed up the calculation of similar paths by calculating them together, but I haven't actually read any papers explaining how that works so I don't know if that's even true or not, but if it is then that would be a more sensible way to save cycles.

EDIT: Something relevant to this bug though, is that the lower-res slopemaps it's using might be bicubic interpolated rather than taking the max slope value in a given cell. This has similar tradeoffs though; bicubic gives incorrect paths, max value may not find valid paths. Lower-res slopemaps would actually be more appropriate for pathing for large units anyway, rather than for long-distance pathing.

EDIT: No, there are no good ways of speeding up pathing for similar paths. Plain-old A* is still king.

Check out 0 AD pathing if you want to see something cringeworthy.

hokomoko I don't C++, and I'm running windows. AFAIK compiling spring on windows produces inconsistent results and is not valid for testing. I can only reasonably fix half of those problems (and A* in C++ is still a PITA due to lack of predefined data structures such as priority queues). :P

quote: Check out 0 AD and its pathing too. Java pathing ftw.

- 0ad pathing does not use Java
- no components of 0ad use Java
- 0ad pathing uses c++
- 0ad pathing isn't all that bad
- 0ad pathing uses multilevel pathing like Spring

no idea about code blocks but follow this to the letter:
https://springrts.com/wiki/Building_Spring_on_Windows#Compiling_with_MinGW

if you hit issues, message me in the lobby.