Dipping into Dots

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