Technical solution to eliminate desync in single-player sessions

Again, this



is only a valid piece of code if packets are computed at precisely 1s (or whatever time unit is used to relate speed to distance) intervals. Is that true?

I would expect a check like if (packet.Target > MoveSpeed * delta), but this is not the case.

You mentioned to look at



In particular, is the 3 in (packet.Target / 3) a magic number, or is it related to the movespeed?

Lastly, packets are rejected on the basis of timestamp if and only if they are received out of order (timestamps not ascending), received in the future from the server (packet.Timestamp exceeds now), or are received in too rapid a succession (delta < (packet.Target / magic_number)).

That would seem to have problems. I could cleverly hold my packets for a long period of time, this making the difference between packet.Timestamp and "now" (server current time) very long. Then, I can bypass the third "too rapid a succession" check by expending the buffer.

However, your code doesn't currently simulate a sequence of packets, so I cannot demonstrate that by a code modification.

"

qwave wrote:

"

I'm the hacker. I have complete control over my local system. Why the hell would I call .Next on that function? I can write a thread that intercepts it and calls something else.

Because the server is going to call .Next(), and it needs to match the simulation. Seriously, if you get on Skype I can explain it much easier, but it seems that you are just trolling.

You've literally asked the same 'how do seeds work' question like 200 times now. Do some research.

Again, why would the server call Next?

"

// For the sake of simulation, we will perform 1 calculation per 'distance' of the target
for (var count = 0; count < target; count++) {

This literally does nothing to invoke calling Next that I cannot intercept and spoof. Note how I ran the code in the same for context, thus I'll still be in lockstep with whatever crap "algorithm" you're running on the server.

"

That would seem to have problems. I could cleverly hold my packets for a long period of time, this making the difference between packet.Timestamp and "now" (server current time) very long. Then, I can bypass the third "too rapid a succession" check by expending the buffer.

The timestamp has to match the action simulation. The server will be able to determine if you hold the packets because it won't produce the same simulation.

"

Again, why would the server call Next?

The server uses the same Simulate() function as the client.

"

This literally does nothing to invoke calling Next that I cannot intercept and spoof. Note how I ran the code in the same for context, thus I'll still be in lockstep with whatever crap "algorithm" you're running on the server.

The server is running the same algorithm as the client.

"

qwave wrote:

"

How in the nine layers of hell would you ensure that the server runs this every time I run it on the client, without the client saying, "Hey, I ran qwave's magical hackproof next function"? Aliens again? Or Psychic computers?

It's obviously magic to you. But if you run the code, you will see how the server runs this every time. I wrote this code to prove this fact. RUN THE CODE.

[Removed by Admin]

Where the hell do you think I get my hack code concepts?

This works on your computer because, guess what, you're running the server and client on the same damn machine. Try running the two modules on two separate machines with at least 50 ms of lag, you'd see quite a big desync situation going on within 200 fucking milliseconds.

"

This works on your computer because, guess what, you're running the server and client on the same damn machine. Try running the two modules on two separate machines with at least 50 ms of lag, you'd see quite a big desync situation going on within 200 fucking milliseconds.

Add a Thread.Sleep then to simulate latency. Latency does not effect the simulation.

"

qwave wrote:

The server is running the same algorithm as the client.

And to get this through your head: I'm running my cheat IN THE SAME FUCKING ALGORITHM YOU'RE PROCLAIMING. WITHIN THE SAME FUCKING FOR LOOP. THEREFORE, MY SEED STATE IS THE SAME AS YOUR MAGICAL SERVER.

"

And to get this through your head: I'm running my cheat IN THE SAME FUCKING ALGORITHM YOU'RE PROCLAIMING. WITHIN THE SAME FUCKING FOR LOOP. THEREFORE, MY SEED STATE IS THE SAME AS YOUR MAGICAL SERVER.

So then what's the problem? The client and server simulation are in sync, no matter how much latency is involved.

This is terrific.

"

qwave wrote:

"

This works on your computer because, guess what, you're running the server and client on the same damn machine. Try running the two modules on two separate machines with at least 50 ms of lag, you'd see quite a big desync situation going on within 200 fucking milliseconds.

Add a Thread.Sleep then to simulate latency. Latency does not effect the simulation.

Thread.Sleep to simulate latency? You are an idiot, sir.

Thread.Sleep sleeps BOTH SERVER AND CLIENT. THAT IS NOT LATENCY, THAT IS SLEEPING THE SAME TWO THINGS.

"

qwave wrote:

"

And to get this through your head: I'm running my cheat IN THE SAME FUCKING ALGORITHM YOU'RE PROCLAIMING. WITHIN THE SAME FUCKING FOR LOOP. THEREFORE, MY SEED STATE IS THE SAME AS YOUR MAGICAL SERVER.

So then what's the problem? The client and server simulation are in sync, no matter how much latency is involved.

Note how when I ran my CHEAT in your SYNCHRONIZED CLIENT it WORKED.