Idk how to tell you this, but how the UI interacts with the server is still a UI issue.The UI pretty much does that as the client parses your debuff/dots and the target's buffs/debuffs to take priority to visualize. The client can not display any info that it doesn't receive. The problem was that the server wasn't and doesn't send the full list of all buffs/debuffs/dots if it exceeds a certain limit. The server only sends you something like the first 48 buffs/debuffs/dots on the target even when it actually has 49+ buffs/debuffs/dots on it. If your debuff/dot ends up in position 49+ on the list no one is seeing it.
I know my timers well enough so that it doesn't affect me too badly.
No, it isn't. This is a case of data transfer and data storage issues which require very different considerations and solutions. The UI is for the most part doing everything correctly, but is not getting all the data that needs to be displayed. If the server was sending the full list of buffs/debuffs/dots the client could potentially parse and cull them down to primarily display the applicable ones, but the server is not.
Would you be doing alright if the total debuff limit regularly caused only 1 (if any) of your DoTs to be applied at all? Knowing your timers is meaningless if your casts are not actually applying them.I know my timers well enough so that it doesn't affect me too badly.
This. I'll also add that you if your buff didn't appear you actually had no clue whether your cast was indeed applied but just not being one of the 48 displayed, or if it had not been applied at all because it exceeded the 100 status limit. That is definitely not a UI-only issue. Playing SMN on boss fates back in 2.0 was a crapshoot whether or not you actually did any DoT damage or not.No, it isn't. This is a case of data transfer and data storage issues which require very different considerations and solutions. The UI is for the most part doing everything correctly, but is not getting all the data that needs to be displayed. If the server was sending the full list of buffs/debuffs/dots the client could potentially parse and cull them down to primarily display the applicable ones, but the server is not.
Would you be doing alright if the total debuff limit regularly caused only 1 (if any) of your DoTs to be applied at all? Knowing your timers is meaningless if your casts are not actually applying them.
K, so not a class design issue? Which is what you were calling it before?No, it isn't. This is a case of data transfer and data storage issues which require very different considerations and solutions. The UI is for the most part doing everything correctly, but is not getting all the data that needs to be displayed. If the server was sending the full list of buffs/debuffs/dots the client could potentially parse and cull them down to primarily display the applicable ones, but the server is not.
'Cause that's what I'm saying. My thing is it's how the dots are displayed is the issue, not that classes are bad because they have dots.
I think we're looking at this from opposite ends. My perspective is: server -(causing issues with)-> UI display, not dot classes being present -(being bad for)-> other dot classes
God, I haven't had that issue in a long while (I think it's been since ARR Odin), but since I've always had skills that are dependant on dots being applied, I could always tell when they were on (aka, festers hitting for the right amount, thundercloud procs, etc). It's not ideal, but in content with that many people ya rarely have to be 100% optimal. But seriously, what content are you doing right now to have ~50 BRDs or SMNs in one place? I don't think I've seen even eureka get that populated. ._.
It was a data transfer/data storage issue that was simpler and easier to solve with class design changes than trying to mess with the game's spaghetti-coded infrastructure. Pruning extraneous non-combo DoTs such as Fracture, Touch of Death, Scourge, Mutilate and Phlebotomize reduced debuff/dot totals to reasonable levels while also freeing up button space.K, so not a class design issue? Which is what you were calling it before?
'Cause that's what I'm saying. My thing is it's how the dots are displayed is the issue, not that classes are bad because they have dots.
I think we're looking at this from opposite ends. My perspective is: server -(causing issues with)-> UI display, not dot classes being present -(being bad for)-> other dot classes
HW was where it was at its worst with BRD & SUM dps being hamstrung in alliance raids, Diadem, World Boss FATEs and S-rank hunts. Groups with multiple DoT heavy jobs often had difficulty getting full credit even when they had been there from the start of the fight.God, I haven't had that issue in a long while (I think it's been since ARR Odin), but since I've always had skills that are dependant on dots being applied, I could always tell when they were on (aka, festers hitting for the right amount, thundercloud procs, etc). It's not ideal, but in content with that many people ya rarely have to be 100% optimal. But seriously, what content are you doing right now to have ~50 BRDs or SMNs in one place? I don't think I've seen even eureka get that populated. ._.
Its not really a problem anymore since the StB debuff and dot purge. Since most jobs no longer have as many dots and/or debuffs the problem isn't occurring with groups as small as 24 people nor groups that are approaching 70+. If jobs had maintained their HW level of debuffs and dots were would be hearing about this problem regularly happening with Formidable, Archeotania, and S-rank hunts
|
![]() |
![]() |
![]() |
|
Cookie Policy
This website uses cookies. If you do not wish us to set cookies on your device, please do not use the website. Please read the Square Enix cookies policy for more information. Your use of the website is also subject to the terms in the Square Enix website terms of use and privacy policy and by using the website you are accepting those terms. The Square Enix terms of use, privacy policy and cookies policy can also be found through links at the bottom of the page.