Adding in a settings option to toggle barrier on/off

[John-Dean]

This first of all locks the settings for vcpkg so that the build is consistent regardless of VS version.

Secondly, adds a new option to the extension setting called "Include barrier":

When checked, the addon will include barrier stats (so they show healing + barrier) on all the overlay windows, when disabled it is the same as the current behaviour.

Ideally this would be on the exclude menu on each window, but as far as I can tell this would require a more rework - as I don't think the combat event type is accessible with these checkboxes.

[Krappa322]

Some thoughts:

1. Could we make the option to include/exclude barrier generation per window rather than global? I imagine this would be much more useful since then you can keep both windows up at the same time and you could separate the two. Perhaps the proper place in the UI is under "stats exclude" and there you have an option for "healing" and one for "barrier generation" 1.b If we do that, maybe we could also paint the bars in the window based on how much you have of each? So if you do 70% healing and 30% barrier generation, we paint a bar that's 70% green then 30% beige? 1.c Let's maybe also add an option under the "Sort by" option where you can select to sort by barrier generation (ascending/descending)? And I guess one for healing + barrier as well ("Total outgoing" maybe?) 1.d Let's maybe also add a new window preset which is "Peers Barrier Generation"?
2. Can we try to consistently call it "barrier generation" rather than just "barrier" as I think it's unclear what means what. You can obviously pad your own stats quite a bit by just spamming barrier off cooldown but that's hardly being a good player, and it should be obvious to everyone reading the stats that they are seeing the barrier generation, not the used barrier (i.e. the generated and consumed barrier)

For the actual implementation on 1., I imagine you have to tag the events whether they are healing or barrier when storing them, but that shouldn't be too hard. Then aggregate all the barrier into a separate variable during the aggregation

[Krappa322]

Nice work btw, I'm surprised you can get something somewhat usable just by removing a few if cases, I didn't think about that at all 😄

[John-Dean]

I agree with your points around doing this per-window - and it's where I want it to head.

For now it functions, and my guild is going to test it in a few raids to confirm it's all working as expected, then I'll explore the option of doing it per window.

The per window I think will need a wider code change, perhaps having 3 healing totals - non-regen healing, all other healing, barrier - which can then be totaled for the window; but I'll need to review your code further to implement that change.

I'm away now for a week, so apologies, this is going to sit for a while.

[Krappa322]

Awesome, no worries

[John-Dean]

Also, just thinking out loud, in theory can't we work out if the barrier expired or was actually "used up"? I'm sure arcdps must throw events for that.

[Krappa322]

Arcdps gives you, for each damage event (in area combat), info about whether the damage was absorbed by barrier or not.

The issue is how you determine whose barrier was consumed - who generated the barrier that was lost in this damage event. Now that would be doable at face value - although very complicated since you have to keep track of all barrier stacks and their durations - but it's impossible as far as I can tell because we don't have a consistent way of ordering events. Barrier events come from local stats and damage events come from area stats and they really are not possible to, consistently, order against each other. Similarly, your local stats can not be ordered against those you receive from a peer over evtc rpc

[Krappa322]

Maybe you can look at the timestamps in events and get something that's like 98% accurate. I haven't done anything like that historically but not really opposed to it, as long as we make it clear to the user about what the shortcomings are

[John-Dean]

I think it's easier than you make out.

Looking into this there is an area event "BarrierUpdateEvent" and that shows % increases/decreases of barrier.

I would consider any barrier that takes damage to be worthwhile (even if it's not fully used), so you can track all the barrier update events and the delta for the barrier they apply. If there is then a corresponding barrier update event where you have -delta the same you know the barrier expired naturally. If there isn't a corresponding event after the timeout of barrier then you know it was (at least partially) used up, and so I would track it.

It's not going to be perfect, but it gives you an idea of "impactful" barrier.

[Krappa322]

CBTS_BARRIERUPDATE is not in the live API

Besides, how would you track who generated the barrier referenced by that event?

[Krappa322]

And, of course, you still have the same issue that you need to order area events against local events, same as I described above

[John-Dean]

Hmm, trickier than I thought then!