After tweaking the script and setting time_smooth to 0.99 I get almost constant difference in position.
It looks like its not the engine thats causing the difference, but my script.


This is the update counter for each player (separately)



And this is the update I send immediately after the player changes input (because first update will come after 200ms.)

my.latency is stored and send on each client to the server upon connecting.


Any toughts what is causing the constant difference?
The first update I send with event is off by 8.x quants. The others are 18.8x quants. (I think its ahead of my actual player,btw. Cant see that fast)

Man, are you updating your ping?
I hope you know that your ping right after connecting is much higher.

Yes , I am updating the ping constantly.

After testing a few times , the first time after I posted I got, again, variable result, but now its stable again. No reason, no change.

Just tested 2 times , fixed error between current and predicted position.

I'll try to see if the predicted is further then the current position and I'll try sending a prediction with different combinations of 200ms and latency time / 2 added or substracted and I'll post again.





EDIT: Unstable again, gives variable results. I have no idea what is wrong. Latency is fixed at 7ms.
I gave some tought on this one

time_step times 75 frames (on 60fps) gives 20. I'm not updating very often

Any idea how to make it count in ms? This ticks stuff is extremely confusing...

16 ticks equal 1 second, that means when you write

d += time_step; // or better time_frame
if(d >= 16) error("hello");

the error message pops up after 1 second.

Yes, but I wanned to turn that into ms. , eg:

d += time_var; // add duration of frame in ms
if(d >= 200) error("hello"); // 200ms.

Nevermind that, I ended up with this:

5 = how many times/sec.

The other problem still stands. I just ran the client for 30 mins. At first, the error was almost constant (depending on direction, I mean movement_input being different, it gave different errors, but they almost remained constant). I just checked the client and the error now was adding up with 0.5 quants per update, corrected at 20 quants to 16 or 17, then adding up again.

I almost have a correct prediction method, but I'm truly lost now!

I dont have any ideas what could be wrong to give 18 quants difference even when updating 5 times/sec instead of 0.8 times/sec.
In theory the error should have been reduced down to 3 quants, due to often updating, but it remains around 18.


The even stranger part is that I was updating once every 1.2 sec. with my previous wrong counter, and I was predicting for 200ms. in the future, but the position was still almost correct, like it was ment for 1200ms silence, not 200 ms.


I have a ghost in my laptop that is joking with me!

I deleted all my client-server code and downloaded Superku's Multiplayer script. Adapted it to my GUI and added rotation, but I just noticed its client authority.

I'll start from scratch again :| Without prediction, to see if the latency produced error in position will be smaller than 18 or even 8 quants (it should be with 7ms lag, at 160 quants/sec.)...

What does that mean and why is it bad?

It means the client controls his position , not the server.

Its bad because it makes cheating easy. Someone can make 'speed' or 'teleport' hacks.

The only way this could work is to make the server force the client to move at a certain position if the client moved too far during the last update, exceeding the predefined maximum client speed, for example.

But this way you must have a reasonable fixed speed for all entities. Otherwise if you're making a game with a slow warrior and a fast rogue, the cheat comes into play, making the warrior as fast as the rogue, but twice tougher...

How do you plan to make a normal multiplayer game without client side movement? AFAIK all games (including for example CoD) do it this way, the server simply checks the movement for hacks (for instance flying, too fast, ...), approves it and sends it to the other clients.

You make the client send only input. The server moves the player and sends back the result.

With high latency, this becomes a problem, because the client seems unresponsive. You have to noticeably wait a fraction of a second to start moving after a key is pressed. To deal with that, you make local movement, but as soon as an update arrives, you correct the local position with the updated server position.


Thats where my problem comes from, my client and server are out of sync by 18 quants constant, and I cant pinpoint where this comes from. I'll try today without any prediction, starting from scratch, to see how much the difference will be between the client and server positions for 7ms latency. It should be just a few quants, no more...

Thats how a lot of games do it, btw, but they've learned their lessons I remember Counter-Strike being the most noticeable. Everybody got speed hacks back in the original. But, if you've noticed for example WoW, if you lag, you suddenly appear somewhere else. It doesnt matter that you just ran half a mile...