UI Lag

People talk about this a lot, but don't seem to understand why it's the way it is, or what's really going on. They throw around terms like "server-side UI," but don't know exactly what they're talking about.

So I thought I'd clarify what's going on to the best of my knowledge.

----------------------------------

In XI, the UI is done entirely on the client. That is, when you say "open inventory," your client immediately opens the window and displays the items it thinks you have. The server is unaware that your inventory is open. Some things like trade confirmations wait for the server, (and are thus slightly laggy), but most is done client-side and the server trusts that the client is behaving as it should.

This can be a problem, though. For example, the XI server does not confirm where your character is -- it trusts the client. That means with a simple client-side hack, you can teleport your player wherever you want, claim mobs before others by snooping client memory, etc. The server will blindly accept it as the truth.

-----------------------------------

XIV is the opposite. Every action you take in the UI round-trips to the server and back for confirmation. Open inventory? Round-trip and confirm. Display items in window? Round-trip and confirm. Look at item details? Round-trip and confirm. Go to sub menu? Round trip and confirm. Close window? Round trip and confirm. Open map? Round trip and confirm. You get the idea.

There's no such thing as "server-side UI." By definition, UI is done on the client. It's more accurately described as "server-confirmed UI," requiring a message to go halfway around the world to the server and back again, (maybe half a second), for every UI action you take, however small it may be.

----------------------------------

This means no matter how much they "optimize" it, the interface will always have a built-in lag: the time it takes to get to/from the server, plus an irreducible processing time. They may be able to improve the latter slightly, but ultimately, they can only improve it to a point.

The server and client were engineered this way from the ground up. It was a design decision. "Fixing" it would require re-architecting the entire system into something more like XI or WoW, and pushing all of the UI event loop into the client instead. This would likely be a fairly enormous undertaking, and I'm skeptical it could be done any time soon, if at all.

The point is: it was intentional. It's not a bug. That's probably why SE has remained awkwardly silent about the problem ever since alpha.

Why did they do it this way? We can only speculate, but I imagine that by tracking and recording every action on the server, it helps them stop bots and hackers. It prevents many of the problems we had in XI. Maybe the client was farmed out to China and they could only rapidly iterate on the server. We'll never really know. However, it's still quite useful, from a theoretical standpoint. By some measure, this is an improvement over XI.

But is it worth it? That's the question. I guess we'll see.

So, the solution is worse than the problem. :3

Don't think it was worth it to go all the way to server-side confirmation. Every movement and every menu navigation? is too much. Pos-hacks in FFXI hardly affected me, and they had the means to detect perpetrators if they pos-hacked, so they could've done the same in FFXIV. However, slow menu, bazaar checking, inventory checking, equipment checking is really irritating...

Can't they do a compromise where only the important stuff are server-confirmed (claiming mobs, and specific actions important to botters like starting mining, fishing, gathering, crafting), and leave the rest to the client (movement, menus, inventory)?

I've never seen anyone duplicate an item or create an item out of nothing in XI, despite its architecture so I'm guessing having inventory and menu server-confirmed every click isn't necessary to prevent that.

To me this sounds more like a crutch than a fix. No matter what hackers will always be a step ahead, so to me the solution is taking away the need to 3rd party programs.

RMT is an entire different issue however, but this still feels like it's doing more harm than good.

Your galka is so red. :D

I'm hesitant to speculate why they did it this way, but grasping at straws here:

There are potentially good things this does. With the server being the authority on all player actions, they can more easily stop things like hacks, bots, RMT, etc. It pretty much stops stuff like client-side duping exploits in their tracks.

However, there's other, less positive possibilities. Writing 3D engines is a fairly repetitive operation, and a number of game companies are starting to farm that part of the game out to China and elsewhere. Perhaps the server handles everything in XIV because it's the only part of the game SE had close control over.

If I were them, based on customer feedback, I would immediately start formulating a strategy to change this. It's hard, because this is a core design decision that's likely baked very deeply into the game's architecture. It will require many resources to fix.

Maybe like you said, they can start small and start converting one feature at a time. It's also a possibility that they've already had this discussion, and decided it isn't worth changing. But either way, it's going to take a long time to fix. There's likely no single "magic patch" for this.

He is!


I hope so, a crisp UI would go a long way.

The sad thing is, the one major reason is most likely due to bots and hacks, which is something you can just ban the player for, its not impossible to prevent and there are many pos hacks already out for XIV, so it makes it a very silly way to route things for the purpose of that.

But the amount of people who would leave due to a repeating in botting like XI is probably the same amount of people who will now leave due the interface.

And i'd much prefer a super fast interface than them trying to prevent hackers and botters because that is just a complete losing battle.

I think moving certain things to server side rather than trusting the client is the correct move, but like all other things square enix it was taken to an extreme in the direction opposite of a previous extreme. Square Enix and the middleground have yet to be introduced.

I was appalled at how much the client was trusted in XI, even for a game supposedly originally intended to be only a console game. I wonder if the go to extreme like this just so people will say "this is worse, go back to the other thing".. There are a lot of things where waiting for a server confirm would be redundant or unnecessary (assuming basic competence) where they seem to have done it that way anyway.

I can understand server side validation for things like movement but there is NO good reason to put their playerbase through the pain of server confirmation on EVERYTHING. When I start synthing I don't need server validation, when you choose mats from inv, again don't need server validation, when I start the synth, that is when you do the material/synth validation. Let the client handle the beginning steps but let the server validate the completion. This prevents people from hacking as the server still has final say but it removes the needless lag on every single action. Not only does all the excess traffic create lag in the UI but I have no doubt that it affects general performance because communication has probably more than quadrupled compared to something like FFXI

Somewhat related. For anyone interested, size comparison of XI retail and XIV in alpha, beta and what it is now.

Yeah they were very few people bothered about XI bots, and in all honestly the only place it affected was NM's lol. No point in using bots in any other place.

So this is just down right dumb.

It's still trusting client for current pos, you can keep moving after disconnection.

I'm not convinced that the Lua based UI is just not very slow for loading pages with alot of graphical content. I notice that after alpha all the lua objects were heavily obfuscated (see client/script folder, all these files and folders used to have plain names showing the UI element they represented).

Very rough estimation of open times just based on hitting a button:

• Attributes and Gear - 3-4 seconds on fully loaded setup (all but 3 accessory slots filled), ~3 seconds naked (but this loads full inventory too and I don't have retainer space to test with empty inventory)

• Actions and Traits - 3-4 seconds with 11 abilities and 2 traits set, ~1 second with 1 ability and no traits, on job with only 1 trait available in the right hand list.

• Point allotment - ~1 second

• Inventory - 3-4 seconds (can't test with empty inv)

• Journal - ~1 second

• Party - <1 second for initial open, <2 seconds for server data to be populated

• Social Lists - <1 second

• Linkshell - <1 second

• Retainer list - <1 second

• Opening map - ~1 second in market ward, 1 second in city, 2 seconds outside city, then about 1 second for repeated opening.
  Teleport - <1 second

• NPC Linkshells - <1 second

• Support desk - - <1 second for initial open, <2 seconds for server data to be populated

• Emote list - 2-3 seconds (this is more UI heavy that it first appears, the 2nd and 3rd tabs have lists which each have separate icons).

• Use item list - <1 second (note: had no usable items).

Even just a loading cursor would help I think while it's preparing the dialogs.

Of course there are places where it's obvious server roundtrip / transaction waits are a factor, like adding items to bazaar and so on, but I really believe there is just a horrendeous render time on most of the UI widgets.

I've just done some more testing, I can still open the equipment pages after pulling the router cable and being on R0, I'm pretty sure this is client side lag. I was also able add items to the crafting dialog with the cable out too.

If anyone else wants to repeat these tests please feel free and let us know if you can confirm results. Note this might be subject to having the right setup, if you just pull the link from your computer it may detect and bump you to the login page, whereas if you can keep the link to your computer but stop block external traffic you can force R0 without it insta-closing and test in that state. Be careful about moving in that state, I know this was considered an exploit in XI as you could move through aggro areas in R0 and bring the connection back afterwards.

What about being able to still chat in game while the server is crashing/under R0? That definitely can't be client side. Maybe the "server side" menu mechanics can produce the same effect?

I don't know about that, I haven't experienced any natural R0's.

But it's possible that as part of the seamless zoning maybe the zone servers processes are separate from the chat system? Certainly I see 2 TCP connections whenever ffxiv is running, perhaps this is due to separation of some functions between servers? But that's a side issue to the UI pages taking many seconds to appear and refresh.

Ah, that's interesting to know, I was wondering how it worked.

Also, it seems that I somehow skipped the paragraph where you said you were manually disconnecting by unplugging the router cable, my bad. It's a relief to know that the UI may not be doing many server side checks after all.

Tested in Wireshark, if I leave a capture running without doing anything but moving the all data is on port 50562, but if I send a tell to myself I can see the outgoing packet (including the /tell data, unencypted) coming from port 50563 on my machine.

p.s. on the Lua script obfuscation, seems that they are using a very simple scheme...

Command turned into 7vxx9w6 and CommandDebugger into 7vxx9w6658p335s... it's just like those childish spy decoder wheel type problems, simple one for one character replacement!

Sure if anyone felt inclined they could write a util to decrypt the names, but I don't know what good it would do unless someone could find a binary lua decompiler that could understand SE's dialect and maybe figure out why some of the widgets are so slow. (and maybe make a user patch /winks).

Sadly as much as it would help, it's probably not even worth the time to invest as it would probably get shut down. The unofficial windower website for XIV has already received a cease and desist letter and announced they will not continue development.

Well that's the same policy as XI pretty much... once they have time to accept that people will continue to find ways around the deficiencies they might stop pursuing so aggressively.

What the real shame here is, is that the UI is clearly extensible and the widgets based on runtime executed plug-in type architecture, but instead of using this as an opportunity to engage and allow custom development around the UI, it's going to be locked off and closed.

Perhaps at a later date, and if they find a way to approve and allow custom UI widgets to be submitted, vetted and distributed through an official channel which can be used on both PC and PS3 then this situation might change... but I somehow doubt it. It would be too out of character.

The chat servers are most definitely separate from the game servers. When servers have crashed outright, people can still chat in linkshell/parties/etc until, some time later, the client closes having detected the d/c.

Technically you don't have to agree to that and you can make whatever the hell you want. Only a matter of time till something come out, question is will the game still be around?

I imagine 100 fan boys populating 8 different servers if they don't polish their ***. D:

@Shaone:

It's interesting what appears to round trip and what doesn't. For instance, I don't see inventory being done in client memory, (or at least haven't found the memlocs for it), but then again, it doesn't seem to load in on-demand every time either. (But something like item durability/damage does.)

Also, movement. I've noticed that folks on very high end machines tend to have a visible stutter in location during more than those on lower-end ones. But this appears to be that above a certain level, the framerate is high enough that you notice it more. On lower-end systems, the framerate is low enough that it's disguised by overall graphic sludge.

If you're running through a crowded area, spinning your camera (and thus forcing full screen redraws for example), your character will stutter teleport a foot or two every say... 2-3 seconds. It appears to be almost linearly tied to the R value of your client, with the effect becoming more noticable at R >500 and downright crippling at R > 1000.

It does NOT appear to be dropped frames. The camera rotation doesn't hiccup -- your actual character location does. This implies they're still not trusting the client on movement. They let you start moving, and go a certain amount of time without a sync, but the server is updating your position and resyncing with the client every few seconds. While you can indeed keep walking while your R = 0, you can only go so far before your client actually freezes, awaiting a server location update.

na in ffxi you could go as far as you like with R0 but if you zone noting happen or if you d/c you be back where you left off. I don't know what they going to do but they better start fixing it :(

Actually I had a natural r0 and got all the way from the Limsa Lominsa gate to the upper level to the market wards. Doors wouldn't open but chat continued to work. I received an error message saying there was a server error. When I came back in my char was standing on the bridge to town. Took upwards of 30 seconds to disconnect me.. possibly as long as 60.

So how about.. if it gets a sync it sets the char position, but if it don't get one it ignores it?

One thing I've noticed is that when you open a dialog, it spawns a new thread then closes it as the dialog appears.

Actually that makes a lot of sense to explain something I seen.. I was playing the beta on a dual core 939 amd chip. (slow as hell) and I noticed an exceptionally huge lag in the menus on that processor.