• 0

    posted a message on IceHUD
    Target cast bars not always interrupting properly should be fixed in r59367.

    I've also added some minor fixes for the "flash on failure" option not disabling when the player castbar was disabled as well as a rare problem with accessing a nil text positioning option when switching bars rapidly (such as rapid shapeshifting as a druid).

    I'm currently in a state of zero known issues so I think I'm going to brand 59367 as a 1.1 release and put it up on curse and wowinterface since iceroth never did.

    I toyed a bit with adding click-targeting and click-casting to bars, but it doesn't seem feasible right now due to blizzard's secure frames stuff and the fact that these are "statusbar" widgets instead of "button" widgets. I'm still investigating if this is an option, but I'm probably going to not (be able to) add those features. Targeting/click-casting still works on the TargetInfo block, however, because that's a "button"-derived widget and not a statusbar.
    Posted in: Unit Frames
  • 0

    posted a message on IceHUD
    Okay, as far as I can tell, UNIT_SPELLCAST_STOP doesn't actually send what spell stopped casting...the last thing iceroth added was some code to stop a castbar from deactivating when a seal went off since it wasn't the spell being cast. However, when UNIT_SPELLCAST_STOP comes in from a target, it doesn't bring any spell information with it so the bar can't detect if it needs to stop or not.

    Perhaps I'm reading the API documentation wrong, but it sounds like it should be passing in the spell name, it's just not. I'm going to add a check to skip iceroth's early-out for this by verifying that "spell" is a valid variable before comparing it to self.current.

    FWIW, Quartz doesn't even try to check the current spell, just assumes that a STOP event means to stop the current.
    Posted in: Unit Frames
  • 0

    posted a message on IceHUD
    Quote from Parnic »

    I noticed that yesterday, but as far as I can tell, it's always been that way (none of my changes should've done it since they were all specifically targeting the player). Will investigate when I get some time.


    FYI - I have a fix for this locally, but it involves commenting out some code that was added shortly before iceroth quit. The check-in says something about fixing the cast bar for pally seals/judgments, and since I don't have a pally to check on, I'm not going to check this in just yet. I'll let you know what I find out.
    Posted in: Unit Frames
  • 0

    posted a message on IceHUD
    Quote from zably »

    Edit: Self casting bar works pretty well. Enemy casting bar still isn't effected by interrupts, ie. kick.


    I noticed that yesterday, but as far as I can tell, it's always been that way (none of my changes should've done it since they were all specifically targeting the player). Will investigate when I get some time.
    Posted in: Unit Frames
  • 0

    posted a message on IceHUD
    Quote from Parnic »

    Yeah, most likely. I think I have a good fix, but I'll have to wait til after maintenance to apply it :P.


    Try r59165.
    Posted in: Unit Frames
  • 0

    posted a message on IceHUD
    Quote from zably »

    Maybe that CHAT_MSG_SPELL_FAILED_LOCALPLAYER event... It triggers whenever your spell cast fails, for any reason, including already casting a spell, out of mana, out of energy, out of range, etc etc etc...


    Yeah, most likely. I think I have a good fix, but I'll have to wait til after maintenance to apply it :P.
    Posted in: Unit Frames
  • 0

    posted a message on IceHUD
    Quote from faux »

    Yeah, that's pretty much the case. The cast bars disappear from both the enemy cast bar and player cast bar until the cast is over, then they reappear and you repeat the same problem. Guess this is really a sign to knock a bad habit.

    //edit
    Just a bit more testing, the issue is far more frequent on longer cast times like Fireball (3 seconds) than something like Scorch (1.5)


    I'll fire up my mage (no pun intended) tomorrow and debug this as best I can. Thanks for the extra data. So far this is the only problem I've heard with the latest version, so at least I'm not breaking anything too terribly :). Hopefully the memory bug is cleaned up now.
    Posted in: Unit Frames
  • 0

    posted a message on IceHUD
    Quote from faux »

    I still have issue with castbars disappearing after button mashing, it was dreadful trying to arena tonight with this problem. (rev59085)

    They're disappearing when you mash buttons? The previous problem was that they wouldn't disappear when they should've and now I assume they're disappearing when they shouldn't? Are you talking about the player cast bar or the target cast bar?

    Quote from faux »

    I think I may just revert to revisions before all these big commits.

    By all means, use what works best for you :). I'm happy to try and fix any bugs people are seeing, I just need them reported first, as you've done :).
    Posted in: Unit Frames
  • 0

    posted a message on IceHUD
    Quote from Parnic »

    So you're saying the garbage collection isn't reclaiming the unused IceHUD memory? I remember one time seeing IceHUD gathering memory very quickly, but every GC would clean it up. It continued rising, but at least wasn't permanently claimed memory. I'm still investigating this.


    I've removed the usage of some local variables in the Update function in r59085. I didn't see any out of control memory problems, though it was still marginally increasing. I'm still looking, but I don't even really know what to check at this point.
    Posted in: Unit Frames
  • 0

    posted a message on IceHUD
    Quote from Veyska »

    Last handful of revisions (last week or so I think? thereabouts) IceHUD's been chewing up an enormous amount of memory (taking and keeping memory, not base memory). Seen it get up to 10MiB. What changed recently that could have cause this? Mildly annoying... :-P


    So you're saying the garbage collection isn't reclaiming the unused IceHUD memory? I remember one time seeing IceHUD gathering memory very quickly, but every GC would clean it up. It continued rising, but at least wasn't permanently claimed memory. I'm still investigating this.
    Posted in: Unit Frames
  • 0

    posted a message on IceHUD
    Quote from Srosh »

    Please make DogTag an optional dep - I do not want that lib on my system. I don't need it, I don't use it.


    DogTag is removed as a dependency in r59081. IceHUD is still marked to use LibDogTag-2.0 as an external (so WAU will pull it down), but you can safely delete the lib and IceHUD will revert to its old text formatting instead.
    Posted in: Unit Frames
  • 0

    posted a message on IceHUD
    Quote from Veyska »

    Last handful of revisions (last week or so I think? thereabouts) IceHUD's been chewing up an enormous amount of memory (taking and keeping memory, not base memory). Seen it get up to 10MiB. What changed recently that could have cause this? Mildly annoying... :-P


    Yikes! The main thing that changed was my addition of color changing for the bars...I suppose that could do it. I'll investigate and see if I can reproduce it, though this is really my first foray into the Ace world :). Thanks for the report!
    Posted in: Unit Frames
  • 0

    posted a message on IceHUD
    Quote from zably »

    Ok, based on the code you added, I made a few assumptions, and I think I fixed that lag error thing. If any of these are wrong, maybe I broke something.

    1. In the Enable function of the castbar, none of the events interfere with each other, ie. adding more won't break existing ones.
    2. New functions called by those newly registered events won't override other functions, triggered by other events.

    Anyway, adding

    self:RegisterEvent("CHAT_MSG_SPELL_FAILED_LOCALPLAYER", "SpellCastChatFail")

    to the Enable function in IceCastBar, and then down below adding

    function IceCastBar.prototype:SpellCastChatFail()
    self.current = nil
    self:StartBar(IceCastBar.Actions.Failure, "Interrupted")
    end

    seems to fix the "mashing 2 then w" problem.

    Edit: Breaks the enemy cast bar. Anyway to add a check so that it only resets your cast bar?


    I think I've got it fixed for the player only in rev 59079. Let me know :).
    Posted in: Unit Frames
  • 0

    posted a message on IceHUD
    Quote from Srosh »

    Please make DogTag an optional dep - I do not want that lib on my system. I don't need it, I don't use it.


    O_O...okay, then. I'll retrofit it to skip dogtag if possible. Can I ask why you're so against it?
    Posted in: Unit Frames
  • 0

    posted a message on IceHUD
    Alright, horizontal and vertical text alignment can be adjusted (within a pre-defined range) in rev 59026. With the new sliders, you can move the text all the way up above the bars or shift them around to your liking.
    Posted in: Unit Frames
  • To post a comment, please or register a new account.