Technical solution to eliminate desync in single-player sessions

"

RogueMage wrote:

"

Sachiru wrote:

So essentially this proposal is akin to transmitting /oos data over UDP?

No, not at all! When you send an /oos you are asking the server to manually resync your client. That's drastic and time consuming and can create abrupt (though expected) rubberbanding.

The UDP update stream is not used to resync the client, it's intended to reduce the need for resyncs and minimize the abrupt visual disturbance of rubberbanding.

One way to regard the UDP update stream is as a series of positional hints that give the client timely clues as to where the server's simulation is proceeding. Since it's a UDP stream, these positional hints can be made available with far less network latency than an /oos resync process. And since the client uses the hints to make movement vector corrections rather than abrupt player or enemy position changes, it avoids the visual disturbances produced by rubberbanding.

This sounds very good in theory (and much more realistic than OP's suggestion), the only problem is, how exactly do you deal with having to slightly resync

You have a UDP stream which basically consists of deltas of how incorrect the client is, the client then needs to make adjustments (else its no different to the current system), so there needs to be a way to do slight resyncs that don't look weird on the client.

Think of it this way, if a mob is at position (43,10) on the server, and (46,5) on the client, and the client receives a delta of the difference (lets say (3,5), the client then should update the actual position of that mob to reflect whats on the server, problem is, that can easily look jaggered and weird

Theoritically speaking, if the updates happen often enough, this may not be an issue, but we still have the problem of decisions, that is, wether or not a spell crits. If you crit on the client, and then a server sends the delta that such a crit should have never happened, wtf is the client meant to do in such a case to deal with this situation? Reverse the crit instantly and then have proceed to create a wtf moment for the player?

Something about desync needs to be done. Many melee spells are just completely unreliable because of desync. 80% of my deaths are because of dsync. This is beyond frustrating. I love playing melee, but I am penalized using any "fun" abilities because of constant desync.

"

genericacc wrote:

If you can cram even a state delta, let alone all position data, for Coward's Trial into 36 bytes I will be very impressed. If this uses floating-point position you're at a healthy 12 bytes per object or so.

You'll note I specifically said 'The Majority' not 'All'. And trust me, the majority of packets if you're running around a single player level are this:

Client sends a byte message, which, along with the header is 55 bytes long.
Server returns a byte message, along with the header, padding and a frame checksum which is 64 bytes long.
Client Acknowledges the server, sending no bytes but a single Ack, that is 54 bytes long.

"

TCP/IP routing is the same as UDP/IP routing, they both use IP to route. Also, since you only care about the latest state on this stream you don't need reliable delivery.

I'm referring to the routing data that is contained in the header of the packet.

"

Routers generally handle UDP started by the client just fine, otherwise you wouldn't be here since DNS uses UDP.

Fair enough; how ever UDP still has the problem that one must actively take care not to flood. UDP Congestion is a real issue. Perhaps you might want to read up on the ramifications of Congestion collapse.

"

Do you have anything else you copied from Baby's First Network Programming Textbook or are we good now?

Hush now, the adults are trying to talk.

Premium member only servers which stream udp resynchs. 14.99 per month. Paying for brute force might seem crude, but its effective.

Wow, fat thread! O.o"""
Seems there are still alot of demands for less desync ingame and it also seems that GGG still can't do alot for better client/server communication if I read this right. "We are working on it" doesn't sound that promising imho because they seems to work on it forever.
And the comparison with D3 was interesting. Especialy the reasons why D3 feels smoother AND has less desync. Cut animations etc. would be no issue also to use with PoE along with other stuff. It sounds like PoE is a little bit "over engineered" which isn't even neccessary imho. "Path of Exile's combat animations transition smoothly from idle to attack to idle." Cute but who really needs these details? XD remove it if it leads to desync, simple. Keep it simple is the key "KISS principe".
I also don't understand this: "They (D3)also don't really have narrow corridors or doorways to the extent we do, which also helps a lot, though you lose the feeling of claustrophobia such level features create." Why do narrow and tight areas even can cause lags/desyncs? Ok, IF this really is ture than I now know why in Blizzard games everything is big, huge and oversized. :D

I don't really want to compare D3 and PoE but D3 shows us that even a fast client/server A-RPG can be mostly lagfree (except WW Barbs of course). So if GGG just could use SOME of the (dirty?) tricks that Blizzard did, it could help to improve the general PoE experience alot. Not 1:1 possible of course but I know there is still alot of potential to improve PoE.
And after they solved the desync issues, GGG should find out how Blizzard can manage to have tons of Mobs and effects onto the screen without an noticable impact onto the game performance. What's that for sorcery?!?! ;)

"

If item creation and currency use is done from the server, then you have monsters only dropping items 2-3 seconds after they die, and waiting 2-3 seconds for every currency item to take effect, since you have to wait for the next snapshot to be verified (and on a turbulent connection, that could be a while). Using (say) 1000 Fusings to try for a 6-link would take forever (you couldn't spam shift+right-click).

So what you're saying is the client handles some, maybe a lot, of the RNG involved in crafting?

That brings a whole new problem to light as to why some players have obscenely crummy luck (RNG)

How can crafters get around this bad luck? Letting the server do all the RNG.
Craft slow, one by one?
Equip / unequip items?
Drop / pickup items?
Move items inside inventory?
Move to different timezone instance? (Where ping is roughly 150+ms)

"

Rhys wrote:

qwave has suggested a radical change to our core game systems. The concept is not impossible, I think, but it isn't really feasible. It's simply too big of a change. It also has some security concerns. But it was fun to think about and discuss.

Sorry, but this reads as: "thanks for your opinion, but we know better."

Question is how long people are willing to keep enduring the desync "solutions" before they simply find another game to play.

Right now, the economy in standard and regular hardcore are already pretty much crap, so all the hacking and duping you're trying to prevent isn't going to change the situation much.

And releasing new content isn't going to bring people back if the core gaming experience is still the same.


All in all, you're spending a fuckton amount of time fixing a system that won't be useful until most people have left + spend months creating content which most people will just graze through in a matter of hours IF they decide to come back to check it out.

Anyone else see this as a formula for failure? At all?

"

Fusion_Power wrote:

"They (D3)also don't really have narrow corridors or doorways to the extent we do, which also helps a lot, though you lose the feeling of claustrophobia such level features create." Why do narrow and tight areas even can cause lags/desyncs? Ok, IF this really is ture than I now know why in Blizzard games everything is big, huge and oversized. :D

I guess this is related to the calculations involving positions of NPCs and line of sight.
With thin corridors, one of the methods of finding out whats visible is to use a ray casting algorithm; which whilst effective, is not computationally cheap compare to, say:
In a large open space, all the server needs to do is pass a vector from the player location to the npc.

Merely a guess of course :)

I cannot help myself guys for showing you my appreciation for this thread enough, but this keeps me reading it everyday and i am totally immersed into this. My god, have i never thought, this stuff can get so complexed.

Best regards, Fary :)

"

Hyskoa wrote:

"

Rhys wrote:

qwave has suggested a radical change to our core game systems. The concept is not impossible, I think, but it isn't really feasible. It's simply too big of a change. It also has some security concerns. But it was fun to think about and discuss.

Sorry, but this reads as: "thanks for your opinion, but we know better."

Question is how long people are willing to keep enduring the desync "solutions" before they simply find another game to play.

Right now, the economy in standard and regular hardcore are already pretty much crap, so all the hacking and duping you're trying to prevent isn't going to change the situation much.

And releasing new content isn't going to bring people back if the core gaming experience is still the same.


All in all, you're spending a fuckton amount of time fixing a system that won't be useful until most people have left + spend months creating content which most people will just graze through in a matter of hours IF they decide to come back to check it out.

Anyone else see this as a formula for failure? At all?

And their "better" means "enjoy desyncing, it's better!" XD
On a serious note, their code seems to be too far gone to be fixed. Do they even care with all "micro" (100$ skin is hardly a micro transaction at the cost of two AAA titles) transactions going on?