Why desync is fixable:

The discussion is mainly about this GGG statement:

"

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.

And their reasoning for dismissing that strategy

"

Startkabels wrote:

I think you have no idea what you are talking about

The most common types of mistakes when programming are:
Programming without thinking
Writing code in an unstructured manner

Before you starting debugging you reproduce and isolate. And you know what then?

YOU TURN ON LOGGING AND GET AN ERROR CODE

You seem to always disagree with people who have more experience.

A simple example:

You write some code that adds two numbers together. You input numbers 2 and 3, and you get '6' as the output.

This means you have to go through, and check each variable, is one of them recording incorrect? You find the problem is that it was overwriting the first number with the second, so it was going 3+3.

Now lets add 1,000,000 variables. Now you have each of them assigned the number 1, and then add them. You get 562,141. Where did you go wrong? Good luck finding that.

Error codes are things that you PROGRAM yourself. A good code has well written annotations and also well written error captures that help to navigate those variables, objects, functions, to narrow down where the error code is. You can test individual parts for SOME systems, but certain setups you can only test by testing other parts of them.

It is like how with the LHC they can't actually interact with the particles they are sending around, or view them. What they can see is the results of these particles, and then through theory can draw conclusions about what those particles were. This is not as simple as looking at a piece of wood and saying "this is wood", its like looking at a termite hive and saying "there is wood under there somewhere, otherwise there would not be termites" but you can't see any of the wood.


Bug checking is 99% of good code, and its also the hardest part, because as soon as you have more than 2 inputs, it becomes compounded in how you can solve the issue.

Ok, you missed the part about logging while it was in capitals, ok....

You simply do not even understand logging lol

"

Real_Wolf wrote:

You seem to always disagree with people who have more experience.

Are you a psychic?

"

A simple example:

You write some code that adds two numbers together. You input numbers 2 and 3, and you get '6' as the output.

This means you have to go through, and check each variable, is one of them recording incorrect? You find the problem is that it was overwriting the first number with the second, so it was going 3+3.

No you watch the logging that you customized to capture the specific calculations and look for unexpected behaviour

"

Now lets add 1,000,000 variables. Now you have each of them assigned the number 1, and then add them. You get 562,141. Where did you go wrong? Good luck finding that.

No let's not add 1000000 variables, I said you first reproduce and isolate.

"

Error codes are things that you PROGRAM yourself. A good code has well written annotations and also well written error captures that help to navigate those variables, objects, functions, to narrow down where the error code is. You can test individual parts for SOME systems, but certain setups you can only test by testing other parts of them.

That is called a reproduction scenario

"

It is like how with the LHC they can't actually interact with the particles they are sending around, or view them. What they can see is the results of these particles, and then through theory can draw conclusions about what those particles were. This is not as simple as looking at a piece of wood and saying "this is wood", its like looking at a termite hive and saying "there is wood under there somewhere, otherwise there would not be termites" but you can't see any of the wood.

What you are comparing programming to the Large Hadron Collider? Have you lost your mind now?

"

Bug checking is 99% of good code, and its also the hardest part, because as soon as you have more than 2 inputs, it becomes compounded in how you can solve the issue.

I clearly disagree

"

Startkabels wrote:

I think you have no idea what you are talking about...

YOU TURN ON LOGGING AND GET AN ERROR CODE

OK, I tried answering your question with a considerate reply, and you exposed yourself as an arrogant and insulting troll. Finding it harder to provoke other posters these days? Here's why:

http://userscripts.org/scripts/show/176577

I was not trolling but being as clear is I could, unlike your "if you can't convince them, confuse them" answer.

And don't get me wrong, I am not saying that what you say about programs and programming is incorrect. But clearly you have no experience with debugging.

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.

"

DE3me wrote:

The fun fact here is that you know a solution to all this problems:

"

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.

And here comes the problem. You eliminate the best option to fix the problem by default with an garbage argument and here is why:
If you play a AoS/MOBA you can easy play on US servers from Europe or otherwise. Even the 300ms, you probably get, aren't worse than the whole pre-calculation thing, because they are STABLE and you get used to it. Especially for a game like PoE (hardcore player focused) stability is fucking everything. Even players in bad connection areas will get used to high pings and it will be way better than this uncertain "Am i where i think i'm or i'm already dead?" thing.
Yes, i'm a in europe so i probably have a ping around 25-50ms to servers around here, but i experienced higher pings playing on other continent servers and it may feel bad at first, but you always get used to it.

The main thing you need for a flowing game experience is stability! You can get used to play on high pings like another contintal server, but with your way the player is extradited to the whole desync problem. Plus you get the option to ease things for players in bad connection areas when you get more money pretty easy with new servers in new areas.

I really hope GGG is reading this an rethink the whole problem, because the way the game is now and the hardcore approach (which i really like) will probably never work in this game.

I could not agree more.

I have no problem dying due to my own stupidity, but it's disheartening to know that the game itself is working against me every minute I play it. I don't know about you, but I'm not willing to waste dozens or hundreds of hours spent leveling in hardcore simply because of something in the game other than the enemies trying to kill me.

I'm more than willing to sacrifice responsiveness in return for improved playability. Left unchecked, the game will practically destroy itself. All of my friends who've played the game thus far have quit. You know what each and every one of them says to me when I ask them to play? "Tell me when the desync gets fixed."

Desync is a burden on us all, and something must be done about it. Beating around the bush and coming up with a laundry list of excuses about why you won't (not can't) change the way the networking is handled isn't going to solve anything. The fact is, desync is a terrible plague hanging over this game like a disease, slowly sucking the life out of it.

"

MrAuntJemima wrote:

I could not agree more.

I have no problem dying due to my own stupidity, but it's disheartening to know that the game itself is working against me every minute I play it. I don't know about you, but I'm not willing to waste dozens or hundreds of hours spent leveling in hardcore simply because of something in the game other than the enemies trying to kill me.

I'm more than willing to sacrifice responsiveness in return for improved playability. Left unchecked, the game will practically destroy itself. All of my friends who've played the game thus far have quit. You know what each and every one of them says to me when I ask them to play? "Tell me when the desync gets fixed."

Desync is a burden on us all, and something must be done about it. Beating around the bush and coming up with a laundry list of excuses about why you won't (not can't) change the way the networking is handled isn't going to solve anything. The fact is, desync is a terrible plague hanging over this game like a disease, slowly sucking the life out of it.

Wow, this post echoes my own sentiment so much (except maybe the friends quitting part. I only had like one friend that played POE and he might have quit for other reasons liks Standard's economy. Also the hardcore part. I'm not much of an HC player).

The thing is, it might be unreasonable to say that it's a laundry list of excuses, but that's exactly what it came off as in the dev manifesto.

It is ridiculous the number of desync deaths that I have with 60 ms stable ping. "play around desync, build tankier," they say. Is limiting build diversity because of (what is perceived as) horrible synchronization code really a good thing? Nope, and I think the devs recognize that and are probably working on it behind the scenes. We can't be sure for sure though.

"

Startkabels wrote:

...some wild and incoherent nonsense about programming...

lolwut?

I believe sir, that you couldn't tell the difference between C# and D flat.