POE WILL BE THE NEW VANGUARD IF THEY DONT CHANGE SHIT UP

"

ScrotieMcB wrote:

"

Gobla wrote:

"

ScrotieMcB wrote:

I did research on my posts during the writing process. Anyone is free to look up these definitions online; I think most everyone would agree my use of the words is closer to the truth.

You seem to be mixing them up quite a bit to be honest. There's several instances where you use open-loop while you seem to mean closed-loop and vice-versa.

For example, you claim Diablo 2 did not have open-loop because it had desync. That's exactly the property one would expect from an open-loop system, which I take to mean you actually intended closed-loop.

No, I spoke accurately. An open-loop system has no resync, thus has no detectable desync (it's still there, but it's utterly invisible). Any form of resync is feedback, thus the system is no longer open-loop.

It still would have detectable desync through multiplayer and server-side only processes (dropping items etc.).

And resync is not feedback. Feedback is part of the process, a closed loop process simply means the output of the process (in this case the server-side calculation) is looped back and included with future inputs.

Resync is simply overwriting the state of the system, it's not part of the system.

"

Gobla wrote:

It still would have detectable desync through multiplayer and server-side only processes (dropping items etc.).

You mean visible to others when they view you, but not to you viewing yourself? If so, then correct. However, if dropping items is something which the server sends to the client when it believes the client's player has killed monsters, then that's feedback.

"

Gobla wrote:

And resync is not feedback. Feedback is part of the process, a closed loop process simply means the output of the process (in this case the server-side calculation) is looped back and included with future inputs.

Resync is simply overwriting the state of the system, it's not part of the system.

Wrong. Anything the client claims which is either corrected or verified by the server is feedback. This means the vast majority of messages from the server to the client are feedback.

When the client says a player is one place, then the server says otherwise, and the player's position is adjusted on the client as a result, that's feedback. Which means: /oos is feedback.

When a monster is killed and drops items, where items drop is a form of feedback; the implication is that a monster was at that location when it died. Which items drop, and whether any items drop at all, and even when the items are dropped, is not feedback in that situation, since the client does not make claims to know drop rate nor perform damage calculations. However, when you drop an item from your inventory to the ground, not just where, but also when, which and whether items drop is feedback.

When you receive a whisper from another player, that isn't feedback.

"

ScrotieMcB wrote:

Wrong. Anything the client claims which is either corrected or verified by the server is feedback. This means the vast majority of messages from the server to the client are feedback.

When the client says a player is one place, then the server says otherwise, and the player's position is adjusted on the client as a result, that's feedback. Which means: /oos is feedback.

When a monster is killed and drops items, when and where items drop is feedback. Which items drop is not feedback in such an instance. However, when you drop an item from your inventory to the ground, when, where and which item drops is feedback.

When you receive a whisper from another player, that isn't feedback.

By your generalized definition, yes.

By the definition within the context of a closed-loop system, no.

Feedback within that context means this:


It doesn't refer to any possible response. It refers specifically to a feedback loop that's continually used as input for the system to function as error correction. That's feedback.

"

ScrotieMcB wrote:

"

zriL wrote:

I've never agreed to that Chris quote. It's sad to see that they perfectly know the solution and don't want to use it only because there are people that have more than 250 ms. I don't understand the point in sacrificing every player with good latency for the sake of some players (probably in minority) that won't have a good gaming experience anyway because they will still suffer desync and even more than the others.

I've never really agreed with it, either. However, over time, I've grown to agree with the decision to have the client be immediately responsive... while still thinking this particular passage does a mediocre job of explaining why it's the right choice. You don't enjoy seeing other people putting up strawmen of positions you actually hold.

One good reason to use the immediate-response system is something which Chris partially addresses: it allows the game to respond immediately to player input, which is essential for mechanics-based challenges where movement is key, such as Vaal's Slam and Dominus' Touch of God; when the system works, such immediate response does in fact feel great. When reaction goes sluggish, these types of challenges instead feel like cheesy one-shots. When executed well (not saying it is currently), the immediate-response model is the way to go with these types of gameplay elements.

Another good reason is economics. Good closed-loop systems require lots of network hardware, which GGG didn't have. Similarly: even if they did have the money to purchase all that extra hardware, they could save the money by skipping those purchases and put it instead into the development of more content.

I'm sure it's only economics. Immediate client response doesn't allow you to dodge anything better, it only makes you think so. Server-side, you'll be at the same location whatever communication system you're using. They should just buy tons of server, at this point it's way cheaper than trying to fix this shit.

I even doubt economic reasons. After all, when you're in a party, the server has to send all the information about your party members. At this point, sending your own information as well should be almost negligible.

There is no mystery to desync.

It is cheaper and less work for GGG to simply ignore player rage than it is to fix desync.

This also applies to all aspects of the game. The first rule of GGG is there is nothing wrong with the game and all criticism will be ignored.

"

zriL wrote:

Immediate client response doesn't allow you to dodge anything better, it only makes you think so. Server-side, you'll be at the same location whatever communication system you're using.

This is false, because it assumes a mechanical challenge begins with player response, and ends with server receipt of that response; in truth, it begins with the challenge itself, then receipt of that challenge by the client, then player response, then server receipt of that response.

In a wait-on-the-server system, the challenge originates on the server, and the client's simulation is chronologically behind the server's. Thus, there is a period of latency before the client ever receives the challenge. Then there is human response time after the client receives the challenge, then additional latency while the player response is delivered to the server...

latency + human response time + latency

In a predictive system, the challenge originates on the client itself, because the client's simulation is chronologically ahead of the server's. Thus, there is no initial period of latency before the client receives the challenge, although there is still human response time after the client receives the challenge, then latency while the player response is delivered to the server...

human response time + latency

Of course, this all rests on the premise of the prediction being accurate, that what the client sees of the gamestate is the truth, or at least reasonably similar to the truth. When the predictive system fails, it no longer becomes a matter of delivering the correct responses late, it becomes a matter of delivering a completely different response, one to a situation which doesn't actually exist.

"

ScrotieMcB wrote:

"

Gobla wrote:

And resync is not feedback. Feedback is part of the process, a closed loop process simply means the output of the process (in this case the server-side calculation) is looped back and included with future inputs.

Resync is simply overwriting the state of the system, it's not part of the system.

Wrong. Anything the client claims which is either corrected or verified by the server is feedback. This means the vast majority of messages from the server to the client are feedback.

When the client says a player is one place, then the server says otherwise, and the player's position is adjusted on the client as a result, that's feedback. Which means: /oos is feedback.

"

RogueMage wrote:

You're using "feedback" in layman's terms, i.e. any sort of response to an action that is conveyed back to the actor. That's a definition broad enough to include this online forum, as a form of user "feedback" to GGG. That's fine, but it's not what I'm referring by a "closed-loop feedback control system", which is an engineering term that describes a specific type of continuously self-regulating dynamical system.

When I tried to explain the distinctions between technical jargon and layman's terms to you earlier, I was not being condescending, I was giving you the benefit of the doubt. But you rejected that olive branch and plunged well past layman's terms into your own idiosyncratic interpretations of what engineering jargon like "feedback", "open-loop", and "closed-loop" might be stretched to mean in a rhetorical sense. While there may exist some philosophical realm where "/oos is feedback", engineers are trained to make finer technical distinctions than that.

"

ScrotieMcB wrote:

I did research on my posts during the writing process. Anyone is free to look up these definitions online; I think most everyone would agree my use of the words is closer to the truth.

Training is key in this case, because feedback control theory starts with a foundation in calculus and proceeds into topics like impulse and transfer functions, Laplace and Z transforms, Bode plots and pole-zero analysis, and closed-loop stability and transient response. Sorry to bury you in technical jargon, but that's the industry vocabulary, and it typically takes several years of study for budding engineers to master. It's not something you can "research" in a weekend via Google or Wikipedia.

"

ScrotieMcB wrote:

...

You're right. Forgot that.

Still, you said it, "this all rests on the premise of the prediction being accurate". Given how bad is that accuracy, I think I would dodge that challenge better if AI was only server-side.

Then they could tweak animations or damage timing to compensate for latency.

"

zriL wrote:

"

ScrotieMcB wrote:

...

You're right. Forgot that.

Still, you said it, "this all rests on the premise of the prediction being accurate". Given how bad is that accuracy, I think I would dodge that challenge better if AI was only server-side.

Then they could tweak animations or damage timing to compensate for latency.

The really funny part is I was talking about good predictive systems. Path of Exile, for reasons which confound me, has the player's character respond immediately to input — therefore we have rubberbanding — while monsters actually wait on the server for commands before they act — therefore we do not bypass the double latency penalty for mechanical skill tests.

GGG's core decision to go with a predictive system was the correct one; however, their implementation is god-awful. Through gross negligence, we've managed to get the worst of both worlds.

"

ScrotieMcB wrote:

Path of Exile, for reasons which confound me, has the player's character respond immediately to input — therefore we have rubberbanding — while monsters actually wait on the server for commands before they act — therefore we do not bypass the double latency penalty for mechanical skill tests.

GGG's core decision to go with a predictive system was the correct one; however, their implementation is god-awful. Through gross negligence, we've managed to get the worst of both worlds.

Are you saying there is no AI done client-side ?

I think mobs continue moving when the player is disconnected. But now that I think of it, it might only be them following their last order...