1. [Addon] CombatLogFix (Fixed Version for DKs)

    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]

  2. 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

  3. 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 :)

    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.
    Edited: October 6, 2025

  4. Hi! You’re welcome :)

    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.

    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
    Edited: October 7, 2025

  5. aha, i see, thats all good then.

    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.
    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!
    Edited: October 7, 2025

  6. 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.
    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.
    I tested this new "smart" version. and it works much better than any other.

  7. 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.

    Code:
    local f = CreateFrame("Frame")
    f:SetScript("OnUpdate", CombatLogClearEntries)
    CombatLogFix.zip

  8. 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.

    Code:
    local f = CreateFrame("Frame")
    f:SetScript("OnUpdate", CombatLogClearEntries)
    CombatLogFix.zip
    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.

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •