ensidiafails doesn't include libfails. There are sometimes differences how both "addons" detect the same fail.Ryu ported a lot of ensidiafailscode to libfail, but not everything.
I think algalonfails and a few other hardmodes are still missing from libfails.
And the biting.cold fail,keeps changing a lot in both addons ;)
Elsia, I have a feature request with regard to the "hide in combat" option : could please you add a 3,5s delay from last data recorded before showing the window again ? When someone in the raid still have a dot that ticks every 3 seconds, the windows hides a short time every 3 seconds. This is utterly frustrating when you try to do something with it. As an alternative, you could try to add a small delay, say 0.5 or 1 second before hiding when entering combat. Not sure which solution is better.
I haven't really seen that phenomenon myself yet but that isn't surprising because I don't actually like to hide recount in combat. What I find strange is that this can even happen. Can dot classes drop out of combat between ticks or does UnitAffectingCombat report inconsistently for dot classes or is this for mobs with odd aggro?
I think that happens when a raid member suffers from a mob DoT, in the few seconds after the last mob died (i.e. until all DoT of all mobs fade from players). It may involve another Recount setting. I will take a look.
Yeah I know those, I still consider it theory because I haven't seen a combat log entry actually firing when the debuff is in effect. Once we know that these in fact do fire we'll know more.
Taking this debuff I'm inclined to treat these "*HEAL_*_ABSORB" events like ordinary heals because they do serve an effective function of making sure that heals land for a given amount. Overheal behavior of these events is as yet unknown.
If anyone can provide combat logs from the PTR for this encounter I'd be very grateful.
In fact there are no healabsorb events in the combat log, only for the combat text. While I haven't traced the extracted blizzard addon code completely, I'm pretty certain that these in fact directly relate to the addition of absorption fields in the combat log.
I.e. if a heal is (partially) absorbed, the combat text now knows if a heal, a hot or a crit got absorbed and display it accordingly. The combat log itself only show the absorb as part of the SPELL_*_HEAL added field.
Simply put the SPELL_*_HEAL event has now an added argument called absorbed. This contains how much of the heal was absorbed by an effect on the target, very much comparable to the absorbed field for damage events, which show how much of the damage was absorbed by an effect on the target. Like damage absorbs these are impossible to attribute exactly and can only be attributed through some guessing heuristics.
About the comment, it's an old comment to track possible bug reports re overheals. It's long stale. I'd just ignore it. I'll have to do a comment cleanup eventually but that's extremely low priority in my book ;)
I like the idea behind RecountFailbot and the nice history/summary mechanisms it inherits from Recount, but unfortunately it appears to be missing detection for many of the categories of fail detected by the stand-alone addons mentioned above.
Any chance RecountFailbot (or LibFail) could be updated with a more comprehensive set of fails, or possibly plug into EnsidiaFails as a data source to get these? The output would be much more useful if it wasn't missing so many types failures.
The guts of RecountFailbot is LibFail, it's as good or as bad with regards to fails as the lib which I don't maintain.
A constructive approach is to identify which fails are missing and report them to the libfail maintainers. This will help all addons that rely on the lib, not just RecountFailbot.
tbh, it's not worth my time to help the libfail devs re-invent the wheel when EnsidiaFails already does an outstanding job at detection, esp since the only added value would be the ability to display the summary results in the Recount window. IMO it's better to simply drop the libfail dependency and just have a Recount plug-in to EnsidiaFails that can leverage the existing detection and provide the Recount reporting.
Trying to support EnsidiaFail, which has no clean, defined or guaranteed APIs for fails by third parties, is a really bad idea. That would be a serious waste of time and a maintenance nightmare to boot. In lieu of either a clean API by ensidiafail or an alternative lib that offers the fails you want, I won't be going there. It's your call if you want to help with libfail or not. I think libfail is a great solution, hence I plan to support it despite the fact that by the way it (doesn't) handles localization, it causes some unnecessary maintenance overhead.
IMO fail events should be a lib, and ensidiafail isn't one. In the best case the lib should be self-sufficient (i.e. also self-localized) and libfail isn't currently, but it's the next best thing. All it takes is people willing to report fails to support.