Path. about astar HOT 3 CLOSED

Sorry but, I'm really having trouble with understanding what problem you're trying to solve. FindPath only gives you the path that a unit should take. The server then moves that unit along the path.

Say the server executes FindPath() which results in a path with the following positions: {a, b, c, d, e} for unitA to get from a to e.

Then the server sends the following packets to the client:

1: unitA is now at a
2: unitA is now at b
3: unitA is now at c
4: unitA is now at d
5: unitA is now at e

Due to packet loss the client might receive:

1: unitA is now at a
2: unitA is now at b
3: LOST
4: unitA is now at d
5: unitA is now at e

Is this the problem you are describing?

In this case what you could do (but is very much outside of the scope of this path finding library). Is to have the client store the current position and the velocity vector of the unit. Something like

After packet 1: position of unitA is a, velocity = 0
After packet 2: position of unitA is b, velocity = (b -a)
Packet 3 is lost, but let's assume the position of unitA is its last know position plus its velocity vector so the position of unitA is b + (b - a).
After packet4: position of unitA is d 
After packet5: position of unitA is e

So the client predicts where the unit will be if the packet is lost, or late. Of course if the unit was about to take a turn the prediction is wrong, you can add some smoothing between the predicted position and the actual position to deal with that.

Does this help?

from astar.

Hey,

I'm sorry I don't fully understand the question. Is it correct that your problem is that clients are missing changes to the path finding graph because you sync it over UDP?

Most games use two streams of data. UDP for fast positional data which is overwritten by every new packet (things like, where is the player). And a TCP stream for important game data (things like state changes). In this case of adding or removing connection between two nodes on your path finding graph I would send those over the reliable (TCP) stream. As the changes aren't very often but it is very important that every client knows about them.

Of course I have now made a lot of assumptions about your game. But I hope this helps a bit. Feel free to expand on your problem so I can give a better answer :).

from astar.

Yo,

Sorry, maybe I didn't explain it so well.

Image: https://i.imgur.com/rtgvWxh.png

What I meant, is about a new implementation to FindPath (), adding some new "conditions" to limit the search for paths. I tried to explain about UDP, since UDP may have packet losses, in those losses, if I have it viable, I would like to be able to "recover" something close to the position of the lost packets. With that, FindPath could have the option of limiting to find from start to finish, with a sequence of a maximum of 6 steps and from a certain distance in each path.

Cheers.

from astar.