Dipping into Dots

[Carighan]

I don't think it sounds very likely – not because it couldn't be interesting but because as I understand it, they're edging away from DOTs in general because it causes issues in large-scale battles where a boss can only have so many status effects at a time, so jobs reliant on applying statuses can't perform to their full intended ability.

This is so wild to me because while this is an issue every MMORPG had to tackle a long time ago, they all solved it. And FFXIV is >10y old, it really has no excuse not to have solved it so far.

An easy one if your engine is hard-limited in how many timers it can possibly track is to "cheat" DoT timers on raid targets (and ignore the issue of DoT pushoff on trash mobs because it's really not that important, usually an upside of a DoT class is that they keep a large percentage of their damage when fully mobile which helps on bosses and is balanced by their lower AoE/trash damage): You don't actually have the server track a DoT that deals damage every 3s or so. The GUI shows the applying DoT caster their DoTs, and damage numbers are shown as if the DoT is ticking. In reality, all of this is done in a single serverside function though with some efficient external code that simply tracks DoTs in aggregate, and adds to the total DoT-potency or deducts from it as debuffs are "applied" (they're not) or fall off (they don't). Usually as an actual external software piece that can in-realtime increase or decrease the value of this single, "aggregate", DoT.

An even more extreme version an old MMO I played did was: When you apply a DoT to a boss, it doesn't deal any DoT damage. Rather the server has an invisible combatant that will, in say, 18 seconds, deal the total of the DoTs damage to the target. It would also do this on re-application, cut by the remaining time on the delay-timer of course. This works because bosses have so much health that it's virtually impossible to know whether your DoT didn't deal all damage at once at the end. The combat log would say "Your XYZ did a total of ABC damage to OPQ", which is in fact mechanically exactly what the server did, it never bothered tracking a DoT.

[Mikey_R]

This is so wild to me because while this is an issue every MMORPG had to tackle a long time ago, they all solved it. And FFXIV is >10y old, it really has no excuse not to have solved it so far.

Neither of what you have said is actually the issue here.

Every enemy is hardcoded to be able to support a maximum of 60 status effects. Of those 60 effects, only 30 are shown on the HP GUI.

If your DoT ends up in one of the spots past 30, you will not be able to see it, even if you only track your own status via the option in the settings, if it ends up in the last 30, it will not show.

If you refresh the DoT and it is part of the last 30, it stays as part of the last 30, even if there is theoretically space for your DoT to be visible.

This was an issue that only really reared it's head in Alliance Raids up to HW and to a lesser extent, SB. On those expansions, the number of debuffs a single party can inflict with 100% uptime was already quite high (basically every job had at least 1 DoT and many had either damage downs or resistance downs, it adds up quickly). Multiply that by 3 for an Alliance raid and it quickly extends into the over 30 debuff slots. This is one of the reasons why so many DoTs have been removed from jobs over the expansions, along with other debuffs.

Now, why this cannot be changed, I do not know. I am not a programmer and I do not know how it is all programmed, but if it was a simple thing to solve, you would have thought they would have solved it. Especially since it does also affect hunt mobs and it can have an effect on players too, with fights like TOP having so many buffs/debuffs, player buffs were being deleted to make room. This was also an initial concern for Viper when it was released as it too has a lot of buffs just to do it's rotation.

[Azurarok]

This was an issue that only really reared it's head in Alliance Raids up to HW and to a lesser extent, SB. On those expansions, the number of debuffs a single party can inflict with 100% uptime was already quite high (basically every job had at least 1 DoT and many had either damage downs or resistance downs, it adds up quickly). Multiply that by 3 for an Alliance raid and it quickly extends into the over 30 debuff slots. This is one of the reasons why so many DoTs have been removed from jobs over the expansions, along with other debuffs.

It's still a notable issue with players, made worse in DT by the slew of '-ready' buffs being procced by raid buffs and the like. They really need to raise the number of slots somehow

[Carighan]

Neither of what you have said is actually the issue here.

Every enemy is hardcoded to be able to support a maximum of 60 status effects. Of those 60 effects, only 30 are shown on the HP GUI.

If your DoT ends up in one of the spots past 30, you will not be able to see it, even if you only track your own status via the option in the settings, if it ends up in the last 30, it will not show.

Oh no I understood that part (granted I was thinking more about the hardlimit of 60, not the UI-limit of 30).

But yeah it's annoying because like you say, it should have been changed long ago.

The status-hardlimit is solved like I said, by effectively only having one big DoT serverside that usually runs on a separate machine and interfaces with the main game code by applying direct hits of damage every 3 seconds and updating the time left on various DoTs to sync out to the players (the server never actually tracks the DoTs, it just sends those times to the clients).

The UI limit is even more easy to fix. Your client knows that your DoT has 18 seconds once applied. It knows that when you re-apply it with 11 left, that number goes up to 18. Especially if the server never wants to track the actual DoT anyways (as per above) then there's no reason to ever make DoTs an actual debuff, as in, the entity on the server actually has "Combust" on it or so. Rather what happens is:

1. A signal "Player has applied Combust on target X" is sent to the server. As per above the server sorts this out, never puts it into the debuff tracking, and instead forwards it to the DoT tracking engine.
2. The player's client, completely independent of any actual effect, starts showing an icon and counting down seconds, ensuring this is always shown before actual debuffs as synced to the server starts.
3. If the DoT tracking engine sends an update about remaining duration to the client and it differs, the client sets the remaining duration on the shown icon to that and keeps counting from there (just to re-sync when the effect ends).

And this is a fairly basic optimization, you can do much better but this can essentially be transplanted into an existing system at no cost.