Why the netcode issue exists, and why it cannot be fixed.

[APilgrim]

The decision made was to design the game in a way which makes the server dictate the live-state of the game as opposed to the client. This is contradictory to the vast majority of online games on the market, presently, as well as in the past.

I respectfully disagree that this is the case here. And here's some examples that anyone can observe to back up why I think the conclusion regarding the client-server dictation of the live-state is wrong:

1) Most recently, the gil hack where a player could purchase something off the market board using another players identification (and therefore be using another players gil to purchase something). This is/was only possible because the servers in FFXIV tend to implicitly trust the information from any given client to an extent that is not the norm in more modern MMOs. This type of hack is "old-school" because more sophisticated and secure (modern) MMO design does not implicitly trust the client. Simple hacks like this are accomplished by simply editing memory on the client platform (the easy way, and the same way trainers work in single-player games) or by editing outbound packets coming from the client (the harder way that usually requires a little technical knowledge regarding packet editing and obfuscation or cryptology). Either way, this type of hack is only possible because the client is telling the server what is happening and the server is simply trusting and accepting what the client is telling it. It's the kind of hack you'd find in older games like Maple Story and earlier.

But this hack has nothing to do with Client vs Server Live-State you may be saying to yourself? But it does, and here's another example that explains why and shows that FFXIV is essentially a Client Live-State specifically regarding player location:

2) Teleporting bots. Happily zipping around interacting with mining/botany nodes or farming NPCs. Once again, an "old-school" hack that is only possible because the server implicitly trusts what the client is telling it (i.e. only made possible by a client-dictated live-state). If it were the case that FFXIV operates in primarily a server live-state, we'd be seeing "speed hacks" at most instead of teleporting characters. Why? Because speed hacks are essentially the client only getting away with as much as the server allows - but ultimately the server has the final say and knowledge regarding player position and "knows" that what the client is telling it isn't possibly correct. Teleporting hacks occur only when the client has complete and ultimate say on character position within the game-world and the server trusts client to dictate what the live-state is (i.e. a client live-state like exists in FFXIV).

There are additional examples I could bring up but these 2 are the most well-known to the average player and prove the point regarding the client-server relationship in FFXIV - but I don't want to digress the topic too far into hacking FFXIV. Hacks just demonstrate the inner-workings of the client-server relationship better than subjective observances regarding AOE indicators from any given player that may be subject to varying degrees of lag/latency. And the hacks we see in this game are not the result of the server dictating the live-state of the game - in fact, the hacks we see result from the client being given too much trust in dictating the live-state of the game to the server. And which most modern MMOs have better designs to defeat and cases of where a server live-state would make extremely difficult to impossible.


Then what's the deal with all the complaints regarding avoiding AOE hits?

In this case, the server has to tell the client something that impacts the live-state of the game (NPC actions having a live-state impact on the client/character/player). And when it does, it doesn't match up with what the player is seeing on their client. Why? Because FFXIV primarily runs in a client-dictated live-state and not the other way around!

In a server dictated live-state, the server would be telling the client where the character is located (still in the hit-box of an AOE action) - and the result would be that the client would show the player's character still being located in a position to be hit by the AOE action when it occurs. Or in other words, the NPC action hitting the player would appear to the player as being coherent because their character would literally still be shown to them as still being within the area the AOE is hitting... the catch would be that their controls/input that were used in an attempt to move their character out of the AOE indicated area would appear to not work or be "laggy" to the point they were unable to get their character out in time. That, or their character would rubber-band back to being in a position to be hit.

In more of a client dictated live-state, the client would show the player as having responsively and clearly moved out of the AOE indicated area (if they actually do so)... and yet still possibly receive notice from the server that their character was still hit by the AOE. Which is the case here with all the complaints.

As an example, look at Coincounter (the 2nd boss of AV). He doesn't show AOE indicators (so we can even remove the indicators from the discussion) and has both a frontal AOE and a big 360 degree AOE. In the case where a tank sees he is gearing up a swipe attack (frontal AOE), the tank can run forward and through Coincounter and be standing behind him to avoid it.

If the tank/client/player is impacted by the issue and receives a hit irregardless of standing behind Coincounter (and in theory, making being hit impossible): the tank/character will be flung off in a certain direction. If the live-state were dictated by the server, the tank would be flung off in a direction away from Coincounter towards his front (as if the character were still standing in front of Coincounter and being flung away correctly). If the live-state were dictated by the client, the tank would be flung off in a direction behind Coincounter because this is where the client says the player is. And this is what happens in FFXIV in this fight: the client maintains where the character is located correctly and even responds to the hit correctly (by making the tank fly away in a direction behind Coincounter) even if it makes no coherent sense to the player.

The server doesn't care and isn't involved with where the player is located. Simple as that. All it is/was concerned about is very briefly being involved in the live state (likely even just one packet) by telling the client if the player was hit or not - and that's where the issues ultimately lay. And it's an issue that may even be fixable by involving the server more and not the other way around (causing the issue).

If nothing else, apply Occam's Razor: Is it more likely to a problem with SE using a more costly cutting edge server-client design... or more likely that SE is using a rather antiquated and cheaper design?

I'm going to go with SE using a more antiquated, hackable, cheaper, client-server design (and I'm not a hater of the game or SE).