-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Path. #36
Comments
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 :). |
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. |
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: Then the server sends the following packets to the client:
Due to packet loss the client might receive:
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
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? |
Hi,
Is there any possibility that I could find missing paths by using some condition?
For example, I want to use the grid for an online game, as I am working with udp, so in this case there may be packet loss and I am also using interpolations. The grid can have walls and so on, so sometimes the interpolation can end up taking a path in which it is blocked, so my idea is to try to "recover" by calculating some points from packet losses. As each movement works with sequences or timestamp, then the idea of filling in, would be being able to limit the searches of the path, to find such a path, it needs to go through amount of time or sequence. He does not need to find the slowest or the fastest, but the necessary condition.
Thanks,
Regards.
The text was updated successfully, but these errors were encountered: