Path subdivision in unsynced

[NeonStorm]

Everybody knows that the pathfinder is performance heavy.

If some other troll makes 1000 small units, why do you have to calculate everything?

The idea is to capture the player's move commands run pathfinder locally and send way-points in a lazy way to synced.

+1 The path-subdivision could reduce the performance impact in synced, thus for all enemy units.
-> And makes you "responsible" for your own lagging / unable to lag others before you lag.

+1 That would even allow user to customize pathfinder quality for themselves.

I don't want to get into the pathfinder stuff if others are already familiar and motivated to do it (even if only for themselves).

[Forboding Angel]

Opens it up to exploitation.

What is to keep the player from intercepting it on his side, and making those small units path over cliffs, etc etc etc.

[gajop]

You can't really make the pathfinder unsynced without changing much of the code.
One might as well make the whole Spring unsynced then :)

[SinbadEV]

I don't see why the pathfinder can't be unsynced... only the move order and path itself needs to be synced... so instead of finding the optimal path identically on every instance you* would verify the validity of the path chosen. (more network traffic, less local processing)

*(not me... I don't know what I'm talking about, just trying to think outside the box)

[gajop]

I don't see why the pathfinder can't be unsynced... only the move order and path itself needs to be synced... so instead of finding the optimal path identically on every instance you* would verify the validity of the path chosen. (more network traffic, less local processing)

*(not me... I don't know what I'm talking about, just trying to think outside the box)

Verifying the validity of a path is obviously faster than finding the path, I can agree with that.

But you would need to calculate the path for your move order, and sync it via network, and that's going to be network heavy.

If you have multiple units trying to find a path, that will create slightly more complicated paths than in the case with one unit.

More importantly, paths need to be recalculated every once in a while when something gets built/destroyed or terrain gets changed. That may create new better paths or make the current one unusable.

[NeonStorm]

But you would need to calculate the path for your move order, and sync it via network, and that's going to be network heavy.

You only have to set a path length+width, length*width = 250000 elmos*elmos
200 width -> 1250 lenght
400 width -> 625 lenght
1000 width -> 1000 length or break formation/swarm if width too large.

Then assign units to a path.

A gadget path can replace the custom order with a move order so that the current pathfinder understands this and very few bandwidth is required.

Widgets could send insert waypoints in a lazy way so that cancel long move orders don't waste bandwidth.

And don't subdivide on almost flat terrain.

[zerver]

Like already said opens up for exploits and the network traffic would go *boom*. Please help test Spring MT which runs the pathfinder on a separate CPU core. http://springrts.com/wiki/Spring_MT

[knorke]

wrt exploits: if only pathfinding is unsynced by pathfollowing/physics remain synced exploits should not be possible. A cheater might try to make the units path over impassable terrain but they would simply get stuck.

Machines:Wired for War is a game that might have worked like this. After giving a move order the units took a few moments to start moving and paused at every waypoint. (in SP too so it was not network lag) This delay was noticeable shorter on faster computers.
iirc there was a mission where enemy units travel a long way across the map to attack your base. On fast computer, the enemies arrived much earlier.

[NeonStorm]

You can already do this with widgets, but that causes some traffic.

Only a gadget can reduce the traffic by compressing multiple move orders into one.

But I think formations cause a lot more traffic with their many move orders.

It would only buff the speed if the pathfinder
* can be set to ignore the possibility of diversions
* returns a upcoming pathing fail instead, so that the widget can calculate a new path based on new high-map information before the unit stops in front of the next wall.