Quote:
I send the move request. Once the server responds that movement has begun, I calculate the time required to reach the destination.
It's self explanatory, it won't fail even with lag.Quote:
Wouldn't it fail to reach its destination if you had packet loss or server was lagging?
You send a packet that says "move to pos x,y" and then the server responds with "character moving to x,y". If you have packet loss then I guess you'll just need to detect a timeout for the response from the server (which I have implemented). As far as lag, that's not really an issue. That's just gonna result in less fluid movement.Quote:
Wouldn't it fail to reach its destination if you had packet loss or server was lagging?
interesting you planning to publish it ?Quote:
You send a packet that says "move to pos x,y" and then the server responds with "character moving to x,y". If you have packet loss then I guess you'll just need to detect a timeout for the response from the server (which I have implemented). As far as lag, that's not really an issue. That's just gonna result in less fluid movement.
"TCP guarantees delivery of data and also guarantees that packets will be delivered in the same order in which they were sent."Quote:
I see, so his way will definitely mess up on that condition.
The pathfinding algorithm is open sourced: [Only registered and activated users can see links. Click Here To Register...]Quote:
interesting you planning to publish it ?
Aha, I got you. I thought you were calculating time after your request not after receiving a response.Quote:
You send a packet that says "move to pos x,y" and then the server responds with "character moving to x,y". If you have packet loss then I guess you'll just need to detect a timeout for the response from the server (which I have implemented). As far as lag, that's not really an issue. That's just gonna result in less fluid movement.
|
|