Seems to me this would prevent a fraction of a thousandth of a percent of "lag deaths" in cyrodiil. A wall animation is nothing compared to a Zerg of 50 players.

What they need to address is the issues that Fengrush brought up and I think hes correct about them being the true reason for the lag in Cyrodiil.
They need to deal with those stacking heal/buffs and make it so you just benefit from one instead of like 20 at the same time. So they need to address cross healing and until they do it might not much get better.

worrallj wrote: »

Seems to me this would prevent a fraction of a thousandth of a percent of "lag deaths" in cyrodiil. A wall animation is nothing compared to a Zerg of 50 players.

It wouldn't fix lag, but it would likely fix at least some of the spontaneous load screens you get when a keep flips or upgrades.

Load screens are usually used to hide major map changes or asset loads, and so are usually indicative of something nearby changing in a major way that required a client-side map state update, ie keep flipped alliances and all the banners and such switched, or keep upgraded and all the walls needed to be updated with the new upgraded models.

The proper solution would be to investigate why such a change unnecessarily fired a load screen (it didn't need to, as keep state updates can be done while the player is still playing, load screens not occurring every time is evidence of that), but this would at least remove a potential cause of some of the load screens near keeps.

Thevampirenight wrote: »

What they need to address is the issues that Fengrush brought up and I think hes correct about them being the true reason for the lag in Cyrodiil.
They need to deal with those stacking heal/buffs and make it so you just benefit from one instead of like 20 at the same time. So they need to address cross healing and until they do it might not much get better.

Bingo. When simulating the state of and interactions between objects in a virtual world (ie players and NPC's in a game world), performance bottlenecks usually aren't caused by the simulation of individual objects (ie the number of players), rather the interactions between objects and how they scale.

If we assumed that every player in Cyrodiil was doing nothing but standing around idly, then the server is basically just keeping track of the state of each player, ie if they've moved, what are their stats, what bar are they on, and all of the more primitive information about them such as their character and account ID's, etc.

The server is pretty much just doing some data tracking, which is not all that slow, and the overhead of all this data tracking is constant, it scales to the amount of players, and the amount of players alone.

Since we can very clearly see that lag gets significantly worse as players clump up, and since we know that the data tracking overhead only scales with the amount of players, we can safely say that the problem is not the amount of players in the map, but the amount of players in a given area, which leaves us with interactions.

And, if you look at how much work the server actually has to do in player-player or even player-NPC interactions, you can start to see why they really slow down the more players interact with each other.

In the case of AoE's, I won't go too far into detail, but it roughly works as follows.

Before I break it down, I do want to say that this is making some rather large assumptions about how optimized this AoE function is. I'm assuming that there's a rather large optimization put into place, where the map is divided into a large grid and players are sorted into lists within each grid cell, and I'm also assuming that each step in the function is ordered from fastest to slowest, to ensure that the slower steps don't run any more than what's necessary.

First, we need a list of players who are within the AoE that may possibly receive our AoE effect(s):

1. Figure out which grid cells intersect the AoE, and grab all players within every grid cell that intersects the AoE, putting them into a single list, leaving players that obviously can't be in the AoE out of the list
2. Start looping over the list
3. Grab next player from the list
4. Check if the current player is inside of the AoE (moderately fast), and if they're not in the AoE, remove the player from the list, and go back to step 3
5. If we're calculating a damage AoE, skip to step 6. If we're calculating an AoE heal, check if the current player is already at max health. If we're calculating an AoE buff/debuff, check if the current player already has the buff/debuff. If either of the two conditions earlier were true, remove the player from the list, and go back to step 3
6. Check if the caster can see the current player by tracing a ray from the caster to the player (this can be very slow), and if the caster can't see the player, remove the player from the list, and go back to step 3
7. If there's still more players we need to loop over in the list, go back to step 3, else, end the loop.

We now have a list of players who are within the AoE, that may possibly receive our AoE effect(s), but we still have the actual effect(s) to do.

Before we start them, we then need to sort the list.

If the list is for an AoE smart heal, we need to sort the list from lowest to highest health. There are multiple sorting algorithms documented online, so I won't cover the sorting, and chances are Zenimax are probably just using some sorting library that is fairly optimized already, but sorting is moderately fast, but does scale with the amount of players needing to be sorted.

If the list is for an AoE regular heal, AoE buff or a damage AoE, I assume the list gets sorted from closest to farthest from the caster. This is a bit slower than even sorting from lowest to highest health, since there's a bit more work needing to be done to figure out the distance between two 3D points, but it's still moderately fast, scaling with the amount of players.

Then, we need to grab the players that the AoE can affect, and discard the rest, so we basically grab the first n players of the list, where n is the AoE target limit of the effect.

Finally, we loop over the list, grabbing each player of the list just like above, and we then call whichever function performs the actual effect (dealing damage, healing, applying a buff/debuff) on each player. This function call happens for each player, so say for a damage AoE with a target limit of 6 targets, the deal-damage function is called 6 times, which can potentially be slow if the function itself is slow.

Now, with all of that, think of what the server is doing for 50+ friendly targets that can take AoE heals and buffs, on top of potentially 100+ enemy targets that can take AoE damage and debuffs. And this also happens each tick, for ground effects.

Think of that, and you can start to see why AoE's might possibly be a performance drain on the servers.

worrallj wrote: »

I get lots of very brief load screens, like 10 in a row, that each last less than second, when riding from one keep to the next. It stops your horse in his tracks. Pretty annoying but doesn't actually mess much with gameplay.

That's true, its annoying but not game breaking like the other issues, but the crazy thing is, this never used to happen! For the first 3 years or so, you could ride full speed around the entire map and not have a single loading screen. Then at some point, I forget which patch it was, it all went wrong. The lag increased, the loading screens popped up, people started crashing and freezing, and its never been properly fixed since.

Good job pointing this out.
These client side load screens don't always get you, but they're there.
It's that extra corner wall that really does it.

+@eKsDee nice wright up, it isn't perfect but gives a grasp of the concept. Problem is there's more than one angle to the problem as you'd guess. When players clump, except in the case of an AoE calculation, It's mostly all render and client lag with your CPU trying to generate all the pieces. The server handles calculations for the entire server regardless of distance. If you want to factor in more calculations imagine the plethora of them it takes to work the mind of an NPC, yeah there kinda brain dead patterns but they add up. What the meeting of players does do is heighten the chance more abilities will be activated, and thus more calculations.
But you dismissed something simple the more players on a server, the more abilities that can be cast on a server. So while the number of players on the map may not directly be an issue (especially if there all in load screens,) the number of players in combat is. Which runs up the numbers the more players you have on a server.
Not that I don't recognize what @FENGRUSH said about Hots, Dots, & Buffs (I haven't seen his direct statement,) but those aspects are apart of the flow & diversity of the game. Could they be phased out, they partially were when they nerfed Dots, but I'd rather fix the game than change the gameplay if possible.
I made a post saying they should partition Cyrodiil to make it work.
A small game change yes but not game breaking.

Loadscreens, their lack of progress bar, and the consant worry that they may be one of the fabled "infinite loading screens" is quite possibly the single worst thing about ESO.