• 0

    posted a message on Stop talent blocking with LibChatAnims
    Quote from oscarucb
    That works. I had seen your project before you posted this thread, and I didn't really understand the implications for users until I saw this thread. I didn't understand it could also work equally well as a stand-alone mod until I opened up the code.


    Done and done. I also updated BlizzBugsSuck to include it so that current users of the addon can benefit rather than downloading another addon.
    Posted in: Libraries
  • 0

    posted a message on Stop talent blocking with LibChatAnims
    I see. So in summary, you're asking for a better project description? How about I copy paste what I said in this thread (mainly because I'm not sure how to explain it better than I did here :D). Would that be good? Or something else?
    Posted in: Libraries
  • 0

    posted a message on Stop talent blocking with LibChatAnims
    Technically it's not a bug with the interface because the user isn't affected unless they install and addon that interfaces with specific chat code. The user can use WoW perfectly fine without said addons installed.

    Whilst I respect your opinion about having it be a separate addon, I completely disagree with it. As your list clearly depicts, we're already in a horrendous situation where a user must be navigated to a certain page and told to download xyz addons. Not only is the list stupidly huge instead of being in 1 addon, but the low addon popularity itself speaks volumes.

    A few advantages of having it be a library:
    • A quick an easy way to affects hundreds of thousands of users in a very short space of time (the latest versions of Chatter and Prat now bundle it, I say that's a large quantity of the WoW player base)
    • No conflicts with other addons trying to do the same thing: Cremor just posted the addon "NoTaint" which used to do a similar thing in a sub-optimal way. By embedding the library instead, there is no conflict of hooks between addons. People can continue to enjoy using that addon which fixes popup-related issues with no conflicts with other addons.
    • The user doesn't need to be educated about the issue, linked to a page, and convinced to download an addon. Whilst this is fine and dandy for advanced users, most of the WoW player base doesn't fall under this category, and very rarely dabbles in new addons unless recommended by word of mouth - a slow process.
    • If it is ever fixed, it can be easily "killswitch" killed in the repo, which will ripple across addons as they update. There is no need to educate every single author that the issue is fixed and tell them they should stop directing their users to a random taint fixing addon.

    As it stands this is the most successful way of doing this with the least hassle. It's just a matter of if said author cares enough not to have his or her addon blocking a users talent changes to the point they'd flat out fix it for ALL their users by embedding a library, or, continually keep pointing users to install another addon to fix an issue their addon is being blamed for.

    Now, to the point about listing this library in your guide. No, I do not agree with it. Whilst I made this library without a load-on-demand flag so that advanced users could install it if they wanted to, I am not interested in having users pushed to install another "fix" addon. Then after that, tell them all to remove the addon whenever the issue is fixed. Having the authors remove it when it's fixed means you're making less people do work, and if the author isn't aware that it's fixed, it won't matter, as the library will be inert.

    As far as I'm concerned my work is "done". With the inclusion of this library in high popularity addons, I have single handily solved an issue for many people in a matter of days. It's now up to the individual authors themselves to deem how important having their addons not be blamed for blocking talents is.
    Posted in: Libraries
  • 0

    posted a message on Stop talent blocking with LibChatAnims
    The most popular way of having your addon blamed for blocking talents currently is the use of static popups. This is (apparently/hopefully) fixed in patch 5.2

    There's also a second way this can happen which is largely unknown as it only affects a select group of users, those who have separate chat tabs set up for various chat events, e.g. Whispers.

    Due to Blizzard's use of UIFrameFlash on chat tabs that receive new messages, any addon that was in the execution path (e.g. chat mods, chat filters) will then be blamed for talent taint.

    This chat code has been the same for donkeys years, however it is only now an issue as Blizzard decided to slap a UIFrameFlash onto the talent frame, rather than use their awesome animation system that's been in the game for a few years.

    I don't envision Blizzard fixing this any time soon (ideally they'd remove UIFrameFlash and use animations instead), at least not in time for patch 5.2 anyway.

    Basically what this library does is hook 4 Blizzard chat functions (which from testing, can be safely hooked without any issues or execution blocking) and re-writes said functions to use the animation system. This method has been working swell for me for 2 weeks now and has been working without any issues reported from alpha users of various addons that now have this library embedded.

    So, here's some project page copy pasta:
    A library to force common FCF (Floating Chat Frame) functions to create and use animations instead of using UIFrameFlash.

    Why?
    The use of UIFrameFlash can be traced to various addon taint issues, most commonly the blocking of changing talents.

    You need this library if:
    • Your addon hooks the `.AddMessage` functionality of a Chat Frame to modify the output.
    • Your addon makes use of chat event filters. (ChatFrame_AddMessageEventFilter)
    What will this do for my addon?
    If your addon does make use of one of the above 2 features, it will prevent your addon being blamed for blocking talent changes.


    Project page:
    http://www.wowace.com/addons/libchatanims/

    You can embed this like any other library.
    Posted in: Libraries
  • 0

    posted a message on Splitting realm from name
    The first value, "name", doesn't include server. Did you not test this?

    Also, there is no longer space between character names and server names.

    Anyway I use:
    name = name:gsub("%-.+", "*")

    Which replaces servers with an asterisk as this is consistent with Blizzard's behaviour. You could also remove the asterisk if you want it to be blank.
    Posted in: Lua Code Discussion
  • 0

    posted a message on CT MOD dev update!
    Why does this mod still exist?
    Posted in: Project Discussion
  • 0

    posted a message on AceTimer is now animation based
    Unfortunately it appears that 2 people so far have reported issues with timers not cancelling, and I've traced it down to the debugprofilestop call firing the same values for them in a short space of time. Unfortunately, it's obviously not "high precision" enough for them. I'm looking into to re-writing the id system for a new version.

    edit: Not sure why I didn't think of this before, but we use a unique table for every timer, so the table id would be perfect. The question is, is it worthwhile to add a load of extra upgrade code to upgrade a lib that's been out as an alpha for ~4 days.
    Posted in: Ace3
  • 0

    posted a message on AceTimer is now animation based
    Quote from endx7
    This is somewhat contrived and unlikely to happen in the wild, but something like



    debugprofilestart()
     
    local id = AceTimer:ScheduleTimer(...)
     
    print(id)
     




    seems to cause duplicate ids about 10% of the time (at least on my setup).



    Luckily, while this will cause it to lose track of timers on the short term, it will find them again when they expire and are put into the inactive list.




    I'm actually surprised it's as low as 10%! The "start" function (as you've noted) is highly unlikely to ever be used outside of a author-debug situation. But even then, it technically should not be used for profiling.



    It is noted here and here how profiling should be done with 2 calls to stop.



    Note that debugprofilestart() is more of a global reset than a "start". It is not necessary to call it, ever. In fact, it is probably a much better idea to simply do 2 calls to stop() and calculate the difference, since calling start() will interrupt timing measurements done by other addons.



    Quote from oscarucb
    Thanks so much for doing this!

    Might want to update the relevant ticket:
    http://www.wowace.com/addons/ace3/tickets/296


    I added a comment for anyone looking at it in future.
    Posted in: Ace3
  • 0

    posted a message on Skada: a damage meter
    From what you're describing, I'm not so sure that the actual issue is fixed, just hidden. Is the Skada display still updating properly?
    Posted in: General AddOns
  • 0

    posted a message on Skada: a damage meter
    Please grab the latest Skada (r424) and let us know if it still happens. Also, was this something that happened at login, or whilst exiting combat, etc?
    Posted in: General AddOns
  • 0

    posted a message on AceTimer is now animation based
    The animation throttle only applies to actual animations like rotate and alpha. If you don't specify one of these, the throttle does not apply. (So nothing needs changed).
    Posted in: Ace3
  • 0

    posted a message on AceTimer is now animation based
    My LibTimer project has been merged into AceTimer, with full backwards compatibility and upgrade code.

    Advantages include:

    • Theoretically more efficient as animations are handled C side.
    • Recycling of animation objects.
    • No chance of "timer pile up", avoids the dreaded "Script too long" error (unless your function actually is that large).
    • Simple id based system.
    • Support for unlimited args.
    • Zero load when no timers are running.
    • Timers can now go as low as 0.01 instead of 0.1

    If your addon is grabbing AceTimer directly from the trunk, a simple "bump" to your addon to re-zip it will pack the new AceTimer.

    Please report any issues you may encounter.
    Posted in: Ace3
  • 0

    posted a message on Mapster: Official Thread
    Quote from Dridzt
    Aren't SSDs supposed to only hold non-changing files?

    I don't have one installed but I remember talking about them with colleagues at work; as I recall they have a limited number of writes before failing which is why you normally put the OS on them and make sure to move all frequently written files to traditional storage (Documents, Temp directory, swap file etc)

    Using them as a game drive seems like a sure-fire way to shorten their lifespan all the faster.


    That argument was valid about 5 years ago, things have changed ;p

    Quote from Dridzt

    Unless I'm confused about how they work / their limitations.
    (I think one of the selling points for Windows8 is exactly the OS capacity to handle SSD "natively" ie not run defrag on them, move frequently written - not just accessed but modified files - out etc)


    That was Windows 7.
    Posted in: Map/Minimap AddOns
  • 0

    posted a message on Mapster: Official Thread
    That happens to me with the default map (no addons) on PTRs, which I install on my crappy HDD. It's either A) you are still streaming map data files or B) you're using a slow HDD/heavily fragmented copy of WoW.
    Posted in: Map/Minimap AddOns
  • 0

    posted a message on Replacing UIFrameFlash with Animations
    Thanks! Edited that in.
    Posted in: Tips, FAQs, and Guides
  • To post a comment, please or register a new account.