Maintenance for the week of December 15:
· [COMPLETE] PC/Mac: NA and EU megaservers for maintenance – December 15, 4:00AM EST (9:00 UTC) - 12:00PM EST (17:00 UTC)
· [COMPLETE] Xbox: NA and EU megaservers for maintenance – December 15, 4:00AM EST (9:00 UTC) - 12:00PM EST (17:00 UTC)
· [COMPLETE] PlayStation®: NA and EU megaservers for maintenance – December 15, 4:00AM EST (9:00 UTC) - 12:00PM EST (17:00 UTC)

Server Load Reduction, Proposal(s)

Syrpynt
Syrpynt
✭✭✭
Heya peeps, I know many of you hate my ideas (but they come from a good place with good intents), but I tend to think about what would make ESO run smoother since high-traffic hours make the game somewhat frustrating. No one likes to get DC'ed in the middle of a trial, group dungeon, battleground, or even simply questing the overworld by your lonesome.

My proposals are taking 1st into account of server load/performance tweaks, and 2nd is user habit/comfort. I already know I'll get pushback from elites and veterans who would have to "adapt" and might relearn even basic combat.

Proposal 1: Increase number of light attacks between abilities
Why?? Because abilities take more GPU and CPU effort to render.
How?
X. Increase light, medium, and heavy attack strength to compensate, dependent on the total number of light attacks "designed" to be swung inbetween abilities. 2 light attacks doubles the total time without animation cancelling.
Y. The other alternative is to decrease enemy health by 20-33%, and keep light and heavy attack strengths the same.
Example:
We currently do weaving like--
  • light attack --> ability (cancel light attack) --> Weapon-Swap/Bash (cancel ability) --> {repeat}
  • 0.5 animation time for light attack + 0.5 animation time for ability
But if we change it to--
  • light attack --> light attack --> ability (cancel light attack) --> Weapon-Swap/Bash (cancel ability) --> {repeat}
  • 1.5 animation time for light attack + 0.5 animation time for ability
We get--
  • B = 1.5 animation time for light attack + 0.5 animation time for ability
  • A = 0.5 animation time for light attack + 0.5 animation time for ability
  • ( (B - A) / A) * 100% = ( (2 - 1) / 1) * 100% = 100% time increase, or 2X longer before a 2nd weave is started.


Proposal 2: Increase time intervals for regeneration, Heal/Damage Over Time procs/abilities
Why?? Because more frequent calculations is more load to the server. Also, decimal calculations require more computing power to solve, than whole numbers.
How? Change 0.5 second, 1 second, 1.5 second status checks, etc--to 2 second or 3 second intervals but with the equivalent boost in magnitude to compensate for the waiting.
Example: Major heroism, every 1.5 seconds gain 3 Ultimate --> to --> Every 2 seconds, gain 4 Ultimate.


Proposal 3: Remove weapon swapping, simply make the "swap weapon" only switch to the 2nd ability bar.
Why?? Because less animations is less load, as well as even MORE time required for combat, which can be compensated with adjusted power, or enemy health (globally).
(but bonus is: The game looks less silly with characters swapping weapons from their "magicians hat"-like inventory every 1 second to get "optimal dps..."
How? Don't allow 2nd weapon to be slotted. That simple.
Downside(s):
  • No animation cancelling with weapon swap, would require to use bash? Not sure if animation cancelling could still happen with the "ability bar" swap still. Maybe? Then I know it would get less pushback.
  • No passives for specific scenarios, or weapons aren't catch-all for every scenario. Example: 2H for single target + 2 adds VS DW for mobs of adds or critical damage bonus.
From proposal 1, the new time for a single ability rotation becomes--
  • light attack --> light attack --> ability (cancel light attack) --> {repeat}
  • 1.5 animation time for light attack + 1 animation time for ability
    and doing the math again we get--
  • C = 1.5 animation time for light attack + 1 animation time for ability
  • A = 0.5 animation time for light attack + 0.5 animation time for ability
  • ( (B - A) / A) * 100% = ( (2.5 - 1) / 1) * 100% = 150% time increase, or (!)2.5X longer before a 2nd weave is started.

Increasing time between calculations will slow down combat, but can be compensated with increased power/stats for players, or decreased health/stats for NPC/Enemies.

So theoretically, combat will last the same amount of time! Nice.

Feedback is welcome!

edit (!) - Not 1.5x longer, but 2.5x longer weave times, if you combine proposal 1 and 3.
Edited by Syrpynt on September 10, 2021 8:52PM
  • SirAndy
    SirAndy
    ✭✭✭✭✭
    ✭✭✭✭✭
    Syrpynt wrote: »
    Feedback is welcome!
    popcorn.gif

    Because abilities take more GPU and CPU effort to render
    Wrong ...
    decimal calculations require more computing power to solve, than whole numbers
    Wrong ...
    Because less animations is less load
    Wrong ...


  • Syrpynt
    Syrpynt
    ✭✭✭
    SirAndy wrote: »
    Syrpynt wrote: »
    Feedback is welcome!
    popcorn.gif

    Because abilities take more GPU and CPU effort to render
    Wrong ...
    decimal calculations require more computing power to solve, than whole numbers
    Wrong ...
    Because less animations is less load
    Wrong ...


    Floating numbers take longer to calculate than integers. But ok--waiting to hear your explanation with evidence to thwart decades of computer science research. \o/
  • SirAndy
    SirAndy
    ✭✭✭✭✭
    ✭✭✭✭✭
    Syrpynt wrote: »
    Floating numbers take longer to calculate than integers. But ok--waiting to hear your explanation with evidence to thwart decades of computer science research. \o/

    That was true 25+ years ago before there were dedicated FPUs.
    I've been programming (started with Assembler) for over 40 years.

    Modern day CPUs have FPUs built-in.
    Modern day compilers can optimize FPU calls (by interleaving them) resulting in FPU operations that are on par with integer operations.

    I quite literally deal with this every single day of my life.
    type.gif

    PS: I work in computer science research ...

  • Syrpynt
    Syrpynt
    ✭✭✭
    SirAndy wrote: »
    Syrpynt wrote: »
    Floating numbers take longer to calculate than integers. But ok--waiting to hear your explanation with evidence to thwart decades of computer science research. \o/

    That was true 25+ years ago before there were dedicated FPUs.
    I've been programming (started with Assembler) for over 40 years.

    Modern day CPUs have FPUs built-in.
    Modern day compilers can optimize FPU calls (by interleaving them) resulting in FPU operations that are on par with integer operations.

    I quite literally deal with this every single day of my life.
    type.gif

    PS: I work in computer science research ...

    Ok, so then why did the development team go from low digit values (with decimal places), before OneTamriel, and then to large digit values with truncated multipliers? And isn't the math done server-side?

    FPU or not, animation cancelling and high ping rates cannot be just as taxing as less-frequent ping rates from user nodes.

    Can you explain the server performance problems then? What, besides maximum population on servers, is directly causing desync and performance problems for people in trials or Cyrodiil?
  • Sluggy
    Sluggy
    ✭✭✭✭✭
    1) What you propose is a fundamental change to the entire functioning of the game. That would not go well with either the players or the management and probably the devs as well.

    2) Yeah, FPU vs integer stuff - not really an issue these day. The days of FISR are long gone ;)

    3) Without seeing the software and working with it for a period of time no one outside of the dev team can say what the issues are but it's probably more of an architecture issue. Getting multiple processors, threads, and even machines to play nice is very tricky and often requires extra work to be done just to ensure things happen in the right order and catch and correct things when the don't. And then you need to consider how much data can be processed in parallel vs how much is dependent on the outcome of other calculations first, and changing that around can have massive impacts on the stability of the project itself as well as how the game even feels, plays, and follows it's own rules.

    Given that this game's core tech was probably developed around 2010 or 2011, the techniques and knowledge from that time could be very different from what could and would be done now. I mostly deal with small-scale, single-player games but even those are using vastly different technologies and techniques than was used 10 years ago simply due to the change in hardware and the growth in knowledge across the industry. I can only imagine what might have changed for large-scale, networked machines running massive servers.
    Edited by Sluggy on September 11, 2021 4:56AM
  • Amottica
    Amottica
    ✭✭✭✭✭
    ✭✭✭✭✭
    Syrpynt wrote: »
    Proposal 1: Increase number of light attacks between abilities
    Why?? Because abilities take more GPU and CPU effort to render.

    I am fairly certain the server does not have a GPU. Graphics for the game are local to our PC/consoles which means the server is not processing the graphics.

    At that, a skill and light attack probably9 require very similar processing power for the server. One of the devs basically stated as much long ago. Buffs, debuffs, and pretty much everything involved still need to be calculated.

    I did not read the rest of proposal 1 because it is based on incorrect information.

    Proposal 2 merely requires us to increase our regen and do more basic attacks which basic attacks still require similar server load as skills.

    Proposal 3 has the same answer as number 1. Animations do not cause server load as they are all local. This idea also destroys combat with no real benefit. Very few stamina builds use only one weapon. Tanks and healers tend to use two different weapons in high-end content.

    Sorry but these are a local PC load issues, not a server load issue.
  • Syrpynt
    Syrpynt
    ✭✭✭
    Amottica wrote: »
    I am fairly certain the server does not have a GPU. Graphics for the game are local to our PC/consoles which means the server is not processing the graphics.

    At that, a skill and light attack probably9 require very similar processing power for the server. One of the devs basically stated as much long ago. Buffs, debuffs, and pretty much everything involved still need to be calculated.

    I did not read the rest of proposal 1 because it is based on incorrect information.
    GPU is client side, CPU is Server side, I know this and didn't explain it because I assumed people were already aware of this.
    The packets tell the servers "the player executed a light attack/ability" has to be captured, and if too many get to the server at once from animation cancelling, then some actions will be dropped. Hence lag and mis-timing because ping fluctuates to read too much data. So reading too much into a sentence that isn't well explained, doesn't make the rest of the information incorrect.
    Amottica wrote: »
    Proposal 2 merely requires us to increase our regen and do more basic attacks which basic attacks still require similar server load as skills.
    Yes, as stated, rebalance is required. But not changing the games balance to exclude animation cancelling hasn't helped performance. At all.
    Amottica wrote: »
    Proposal 3 has the same answer as number 1. Animations do not cause server load as they are all local. This idea also destroys combat with no real benefit. Very few stamina builds use only one weapon. Tanks and healers tend to use two different weapons in high-end content.

    Sorry but these are a local PC load issues, not a server load issue.
    Animations have a time associated to the handshake/confirmation packets in order to allow your character to do the damage that you think you're doing. Ever have an enemy in your range and cursor directly over it, but nothing lands? Your handshake failed with the server. There is desynchronization with your client computer and the server. More data is more chance for errors, especially when at limits. Increasing frequency of those packets (by animation cancelled) will increase loads.
    Edited by Syrpynt on September 11, 2021 6:34AM
  • Sluggy
    Sluggy
    ✭✭✭✭✭
    There's a reason they went with the Global Cooldown system. And it is exactly to avoid the situations you're talking about. Players' clients can only send so many messages per second and sending more than that for an extended period (like a few seconds) will cause the connection to drop. As well, the server will only allow so many actions per second as well in the form of GCDs. This is hardcapped and cannot be exceeded by animation canceling despite what many people seem to claim about all of the alleged cheat-engine users and macros users.
    Edited by Sluggy on September 11, 2021 1:33PM
  • Amottica
    Amottica
    ✭✭✭✭✭
    ✭✭✭✭✭
    Syrpynt wrote: »
    Amottica wrote: »
    I am fairly certain the server does not have a GPU. Graphics for the game are local to our PC/consoles which means the server is not processing the graphics.

    At that, a skill and light attack probably9 require very similar processing power for the server. One of the devs basically stated as much long ago. Buffs, debuffs, and pretty much everything involved still need to be calculated.

    I did not read the rest of proposal 1 because it is based on incorrect information.
    GPU is client side, CPU is Server side, I know this and didn't explain it because I assumed people were already aware of this.
    The packets tell the servers "the player executed a light attack/ability" has to be captured, and if too many get to the server at once from animation cancelling, then some actions will be dropped. Hence lag and mis-timing because ping fluctuates to read too much data. So reading too much into a sentence that isn't well explained, doesn't make the rest of the information incorrect.
    Amottica wrote: »
    Proposal 2 merely requires us to increase our regen and do more basic attacks which basic attacks still require similar server load as skills.
    Yes, as stated, rebalance is required. But not changing the games balance to exclude animation cancelling hasn't helped performance. At all.
    Amottica wrote: »
    Proposal 3 has the same answer as number 1. Animations do not cause server load as they are all local. This idea also destroys combat with no real benefit. Very few stamina builds use only one weapon. Tanks and healers tend to use two different weapons in high-end content.

    Sorry but these are a local PC load issues, not a server load issue.
    Animations have a time associated to the handshake/confirmation packets in order to allow your character to do the damage that you think you're doing. Ever have an enemy in your range and cursor directly over it, but nothing lands? Your handshake failed with the server. There is desynchronization with your client computer and the server. More data is more chance for errors, especially when at limits. Increasing frequency of those packets (by animation cancelled) will increase loads.

    First, there is no reason to talk about the GPU when discussing server load. It is completely irrelevant.

    Second. magicka, stamina, and health regen have a very insignificant server load as they have the least amount of items that affect them compared to doing damage and healing skills. There is no reason to affect them.

    Even with DoTs and HoTs, the issue is with the calculations so reducing their frequency is nothing more than a bandaid. Heck, Zenimax would do better by lengthening the GCD on skills but even then it could push us to repeat basic attacks which would negate any benefit. However, this is a bad idea because it would also change combat from being fluid to more like WoW and FF. The number of players it would drive away (the reason Zenimax would not do it) would have a greater effect.

    Third, and stating again, weapon swap is so insignificant to the server load compared to almost everything else we do.

    I would suggest that Zenimax should not make such changes as they add very little to the server load but heavily affects how we play the game? These changes would have a negligible effect on the server load. Heck, the effect these suggestions would have would be even less than what Zenimax tested in Cyrodiil which they noted that they "do not have a significant enough impact on improving the overall player experience."

    However, I do thank you for presenting your thoughts on the matter. It is good to have open discussions about what may help.
  • Syrpynt
    Syrpynt
    ✭✭✭
    Amottica wrote: »
    First, there is no reason to talk about the GPU when discussing server load. It is completely irrelevant.

    Yes, in that case it is not server load, but load on the user to keep up with all the other player's animations: All the cancelling is not visible even most of the time. In PvP this gives huge disadvantages. It's exascerbated by the desync from "where" a player is relative to your character. That example sounds like a duel, but it gets worse in Cyrodiil blob raids.
    Amottica wrote: »
    Second. magicka, stamina, and health regen have a very insignificant server load as they have the least amount of items that affect them compared to doing damage and healing skills. There is no reason to affect them.

    Even with DoTs and HoTs, the issue is with the calculations so reducing their frequency is nothing more than a bandaid. Heck, Zenimax would do better by lengthening the GCD on skills but even then it could push us to repeat basic attacks which would negate any benefit. However, this is a bad idea because it would also change combat from being fluid to more like WoW and FF. The number of players it would drive away (the reason Zenimax would not do it) would have a greater effect.

    Yeah, one or 4 players, it's fine. Rarely have issues in group dungeons. But once you are in a 12-group for trials or PvP, and getting all the bonuses from other player effects and stacking bonuses--not just for you, but for all your other groupmates--it becomes overwhelming. Hence why people talk trash about Cyrodiil's performance. Removing the procs in February had a performance boost, but was "insignificant." Removing heals outside of group also was 20% but also considered "insignificant"--compared to what players actually wanted. But if players want heals ball-group raid allies, but also want better performance, the actual mechanics of cooldowns should be adjusted as a 3rd compromise.
    Amottica wrote: »
    Third, and stating again, weapon swap is so insignificant to the server load compared to almost everything else we do.

    Similar to my perspective above, it's fine for small groups. But for +10 players in a single area, everyone being weapon-swap experts at the max GCD--desync and disconnections start to happen.
    Amottica wrote: »
    I would suggest that Zenimax should not make such changes as they add very little to the server load but heavily affects how we play the game? These changes would have a negligible effect on the server load. Heck, the effect these suggestions would have would be even less than what Zenimax tested in Cyrodiil which they noted that they "do not have a significant enough impact on improving the overall player experience."

    However, I do thank you for presenting your thoughts on the matter. It is good to have open discussions about what may help.

    I think that people already leave the game over server performance issues. So to say that changing the combat would be worse than fixing the desyncs and DC's that happen to everyone in high traffic hours, and sometimes CTD--if improving the combat fixes it, then maybe just increase the GCD time by 50% instead of 100%.

    Instead of doing this on PTS, for the same players who have the same strong opinions about all the same subjects, it should be tested live for 3 days in the middle of an event when people are reporting many DC's. Just like how to had to do a live test with Cyrodiil.

    Edit:
    & yes, I also appreciate having this in depth discussion with others. o/
    Edited by Syrpynt on September 11, 2021 3:58PM
  • GRXRG
    GRXRG
    ✭✭✭✭
    You seem a pve player and talk a lot of animation cancelling, in pve you do weaving and not pure animation cancelling like in pvp where it's broken anyway and not usable anymore, it's clunky and works only on some abilities, other times won't, they just ruined it patches ago with the block changes.

    The only idea to reduce lag I had if they have obsolete server is to compartment the zones even further.

    Why in Battleground and Imperial City you lag a lot less then Cyrodiil and you are almost lag free? Because the maps are very small and divided by loading screen in between districts, so the server handle them individually and doesn't have to handle abilities casted in a huge map from bottom to top, like happens in Cyrodiil.

    Another idea could be put light attack in the same global cooldown of skills, this way you will slow down the game a lot in the gameplay which maybe sucks a lot, but you will be only to cast 1 ability per second, making the server calculations less overloaded with floods of data.
    I am experiencing this a lot with Elemental Weapon skill, when you lag you cannot weave-cast it (press LA and Elly at the same time won't work, but of you have good connection it will work everytime), with a single press of 2 buttons at the same time you get the skill firing.
  • Kuratius
    Kuratius
    ✭✭✭
    The only sensible suggestion you had, which was to reduce tickrate on dots, has already been implemented. [snip]

    Eso suffers from inefficient programming and from trying to make more and more parts of the combat logic serverside. Which I personally disagree with, but that's a different can of worms. Every fps game does client side prediction and then lets the server verify, but eso is apparently incapable of that. Some of that logic wasn't optimized because it was assumed to run on a client instead of a server, the entire design was only quick and dirty and only meant to handle a few sets and abilities efficiently, so you get the current mess. From what we've seen, at least part of the issue stems from yandere dev level coding on things like seducer sets (as a conditional) instead of simply storing a number that gets updated like they do with statstick sets like julianos that didn't get disabled. Seducer was disabled during the first proc set tests, strongly suggesting that they messed up the way it was coded. And when you have 300+ sets to catch up on....
    Branchless programming is what you'd want to look up if you're curious.


    That's not even getting into the fact that eso exclusively uses tcp instead of udp despite the higher latency, general overhead, and garbage like nagles algorithm. And believe me, I checked using tools like wireshark and netlimiter.



    Also, the thing with fpus and integers is that you can make a certain amount of operations of each simultaneously. So you want to use both efficiently, depending on how many of each you have.

    There's also the part where some of the backend server stuff was apparently completely single threaded, explaining why loading screens could in some cases be limited by server performance instead of cpu and storage speed of your own pc.


    [snip]
    [edited for bashing]
    Edited by ZOS_Icy on September 12, 2021 1:08PM
  • Sluggy
    Sluggy
    ✭✭✭✭✭
    In the end these are all bandaid fixes and heavily biased towards the way you would prefer the gameplay to function. Given what little knowledge we have I think it's safe to say none of them would have any meaningful impact on performance and would also significantly change the fundamental gameplay. There's just no way that will be a good thing.

    I'll stand with my previous assessment that it's very likely an architectural problem where efficiently accessing data is the key to performance. Unfortunately, if that were to be the case it would be extremely difficult and expensive to change at this point and still wouldn't guarantee significantly improved results. Again, not saying this is the problem. But in my limited experience there are some arrows pointing that way.
    GRXRG wrote: »
    You seem a pve player and talk a lot of animation cancelling, in pve you do weaving and not pure animation cancelling like in pvp where it's broken anyway and not usable anymore, it's clunky and works only on some abilities, other times won't, they just ruined it patches ago with the block changes.

    The only idea to reduce lag I had if they have obsolete server is to compartment the zones even further.

    Why in Battleground and Imperial City you lag a lot less then Cyrodiil and you are almost lag free? Because the maps are very small and divided by loading screen in between districts, so the server handle them individually and doesn't have to handle abilities casted in a huge map from bottom to top, like happens in Cyrodiil.

    Another idea could be put light attack in the same global cooldown of skills, this way you will slow down the game a lot in the gameplay which maybe sucks a lot, but you will be only to cast 1 ability per second, making the server calculations less overloaded with floods of data.
    I am experiencing this a lot with Elemental Weapon skill, when you lag you cannot weave-cast it (press LA and Elly at the same time won't work, but of you have good connection it will work everytime), with a single press of 2 buttons at the same time you get the skill firing.

    Generally speaking, the game would already be doing this anyway. All games use invisible spatial divisions (sometime dynamically changed in size even) to reduce the number of calculations needed in an area. However, they still need to sync up all of that state info at some point so that people can seamlessly transition between each of these invisible boundaries. Breaking up the zone would allow them to more easily break up the calculations needed for a given logical or physical machine and would then require less syncing with other machines which might help performance. But in the end, hot spots will be hot spots. You get enough people in a single IC district during an event and it's just as bad as any hammer zerg in Cyrodiil.
Sign In or Register to comment.