Client-server Action Synchronisation

"

HoneyBadGerMan wrote:

We need a Scumbag Steve image macro for GGG which says:

Won't fix desync by trusting client because worried that it will make it possible for people to cheat.

Possible for people to cheat anyway.

"

Nicholas_Steel wrote:

I would rather they resync significantly more often than how often they currently resync.

If they synced 30 times per second instead of once every ten seconds, you'd never experience desync. You'd feel the latency more, but you'd never experience desync.

"

standalone09 wrote:

"

HoneyBadGerMan wrote:

We need a Scumbag Steve image macro for GGG which says:

Won't fix desync by trusting client because worried that it will make it possible for people to cheat.

Possible for people to cheat anyway.

Love your work! Pity the hat is largely hidden behind the text though. Still, not much to be done about that I guess. Just like desync, right?!? Not much to be done about it? Desync? Get it? LOLOLOLOL

"

HoneyBadGerMan wrote:

If they synced 30 times per second instead of once every ten seconds, you'd never experience desync. You'd feel the latency more, but you'd never experience desync.

You'd also not experience the game itself. Technical feasibility aside (your solution is not feasible, I explained why in a longer post a few pages back) you'd barely be able to move because the game would be stuttering. Look at videos of professional flicker strike builds, this is what you gameplay would look like, only without you doing any damage.

"

PixelDemon wrote:

It could use more work, and will hopefully get it, it is annoying but tolerable, hardly a company killer like some people seem to think.

Please do believe me when I tell you that you cannot make this blanket statement. I can give you a lengthy technical argument as to why this is the case if you want, but here's the gist of it: Due to the nature of desync, even a seemingly tiny change in your connection quality can turn the problem from a minor annoyance to a completely gamebreaking issue. It does not take huge ping times or massive packet loss for that to happen. I've had to change providers twice in the last two years. The game went from 'What is desync' to completely unplayable to 'Well I guess I can't play melee then'.

"

The client can never predict or account for other human players, so there will always be some desync when playing with other human players even with your model. The problem worsens as more and more human players are involved.

Of course this is a problem that affects all network models and your proposel is still heaps better than the current implementation, especially for solo play.

That depends on how you're defining "desync" -- in real-time, then yes it's unlikely due to the disparity in latency however each machine will play out the exact same state seen on each client (hence anomalies such as "rubberbanding"/"invisible damage sources"/ect will not exist at all)

"

vezuial wrote:

You'd also not experience the game itself. Technical feasibility aside (your solution is not feasible, I explained why in a longer post a few pages back) you'd barely be able to move because the game would be stuttering. Look at videos of professional flicker strike builds, this is what you gameplay would look like, only without you doing any damage.

Sorry man, but you're wrong about this. AFAIK every version of Quake ever has, by default, synced 30 times per second, and the gameplay in every single one of those games is smooth as silk. You can make it smoother still by cranking the sync rate up further. I usually set my servers up with a 60hz sync on LAN. You never actually notice any desync in Quake because the sync happens so frequently that there's never really any time for it to get out of sync. Latency, on the other hand, is a total game killer. Every single lag spike is completely noticeable, and entirely awful. By contrast, I play PoE with lag spikes that would make Quake completely unplayable and there's barely any impact at all.

I think, to some extent, you're confusing latency and synchronicity. They're related, but not the same.

Trust the client and get a good anticheat that gets updated time to time.

It would already help if the server just stops the "simulation" suddenly when desync is detected so players don't die "offscreen" while not be able to react. The big problem is, that the Server just continues and doesn't care if the client desyncs, a very bad behaviour imho.
GGG could also add more servers to reduce the desync a little bit without changing the netcode completely.
Or they could made a pure "server only" gamplay where the client just shows what's going on and the servers approve every action first before execute them (like in Worl of Tanks).
All these methods would still be save and do not raise the chance of cheating. No clue why GGG does not try anything in that direction. I suspect they did not even touched the Netcode in years. :(

This is from the 1.3.1c patch and Q&A thread.

"

Chris wrote:

Are there gonna be any synchronization improvements in the/prior to act 4 expansion?
Will the desync issue ever be dealt with or improved?

Yes.

and

"

Chris wrote:

Is there any information that you can give about future QoL improvements that are in the works?

...

The short answer is that the new expansion has a bunch of improvements, both in areas that you were hoping for and in areas that you don't expect us to improve. There will continue to be improvements after the expansion too, of course.

Right now, half of our programming manpower is allocated to QOL/performance/sync improvements.

So yeah, this is the best stuff I've read in like, forever. I feel like so much QQ could have been prevented if only this information had been communicated to the community a bit earlier. I mean, I'm betting that for most of us "sync improvements" is an area "that you don't expect us to improve."