Why desync is fixable:

"

HellGauss wrote:

However all these do not really apply to PoE, because it is the server that causes desync, not the other players.

Wrong.

It is the nondeterministic nature of players (i.e. you can never fully predict what a player will do with 100% accuracy all of the time) that causes desync.

Desync, or de-synchronization, as clearly stated in the dev manifesto, is caused by events happening out of sync on the server and the client, or in simpler terms for the retarded among us, what's happening on the server isn't what's happening on the client.

This occurs because

a) The server predicted that the player will do action X, but the client reports that the player did action Y.

b) The server predicted that the player will do action X and computed the result Z. It waits for the client to confirm that he does action X and to do another action, but because of delays caused by whatever reason, the client was not able to send the confirmation for action X fast enough, or sent action X and action Y near-simultaneously.

The reason why desync occurs is because the server's behavior is that if the server predicts that the client will do action X and the client actually does action Y, the default behavior is to revert to the previous state and discard both actions X and Y.

Why does it discard action X? Because it's a wrong prediction, and it would be a huge WTF moment if you casted Immortal Call and the animation and effects for Enduring Cry played back.

Why does it discard action Y? Because a client can manipulate things on the clientside. If hackers or botters discover that GGG has stupidly decided to follow clientside prediction and/or actions in the case of desync, you can be sure that there will come to be hacking tools that will force a desync to occur, and predict that >9000 Mirrors of Kalandra dropped off Normal Hillock's death on the client.

Discarding prediction and forcing input latency into the game is a stupid idea. People who say "I can play around lag and predict what I need to do next" are CASUALS who do not understand how critical even 250 ms of delay is when it comes to split-second timing of skill chains. I cannot stress enough how a split-second Granite Flask drink has saved me from certain death, and delaying that flask's activation by 250 ms is something I find intolerable. This does not include the clusterfuck of complaints GGG will have when PVP is implemented, and a 450ms player PVPs against a 45ms one.

Why does Blizzard not have desync? Well, whoever told you that they don't have desync is a liar and a moron. They have it, they just have ways of hiding it, such as input latency (what you do isn't instantly shown to you), lowering the average ping of players by adding a fuckton of servers everywhere (trust me, if GGG has something as widespread as Battle.net, desync would be much, much rarer). Diablo 3 cheats around this by making the impact points of everything very large and very far in advance, giving them ample amounts of time to correct desync issues, but making D3 more easymode since it tolerates looser timings. This is evidenced by D3 barbarian Whirlwind, where (if you carefully check animations) you see cases of Whirlwind activations that damage enemies slightly outside of your damage radius on activation but are in the path of your movement. GGG, in its goal to preserve the hardcore nature of its gameplay, has elected to go with tighter impact timing, which means that you cannot be as sloppy, but more desync.

"

Sachiru wrote:

nothing new in a wall of text

...great, and now go and read the answers to your post in the first few pages...
Oh, and btw who said that you have 250ms delay?

"

Real_Wolf wrote:

Whats interesting is that you don't seem to understand the word "analogy"

Go look it up. The LHC is an analogy.

We are learning words today! YAY

The fact that you say 'why are you comparing to the LHC' shows that you completely misunderstood all the things that have been said so far.


The issue with debugging code. You can't see what the code is actually doing, you can only see the output.

It is trivial to go 2.0 + 2.0 = 3.0 and then look at the actual variables, but lets make a more complex thing.

Lets say you have a deck of 52 cards. Your game draws a card for you, then throws up an error. You made the error code, so you can see the error is that it drew a card that doesn't exist. Now you have to find out why the card doesn't exist. In this case the 'discard' didn't apply properly and left the card in the main deck to be drawn. So you input it so that it discards properly.

This seems like a simple solution. But in fixing it, you would have to isolate the function that produced the error, in this case its NOT the draw card function. The draw card function threw up the error, because thats when it broke. But the discard function was what CAUSED the problem that needed fixing. To solve this you have to check the draw function, it seems to be fine, then you check the play function, it seems fine, then you check the discard function, it seems fine. So now as everything seemed to run just fine, you have to check the functions against the variables, discard leaves a variable in the wrong place, theres your problem.

Then you have to fix discard so it discards properly, but make sure that the draw and play functions still work as normal.

Looking through all 52 card variables to make sure they are in the correct place, not to mention there are probably different arrays for 'hand' 'discard' 'deck' and such, then following each card to see where it went. This is not a SIMPLE task, and thats just with 52 cards.

The issue for 'real' computer coding, not just the simple script stuff that you seem to be familiar with, is scale. Take those 52 cards. Imagine they are 52 users. Now make it 520,000 users. Now track all of their data, and find out why one of them is having an error someone else isn't. Now fix that error, WITHOUT breaking it for anyone else.

Dear Real_World :D

Thank you for contacting the Solitaire helpdesk.

Can you please enable logging with the little checkbox in the corner and try again?

If this bug occurs again please send us the log file which you can find in the Solitaire folder.

Thank you and have a nice day!

"

Startkabels wrote:

Dear Real_World :D

Thank you for contacting the Solitaire helpdesk.

Can you please enable logging with the little checkbox in the corner and try again?

If this bug occurs again please send us the log file which you can find in the Solitaire folder.

Thank you and have a nice day!

You do realize that the implementation code behind your imaginary checkbox has to actually be written by someone, right?

Yes I do, what is your point?

Can we stop the discussion about how programming works? If you want to discuss this do it through PMs, because i think it go nearly nothing to do with this thread.

I think that we can back InTopic and go to a conclusion (which can however be a hint for a further thread).

Let's start with the assumptions of the sync-manifesto:

"

All online games have this situation. The server has to dictate whether things happen or not, but there's a 50-250ms delay before data gets to the server and back. There are three ways that games can solve this:

1)Trust the client. This means people can cheat, but the results are instant. We will not do this.
2)Wait until data arrives back from the server before doing anything. This is a very common strategy in RTS and MOBA games. If you click to move, the unit will only start moving once the server says so, which is 50-250ms later. If you are close to the server, you'll quickly get used to the lag and everything feels pretty good. If you're far away (New Zealand, for example), it feels like you're playing drunk. Every time you issue an order, nothing happens for quarter of a second. This does not work for Action RPGs.
3)Start predicting the result of the action as though the server said yes, immediately. When the server later gets back to you with a result, factor it in. This is what Action RPGs including Path of Exile do. It means that when you click to move, or click to attack, it occurs instantly and feels great. The problem is what happens when the server decides that the action can't have occurred - that's when the game gets badly out of sync.

The difference between the 'wait' phylosophy (point 2 of the sync-manifesto) and the 'predict' phylosophy ( point 3 GGPO-like) is very little and maybe only personal tastes can say which is better. The former shows desync as latency, while the latter as 'teleports'. As GGG, I prefer the 'predict' method in an aRPG, even if it is more difficult to program due to the fact that the game has to handle fast updates of game-status.

The main differnece between PoE and most RTS is that they are deterministic. This is why they work, not because they use the 'wait' method. In this framework the only source of desync are far away opponents, and the desync is only related to latency, because there are no bandwidth issue involved: in multiplayer the communications are p2p, and only commands are sent, not the game status. This allows continuous update (even if a little bit delayed in multiplay).

Even in the aformentioned paper ( http://www.altdevblogaday.com/2011/07/09/synchronous-rts-engines-and-a-tale-of-desyncs/ ) the author, which is a skilled game programmer, propose the wait method, but in the comments he suggests GGPO as an interesting alternative. However i remark again that the main aim of that paper is not to describe how to handle latency, but it is an explanation of why determinism works so well, and the description of some problems in the difficult (but not impossible) task to create a deterministic enviroment. In a deterministic world, both methods would perform well (or at least much better than the current system). He also clearly state that in a deterministic framework there would be no desync at all in single player.

Back to PoE manifesto, i do not know why GGG did not mention determinism while describing why other online games work well. And, most of all, why such solution has been discharged by default for PoE. I do not think think that it is for cheating and for the point 1: i already described in another thread that cheating is not a serious issue if some countermoves are taken (at least no much more an issue than it is today) , since the client is allowed only to send commands, as required by determinism, and not to define the game-status.

"

HellGauss wrote:

The difference between the 'wait' phylosophy (point 2 of the sync-manifesto) and the 'predict' phylosophy ( point 3 GGPO-like) is very little and maybe only personal tastes can say which is better. The former shows desync as latency, while the latter as 'teleports'. As GGG, I prefer the 'predict' method in an aRPG, even if it is more difficult to program due to the fact that the game has to handle fast updates of game-status.

That is the key point where i disagree with you.
(latency vs random 'teleports')
PoE is a game aimed at hardcore gamers and (at least after my experience) the thing a hardcore gamer dislikes the most is something ingame he can't control. In that respect a bit delay should be the better option for a game like this than something that can take the control out of the hands of the player and puts it in some sort of a 'random' arbitrariness of the system.

"

DE3me wrote:

PoE is a game aimed at hardcore gamers and (at least after my experience) the thing a hardcore gamer dislikes the most is something ingame he can't control. In that respect a bit delay should be the better option for a game like this than something that can take the control out of the hands of the player and puts it in some sort of a 'random' arbitrariness of the system.

Having your character on "wait" status is no less controllable, and can still lead to random deaths. You appear to be under the delusion that, while under "wait" status yourself, monsters would also be on "wait" status. This is not the case; the server gamestate would continue to progress without you, much in the same way it currently continues to progress with incorrect positions on the client.

Why doesn't OP program it himself?

Obviously he is all and knowing.