Printable View
Hi!
I've made a small fix to the CombatLogFix addon.
This resolves an issue where Rune-based spells were incorrectly excluded from the power cost filter, causing the addon to fail at properly detecting a broken combat log when playing Death Knights.
You can find the details of the change in this repo.
[Direct Download]
Hi sir, Thank you for this!
Do you think this might also fix rune desync bug where your client can see runes are available but they are actually not, and previously when u used ability it did not trigger rune cooldown ?
Also, any change you can update properly "Loss of Control" - retail backport as it doesnt work properly sometimes.
Thanks
Hi! You’re welcome :)Quote:
Originally Posted by scienide
About your first question: any rune visual addon (including Blizzard’s own RuneFrame) relies on the same client-side APIs and events (GetRuneCooldown, RUNE_POWER_UPDATE, etc.). These don’t pull live data from the server; they only reflect the client’s locally cached rune state. Therefore, if the client becomes desynced, the addon inherits that desync as well.
Theoretically, it would be possible to build an addon that emulates the entire rune system locally using the combat log, but that would be extremely complex (just imagine all the conditions involved) and it couldn’t be guaranteed to be completely reliable.
Honestly, the concept feels very forced. Even with constant testing I don’t see it as viable, not to mention the amount of work it would require.
About “Loss of Control”: I personally don’t use that version, I prefer the minimalist LoseControl. So I can’t really promise to work on an addon I don’t actually use, at least not for now. I’m sorry, friend.
aha, i see, thats all good then.Quote:
Originally Posted by Khalxz
Regarding Loss of Control, I use both this and Losecontrol.
Loss of control for me, and losecontrol for others.
You should try it, its really good and works with Psychic Horror as well. There is several versions of that addon, but there is one particular on that works best.
I believe its this one
https://github.com/RomanSpector/LossOfControl
Edit://
I see there is a new version now ... need to test that
https://github.com/thierbig/LossOfControlSmart-3.3.5
Yeah, it’s probably better. Personally, though, if I ever decide to use LoC, I’d probably modify it to make it simpler for the player by showing only the icon and duration.Quote:
Originally Posted by scienide
You’re right that LoseControl does have some limitations, not just the Psychic Horror case, but also because it would be great if it could display multiple types of CCs (kind of like a dynamic group WA).
For example, when you’re both stunned and silenced, LoseControl only shows the highest-priority effect (the stun). So you trinket it, only to realize you were also silenced, meaning it would’ve been better to save the trinket.
I might check out the other options soon when I get some time. Thanks for the suggestion!
Yeah test please. I really enjoy it more than losecontrol.Quote:
Originally Posted by Khalxz
I tested this new "smart" version. and it works much better than any other.
Why it's better to try detect when combatlog is broken instead of just doing it the old simple way of clearing the combatlog every frame like this?
I've used this for years and never had any issues.
CombatLogFix.zipCode:local f = CreateFrame("Frame")
f:SetScript("OnUpdate", CombatLogClearEntries)
Hi, I haven’t tested whether there are any negative side effects to clearing the combat log every frame. Assuming that, as you say, it doesn’t cause any issues (i.e. it still correctly identifies all events and sub-events without losing any due to the clear), then the only real difference would be optimization.Quote:
Originally Posted by kebabst0rm
As a general optimization rule, it’s best to avoid relying on OnUpdate scripts or high-frequency events like CLEU unless it’s actually necessary. The main reason is to avoid unnecessary CPU overhead. You could argue that it’s just a single function call and not a big deal for the CPU, and that’s objectively true, but that doesn’t change the fact that it’s good practice to aim for optimized solutions, since in the end everything adds up.