Sorry your browser is not supported!

Here is what I have so far:

I have the network send function set to every 250 milliseconds. This way I get a last point and a current point.

I used an animate object function to position/rotate the ball for 250 milliseconds to that current point.

That means I have a 250 millisecond delay to get to that current point. I want to remove this 250 millisecond delay.

Next I am sending out key presses every 250 milliseconds. I wrote a function for moving the player based on what keys is pressed. In that 250 milliseconds I could have the player release a key at 150 milliseconds. Because of the delay it won't update for another 100 milliseconds. This will cause the ball to be off by a bit.

Now with the Animate Object function and the Key Presses being sent I need a way to get the ball to perfectly sync up. I don't want the object to overshoot and I don't want the object to be behind.

Anyone have any ideas how I can accomplish this? I've been two days behind trying to solve this problem lol

DigitalFury

Sorry I don't have any source code to make it any easier. Everything is purely conceptual.

I'd like to add that it can be structured one of two ways:

SendData
250 MS Delay (AnimateObject) - Off by 250 MS
Repeat

SendData
250 MS Delay (Physics) - Positions is off. Ahead by a max of 250 MS.
Repeat

I need a hybrid of the two fixing the 250 MS delay (physics) and correcting it so it isn't so far ahead without having to travel backwards.

Anyone has any ideas other then just updating the send data function faster?

DigitalFury

I think the only way to do this smooth is predicting and correcting. (That might cause some jumpyness in movement if the
network update is slow)
I would do this that way (conceptual too):

Server I.
1. server sends a ping with minimal data to the client, and saves the time when it happenes.
2. server recives the answer for the pings, saves the actual networking delay in msec.

Client I.
1. if recived a ping, answer to it.

Client II

1. if client start to move or rotate, you have to send it to the server, send direction current positions, angles and movement described with a vector. Meanwhile, on acting client side you can smoothly plays these effects. Other players avatar moves as described in the last packet from the server.

2. if recives data from the server, it upgrades the position of the avatars. That might cause some rollback in avatar positions.
Using the new avatar movement angles and speed data, start playing their movement until next correction.


Server II.

1. Server recives movement data and player positions and angles.
We know, when we recive that data, and the player is in move, then it wont be actually there because of the latency. Server sends data to the other clients ( movement direction, speed, angles, rotation vector and speed ) and an updated position data modified with the latency value, predicted where will be the other avatars, when the packet arrives to the specified clients.

====IDEAS:
With UDP, you can update the network loop more frequently. To avoid flood, you can optimize the sent data. 8 pressed key state fit in one byte. If you dont need float data for angles, then it will fit in one byte too using a conversion. (byte value 0=degree 0, byte value 255=degree 360) (that way, you only update the avatars angle value, if their float angles differs more than a critical value.)

I hope you will find at least one useful thing in my description.
(and sorry for my english, its not the best.)

@miso -

Hmm..seems you gave me some good ideas.

You can keep track of latency between the server and the clients in a variable lets say: Latency#. Every 1/4 of the time it takes to send between the server/client a ping will be sent out from the client to the server. The client will time how long it takes to get back a response.

If I find that there is a larger latency then the normal average recorded then I can assume it will lag a bit. If I know it will lag I can predict the movements (with physics) until the lag has stopped from the last key that was sent being pressed.

If the delay is large enough I will have to smooth over the movements with my AnimateObject function instead of just positioning the object. That means the object will be a little behind and maybe at max 250 MS behind but at least it will smooth over the position so it doesn't jump.

I can determine how long it takes to ping and use that figure into determining how long I should run physics.

You take send delay: 250 MS + Latency# to get total amount of time to send. This you can use physics.

Another thing is to measure how much it was off by predicting the position with physics from the sent data. If it is off a significant amount then I'll have to reduce the time that I run physics to predict the next position this way I won't overshoot it all the time.

Haha...I think I finally figured out how I'm going to get this to work out...Toook a tooonn of thought but I think I got it now.

Off to work again,

DigitalFury

You have to keep track of every clients latency, one player may have a better or worse connection, and latency may differ in hundreds of milisecs because the connection he or she has. You have to compute the delay this way:

example sending client 1 data to the other players:
client 1 sends data---->delay to server---->delay to client x

One delay is half of the ping time (ping time is the time of two events, a a ping request and an answer)

@miso - Ah good point. It is from the Client to the server to the client being updated instead of just that client/server.

Thanks,

DigitalFury