WTL; WR: It seems like ESO combat is trying to have it both ways, and structural gaps between two diverging design approaches are what cause 80% of my damage problems. Please lean more into one or the other.

TL;DR: ESO wants twitch-action timing on top of a historically TCP-heavy, server-authoritative MMO stack. TCP preserves order, not the timing relationships that ESO routinely makes mechanically significant, so the application layer has to bridge that gap. Right now it doesn't always do so cleanly, and the result is a combat system where valid-looking inputs can die in short-lived action states, the ability queue, or somewhere else. Lean harder into buffering and preserving player intent, or lean harder into temporally authoritative action combat. The current hybrid is too sloppy.

I think I have finally isolated what bothers me about ESO's combat, and it's not really animation cancelling by itself. It's that ESO demands an input style that does not fit particularly well with the networking model underneath it. Before somebody says "skill issue", maybe. When I do execute, I execute well enough, I think. That doesn't make my opinion correct, but it should at least dispose of the idea that I simply have not learned how to weave. I am criticizing a system that I do understand.

The problem is the familiar one. I light attack, press an ability, see the ability bar acknowledge the input, and the ability does not fire as expected. The light-attack animation continues long and proud, feeling like it's on a hard 1s cooldown, and I'm left asking a question that just shouldn't be this big part of a precision combat system. Was that me, or was that the game? That issue is responsible for practically all of my parse resets, but I think it's symptomatic of something structural.

ESO's gameplay networking has historically been documented as relying heavily on TCP. I am deliberately not claiming that every packet ESO sends today is TCP, because current documentation also references UDP. But ZOS has publicly described the game connection as TCP, and independent packet captures have observed ESO gameplay operating over TCP. The chosen layer 4 protocol itself isn't the problem. TCP is extremely good at reliably delivering an ordered stream of information. However, its reliability guarantee is not a guarantee of timely application delivery. Under loss, retransmission, buffering, or ordinary network and processing variance, TCP's ordered stream can hold later data behind earlier missing data. In a combat system where the meaning of an input depends upon sub-second sequencing, that jank can have immersion-breaking knockon effects, which is why TCP-heavy action systems need unusually good multilayer data handling.

Compounding the issue, gameplay behavior strongly suggests that ESO assigns mechanical significance to brief, unprotected intermediate action states in abilities like Boneyard, Lightning Splash, and Volley. A subsequent Light Attack can interact very differently depending on where the ability is in that transition; on one side of the boundary the skill survives and its animation is truncated; on the other, the subsequent input can overwrite the skill, i.e. a light attack can cancel this intermediate state, and we're stuck in an unusually long LA/action state before the next ability can successfully resolve or supersede it, apparently as a consequence of how the input and combat-state pipeline adjudicates the sequence. That is exactly the sort of distinction for which command ordering alone is insufficient. If tens of milliseconds between two local inputs can determine which action state wins, ESO also needs to preserve and consistently adjudicate the temporal meaning of those inputs. TCP does not supply that semantic information for free.

TCP guarantees that the bytes encoding the earlier command are delivered in stream order before the bytes encoding the later command. What TCP does not preserve is the fact that the client generated those two commands tens of milliseconds apart. Under ordinary jitter, buffering, or especially retransmission/head-of-line blocking, they may become available to the server-side application with substantially different spacing from the timing with which they were generated locally, including very close together after buffering or retransmission. Preserving and interpreting that temporal relationship is ESO’s application-layer responsibility. If ESO adjudicates those commands against short-lived combat states at processing time, that can potentially change which state the subsequent input encounters, and therefore how the sequence resolves. TCP's strict sequencing is specifically associated with head-of-line blocking when earlier data is missing or late.

The other half of the design is much harder for me to reconcile with that architecture. ESO asks for almost twitch-action-game levels of sub-second input sequencing on top of a historically TCP-heavy, server-authoritative MMO stack. A highly latency-sensitive active combat system generally cares enormously about when inputs actually happened, and those systems are commonly designed around techniques that prioritize temporal freshness - prediction, timestamps, reconciliation, purpose-built reliability, and often UDP-based transport for the time-sensitive traffic. The precise implementation varies enormously from game to game, but the philosophy is clear; if fractions of a second are part of the game, then networking and input architecture has to be built around preserving the meaning of every action made within those fractions of a second.

If ESO is fundamentally going to operate through reliable, ordered, server-authoritative communication, then its combat-input model should lean toward preserving player intent better than what it currently does. Lean the combat system further into how TCP operates through the layers. Maybe give the ability queue more room to work (not arguing for more latency here). Accept reasonable inputs early. Timestamp them. Preserve their ordering. Resolve them at the first legal opportunity. Let the player say, in effect, "Light Attack then Ability X," while better preserving the temporal relationship between those inputs. It should buffer player intent, preserve command ordering, as well as timing information, and resolve commands coherently despite heavy loads or ordinary processing variance.

ESO seems to straddle both approaches. It wants reliable, ordered, server-authoritative MMO networking, while also treating timing-sensitive ability interactions as combat mastery. Between my mouse and the authoritative result sit client state, animation state, buffering, the ability queue, network transport, validation, and server processing. Somewhere in that layer cake, inputs my UI visibly acknowledges too often evaporate into yet another dummy reset.

The problem isn't that networks have latency; every online service has latency. The problem is that ESO layers a timing-sensitive action-combat input model on top of a networking architecture optimized for reliable, ordered delivery, without sufficiently (so it seems) designing the input queue and combat-state handling around the consequences of that choice. ESO wants the feel of a low-latency, timing-sensitive action game while retaining a historically TCP-heavy MMO networking model, and too much of the burden of reconciling the inherent jank between those two approaches is left to interpretive benchmarking, mystery, skill issue, or, just actually, fighting with a server over what my client sent and when.

Sooo, what do? Maybe lean into TCP's strengths. Use a more developed input queue. Buffer commands generously enough that ordinary jitter and processing variance do not become part of the player's rotation. Preserve intended sequences and execute them when legal. Since those milliseconds matter, the application layer has to preserve that temporal intent explicitly and adjudicate it more consistently than it does now at those marginal boundaries. The player still has to make the correct decisions and maintain a strong cadence, but the network plumbing stops pretending to be part of the skill check. Or just err in the other direction. If ZOS really wants combat mastery to include tight, sub-second execution windows, then develop the input pipeline more solidly around that requirement. Make temporal precision genuinely authoritative, even if it means adjusting the input windows. Use whatever combination of prediction, timestamped commands, specialized reliability, networking changes, or reconciliation is necessary so that two correctly executed local inputs reliably mean the same thing to the server. At the combat-state level, maybe grant these pre-resolution/commitment/aiming states higher action priority than Light Attacks, while queueing post-skill Light Attacks to resolve immediately after the skill either commits or legitimately fails.

I don't particularly care whether ZOS solves this by leaning further into reliable ordered networking or by leaning further into temporally authoritative action combat. I care that it stops leaving the unresolved seam between those models inside the player's rotation. The current system feels like it's trying to force a freshness-first, twitch-action combat philosophy, the kind commonly implemented using UDP-based or purpose-built real-time networking, through a historically TCP-heavy framework without doing enough at any layer to reconcile the differences. That leaves the player compensating for the architecture. Not good feels. I want to be mastering my class, my rotation, positioning, encounter mechanics, resource management, timing, and decision-making. I do not want to also be questioning how much uncertainty exists between an acknowledged button press and the authoritative server deciding when or whether that button press became an action. If I make a mistake, make me pay for it, but I also want to know that the mistake was mine. ESO's combat-input system just feels too sloppy at that boundary right now. Trying to live halfway between the two is exactly how we ended up with "was that me, or was that the game?" punctuating successful rotations.

Not a rant, just a very, very long-winded thought.