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

[VenKitsune]

Okay so at the time of writing this, Live Letter LX is not yet over, but i wanted to pose this discussion to everyone here.
During the Q&A Between Yoship and the the UI Designer, Kei Odagiri the following was talked about -

M "I think it would be very sweet if we could see whether an attack is physical or magical in a little pop up window"

O "Ohhh yea, that would probably be very handy hehe"

O "With the current system, as how the packet transfer works, as a UI team we can't do anything about this"

Y "If we wanted.... we could probably do it"

Y "There are actions that work against physical or magical damage, so I understand that it would be more useful if you understand and can instantly see where to use it"

Y "But there is a reason on why we haven't implemented it.... We always work on the battle changes until a few days before a patch and we often had to implement final changes"

Y "If we added more features that rely on this information, it would delay development a lot"

O "It would probably overwhelm the quality assurance team"

This was from the live unofficial translation done by the ffxiv subreddit team, so keep in mind that the translation might be a little rough and may well be incorrect in some manner, keep that in mind.



I have a lot of respect for the work done on the UI by the team but....Still...Im confused by this.

Why can't Physical and magical be two seperate text colours?

Why is it so difficult? The game already knows if an attack is going to be phyiscal or magical when you're actually playing the game, why not implement a system where the text colour changes depending on if its phyiscal or magical? You dont have to colour every single attack flying text individually.

We already have additional, contextual damage popups for Parrys and Blocks etc....Why cant those resources be used in a similar way?

Infact, i was talking with a friend about this a few minutes ago which prompted me to post this on the forums....But apparently, she tells me that some third party tools ALREADY DO THIS. They display physical and magical damage taken as two seperate colours. So why cant the UI team do it if its clearly possible just from reading whats already there?

When direct hits were added, Direct Critical hits were also added as a result. This is a clear example of the flying text being changed at a fundamental level for contextual damage. Why can't Physical/Magical be done in a similar vein if all it would require is a change in colour or similar to how parrys/blocks are done?



Does anyone have the answers to these questions?

[Seraphor]

I think they were meaning more along the lines of, if a casting attack is going to deal physical or magical damage then it will look different. Which would be a more major UI change and if the damage isn't fixed to one type until days before the patch goes live, then I can see that being an issue.
They mention a 'pop up window' even, so what was being asked was quite a change to the current system.

What you mean is changing the colour of the floating text after the damage has been applied, to signify that it's magical/physical. It's after the fact, but allows you to learn without additional steps.
This is probably easier to implement, but it doesn't seem like that's what they understood as the question.

[PangTong]

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 don't see why it needs to be some kind of "extra" thing added on to attack data that will somehow cause problems when they need to make last minute changes. Just let us read what's already there.

It doesn't need to be a fancy popup or anything, just changing the text colour of the flying text or cast bar is enough. Hell, even if all that happened was that the attack had (magical) or (physical) after its damage value in the battle log, this would still be miles more helpful than the current arrangement where it's literally a complete mystery, nothing in the game will tell you what type of damage you're receiving. Instead the only way to know if an attack is magical or physical is to either use third party addons (and the fact that these addons can read the properties of an attack and display its damage type should be more than enough evidence to prove that its possible in the actual game), or to simply run experiments to see if the damage is affected by magic-only or physical-only defense buffs.

[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.

[Semirhage]

I suspect the client doesn't have the information, and that's probably the core issue.

Naming no names and discussing no specific forbidden third party things, but from researching the thingy the OP implied existed, the client absolutely receives this information as part of incoming damage network info. In fact, it also natively has the ability to change the color of damage text but they haven't made use of it. While edge cases may abound, there's a third party *cough* nonexistent *cough* tool that does this on a basic level with a relatively simple script.

[Packetdancer]

Naming no names and discussing no specific forbidden third party things, but from researching the thingy the OP implied existed, the client absolutely receives this information as part of incoming damage network info. In fact, it also natively has the ability to change the color of damage text but they haven't made use of it. While edge cases may abound, there's a third party *cough* nonexistent *cough* tool that does this on a basic level with a relatively simple script.

Naming no names and discussing no specific forbidden third party things, my—admittedly presently sleep-deprived—understanding is that the third-party tool in question bases it on whether the combat log is told to say "X uses Y" or "X casts Y", which indeed a very simple script. However, my understanding is also that the 'casts/uses' message is not actually based on whether the damage is magical or physical, but whether the originating ability is handled as a weaponskill or a spell.

But whether it's a weaponskill or a spell isn't guaranteed to be tied to the type of damage, but rather how it's handled in other parts of the combat system. RDM's Enchanted Moulinet, for instance, is a weaponskill (...I think?) but does unaspected magical damage, while the non-enchanted Moulinet—also a weaponskill—does physical. Because it is a weaponskill, you should still be able to use Enchanted Moulinet when silenced (provided you had enough black/white mana before getting silenced, anyway), but it will still do magical damage.

Conversely, it wouldn't surprise me if the three mobs with the obnoxious AoE paralyze in Puppets' Bunker are using a spell (since it's a cast-bar that can be interrupted), but that the attack which paralyzes might well do physical damage. (Mind you, it wouldn't surprise me if it does magical damage either, because rational definitions of magical and physical do not always apply in this combat system.)

Though whether the originating attack is a spell or weaponskill will probably get you like 95% of the way there, admittedly.

And I certainly may be wrong; I haven't bothered to try to slice open the FFXIV network protocol to know whether or not it actually does include the type of damage rather than just the indicator of whether the source is a spell or a weaponskill, nor is the source code for the totally hypothetical unnamed tool available that I know of to take a quick look at it.

However, my larger point is just that from (somewhat painful) personal experience, I know how design decisions made early in a game's life that made sense at the time can come around to bite you several years later when players want a seemingly-entirely-reasonable feature that has you tearing your hair out to try to figure out a sane way to implement without having to gut chunks of established systems to do it.

It's certainly conceivable that for some reasons Square-Enix is just making excuses and the client has all the information needed, and they could do five minutes of work to make it happen. But it's also possible that Square-Enix made some decisions years ago which became part of the scaffolding of current systems, and trying to take out and replace a piece is like trying to remove one of the bottom sticks in a Jenga tower: sure, it's possible, but you're going to live in fear of the Jenga tower falling over.

[ADVSS]

But whether it's a weaponskill or a spell isn't guaranteed to be tied to the type of damage, but rather how it's handled in other parts of the combat system. RDM's Enchanted Moulinet, for instance, is a weaponskill (...I think?) but does unaspected magical damage, while the non-enchanted Moulinet—also a weaponskill—does physical. Because it is a weaponskill, you should still be able to use Enchanted Moulinet when silenced (provided you had enough black/white mana before getting silenced, anyway), but it will still do magical damage.

Pretty sure the RDM does magic damage because his weapon is set for magic damage(of course auto attacks might be different, but skills that are meant to scale with x damage type wont scale with the wrong damage type). Same reason why PLD had to get Clemency because his cross class Cure spell didnt scale with his weapon damage at all. As cheeky as it is, i am totally not surprised that RDM anything does "magic damage" because his weapon has the magic damage tag. As far as people complaining client side this client side that. If the "information" wasn't there to tell whether you got hit by physical or magical damage, then physical/magical cooldowns are either text flavored, or they work specifically and its not true, and/or they dont work at all and theyre just there as fluff skills on tanks

[Semirhage]

snip

Based on a nonexistent thing's lack of support for TEA, I believe you're correct. It likely relies on a set of known data for things like Darkness damage (which I don't recall off the top of my head whether it has a tip-off phrase in the combat log). Like you said before, relying on the text indicator is going to get you almost everything you need, but those few scenarios where it doesn't, that's the part that'll get Square if they tried to implement it officially.

[StriderShinryu]

Seraphor already covered most of it, but the other point about "But 3rd Party Apps!" is related to the data actually being used to generate the display. All a 3rd party app has to do is read the output with no real QA or technical requirements. In other words, they're basically just reading a text file already output by the game. An in game solution would require reading both the input and output data flow, and would have to actually be tried and tested in QA to ensure basically 100% accuracy. There's a lot more going on there that 3rd party apps don't have to deal with.

Would it be possible? Yeah. Is it considered worth doing? It seems not.

[Eriane_Elis]

Better Translation: It requires effort even though it's probably really easy.

I've submitted game breaking bugs both in-game and on the forums and they get thrown in the pile of "works as intended" when it involves some form of work. I don't really understand it, they accept mundane camera "bugs" but won't accept complete character lock such as when you donate at the enclave then try to take your stuff back under certain conditions it will lock your HUD and make you unable to exit. Or when you can't chat anymore because your crafting macro ended on a controller but not on keyboard etc etc... It is what it is, they will fix what they feel like fixing. Not trying to troll, this is just my thoughts on it, not like it matters to anyone.