Technical solution to eliminate desync in single-player sessions

"

But anyway..what would happen, if server would be verifying all actions in "realtime"..like now..but just with some delay. So..server would trust client... but verifying it in background let's say with 30 seconds delay or something like that..

As long as the client maintains a constant connection and is streaming data to the server, then the server can 'validate' the snapshot anytime it wants. I believe it would be the most efficient for the server to perform a single validation once the client leaves the instance. That way it can perform the entire check in a single pass, which will save a lot of resources. However, if this process takes longer than I expected, then they could certainly do the checks more frequently.

So yeah, that would work too.

"

StinkFinger wrote:

SO MANY DESYNC APOLOGISTS...

Holy hell it's pathetic...

Notice how they all have "supporter" next to their names...

No wonder GGG won't do shit to address the problem, they got a horde of lemmings throwing money at a broken game the whole time denying problems and defending flawed code...

The fuck is wrong with this world...

I'm not apologizing desync, I think the state in which it is in now is quite the failure of GGG's networking code. It fails quite horribly at it's purpose, namely to accurately communicate the game-state.

However, believing that the current netcode is insufficient does not automatically make this a good idea.

This isn't a good idea. It would take a very large amount of effort to implement only to end up with a system that's vulnerable to hacking and cheating.

That effort could be much better spend on improving or rewriting the current netcode to greatly reduce desync by optimizing bandwidth usage and using the savings from that to send more information to the client, meaning it gets much more frequent updates on player positions, monster positions etc. and thus they won't be out of sync anywhere near the amount they are currently.

"

That effort could be much better spend on improving or rewriting the current netcode to greatly reduce desync by optimizing bandwidth usage

Gobla, it's not a bandwidth problem causing desync, otherwise I wouldn't be de-syncing in the middle of nowhere just because I clipped on some rocks incorrectly. You can test it yourself, just run around in an area with obstacles (especially dungeons/doors), and you will desync. No amount of optimizing the data stream is going to fix the issues that are plaguing the network code. The problem lies in how they are processing the authoritative checks. Most other multiplayer games do not share these flaws.

"

qwave wrote:

Gobla, it's not a bandwidth problem causing desync, otherwise I wouldn't be de-syncing in the middle of nowhere just because I clipped in some rocks incorrectly. No amount of optimizing the data stream is going to fix the issues that are plaguing the network code. The problem lies in how they are processing the authoritative checks.

It is.

With enough bandwidth you'd be able to send a full description of the entire game-state in every single packet, which would completely remove any desync beyond what's unavoidably caused by latency. Of course, that won't ever be possible, but sending much more information certainly is with optimizations.

It should be clear to anyone that the sort of desync we're seeing in PoE is much, much more than just latency. You can be several seconds out of sync even with a ping of 30ms. Meaning that the relevant information, the actual absolute positions of all entities out-of-place, has not been communicated for at least the amount of time that you've been out of sync.

With bandwidth optimizations you could afford to send much more information much more frequently. Meaning that it won't take several seconds of you running along your merry way, whilst server-side you've been collision blocked, until an update is send and you're resynced. Instead it would happen in under a second, you'd be barely past the mob before you'd be resynced and the client correctly reporting that your actual real position.

That's the problem we're facing in desync. Not that it happens at all, that's unavoidable if you wish to avoid cheating and hacking. The problem is that it's even possible to be several seconds out of sync, that most certainly is avoidable by simply making the server respond with much more relevant information so that the client can immediately respond with accurate and minor resyncs before things get out of hand.

"

qwave wrote:

"

That effort could be much better spend on improving or rewriting the current netcode to greatly reduce desync by optimizing bandwidth usage

Gobla, it's not a bandwidth problem causing desync, otherwise I wouldn't be de-syncing in the middle of nowhere just because I clipped on some rocks incorrectly. You can test it yourself, just run around in an area with obstacles (especially dungeons/doors), and you will desync. No amount of optimizing the data stream is going to fix the issues that are plaguing the network code. The problem lies in how they are processing the authoritative checks. Most other multiplayer games do not share these flaws.

Or when Brutus desyncs HIMSELF...

Don't even get me started on turbo Brutus...

"

qwave wrote:

I wouldn't be de-syncing in the middle of nowhere just because I clipped on some rocks incorrectly. You can test it yourself, just run around in an area with obstacles (especially dungeons/doors), and you will desync.

You would, if there isn't enough bandwidth available to respond with the server's pathing on every movement packet.

If there was this sort of desync would not happen. You would, within your ping, receive information from the server telling you that you can't path past those obstacles and you wouldn't noticeably desync. Even with 500ms ping you'd have barely moved before you'd be back in your actual place. You'd notice it certainly with such high pings, but there wouldn't be any massive shifts or teleports that are currently killing players. With a ping of around or even below 100ms you wouldn't really notice at all.

Desync is a lack of accurate up-to-date information on your client. Bandwidth determines the amount of information that can be communicated.

More bandwidth means more information can be send, meaning the client has more up-to-date information, meaning there is less desync.

"

Gobla wrote:

"

StinkFinger wrote:

SO MANY DESYNC APOLOGISTS...

Holy hell it's pathetic...

Notice how they all have "supporter" next to their names...

No wonder GGG won't do shit to address the problem, they got a horde of lemmings throwing money at a broken game the whole time denying problems and defending flawed code...

The fuck is wrong with this world...

I'm not apologizing desync, I think the state in which it is in now is quite the failure of GGG's networking code. It fails quite horribly at it's purpose, namely to accurately communicate the game-state.

However, believing that the current netcode is insufficient does not automatically make this a good idea.

This isn't a good idea. It would take a very large amount of effort to implement only to end up with a system that's vulnerable to hacking and cheating.

That effort could be much better spend on improving or rewriting the current netcode to greatly reduce desync by optimizing bandwidth usage and using the savings from that to send more information to the client, meaning it gets much more frequent updates on player positions, monster positions etc. and thus they won't be out of sync anywhere near the amount they are currently.

Agree almost completely.

Except to say, I'll go one further: I will gladly put up with additional desync, knowingly, if it means keeping the server from ever trusting the client, and thus remaining extremely resilient against hacking. I imagine such a position, despite wanting to eliminate desync, is nevertheless slightly apologist. So be it.

"

Gobla wrote:

"

qwave wrote:

I wouldn't be de-syncing in the middle of nowhere just because I clipped on some rocks incorrectly. You can test it yourself, just run around in an area with obstacles (especially dungeons/doors), and you will desync.

You would, if there isn't enough bandwidth available to respond with the server's pathing on every movement packet.

If there was this sort of desync would not happen. You would, within your ping, receive information from the server telling you that you can't path past those obstacles and you wouldn't noticeably desync. Even with 500ms ping you'd have barely moved before you'd be back in your actual place. You'd notice it certainly with such high pings, but there wouldn't be any massive shifts or teleports that are currently killing players. With a ping of around or even below 100ms you wouldn't really notice at all.

Desync is a lack of accurate up-to-date information on your client. Bandwidth determines the amount of information that can be communicated.

More bandwidth means more information can be send, meaning the client has more up-to-date information, meaning there is less desync.

This is also good information. It could very well be an infrastructure/network problem. They might not have the resources yet to upgrade.

"

Desync is a lack of accurate up-to-date information on your client. Bandwidth determines the amount of information that can be communicated.

Trust me, ill say this again, lack of bandwidth is not causing desync.

It requires virtually no bandwidth to send UDP packets with movement updates. The problem is that the client is sending intermittent packets that do not represent a complete snapshot of your input and path. For example, if you run in a circle, the client is not sending data to accurately represent the circle. Instead, it is sending segmented paths which result in inaccurate collision data on the server.

If the client sent accurate snapshots instead, the server could simulate the path properly and stay in sync. Accurate snapshots can only be sent in the manner that ive described in my main post, because you need a full amount of snapshot data to generate geometry to simulate the exact path.

ScrotieMcB: Trusting game clients does not mean that you sacrifice game integrity. I know that many people over the past many years have preached that if not everything is 100% server-side, then cheating is possible. Game developers have learned a lot nowadays that enable offloading much of the server-side logic while still preventing cheating.

"

qwave wrote:

"

Desync is a lack of accurate up-to-date information on your client. Bandwidth determines the amount of information that can be communicated.

Trust me, ill say this again, lack of bandwidth is not causing desync.

It requires virtually no bandwidth to send UDP packets with movement updates. The problem is that the client is sending intermittent packets that do not represent a complete snapshot of your input and path. For example, if you run in a circle, the client is not sending data to accurately represent the circle. Instead, it is sending segmented paths which result in inaccurate collision data on the server.

If the client sent accurate snapshots instead, the server could simulate the path properly and stay in sync. Accurate snapshots can only be sent in the manner that ive described in my main post, because you need a full amount of snapshot data to generate geometry to simulate the exact path.

Still, more data in packets requires more bandwidth... one potential fix (without client-side modification) is to up the bandwidth while allowing more info transfer.