i kind of doubt it is even possible to do.
Even if i wanted it, it feels like that is irrelevant.
the skills have been changed.
Fire Breath is now a channel similar to Fatecarver, you cannot revert it with a style as you would be missing a lot of fire from the skill.
i kind of doubt it is even possible to do.
Even if i wanted it, it feels like that is irrelevant.
the skills have been changed.
Fire Breath is now a channel similar to Fatecarver, you cannot revert it with a style as you would be missing a lot of fire from the skill.
i kind of doubt it is even possible to do.
Even if i wanted it, it feels like that is irrelevant.
the skills have been changed.
Fire Breath is now a channel similar to Fatecarver, you cannot revert it with a style as you would be missing a lot of fire from the skill.
I'm also don't think that rig animation can be reverted to old style, but I guess it's possible with effect textures, like right now we have its different recolors.
WoW made some old skill style variants for players pissed with modern effects, and I dont see why we cant have this option in ESO. The more customisation - the better.
HazierBlue wrote: »Makes zero sense from a development standpoint and a waste of resources. The game is already held back by having to cater to old gen consoles. I imagine having double the number of animations would be disastrous for a game that is already struggling with performance.
HazierBlue wrote: »Makes zero sense from a development standpoint and a waste of resources. The game is already held back by having to cater to old gen consoles. I imagine having double the number of animations would be disastrous for a game that is already struggling with performance.
MXVIIDREAM wrote: »The key here is that we’re talking about existing animations that already work in-game. Offering them as optional Skill Styles wouldn’t double the number of animations in memory at once; it’s more like a toggle, where only the selected animation plays.Memory and CPU usage remain essentially the same as before — the toggle is purely visual.
Animations are loaMXVIIDREAM wrote: »The key here is that we’re talking about existing animations that already work in-game. Offering them as optional Skill Styles wouldn’t double the number of animations in memory at once; it’s more like a toggle, where only the selected animation plays.Memory and CPU usage remain essentially the same as before — the toggle is purely visual.
Animations are all loaded into memory. They are not drawn from the server. They all sit client side.
Animations are loaMXVIIDREAM wrote: »The key here is that we’re talking about existing animations that already work in-game. Offering them as optional Skill Styles wouldn’t double the number of animations in memory at once; it’s more like a toggle, where only the selected animation plays.Memory and CPU usage remain essentially the same as before — the toggle is purely visual.
Animations are all loaded into memory. They are not drawn from the server. They all sit client side.
MXVIIDREAM wrote: »They’re client-side, yes — but only the selected animation is instantiated and evaluated at runtime.
MXVIIDREAM wrote: »Style variants don’t mean parallel animation logic or doubled workload; it’s a simple asset swap, similar to existing skill styles or cosmetic overrides. From an engine and performance standpoint, the impact is effectively negligible.
MXVIIDREAM wrote: »They’re client-side, yes — but only the selected animation is instantiated and evaluated at runtime.
Nope. Toon animations are all loaded at runtime - how do you think you are seeing other people animations?! Other animations such as mob or say harrowstorms are loaded when you port into their zone.MXVIIDREAM wrote: »Style variants don’t mean parallel animation logic or doubled workload; it’s a simple asset swap, similar to existing skill styles or cosmetic overrides. From an engine and performance standpoint, the impact is effectively negligible.
Colour variants are not the same as animations.
MXVIIDREAM wrote: »But local skill animations?
MXVIIDREAM wrote: »But local skill animations?
Skill animations are not "local". All players see all other players animations - so to have changeable animations means that both animations must also be loaded into memory. There would then also need to be an additional check in the code so (for example) my toon knows which animation your toon is using.
MXVIIDREAM wrote: »skill animations are stored as assets on the client. Only the currently active animation is instantiated and evaluated at runtime. Replication to other clients does not require both variants to be playing simultaneously — it simply sends the reference of which animation to play.
MXVIIDREAM wrote: »skill animations are stored as assets on the client. Only the currently active animation is instantiated and evaluated at runtime. Replication to other clients does not require both variants to be playing simultaneously — it simply sends the reference of which animation to play.
1) Runtime is when the game loads. So to have access to both, both need to load.
2) It's not about playing simultaneously - to play the animation it first has to be loaded. Not knowing which animation someone has means the game has to load both, so it can play one or the other.
MXVIIDREAM wrote: »Skill animations are fully handled by the client — loaded, instantiated, and rendered locally. The server only tracks skill usage and sends a small reference so other clients know which animation to play. It doesn’t matter how many variants exist on your client; only the one being played is instantiated and evaluated. Extra variants sitting on disk do not consume runtime memory or CPU/GPU until used. This means having multiple skill animations has no meaningful impact on client or server performance.
MXVIIDREAM wrote: »Skill animations are fully handled by the client — loaded, instantiated, and rendered locally. The server only tracks skill usage and sends a small reference so other clients know which animation to play. It doesn’t matter how many variants exist on your client; only the one being played is instantiated and evaluated. Extra variants sitting on disk do not consume runtime memory or CPU/GPU until used. This means having multiple skill animations has no meaningful impact on client or server performance.
You are so close to getting it. Let me try get you over the line.
I load up my Templar - the game loads into memory all 54 animations for my Templar skills AND all 324 animations for all other class skills - because at some point i'm going to see another player cast one.
Those all sit in memory until the server tells my game which one to play. Doubling up those 378 animations means I now have 378 additional animations sat in memory just in case they need to be played.
It also means instead of my client being told a DK just cast skill X, the server now needs to check which variant of X the DK is using, and then tell my client a DK has cast skill X with variant A.
That's additional memory usage on the client, and additional server calcs. Now replicate that across the board for 12 people in a trial, or 900 people in Cyro. That's a lot of extra server calcs at a time when ZOS are seeking to reduce them.
Edit for clarity: Animation files do not sit on a disk waiting to be played - they are loaded into memory at runtime for faster access when needed.
MXVIIDREAM wrote: »Yes, clients preload animations for other players, but doubling variants adds only a few MB per animation and a trivial network flag. Only the active animation is instantiated and evaluated; everything else sits dormant in memory. The impact on client or server performance is negligible.
MXVIIDREAM wrote: »Yes, clients preload animations for other players, but doubling variants adds only a few MB per animation and a trivial network flag. Only the active animation is instantiated and evaluated; everything else sits dormant in memory. The impact on client or server performance is negligible.
And again: The game already has limitations because of memory. It also has performance issues because of server calcs. One extra calc is negligable - hundreds at the same time are not. ZOS are already limiting memory, and are already trying to reduce server calcs. That would run contrary to your claim it won't affect performance.
Pepegrillos wrote: »I can't remember where, maybe in the last combat Q&A, but I think I heard one of the combat devs said that they had to make new animations to fit the changes to some of these skills. I'm not sure if the old animations would fit the new stuff.
MXVIIDREAM wrote: »MXVIIDREAM wrote: »Yes, clients preload animations for other players, but doubling variants adds only a few MB per animation and a trivial network flag. Only the active animation is instantiated and evaluated; everything else sits dormant in memory. The impact on client or server performance is negligible.
And again: The game already has limitations because of memory. It also has performance issues because of server calcs. One extra calc is negligable - hundreds at the same time are not. ZOS are already limiting memory, and are already trying to reduce server calcs. That would run contrary to your claim it won't affect performance.
Last time I’ll reply as you’re taking away from the poll significantly now
Extra skill animation variants are almost invisible to the server — it only sends a tiny reference ID so other clients know which animation to play. The server doesn’t process or evaluate the animation itself, and only the active animation is instantiated on the client. Compare that to Cyrodiil’s new HoT system: the server has to check every player for multiple HoTs, track how many are active, and reduce healing by 50% after the third. That’s a per-tick, per-player, multiple times per second,scaling calculation that happens large PvP zones. In comparison, optional skill animations are trivial for both client and server, and have effectively no impact on performance.