Remove cap for debuffs (15) such as bleed and shred armor

[Zarathulhu]

It’d be really nice to know how many bleeds / shred armors we can actually manage to sustain on a high health target, however there is a cap of 15 afterwhich the game only displays “15+”. Could you please remove this 15 cap and always show the total of such debuffs please?

[TriKster]

Hi, this might be interesting for you.
2 Dev responses

Ailment stack 15+, why?

I believe it’s a technical limitation / performance consideration. There’s a similar thing in place for ailment visual effects.

More ailments stacks visible

We would love to be able to give the full ailment stack counts. We can’t do it without compromising the performance of the game. I know this seems like a trivial system. It’s something that people were very confused about why we didn’t have it at all for a long time. This has been on our feature request list for years. The 15 stack limit is the only way we have been able to get the performance we need to not cause major problems. If we find a way to increase the visible stack count, we will.

[Kotli]

You can have more than 15 stacks applied it just that the counter has to stop at 15+ due to technical reasons at the moment.

[Zarathulhu]

Thanks all

[Behemmoth]

Probably instead of counting individual stacks past 15, we could have an estimative?

For instance:

16 stacks of X effect up to 35 stacks = 25+
36 stacks of X effect up to 55 stacks = 35+
46 stacks of X effect up to 65 stacks = 45+

That way despite not having the exact numbers we can have an idea of how many debuff stacks the enemy has got, while at the same time not decreasing the performance?

[Zaodon]

As a software developer, I have to assume the limitation is counting the number, not displaying the number.

[Behemmoth]

But isn’t the limitation visual only, as Kotli stated above? That’s why I suggested an estimative

[Zaodon]

The game has to actually apply stacks to the monster. And it has to know how many are there, and how much damage they do. All that seems to work without performance issues.

Then, the devs have to get the count of each stack of each thing (bleed, poison, etc.). Then they have to show an icon when you hover over the monster to show that ailment, and its count.
So far, so good.

So where is the performance issue?

• It can’t be in the actual count, because that’s needed to deal damage and make the game work.
• It can’t be in the drawing of the icon, because that’s been added.
• It can’t even be in the drawing of the # on the icon, because that’s also been added.

So where is the issue?
Answer: It’s in the polling loop between the icon and the monster.

When you see 1, then you see 2, then you see 3, those numbers are changing in real-time. The second you apply another stack of whatever, that number nearly instantly goes up. If a stack ends, the number goes down. This means the client is constantly trying to update each number of each stack. If you’re attacking fast enough to put tons and tons of stacks, then the client would need to poll for the count REALLY FAST - i.e. constantly. ← That is what would bog down the performance. If they poll less-fast, then the count would be “inaccurate”, but not have a performance issue. Hence, an estimate is given “15+”.

Now, this is my educated guess. I don’t work for EHG and have no idea what the root cause of the performance problem actually is. But this is, IMHO, the most likely cause.

[Behemmoth]

This is basically why I actually suggested an estimate. The server already knows how much stacks the target has, as it needs to constantly calculate how much damage the it is about to receive with all the debuffs effects on it. This would be for 1 player, but when multiplayer comes the data will have to be sent to everyone, with each player applying/reapplying new debuffs all the time, the insane calculations that need to happen in such a short amount of time will be delayed just to provide us information in real-time when it really wouldn’t be necessary.

I really don’t think it matters to anyone if the target has exactly 67 armor or resistance shreds for instance and thus i’m totally against such “precise display”, but being able to see how much stacks we’ve got on average may actually help us deciding if we should try to get more debuff stacks or not. As with the shred example above, if I could see that the target has “50+” stacks I could already think “this is already good, but may i sacrifice something to apply more stacks to provide more damage? what would happen if i get it to lower a bit?” We wouldn’t be left so much in the dark.

The other way i see that we can have the player informed of the amount of debuffs the target has, without impacting performance, is if it happens periodically, say for every X seconds for each stack that goes above 15.

From my point of view if the server has performance hits when sending the data every X seconds or whenever it reaches/goes down a threshold, then we already have a performance hit happening. Also, I don’t see how the game will handle to calculate all the debuffs that can be applied from each and every single player in a party, when it struggles to simply say “hey, X stacks of Y debuffs applied” every few seconds.

If right now it gets such performance hits and cannot cope with sending us data every now and then, we’ll have a more serious problem when multiplayer comes. Probably they’ll need to hardcap the debuff stacks.