Technical solution to eliminate desync in single-player sessions

I like this solution :) I primarily play solo anyway, and would love to have no desync.

Vindictus (MMORPG) does a similar concept (if you do an instance solo, you locally host the server and have no latency, but anti-cheat still exists).

"

Vindictus (MMORPG) does a similar concept (if you do an instance solo, you locally host the server and have no latency, but anti-cheat still exists).

Many online games do this successfully. PoE is perfect for it.

Is there any topic or admin post talking about desync?

- Your solution only works for a single player (this is not just a problem since it's limited but a problem since players may now decide to play solo to avoid desync rather than group up, which is the point of the game. I.e. it isn't just limited but may influence the community into a more single player approach).
- Your solution has security flaws which may result in hacks. Small as those risks may be, the company has clearly stated it has a policy to keep the game hack free. By that logic even a tiny risk is enough to shoot down your proposal.
- Your solution would result in a completely reworked architecture/client. Even though the server code might be usable, implementing this solution basically propels the game back into alpha stage.

It's not gonna happen...


Scrotie is closer to the mark. Switching to udp would free up resources currently wasted on overhead. Using those resources for more positional updates would decrease desync issues across the board (for groups as well as single players) without changing the entire client/architecture.

EDIT: before people go flaming me. Personally I DO like this solution. It's just that as a project manager the above mentioned reasons are enough to shoot it down. Hence defending it is a waste of energy :)

"

Your solution only works for a single player

I've made a couple posts on how it could work for multiplayer as well. But yes, for the most part it's ideal for solo sessions.

"

Your solution has security flaws which may result in hacks. Small as those risks may be, the company has clearly stated it has a policy to keep the game hack free.

The nature of these flaws are not detrimental to the game. You wouldn't be able to dupe, god-mode, change item quality/chance, hit harder, etc. You could only potentially avoid dying under certain situations, but that's way better than constantly dying due to desync.

"

Your solution would result in a completely reworked architecture/client.

This is not necessarily true. We have no idea how much of the infrastructure is already part of the client. None of us are GGG developers, so it might be easier (or more difficult) than expected.

"

Scrotie is closer to the mark. Switching to udp would free up resources currently wasted on overhead. Using those resources for more positional updates would decrease desync issues across the board (for groups as well as single players) without changing the entire client/architecture.

Although using UDP may help a bit in certain scenarios, it will not eliminate desync. In fact, UDP has the potential to increase the amount of desync because UDP packets can be received out of order or lost completely.

I agree qwave.

The possible hacks ARE less gamebreaking than current desync issues.
And indeed we don't know how all this stuff works currently.

It's just, well, from a project manager's point of view those are three gaping reasons it's a proposal that is very likely to miss its mark.

I think the easiest, fastest way to see SOME sort of improvement would be a switch to udp but once again we don't have enough info on the current architecture to make any sort of proper proposal.

I'm afraid we'll just have to wait it out and hope they come up with a solution. Either that, or they have to give us more info and set up a space for us to brainstorm :)

"

qwave wrote:

"

Scrotie is closer to the mark. Switching to udp would free up resources currently wasted on overhead. Using those resources for more positional updates would decrease desync issues across the board (for groups as well as single players) without changing the entire client/architecture.

Although using UDP may help a bit in certain scenarios, it will not eliminate desync. In fact, UDP has the potential to increase the amount of desync because UDP packets can be received out of order or lost completely.

UDP doesnt have the potential to increase the amount of desync, the game must validate the packets order and just ignore "late packets".

The worst thing about desync is that this made the game unplayable and there is other games like path of exile being launched, I really dont want to stop playing path of exile because my friends are not playing anymore :(

"

Let's assume someone had the ability to do this dependably. So what you're suggesting is that I am playing hardcore, and a mob kills me. However, since my client is authoritative, I can simply 'roll myself back' before this death and not actually notify the server that I died.

There are two considerations I would make in this situation:


1. You could only roll yourself back as far as the last snapshot data you streamed. The client will be continually streaming your snapshot in realtime.

2. The server must mandate that it receives a continuous stream of data, otherwise it will forcefully sync you back to the last known state. You might consider this the same thing as the 'desyncs' that we already have. However, this particular 'desync' has nothing to do with being out of 'sync' as much as it has to do with an actual 'loss of connection' (The actual data stream connection has been severed). This would not occur nearly as frequently as the current desync.

I believe is that your approach is completely flawed in this point.
Imagine this easy to code scenario on the client to prevent ever sending a death on HC to server while allowing normal play:
1) Let's say server allows 2 secs time before connection is lost
2) I'll be continually gaining 0.2 secs before I send each action - even I could send them immediatelly - just postponing the trafics to server in very small way. - In 10 secs I gain enough window to completely move outside of this 2 secs window.
3) If death of player occurs - I'll dump all my postponed packets and instead port out to city - I'll have much more than 2 secs available that time

Server will not be able to recognize this situation in any way! It will be all 100% valid!!!

P.S.:
And even more sophisticated I could generate the window enough by just sending that I'm standing at the beginning (pretending that client loading of the area is slow) - I'll easily gain 5 secs just by this. Again with 100% valid events send!

Filousov: I think you are completely misunderstanding the way this works. You don't 'gain' a window over time. The server would strictly require snapshots within a dedicated interval (I think 1 second is best, which allows reasonable ping). Moreover, I have stated a few times that there would need to be a 2-3 second delay on log out or town portal in order to reduce the likelyhood of escaping death in this manner.