Testing Pathing in 82.6 bug fix (pre)release

[Godde]

High maxVelocity and low turnRate seems to be the issues that cause problem 3 in the new spring engine.

I explain and analyze pathing in spring engine 82.6 compared to spring engine 82.5.1.

My terminology is limited and my analysis is mostly based on observation.

1. First I differentiate the pathing based on terrain and features/units.
Picture taken in 82.6

Analysis: Only the center of the unit is consider to passable and impassable terrain no matter how big the FootPrint is(according to my testing). Land units are rarely so big that their turret ends up inside a mountain.
1a. Problem: Ships turrets ends up inside a cliff. Increasing MinWaterDeepth is hardly a good solution since it would make large ships much less useful and if the cliffs are steep it doesn't really make any difference.


1b. Problem: Ships get stuck on the shore.
Picture from 82.6

Analysis: Propably because they were pushed by other units. Usually you can get them out by FPSing them. No ship have gotten stuck so bad that I can't get it free by FPSing it in 82.6 yet.


2. Problem in 82.5: Units with slow/low turnRate and high speed will go zigzag and sometimes even in circles.

Analysis: The pathing is only made once when the move command is given. If the unit is already moving and heading another way than the new move command it will be going at max speed turning slowly towards the pathing "line". As it reaches the pathing "line" it then have to turn again to point at the next waypoint in the pathing line.

[Godde]

2a. Analysis of the solution in 82.6: The faster the unit goes, the further away from the unit the waypoints are selected:
82.5________________________________82.6

Mantis bugtracker:http://springrts.com/mantis/view.php?id=2072


3. Problem in 82.6:

Analysis: Units head for the next waypoints. As their speed builds up their waypoints get further and further away from them. As they get close to the first wall, their next waypoint suddenly changes to the one behind the wall and instead of driving to the edge of the wall they go straight into it. Their speed is preserved when they are going against the wall so they won't update their pathing until the next default scheduled one. When the next scheduled pathing is made their speed slows down but it builds up again before they get time to go around the egde of the wall.


3a. Same situation in 82.5:

[bobthedinosaur]

Yeah. But it's free...

[Johannes]

These are all turninplace=0?

Yeah. But it's free...

It also used to be good...

[nightcold]

a bit off topic...

can i ask where the models are from???(s44???)is godde finally using his game insites 2 make a mod???

[Gota]

Im surprised to see s44 uses such imprecise hitshapes.

[Godde]

These are all turninplace=0?

All of thoose units are turninplace=0 but I have tested to change it to 1 or remove it entirely and they still don't do well. It is propably because these units in s44 have high maxVelocity and low turnRate.

This fix "Mantis bugtracker:http://springrts.com/mantis/view.php?id=2072" is propably the cause of problem 3.

[Johannes]

This fix "Mantis bugtracker:http://springrts.com/mantis/view.php?id=2072" is propably the cause of problem 3.

Just a note, that unlike the bug report said the snaking/twitching was problem not only for turninplace=0 units also happened to units with =1, it was just less severe for them.

[Argh]

For long thin objects, the footprint code could be changed to use a bitmap that was rotated along with the object, instead of a square, which would result in a fairly good solution for detection of blocking objects. The problem atm is that all footprints are static and never use the rotation of the object when determining collisions.

As for turning, yes, it's working very poorly atm.

The heatmap seems to also include the Unit's own former movements (which it should ignore) and then tries to path around itself, leading to various bad scenarios. Units that could use reverse movement are currently totally broken because of this.

[Godde]

Heatmapping is disabled for units in Spring 1944.
I have even removed turnInPlace=0 and maxReverseVelocity but it doesn't make alot of difference.
Only maxVelocity and turnRate seems to matter on subject 3.

It is propably this fix that broke it:
Mantis bugtracker:http://springrts.com/mantis/view.php?id=2072

[Forboding Angel]

Interestingly enough, everything in evo works normally except occasionally units will get stuck at the edges of hills.

[Godde]

Interestingly enough, everything in evo works normally except occasionally units will get stuck at the edges of hills.

That would propably be the same thing as problem 3.
Did you expect any other problems that were mentioned in this thread?

[ginekolog]

I found pahing problem in this new ver, tanks stuck in mountains. Before it worked well.

To reproduce, try to move tanks(leverler, cons) from germany to ukraine in neuropev7 .

GL.

[Johannes]

Interestingly enough, everything in evo works normally except occasionally units will get stuck at the edges of hills.

No, it's just the same as in other games - units get stuck, push each other stupidly, choose very inefficient routes. Even if other games are worse because they have higher speed/turnrate ratio doesn't make it normal, calling it that is just misleading. If you really think that's normal, or don't care, maybe you're just not very qualified to comment on pathfinding?

Another issue, but pretty minor compared to other stuff. If unit is pushed aside by another, while on repeat, and gets queued a new order it visibly retains the waypoint it got from the pushing but actually doesn't ever go to it. http://replays.adune.nl/?2818

[hoijui]

please see:
http://springrts.com/phpbb/viewtopic.ph ... 08#p454708
you may want to do further tests with this.