Client-server Action Synchronisation

Ok, my first post and I want to say that I think this is an absolutely amazing game despite the de-sync issues.

Just had an idea that I'm sure someone thought of but didn't read through entire post. Just as we can manually detect we are out of sync and type /oos to re-sync, why not just automate this on the client side. Maybe I missed something somewhere in this post but it seems like the out-of-sync detection is on the server side when I don't see any reason not to have this on the client side to create one less thing the server is responsible for as well as improve out-of-sync detection time.

"

exhortatory wrote:

The client knows what you are doing, and what's happening in the game.

It really doesn't. You're assuming that knowing the player's input means that it knows what the player's character is doing. This is false, because what actually matters is the server's version of player input. Knowing the player's actual input merely gives the client a very strong educated guess as to what the player's character will actually do.

"

ScrotieMcB wrote:

@Naga and Steel: I'd just like to point out that "client performs calculation" and "server performs calculation" are not mutually exclusive scenarios. Thus, it is not true that either the client must wait on the server, or the server must trust the client. There is a third option: the server and the client attempt to separately draw matching conclusions without one completely and always relying on the other. I grant that this third option opens up issues of its own, most involving how to resolve mismatches between client and server when any correction the server sends will be effected by latency and thus attempting to correct a past, rather than present, version of events. However, it is vitally important to realize that, as a matter of practical reality, Path of Exile is currently in this third category. Sometimes it seems that the developers' view of their own netcode does not fully recognize this intractable truth.

I see their code to be completely lazy about detecting any desynch. It must be very easy to recognize that shooting at the monster which is in different location is hard desync and still it waits literally seconds before it attempts to resync.

I don't know why they want to safe the bandwith so much, but it's definitely damaging their product heavily. Easy 3 times a second all monster positions which moved resync info and the desync will be past. The rubber-banding issue they are all excusing this around is just cheap excuse as the client can interpolate the monsters position and move the monsters to server location. Just desync will be minimal as monsters will be on almost correct locations all the time assuming stable connection (which is general case).

"

Filousov wrote:

I see their code to be completely lazy about detecting any desynch. It must be very easy to recognize that shooting at the monster which is in different location is hard desync and still it waits literally seconds before it attempts to resync.

I don't know why they want to safe the bandwith so much, but it's definitely damaging their product heavily. Easy 3 times a second all monster positions which moved resync info and the desync will be past. The rubber-banding issue they are all excusing this around is just cheap excuse as the client can interpolate the monsters position and move the monsters to server location. Just desync will be minimal as monsters will be on almost correct locations all the time assuming stable connection (which is general case).

Was about to write the same thing.
An equivalent to /oos every 250ms for at least enemy in sight would solve this issue.
Yes it would eat bandwidth (honestly not that much as it mainly xy plus facing position but would improve the gaming experience a lot (more like a lot lot)

Path Of Exile is the only game in existence that needs an explanation/excuse for its design faults.

Do we have resync-on-freeze yet? Resync-on-Bear-Trap?

"

ScrotieMcB wrote:

Do we have resync-on-freeze yet? Resync-on-Bear-Trap?

Also wondered about this. Especially resync-on-freeze sounds like it could help in dangerous situations like it does in Stun ones. Never thought about Bear Trap, always guessed that the position of the bear trap is true anyway and that a resync would happen mechanically.

Resync on death hihihi

Can GGG maybe learn something from DICE who has released a netcode patch which reduces delays with approximately 60%:

http://battlelog.battlefield.com/bf4/news/view/new-netcode-update-rolling-out/

But also invested in new server hardware to address rubberbanding:

http://blogs.battlefield.com/2014/04/battlefield-4-high-performance-server-solution/

I'm don't know how the client-server design BF4 uses compares to PoE, I do know that BF4 uses Punkbuster.

What BF4 does in that patch is the following: They define a small area around the player (they call it a bubble) and they send you a lot more position updates per second for enemies in that bubble than for those outside of it. This is not a new technique, I think I've read about the original Unreal Tournament doing something like that already.

This cannot work for a game like PoE. Shooters send position updates for every entity in the game many times per second. That works fine for them because in a shooter, you usually have just a handful of players. BF is at the upper end of that scale, but still, most players are usually out of sight and can be optimized away by the netcode (which is more less what they did in that patch). Just look how BF4 performs on a 64 player server if you really put all 64 players in the same room. In PoE, you have dozens, if not hundreds of entities on your screen at once.

The current network architecture is not bad, it should just move some responsibilities to the client so that the player can at least rely on the position of his own character. Cheaters can still be detected by validating the client decisions on the server.