Update on Cyrodiil Performance

smileysaint

So the big battles is what makes the gameplay unique. Lose that I lose interest.

Lag will be caused by the number of updates sent too and from the server. So ultimately you need to reduce these. So some of the things I have noticed is updates related to battles in the distance seeing animations trying to render for battle that all skills utilised in that battle are too far away from me to be affected by. So why not reduce the distance I get those updates and just show a battle, give me an indication of when I get in a radius of that battle where skills can affect me rather than using draw distance?.

Limiting these net updates also limits the preprocessing on the server. win win.

Hardware can improve performance because of bad design but there will be a finite amount unless the app is truly scalable, but ultimately as a business I assume there is a cost issue involved although could be cheaper than a re-factor depends how messed up the code is. Also I cannot imagine the user base is as large as it was and we see more and more issues it should be the opposite.

I have noticed on the PS4 that the cyrodill freezes can be mitigated by continually re-building the PS4 database or reinstalling, so im not sure if the client code/config is not corrupting itself as well doing this makes it more bearable ratehr than total freezes when meeting more that 10-20 enemy. Its a fix I dont want to apply too often tho it takes ages and its not my PS4, eso is the only game affected. So maybe take a look at how the client responds as well as server code.

philb16_ESO6

The number of updates to/from the server is better expressed as messages rather than updates. If you remember that far back, QuakeGL was more than capable of handling 40 players in close proximity, andthat was back in the mid 1990's. Hardware and software techniques have improved enormously since then. As it stands at the moment, there are two major issues a player faces when coping with freezes and extremely low frame rates:

1. Client-side lag, where your computer is under-powered or your graphics card is having trouble keeping up with the rendering requirements.
2. Server-side lag which affects everyone

Client-side lag is actually the most desirable, firstly because it puts the power to fix this in your hands, and secondly because it means the server is coping well.

As for the server-side lag, it isn't the number of messages from each of the clients that is the problem. Each of these messages goes into an event queue, waiting for the server to process them sequentially. The problem is the amount of time it takes to process each event - if that is longer than average time between new events arriving into the queue, then the queue will get longer and longer. That means you have to wait longer and longer for any given event to be processed. The name of the game, folks, is to empty the event queue.

If it takes an average of 10 milliseconds to process an event, and events arrive in the queue at a rate exceeding 1 per 10 milliseconds, then you have a recipe which almost guarantees lag because the event queue will end up with hundreds, perhaps thousands of events in the queue at the peak of battle.

AoE's are horrendously expensive in terms of the amount of time it takes to process them, but there is a simple technique which makes them less expensive than single target attacks. If the dev's are reading this, I've probably said enough that they can figure out the rest, if they can't they can always ask.

Rune_Relic

@philb16_ESO6
They are looking at the back end processes.

I already suggested a timestamp on the messages in the pipeline.
Then dumping messages that are too old and using a miss by default system client side.
The age limit then becomes the server throttle.
But its probably better to streamline the instructions in anticipation of extreme traffic rather than message limiting.

The problem is finding if the bottleneck is pipeline latency or execution latency or access latency.
The above will only solve pipeline latency in heavy traffic conditions.

Execution latency simply depends on the amount of instructions incited per message exceeding the response times.
That can only be fixed by more parallel processing or instruction reduction.
(Simplified combat mechanics or lowered AoE targets or lowered server population)

Access latency could be another problem effecting execution latency and pipeline latency.
Multiple processes trying to access and modify data at the same time....held up by file locks...with instructions awaiting service.
Nothing can be done here without inducing concurrency errors and corrupting client data; other than making that database run as fast as possible.
Of course simplifying the player record structure and size would also speed up the database access.
Which again argues for simpler combat mechanics to begin with.

That's without worrying about cross boundary network protocol framesize tuning and TCP-IP stack windowing issues waiting for a response.
A quick negative response is far better than a too slow positive response and/or timed out connection drop / window size reduction.
That just the nature of the beast.

As ZOS has peristantly added more and more data to the each user record and added more systems, its inevitable that the database bloats and record access/sevicing slows down.

I don't work at ZOS datacenters. So we don't know exactly where the bottleneck is other than knowing that heavy traffic is a major issue and population density is a major issue in combat on the server side.

For me they are focusing far too much on functionality at the expense of performance.
Technology simply isn't at the stage to satisfy their creative desires.
Alas they have a "creative design lead" and not a "performance lead".

TheLordSoth

Just curious, do you guys (developers) have any idea wtf you are doing? So far game performance get worse with each update. Now I get to ride across the entire Cry map, only to arrive at a keep where nothing is moving and nothing works but my movement. Then I have to log out or wait for 10 mins to get kicked.
Maybe you should stick to to lower rank gaming programming until you learn to play in the online world with the big boys. I do have to congratulate your marketing team however, they managed to suck a lot of in to buying this load of (you know what) game thinking it would actually work right.

Just my input....have a good one.
PS: You guys have made enough from sales (im sure) maybe you could hire some people that actually know wtf they are doing and create a patch that actually fixes something that matter.

Malmai

TheLordSoth wrote: »

Just curious, do you guys (developers) have any idea wtf you are doing? So far game performance get worse with each update. Now I get to ride across the entire Cry map, only to arrive at a keep where nothing is moving and nothing works but my movement. Then I have to log out or wait for 10 mins to get kicked.
Maybe you should stick to to lower rank gaming programming until you learn to play in the online world with the big boys. I do have to congratulate your marketing team however, they managed to suck a lot of in to buying this load of (you know what) game thinking it would actually work right.

Just my input....have a good one.
PS: You guys have made enough from sales (im sure) maybe you could hire some people that actually know wtf they are doing and create a patch that actually fixes something that matter.

They made more than enough money but why fix the game when you can make more money without fixing it...

philb16_ESO6

Forgetting performance and bugs, and some weird decisions like Imperial City, it's a great game that has given me two years of enormous pleasure. I've made great friends via this game because it seemed (in the early days at least) to attract the 'right crowd'. In the first year at least, they really listened to the players.

They made some bad decisions along the way, but it's still a great game - just bugged to hell and back with some long term unresolved issues generated because they didn't practice code isolation. Code isolation drastically reduces the number of UNI's (unintended negative impact) so for example, if you change the way one ability works, it doesn't have unintentional consequences on other abilities, buffs or debuffs. It also allows for faster testing that more accurately reflects live performance.

Adding new skill trees, armour/weapon sets, materials and buff/debuff trees added a preponderance to the code that had a severe impact on performance on each occasion, suggesting that the code architecture favoured early decision making at the expense of performance. If they had architected for future (and therefore unknown) additions to these items from the start, they could have added these things without wedging them into the existing codebase. Rather they would have slotted into the architecture with minimal impact and without reducing the ability to add future enhancements at each step.

One of the ways they could have improved the architecture is to use much more late decision making coupled with the use of promises. Promises are where you request some data in the code, then carry on without waiting for it in the hope that it arrives before it is required - if it does then you have saved some waiting time, if it doesn't then you have reduced the time waiting for the data.

Architecting code has to be done before you start writing any code at all, and thereafter has to be rigidly (and religiously) adhered to. If you take the care to architect your database to maximise performance, you should do the same for your codebase as well, after all, code is all about shifting, sifting and analysing data, making decisions based upon it, massaging and adjusting it. Information is king, and the database, whether it is a formal database or just an in-memory table, is merely the least important runtime component. However much importance you place upon your database should be applied to your code and with the same care for maintaining the architecture.

All of the above would have a positive impact on performance, but there are also other things you could do, even now with the current codebase, that could drastically improve performance and enhance code isolation and reduce the number of UNI's, in a way that allows for incremental change with major performance leaps at each step.

Rune_Relic

In my day they would have called that read ahead and re-entrant code.
Read ahead can generate its own issues with multithreaded sequential game flow though.
So I always looked at it a little on the dangerous side myself.
And I 100% agree the code should have been written as a completed framework in anticipation of intended additional systems rather than patching new systems in as needed.
But would they ever change anything that turned out to be problematic if that was the philosophy ?

I don't think they wrote the code. As time goes on it becomes clear to me they adopted it from a 3rd party.
They have admitted to that in some areas.
I can only assume they didn't have the manpower/time to do much of it in house.
Probably focused more on world design than core systems (probably where manhours were needed to focus initially).
Sometimes they said it was only based on someone elses game engine.
Sometimes they said the engines were rewritten to be more suitable.
To me it looks like as much as possible was scripted rather than 'architected' from the ground up and what core systems were architected was out sourced.

They are at the stage now where they are ripping apart that 3rd party code and delving into the game/graphics engines.
Going through everything with a fine tooth comb to improve on other peoples work.
It looks like they finally realised they cant live on someone elses dogfood or only now have the spare resources.
I think they have shifted focus now anyway.....whether its too little too late will remain to be seen.

In another thread Hines was reported to say ESO was knocked out as a stopgap experiment until ES6.
If that was the case, you aren't going to sink all your resources into it if you suspect it might be a loss leader.

/shrugs. They are trying harder I think. Perhaps ES6 will learn from all the mistakes and problems. A trial run for the real ZOS.Net. Perhaps ZOS will decide ESO is worth serious investment and make it into the game it really can be. Its almost like the powers that be aren't sure if ESO will sink or float and so wont commit....leaving the team robbing Peter to pay Paul.

AddictionX

NukeAllTheThings wrote: »

So basically our battles should never look like this?

https://youtu.be/MQFxE4AESn4?t=50s

MASSIVE, EPIC BATTLES

The Elder Scrolls Online features the largest PvP battles seen in a major online RPG. The game supports hundreds of onscreen players in epic battles. Swords and axes collide, spells and powers illuminate the ground and sky, and fires rage on embattled stronghold walls. Will you survive these epic battles? Can your overwhelming force take the keep, or will you be forced to retreat?

The Elder Scrolls Online is built to accommodate hundreds of players onscreen at once.

Might want to change that in the game guide on this site

Except, they dont look like that. That means everyone had collision even with friendly faction... also i did not see a single NB using that siphoning attack with prox det....

AddictionX

Add a molag bal faction with banner bosses running around cyrodil

OR

Molag bal forces with super high hp and damage roaming around where there is the most population overloaded like multiple banner bosses with coldfire siege! Molag bal himself shows up at the disposal of his army opening multiple gates to oblivion with a NB banner boss having prox det ganking the gankers!

So when you have the server acting up the molag bal forces come to collect the most souls attacking everything then taking over the keep! Molag bal goes where ever there are cross swords on the map... making them take damage from specifically fighters guild too.

Like the sky turns black and you get chains out of nowhere and all of a sudden you get tons of badass deadra attacking you

mrmadpyrorwb17_ESO

Cyrodiil is a big place with lots of different things to do.

Well it's big, but there's not much to do aside from capturing keeps/outposts and ganking reinforcement lines. Lol.

philb16_ESO6

Not a lot to do? You mean aside from the scrolls, dolmens, skyshards, daily quests and delves? I do get your point though. I would have liked the bridges to be more fortified, perhaps with towers at each end with murder holes for pouring oil.

TheLordSoth

I have a theory. The Development team are either entirely incompetent or they just refuse to fix errors hoping enough people get disgusted and stop playing so that there garbage game servers can handle the traffic. If u get in a full raid in PVP it freezes up and you wind up getting kicked, only to relog to your dead corpse.

What say you?

philb16_ESO6

Interesting theory, probably best handled on a note by note basis. so here's my tuppence.

I don't think the dev team is 'entirely' incompetent. Notice where I put the emphasis. I do believe they are all excellent programmers, otherwise the game just wouldn't work at all. I've worked with incompetents before, and trust me, you only need one in a team to derail an entire project. Someone who isn't able to pull their weight gets shed quickly.

Refusing to fix errors in the hope that enough people will quit the game in order to reduce the population down to manageable size? Ok, that did make me laugh, and actually that does make a weird kind of business sense, but not if you want to make a profit.

Garbage game servers? The physical machines can cope. If they made the poor decision to use dual-core servers, they would still cope. The machines and the network they exist within are not the problem. Hell, you could probably run the game on 80286 servers running at 16Mhz. It is never about the machines, it is always about the software. With the right software, you can run on almost anything. Having seen images of their server farm, the machines can definitely cope.

If u get in a full raid in PVP it freezes up and you wind up getting kicked, only to relog to your dead corpse. Yup, this happens so frequently (even without the crashes) that it spawned this entire thread. The problem is complex. Client crashes (where the client software either crashes completely or loses it's connection to the server) are very different from server issues, even though they are sometimes caused by what is happening on the server. When it comes to performance in Cyrodiil, the game clients are not the most important problems, they are robust enough for most purposes.

If the server (software) is busy dealing with high cost processes (e.g. AoE's, spawning monsters etc), it is unable to process other events in the event queue. You hit a button to do some action or other and that creates an event in the queue. If the server takes twenty seconds to process the preceding events in the queue before it gets around to yours, you will percieve this as lag where nothing appears to be happening. Tweaking the code to make those processes end faster may be the key to fixing this, but what you have to focus on is emptying that event queue just as fast as possible. This is the only thing you have to focus on. Everything else is how you achieve this, but this is what you must achieve. If you can guarantee that every event arriving in the queue will have been processed within 12 milliseconds, the only lag players will percieve is network, game client or player's machine related.

12 milliseconds is going to be beyond most games, I pulled that number out of a hat to emphasise my point about event queues. In reality, anything below 250 milliseconds is going to be playable, even with a ping of 125. That's great for a single event, but if one event takes 250ms, in a battle you are going to have many players pumping events into the queue during that quarter of a second, and many of these are going to be 250ms events too. This creates a situation which is untenable, it's a system which guarantees the the game is unplayable. What this and other games do is create a mechanic whereby the players have less costly (in processing time) things to do, such as blocking, single target attacks etc. In other words, the game relies on a lull in combat sufficient for it to catch up.

Players are players though. They don't do what you want them to, nor do they do what you expect them to. When architecting code, it should have a structure that can cope with the worst case scenario. If the total population of the zone is 500 players, you need to cope with battle in flag rooms with all 500 players, all of whom drop only AoE's. Note that i'm talking architecture here, not actual code. If you take this extreme scenario, you can calculate the maximium rate at which those AoE events hit the event queue, based on the cost to the players (magicka, cooldowns, client throttles etc). You take that maximum rate (events per millisecond) and that gives you the maximum processing time for any event. So if the rate is one event per 2ms, the longest time you can take to process any of those AoE's is 2ms. This is impossible for any piece of sequential code, so you must architect around this. It's not specifically the code that is going to solve this, it is the architecture.

If you are going to write any mission critical software that you know is going to serve heavy traffic and needs to be both dynamic and capable of continuous evolution, you need to design a structure that allows for this before you write any code. You must break everything down into discrete subsystems and you must guarantee code isolation so that you can edit any atom, whether it is a dispatch, routing or terminal routine, and know that it will not generate issues that will manifest as bugs in other routines. If the architecture can't deliver on these requirements, your code will never be able to cope.

nemisan

Helllo, not sure if this has been suggested before, but to help with the lag why not put every toon in a uniform, i.e one for each alliance, with no distinction between light, medium or heavy armour, it will save appearances having to be rendered and after all, your toon is in the army now...cue a certain Status Quo song

philb16_ESO6

Yay, Quo!
You can do that to simplify things for your poor overworked machine, but it doesn't really make much difference. There are a limited number of options on how a toon looks, and your game client already has all the textures (images). Animations are actually more difficult because they continually change your avatar shape, and this is important because it gives players a visual cue as to what you are doing.Simplifying the textures down to low resolution can improve frame rates for sure, but you can already do this at your own discretion, and it doesn't resolve the server-side lag issue.

Remember, the server doesn't render a graphical image like your game client. It is more than likely a command line program that outputs to a log and the console, or even a service/daemon. Everything about the world, what is in it and what things (anything that can move or have an action) are doing can all be described using numbers. Collisions are detected because objects have size, shape, position, velocity and acceleration, all of which can be described mathematically - something that software excels at.

timbuck.3b16_ESO

Turelus wrote: »

ZOS_PaulSage wrote: »

Actively, we are looking at changing the behavior of the players to remove incentives for large groups to stay in the same area.

From someone who has played EVE Online for many years I wish you the best of luck in this, because sadly as long "bring more people means we win" is an effective strategy it's going to happen.

Talking about "EveOnline", you guys could try the TiDi effect ( Time Dilatation).Not the best of thing, but at least the timer give an hint on how mustch you're slowed down.
Wall of text ahead -->
https://community.eveonline.com/news/dev-blogs/introducing-time-dilation-tidi/
TLTR:
Time dilation slows down time so the server can keep up with what y'all are doing.

Merlight

timbuck.3b16_ESO wrote: »

Talking about "EveOnline", you guys could try the TiDi effect ( Time Dilatation).Not the best of thing, but at least the timer give an hint on how mustch you're slowed down.

For that concept to be applicable, ESO would first need to openly admit (display in UI) that there are cooldowns -- because time dilation is essentially multiplying all cooldowns by "server load factor".

Rune_Relic

Well you could slow the load down and all associated traffic generated...or...
you could simply "not overload the server/network/databse with more than it can handle to start with".


Plan A coding (under loaded operations) works pretty well and gets debugged pretty quickly.
Plan B coding (overloaded operations) when the system is at the limiters is a completely different matter.

Plan B coding isn't sexy and a lot of people ignore it if they can.
Which is fine until its actually invoked....and the crap hits the fan...and you find out how bad the failsafe code design is.
That plan B code is there to ensure operations continue even when beyond limits, with minimal if any disruption.
That's why you preplan your worst case framework to cope and then stick to the framework.
ie you identify design limitations and then stay well within them or workaround them.

bhaa

Hi guys,
I've been experiencing horrible latency issues through last years in pvp almost all day around and I dont think anything can be done to prevent ppl from grouping and ganging, after all it seems to be in our nature. So there are only 2 ways I believe are available to prevent it from happening.
1) Create scenarios for limited groups for up to 10, 20 ,30 ppl from each side within relatively small map area and different goals, like capturing and hold flag, or capturing resources, and so on. Ppl will join these scenarios same way we do group dungeons, through the group search tool. Actually that is what have been done in many online games and I must admit it is the simplest and the best solution so far. So its a proved classic way. A patented issues might arise however, but I'm sure they are solvable. I have rarely seen latency issues in such scenarios in other games.
2) Lower incoming dps proportionally to the number of ppl attacking same target, lets say 10 ppl attacking 1 at the same time, their dps should be 10 times lower than normal, and 10'th higher for the one who is being attacked by them. Lets say it will work only outside castles.
That will definitely prevent ppl from grouping and ganging outside castles, but I doubt that balancing can be preserved correctly through out the battle all the times, and a huge question arises about heals in such situations.

So, personally I prefer a classic solution.
Thank you and hope you will find a way to deal with these latency issues shortly, after all we r playing here for two years already and I fail to see any modest progress in that direction so far.
Cheers

philb16_ESO6

It has never been pefect in Cyrodiil, but lag was far less of an issue when the game launched, and the Cyrodiil populations were triple their current level. The devs have things to the game since then that has had an adverse effect on massed battles.

Permitting limited numbers of people to join a battle by effectively isolating it from the rest of the map like a delve would destroy the fluidity, purpose and gameplay of ESO PvP.

If you reduce someone's attacking strength by the number of players on their side, you make it so one person can do enough damage on their own and get more AP from winning, so yes that would encourage smaller groups. At the same time it makes it pointless gathering in groups at all. Yould have to reduce each persons offensive capability be less than the number of players on their side, so they gain by having more players - and that would mean you are actively encouraging players to gather, so you are back at square one.

These were good ideas though, so bravo on coming up with them, and they might yet prove useful in a modified form in combination with other ideas.

bhaa

Just saying give us options, those who have better connection will go to Cyrodiil, the others with worse connection prefer limited instances. As simple as that.

philb16_ESO6

I totally agree, they could employ PvP in a more formal mode for limited battles. At the moment we have massed battles in Cyrodiil (whether we want them massed or not), or PvP in the Imperial City. You could end up with hundreds involved in a fight there too though, and both formats are informal, meaning that anyone can join the fight.

There is room within the game to have PvP arenas. There you could have the possibility of raid v raid for smaller, formal battles. or for more complex stuff 2xRaid vs 2xRaid, or Raid v raid v Raid for threeways. The beauty of these is they can be incorporated into the group-finder mechanism to both find groups for individuals to join and for groups to find other groups to fight against.

ArchMikem

lordrichter wrote: »

Show areas on the map that are overpopulated.

While, to many this will be the place to go, to others it will mean that other places might be less defended. This might encourage battle on multiple fronts. That, in turn, could serve to divert resources away from crowded areas.

Edit: close down the wayshrine into a fort if the population gets too large.

And i keep coming back to Planetside 2 for examples.

On that game's map it gives you an estimation of how many players a certain sector has, as well as flashing blips indicating areas of intense combat. Most of the time i take these as lag warnings and i go somewhere else that shows no enemy players.

Justice31st

ZOS_PaulSage wrote: »

Hello everyone,

Our Cyrodiil performance is something we are very aware of. Performance drags when there are numerous players in the same place at the same time. This is why performance in Cyrodiil is fine for much of the day, but gets worse during more popular times. We are currently investigating ways in which we can reduce the spike of performance loss. We added in some features for Update 6 which we hoped would help, but ultimately did not. This is not a situation where we can just add more hardware. Player population in a given area hurts the performance and the more people that are in one area, the more performance is going to be hurt.

Actively, we are looking at changing the behavior of the players to remove incentives for large groups to stay in the same area. We want to do this by providing larger incentives for Alliances to split up and take on multiple-challenges in Cyrodiil. We’ll continue to work on this. We are also asked by players if there is anything they can do to help. In this situation, the best thing you can do is split off to different objectives when you notice performance going down. Cyrodiil is a big place with lots of different things to do. And thank you for asking.

So in other words, you gave up, tucked tail and ran lol...

FortheloveofKrist

AllPlayAndNoWork wrote: »

Yep..... Blame the PvPers for PvPing...... Sorry this feels like a cop out.

I'm sorry to join the "negativity" but this is unfortunately correct. Why are we, the players, who purchased a game that was touted as a playground for large-scale PvP, how are we the problem for expecting the game to deliver just that? Why are we being asked to play differently because the game cannot handle it?

The last few days on PS4 are unplayable all over the map (PvE). Are we also supposed to stop going to populated cities and stay in the countryside in order to minimize the laggy performance. What other ways are we going to be asked to compensate for the game's inability to function properly.

I have to say this doesn't feel like a cop out. It most definitely IS a cop out. This would be like selling someone a car, and then finding out that your design did not allow the car to make right turns, and so you tell the people who purchased the car to try to make mostly left turns and everything will be fine.

Stop making costumes and hats and "convenience" items and put everything into fixing the base game, both PvP and PvE. A functioning game is a convenience I will purchase. Correction: A functioning game is what I thought I already purchased.

Justice31st

FortheloveofKrist wrote: »

AllPlayAndNoWork wrote: »

Yep..... Blame the PvPers for PvPing...... Sorry this feels like a cop out.

I'm sorry to join the "negativity" but this is unfortunately correct. Why are we, the players, who purchased a game that was touted as a playground for large-scale PvP, how are we the problem for expecting the game to deliver just that? Why are we being asked to play differently because the game cannot handle it?

The last few days on PS4 are unplayable all over the map (PvE). Are we also supposed to stop going to populated cities and stay in the countryside in order to minimize the laggy performance. What other ways are we going to be asked to compensate for the game's inability to function properly.

I have to say this doesn't feel like a cop out. It most definitely IS a cop out.

Stop making costumes and hats and "convenience" items and put everything into fixing the base game, both PvP and PvE. A functioning game is a convenience I will purchase. Correction: A functioning game is what I thought I already purchased.

^This.

nml

ZOS_PaulSage wrote: »

Hello everyone,

Our Cyrodiil performance is something we are very aware of. Performance drags when there are numerous players in the same place at the same time. This is why performance in Cyrodiil is fine for much of the day, but gets worse during more popular times. We are currently investigating ways in which we can reduce the spike of performance loss. We added in some features for Update 6 which we hoped would help, but ultimately did not. This is not a situation where we can just add more hardware. Player population in a given area hurts the performance and the more people that are in one area, the more performance is going to be hurt.

Actively, we are looking at changing the behavior of the players to remove incentives for large groups to stay in the same area. We want to do this by providing larger incentives for Alliances to split up and take on multiple-challenges in Cyrodiil. We’ll continue to work on this. We are also asked by players if there is anything they can do to help. In this situation, the best thing you can do is split off to different objectives when you notice performance going down. Cyrodiil is a big place with lots of different things to do. And thank you for asking.

Respectfully Paul, but I believe this is the absolute wrong way around this issue.

In our hearts and minds Cyrodiil is meant to be large-scale alliance vs. alliance WAR, not small-scale skirmishing. Armies clashing amid the screams and din of bloody battle, for the glory of the emperor and the alliance. To hear that Zenimax intends to "change player behavior" so that "large groups won't stay at the same place" is worrying, as that goes against everything many of us feel Cyrodiil should be... and avoids the main issue which is: why do client performance issues (FPS related only alleviated by /reloadui) dramatically improve the minute I leave my 24-man raid?

I believe there is a problem in the code relating to grouping that needs to be addressed, not so much with 'player behavior'.

Please look into why grouping in general causes a slowdown rather than making people split up more.

Thank you,
-NML

LokiLoke

As of today, ZOS customer service is still referring subscribers to this TWO YEAR OLD thread to try and appease us of lag issues.

trustcotraptb14_ESO

Here's an update: It's still god awful since day 1. Nothing has improved.