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).

[Alcyon_Densetsu]

snip

No offense, but your take on this seems more "deduced" and less "informed" by technical background in operating MMOG datacenters. I do respect your opinion but it doesn't seem as "definitive" as Sinth's —which was less discussing an opinion than a fact, at least in the way he worded it. Seems the man is quite positive on his analysis. That being said, I can't really comment on its validity, so I'll let others do that.

However I have a few questions that don't seem addressed by your explanation.

1) How do you explain that people can cast while running, to the extent of mounting or completing Esuna (1s cast)?
I'm asking this because I suppose that, should the client have authority, it just wouldn't let you do that at all. Not for .1s or even .01, it just wouldn't cast at all. Which is what I've observed in pretty much all other MMO's on the market.

2) How is database hacking related to live-state?
I'm wondering because, as far as I know, the database of ARR was accepting SQL requests without any check whatsoever, which was the (rather rookie) security flaw about it. To rephrase that: it wouldn't check within its own data that a request was possible, it would just process it —no need to "justify" the likeliness of an event for it to be validated (no check, no validation), requests would simply be processed. Pretty much as if we were living in a world where cheaters wouldn't exist and SQL requests were so impossible to write that SE thought no one would try (and evidently succeed). Likewise, teleport hacks are just that from what I gathered: a form of database hacking, where you don't ask the server to process a movement (which I assume would not result in a teleport but instead in very fast movement), but simply update your position in the database which doesn't check at all if it's even possible based on your previous position. Also from what little I know about these early gil generation hacks (and instant-leveling, item generation, etc.), it seems the SQL requests were in plain, not encrypted at all (like your session ID was written in the .exe parameters, without any obfuscation or encryption whatsoever, in plain memory). Apparently this lack of protection, on top of a lack of checks, made the hacks ridiculously easy to perform for a tech-savvy individual.

3) Contrary to your AV example, how do you explain that against Titan, people sitting behind him at the time of a Landslide release would indeed be ejected in the opposite direction of their relative position? (you are behind but you get ejected in front; this rarely happens but I've seen it first-hand)
To me this rather shows that the server saw the player still in front of Titan, regardless of what the client displayed to said player. I would suppose that if the live-state were on the client, you'd always be thrown away "logically" on your screen; however what often happens is that what goes on the server just isn't what we see, or more precisely we see it with a delay.

4) Finally this is a less technical question pertaining to your answer based on Occam's Razor (I love this logic too). Considering that:

• SE is known to be using cutting-edge technology in their development processes. They were the first game studio in the world to buy Silicon Graphics workstations back in the late 90's, they produced one of the most advanced CGI movie in the early 2000's, and to this day few, if any, can rival their mastery of 3D artistry.
• SE is also known to produce some of the most complicated, heavy coding in games, way too much so for the sake of (coding) elegance and efficiency, making me often call them Rube Goldberg machine-makers. This can also be seen with their web design and overall lacking knack for simplicity in UI's (just look at ARR's overcomplicated menus, absence of three-clic rules —which is often dubbed down to 2 in games— and so on). I think this post explains my feeling well.

Don't you think that Occam's Razor rather points us towards thinking that, once again, they over-thought this whole thing, they went for the complicated answers, they just didn't do what most other developers would do, making the result much more complicated (and lacking in efficiency, in the real world) that it had to be? :roll eyes:


___
EDIT: daily post limit reached (DOH!) — I'm so sorry APilgrim, I can't reply below

No offence taken + answers

Alright. Thanks for taking the time to answer I can't solve either way.

I'm still not really convinced by the casting-while-running bit though, since I really never saw that happening. I mean, if you issue a command and the client has authority, it would simply refuse that command if it's forbidden, without even needing to check with the server (that's the whole point of client authority on live-state, as I understand it, much less server-checks required, thus much less stress on said server). I suppose. Unlike you, I don't have work experience in computing besides some very basic web dev (html/css with a bit of php/ajax occasionally) and a keen interest for all things technical, so I'm really not an authority on the matter.

About these database checks… … what I read (unreliable source, but the guy seemed to know first-hand), ARR's database wasn't protected at all, and you could directly send SQL requests. No hacking per se, just knowing the right syntax. Which made me laugh at SE, since even a basic website is more secure than that.

As for Occam… haha yeah, doesn't take much knowledge in ergonomics and web design to see that SE's just bad at it. However that's not just them, many designers I know repeatedly commented that the Japanese scene was often subpar to most UI / ergonomics standards out there (good graphics, bad ergonomics) (the US being notably better than most, since they focused so much on communication and efficiency for decades). I see what you mean about SE being a huge corp., but I think we agree it's an explanation, not an excuse ^^; I mean, Apple and Google are huge too…

I award this whole technical discussion in this thread the "Most Interesting Discussion involving Final Fantasy XIV: A Realm Reborn"-title. Reading technical details about MMORPGs are always interesting, way too few discussions on these. Almost all the time, it's all so vague like "you're lagging cuz your latency is bad derp" or "to fix it, they need to programz teh latency better".

Yeah, a good food for thought is always nice.

[APilgrim]

No offense taken, I didn't mention my technical background because it's the internet where anyone can be anything they want and I thought actual examples that everyone could observe would be more convincing and less argument prone. But I have a CCNA (routing and switching) background [and a misspent youth hacking games, if that means anything to anyone]. I'm by no means an MMO game developer - but fortunately no one needs to be to discuss this topic as it effects players. And we are all deducing here unfortunately since SE hasn't responded with any facts...

1) This issue could occur in any case regardless I'm sure (most likely due to latency/lag) - but I would point out that the client is getting away with something it shouldn't precisely because the server isn't doing anything to stop it... and still the server also has no problem with accepting the client telling the server that a spell was cast successfully and accepting the outcome among other clients.

2) Sounds like what you said and what I said are in agreement? But it's related because it shows that individual clients are running the show and telling the server what the live-state is. The database is just updated with what the clients say it should be even if the new information shouldn't make any sense to a server that may be playing any sort of an important role in the processes. I'd also go out on a limb and say the database would not be attacked directly with either hack though, and instead just normal client actions would be altered. Most probably the identity of one player was replaced with the identity of another player in the act of buying something on the market board (hence why some players were receiving insufficient gil messages if their character ID had been targeted for use with the hack), for example. The result being the server updates the database itself without question because it trusts what the client is telling it. No need to attack the database directly (I suppose it's possible - just not as likely).

3) I would think in that case (and if it's more of an exception rather than the rule), latency/lag might also be playing a role if the direction doesn't make coherent sense with what the client is showing you on screen, or your character position suddenly jumps in position. But programming could be doing some funky things in different situations, fights, effects. And I was only addressing the norm of what happens - there can always be exceptions of course.

4) This actually made me laugh because I was just ranting to a friend about how bad SE's website, customer-service, and account management still is - it hasn't changed much since at least FFXI came out (my first real exposure to SE in a big way). But yes, I absolutely agree SE has a tendency to make things be overly-complicated and unintuitive for the end-user. I'd say a lot of that though has to do with SE being a huge international corporation with many, many, departments and segmentation. I can't really speak for the programming (I'm an amateur programmer at best and haven't even thought about trying to dig into something as big as a game client such as FFXIV). BUT, considering the length of development (and redevelopment) I think it's likely the programming has gotten quite complicated by this point (and also is less likely to be something cutting edge considering the years involved).