Thread: .3 Second Positional Update Delay (Requesting Dev Response)

Ty OP,
Resub cx also. Too many times way beyond the indicator or standing BEHIND pillar in Garuda and die. It just has a sloppy feel. The healing required to make up for this as well as wasted spells that should be cancelled by movement is a drain on the group. Shame, the game is beautiful but not sure I agree with where the resources are focused.

I agree, we need some kind of response. Even if it isn't a favorable one, atleast then we can move on or do w/e each person is going to do. Thank you for taking the time to make this thread OP. I gave you a like.

Thank you OP I have contributed heavily to the 140 page thread I think you sum up what the intention of that thread is and I only hope this gets some kind of response.

Frindly bump.

It is time we got a response for this and a fix.

Probable SE response : "Players are advised that it is exploiting a game mechanic to jump or use an instant ability in order to avoid taking damage."

more silence from the company. not exactly a surprise is it? any bets how big this thread needs to become (i'd say before they answer but that could be never)

So I talked to a buddy of mine who is a game developer. Apparently, with MMOs the polling rate between client and server can't necessarily go much faster than 0.3 seconds.

Modern games with good network code actually use timestamps and even employ some predictional methods to figure out if it was actually possible for you to get out of an AOE. I'll explain:

Current FFXIV Netcode
An AOE pops up under your feet. So you run out of it. Your client sends your position to the server a couple times while you're in it, but ultimately you can't get in another positional check in time before the AOE actually hits. This is what's causing people to take damage even though they got out of it. I'll show this with an image.


Here you can see each positional update (in blue). In this case, the size of the circle is the length of time you have to get out of it (0.7 seconds). Well, if you manage to get in two positional updates, you're going to get hit by it because the 3rd positional check is going to be AFTER the AOE hits.

So how do you get around this?
You attach a time stamp to each positional check, so the server can negate latency, and it has much more information for it to make some predictions. You also will need to send some extra events to the server.

So, for example, if I send a time stamp to the server along with my position twice like in the picture above, then send a special update to the server saying "on my screen I JUST got out of it, and here's the time stamp" the server can check each timestamp and say "okay .. they moved at a speed that is indeed possible (they're not botting or hacking), it was a constant speed, then it looks like everything checks out. You have successfully avoided it! And you take no damage.

TL;DR
The client needs to send time stamps with it's position updates so that the client can make predictions on whether or not you actually could have avoided an AOE.