Spring RTS Engine

I have tested on a totally flat map with (grey heightmap).

When given a move order, ground units wiggle about and have all kinds of micro-jitters, and make absurdly large turns, oversteering, etc. Try it yourself!

You'll observe units making hundreds of tiny 1-2 degree turns, first one way, then the other, back and forth, constantly, all the while just driving in goofy directions...while on a flat map! Where best path is obviously the one indicated by direction of green command-waypoint line!

Is there a tag or unit-move-type trick to bypass spring's A*?

unit def/mov def etc. we need info to help

High turnRate can make the unit turn around so fast that it turns too far, then it corrects, overcorrects to other side..wiggle wiggle.
Here was similar problem:
http://springrts.com/phpbb/posting.php? ... 14&t=32805

That is why in normal systems, speed is computated via a PID-Function.

http://en.wikipedia.org/wiki/PID_controller

Correctly configured, it determinates the smoothest speed and even applies small corrections.

Incorrectly it does the Huntingtons Dance of robots.

Dont know what ticks away at the heart of spring though.

Does it have to do with the size of the pathing grid? Looks stupid but makes sense with a grid.

1. yes it's cause of grid (a grid has only 4 directions)
2. spring optimize those 4 dirs to 8 (adding diagonal ones)
3. still 8 dirs are too less when a long line path is given
4. the problem is very similar to AntiAliasing

you are free to supply patches, entry points for the code are:
https://github.com/spring/spring/blob/d ... r.cpp#L290
https://github.com/spring/spring/blob/d ... r.cpp#L698

thoughts on this proposed solution? http://gamedev.stackexchange.com/a/81596

Apply a 'desired direction' force/vector, combine that with inertia/mass math, apply gravity according to slope, generate final motion, it can smooth things out.

MetalSucker wrote:Apply a 'desired direction' force/vector, combine that with inertia/mass math, apply gravity according to slope, generate final motion, it can smooth things out.

As long as you don't mind your units being hilariously unresponsive to changes in move order. I think the effect would be somewhat similar to all ground feeling like slippery ice.

this has annoyed me too for a while. Trying to micromanage the commander away from danger and he zigzags a bit instead of moving in a straight line over vacant flat terrain.

that proposed solution seems interesting, dunno how expensive it may be.

Maybe spring could use a similar modified pathfinding and allow the unit to move in a straight line towards its next target position from the player's point of view (ex: target of a move order), but only in some situations:
- waypoint is "near" enough
- no obstacles (or low density) or impassable terrain along the line from current position to target position

The inertia thing is awesome for gliders/fliers/high speed vehicles and it's not so taxing taken alone because it's basically averaging forces, very simple, I don't know how it works with a pathfinding algo since I've done it standalone for a silly car game, I don't think it would be good for walkers. The ice thing happens if you're computing everything linear.

raaar wrote:Maybe spring could use a similar modified pathfinding and allow the unit to move in a straight line towards its next target position from the player's point of view (ex: target of a move order), but only in some situations:
- waypoint is "near" enough
- no obstacles (or low density) or impassable terrain along the line from current position to target position

already happens ...

edit: or ... has only lua the possibility to do so ... kloot & googlefrog know more ...

http://springrts.com/mantis/view.php?id=4412
This ticket was made by xponen to request pathfinder-free move goals which can be set by lua. I recently implemented it in dev engine ZK for tactical AI but have not tested it much.

Units not moving directly towards their move order over short distances seems to be a common complaint. I think this is because the pathfinder is optimized for neatness instead of player experience. This is why it can change in ways which are technically better but not practical for common situations that players see. I have an ugly solution to this problem.

Units should have two pathfinders, the current pathfinder and a short ranged efficient pathfinder. If a unit is told to move to a location it should first check whether there is anything blocking a straight line path from itself to its goal. If it needs to turn to face its goal it should be able to figure out its turning circle (or have a unitdef setting so game devs can guide it) and take that into account. In short it should assume the terrain is completely flat and then calculate the best path to the goal (part of a circle then a straight line). Once it has this path it would check it for blocked sections. If there are no blocked sections it should use this path, if there is some blockage it would revert back to the current pathfinder.

The aim of this is to improve player experience when it comes to issuing short move orders. People like responsive units and a short move order means that the player wants the unit to move directly towards a point. Units that oversteer or move along 8 directions over short distances feel very unresponsive. It is hard to micro such units.

This may even result in a performance improvement as many move orders are given close to the unit.

I observed something similar i think.

Would be nice if it were improved sometime.