I doubt frame strata/level adjustment is a feature that many people need, so it's probably something Elsia won't make time to add, but you could do it yourself by editing the code in Recount that creates the window. The GUI code doesn't change in most updates, so you could easily avoid overwriting your changes by reading the changelog and not updating that particular file unless it actually changed.
This is very specific and also somewhat technical to achieve. If you want to try your hands at it have a look at WindowOrder.lua. You will have to detect when the window you want to force fixed strata order on is affected and enforce it's position in the window ordering code.
An alternative solution is to not ever enter realtime windows into the ordering code but force it on a strata lower than the one recount overall is at. In this case check Recount:SetStrataAndClamp() for how Recount sets it's default strata and pick a lower one.
Recount isn't making segments for new bosses in 3.1, what's odd is it didn't make one for Flame Leviathan despite being present in the BossID's lib. The new VoA boss didn't force a new segment either.
Would the problem in Recount be caused by the fact that you tend to be in combat long before you actually see the Flame Leviathan?
Also, an unrelated problem... yesterday I was going at the training dummies with my new kitty spec with a hunter friend, and I noticed that if I wasn't in combat when he started attacking a dummy, Recount didn't start recording his damage until 20-30 seconds of sustained damage-dealing. If I was in combat when he started, Recount started recording his damage immediately. If I entered combat after he started (but before Recount noticed) his damage started being recorded. We were using the Heroic Training Dummy, if that makes any difference (though only segment recording should be affected by the "mob" not being in LibBossIDs, right?).
Target dummies are not yet in the list. Also recount really should record all damage because a damage event automatically puts it in combat. This is only different for healing events and such.
For segmentation, libBossIDs are only used if you only segment for bosses. Then, yes, that lib makes all the difference now.
Would it be possible to add the missing Boss ID's for the ulduar bosses? Bigwigs appears to have the majority of them and the ID for the new VoA boss Emalon the Storm Watcher appears to be 33993 according to wowhead.
For segmentation, libBossIDs are only used if you only segment for bosses. Then, yes, that lib makes all the difference now.
Right, but the "Current Fight" segment always displays the current fight even if it doesn't involve a boss, and the "Total" segment always displays all data including from fights that didn't involve bosses. Neither segment was updating despite the fact that I was standing right next to the hunter and could see him entering combat and dealing damage. That's what I meant; only the retention of named segments should be affected by whether or not the unit being damaged is a boss nor not, but data should still be recorded and displayed for the "Current Fight" and/or "Total" segments. :p
Oh I see this is to training dummy. I'll have to explicitly test that. Training dummies are weirdly implemented and are the sole reason why recount cannot properly handle overdamage for example. It may be that the combat detection for them is similarly weirdly but I have never tested for that.
Oh I see this is to training dummy. I'll have to explicitly test that. Training dummies are weirdly implemented and are the sole reason why recount cannot properly handle overdamage for example. It may be that the combat detection for them is similarly weirdly but I have never tested for that.
I'm not sure about the combat log, but the normal events fire at the right times when attacking a training dummy (PLAYER_REGEN_DISABLED and PLAYER_REGEN_ENABLED) and UnitAffectingCombat correctly indicates that the attacker is in combat as soon as he attacks. Recount just doesn't seem to detect the combat log messages as attacks... possibly the training dummies' flags are messed up? I was only testing with the Heroic Training Dummy, not with any of the lower level ones, but I'd guess they all suffer from the same issue.
@hjalte: Thanks, committed a fix for that.
@phanx: I think I found a way to reproduce (or at least I saw the effect once, but then failed to get into the state again). Just for sanity: You are using current fight mode?
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
This is very specific and also somewhat technical to achieve. If you want to try your hands at it have a look at WindowOrder.lua. You will have to detect when the window you want to force fixed strata order on is affected and enforce it's position in the window ordering code.
An alternative solution is to not ever enter realtime windows into the ordering code but force it on a strata lower than the one recount overall is at. In this case check Recount:SetStrataAndClamp() for how Recount sets it's default strata and pick a lower one.
Bigwigs appears to be using the same ID and that boss mod activated fine, unless Bigwigs isn't using the ID to activate the mod.
Also, an unrelated problem... yesterday I was going at the training dummies with my new kitty spec with a hunter friend, and I noticed that if I wasn't in combat when he started attacking a dummy, Recount didn't start recording his damage until 20-30 seconds of sustained damage-dealing. If I was in combat when he started, Recount started recording his damage immediately. If I entered combat after he started (but before Recount noticed) his damage started being recorded. We were using the Heroic Training Dummy, if that makes any difference (though only segment recording should be affected by the "mob" not being in LibBossIDs, right?).
For segmentation, libBossIDs are only used if you only segment for bosses. Then, yes, that lib makes all the difference now.
Right, but the "Current Fight" segment always displays the current fight even if it doesn't involve a boss, and the "Total" segment always displays all data including from fights that didn't involve bosses. Neither segment was updating despite the fact that I was standing right next to the hunter and could see him entering combat and dealing damage. That's what I meant; only the retention of named segments should be affected by whether or not the unit being damaged is a boss nor not, but data should still be recorded and displayed for the "Current Fight" and/or "Total" segments. :p
I'm not sure about the combat log, but the normal events fire at the right times when attacking a training dummy (PLAYER_REGEN_DISABLED and PLAYER_REGEN_ENABLED) and UnitAffectingCombat correctly indicates that the attacker is in combat as soon as he attacks. Recount just doesn't seem to detect the combat log messages as attacks... possibly the training dummies' flags are messed up? I was only testing with the Heroic Training Dummy, not with any of the lower level ones, but I'd guess they all suffer from the same issue.
I am using v3.1b of both Recount and RecountDeathTrack (and RecountFailBot)
@phanx: I think I found a way to reproduce (or at least I saw the effect once, but then failed to get into the state again). Just for sanity: You are using current fight mode?