(LL Discussion) Physical and Magical not distinguishable? UI can't implement it? Why?

[Packetdancer]

I have to agree that it's odd they say it can't be done. Any given ability must clearly have some kind of data flag in it which defines whether it does magical or physical damage, since that's necessary for it do actually do the correct damage type when playing. Why can't the client simply read this information and apply some sort of simple UI change to indicate an attack's damage type?

I suspect the client doesn't have the information, and that's probably the core issue. I'm going to go out on a limb and guess that the client doesn't have a concept of 'damage type' at all; all damage calculations are almost certainly handled by the server. So the client tells the server "I executed this ability" (where the ability happens to mitigate magic damage). The server just tells the client "you took <X> damage". The client doesn't know that the damage was magical or physical, the client just knows that the damage is <X> amount; the value of <X> as communicated by the server may be lower or higher depending on what mitigations the server is aware you have.

I mean, the damage processing part of that is fairly standard for MMOs (and really, any server-based game). The thing is, I can't see anywhere in that where the client ever needed to know the damage type, which means the client probably has no provision for that information to be conveyed from the server in the first place. So either the client would need to have every single possible enemy attack added to a table that lists whether it's physical or magical, or the actual client/server protocol would need to be changed to contain additional combat information in the packets.

Moreover, consider that the server architecture originally supported elemental-aspected damage types, and almost certainly supported combinations of them depending on certain things. So I'm guessing that behind the scenes the server does the calculation of total damage done and just hands that back. Think of Dungeons & Dragons, when you have a holy sword and the attack does <X> amount of slashing damage but also <Y> amount of radiant damage; the DM will take into account any mitigations the target has (i.e., takes half damage from radiant damage, for instance), and then just subtract the total resulting damage from the target.

Even without the old elemental-aspected damage, if there are any attacks which do both physical and magical damage—and it wouldn't surprise me if there are some—that means the server would calculate the mitigations separately and then just hand back a total damage, rather than handing back a "you take <X> physical damage and also <Y> magical damage". So at that point, communicating whether damage is physical or magical would require splitting any such attacks up into two separate attacks and sending the damage results separately.

And that is not only a non-minor change, but also would have implications for some abilities; think of Third Eye, where it reduces damage taken from the next attack by 10%. If you have an ability that does both physical and magical damage, if the resulting damage is sent as a single attack, Third Eye will mitigate the entire attack. If you split it into two separate attacks, now Third Eye would only mitigate the first. So for things like that to work, you'd need to actually change it so that all damage was bundled into 'attack' envelopes and then the physical and magical damage would share an 'envelope' to make them a single attack, while displaying the damage amounts separately...

I mean, I don't know for sure that's how any of their server architecture works; that's all just hypothesis and guesswork (albeit guesswork based on personal experience both as a software dev in general and a former game dev in specific). But from personal experience, things like that are 100% how you end up with spaghetti code/"that would be a lot of work to change" scenarios that make a given feature request a massive ask, when the request seems on the surface to be utterly reasonable and fairly straightforward.