• 0

    posted a message on ZOMGBuffs Official Thread
    Quote from Xanobia »

    A request regarding mages dampen magic and amplify magic

    Not sure ill ever use it it, but better to ask for it now and not use it than wanting to use it and not be able to

    Anyway it seems i can only select either dampen og amplify magic for buffing on the raid, however there might (again not sure where) be a situation where some ppl in the raid 'needs' amplify and some 'needs' dampen. At the current setup its no possible.

    Could you make it so its possible to activate both and select who gets what?

    A valid point. Can't believe I'd not considered it. And a bit of a pain to get working. :)
    Posted in: General AddOns
  • 0

    posted a message on ZOMGBuffs Official Thread
    Quote from tnbp »

    True, true. And this is the ONLY function I miss from switching over from SmartBuff. It would be the perfect addon if in-combat buffing became available. :)

    I know jack-squat about programming addons, but have you examined the code for SB, by chance, to see how that addon works around it?

    Oh I know how it works, that's not a problem. But for a lot of people it'll cause issues, which was my main reason for not including something like it in the first place. For example, I'm a habitual mouse scroller. I change camera view a lot, and to have a buff on that would just be silly. But I'll consider it and see what the best approach is for ZOMG.
    Posted in: General AddOns
  • 0

    posted a message on Dewdrop Secure Frames?
    In a word, no.

    You need to create a SecureAnchorButtonTemplate to handle the mouse clicks for the menu, SecureStateHeaderTemplate to say what to do with the clicks (opening and closing the menu), then create entries of SecureActionButtonTemplate with attributes that deal with what you want to do (ie, same things that the pet bar buttons do).

    Basically, you're creating a popup action bar that works from a mouse click. Read through the SecureStateDriver.lua and SecureStateHeader.lua comments for most of the documentation for the stuff. It's not light reading, but will give you an idea. There's also some examples on the forums.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Fixing the Raid Lockup Problem!
    Quote from Dr. Woo »

    I have this problem. It's pretty much guaranteed if I get D/C'd during a raid and log back in, it'll freeze to the point where I can't do anything.

    I use ag_UF and CTRA, but use CTRA solely for tank targets (such a waste). ag_UF is my raid display.

    Most likely because of CTRA (WHY are you using this? Get oRA2). But if you insist, scan back a page or two for a fix I posted to stop CTRA locking up.
    Posted in: Unit Frames
  • 0

    posted a message on Fixing the Raid Lockup Problem!
    Quote from teedog »
    But the weird thing is I am in the same raid with people who lock up. Same number of pets, same raid size, same members, same instance, same everything. The same people crash/lock up and have to be kicked from the raid and re-invited all the time. It never ever happens to me.

    Other mods perhaps. Consider other 'less apparent' mods. CTRA for example can and will cause the lockup issue.

    To fix CTRA btw, search for the function prepareFrame and add the following line into it directly after the function declaration:
    	frame:UnregisterEvent("UNIT_NAME_UPDATE")
    Posted in: Unit Frames
  • 0

    posted a message on Fixing the Raid Lockup Problem!
    Quote from Ragnor »
    Bump for Nevcairiel or Saroz, for battleground/arena raids you'll need to do the above I think. Although I haven't had any problems myself there are a few reports of missing or incorrect names.

    Yes, I have the same issue with X-Perl. Will have a fiddle with updating the names OnShow if that is enough.

    As for why the UNIT_NAME_UPDATE thing affects some people more than others. You tend to hear people's worst reports. Where there are more pets in a raid, you are likely to get an exponential increase in the number of events fired.

    Also, I beleive PerfectRaid uses a single raid header (correct me if wrong), and so there is 8 times less header updates being triggered than with X-Perl for example.
    Posted in: Unit Frames
  • 0

    posted a message on Fixing the Raid Lockup Problem!
    Quote from Ragnor »

    According to my guild mate Xinhuan the problem is in the undocumented changes made to the secure raid and group templates in 2.1, he was looking at the problem for the raid frames he uses (xperl) but it may be of interest to ace developers...


    Excellent work. Many thanks to Xinhuan. Implementing change to X-Perl immediately. Makes perfect sense.
    Posted in: Unit Frames
  • 0

    posted a message on Fixing the Raid Lockup Problem!
    Quote from andreasg »

    Some say doing UIParent:UnregisterEvent("RAID_ROSTER_UPDATE") helps, but I am not sure why it would.


    This is a confusion on erm, someone's part. This cures the jittering you get when someone joins/leaves/zones in a raid group. Entirely different cause and effect. But, let's move on:

    I found the main causes are during zoning and between (and including) PLAYER_LEAVING_WORLD and PLAYER_ENTERING_WORLD (whether that's logging in for first time, or zoning into a BG). I can only assume when there's a lot of memory being shuffled around and some race condition is being hit. A garbage collection at some key point for example. Which would explain why it appears to be so random and entirely different from person to person. Noone has the same memory config, logs into same location, has same mods and options and so on.

    The only luck I've had, like andreasg, is to avoid changing attributes for header templates between these times. And ran into same problems if you get into combat when you log in.

    I keep poking more at it, but as you all know, there's precious little you can do to debug it when the game quits out after the long freeze. Will try and put some BIG notice in middle of screen with some timing info tomorrow. You do get a single frame again before the disconnect comes through so with a big enough font and some coffee it might help. But man it sucks, trial and error debugging with a 3-5 min wait between each try.

    Thought for a time it might be the error catcher working overtime with some ACTION_BLOCKED things. Anyway, going to go over everything again if 2.1.2 patch was not done this week. /sigh

    If only some Dev would run a profiler or something against WoW.exe during these times... /wave Devs

    PS: AMD 3000+, ATI 9550, 1Meg DDR
    Posted in: Unit Frames
  • 0

    posted a message on Aguf laggy...
    X-Perl had much of the same problems, but managed to cure it all this morning, so in the interest of fostering relations between mod authors; Here are some thoughts:

    Basically got around the huge startup freeze by forcing the secure templates to startup after the first OnUpdate of a dummy frame which hides itself afterward. Had to move some things away from VARIABLES_LOADED to this new event. Very hard to nail down what the problem is exactly, but something about doing things too soon has become immensly slow.

    Took a lot of trial and error with a good dose of frustration and hair pulling, and I'm not at all happy with how it's turned out. Feels very hacked atm, but it's working. With some more patience and time we can maybe identify the actual problem (or hey, Blizzard might fix it... hmm).
    Posted in: Unit Frames
  • 0

    posted a message on Aguf laggy...
    Quote from Blackhand »

    I can reliably replicate this problem on my warlock. The issue is minimal in the normal game world, in raids and BGs it is at its peak.

    How to replicate:
    ----

    Would love to see this get fixed, can't play with ag_unitframes ( atm ^^ ) and can't play without it.


    This is something else that I had been blamed for with X-Perl for a while, but later we found the culprit to be Theorycraft2 which causes large pauses when pet is summoned dismissed (which also includes mounting since patch).
    Posted in: Unit Frames
  • 0

    posted a message on Pitbull Raid Performance Issue
    Quote from Moxie »

    Pitbull is still "hiccuping" or causing a slight studder of lag when in a raid and either someone joins the raid, moves groups or changes groups. It's been raised a few times by several people but we still don't seem to have a resolution.


    I had the same complaints for a long time with X-Perl. The real culprit is the Blizzard party frames. Whenever the raid roster changes (UIParent registers this), it does a Hide/Show on all the party frames and quite often a LOT of raid roster updates are fired. More members == more times, and this is when you start to notice the frame stuttering.

    Pitbull/agUF etc should just add this somewhere in their party frames module (I don't know how those mods are put together, I just included in with XPerl_Party module).

    UIParent:UnregisterEvent("RAID_ROSTER_UPDATE")

    Until that's done you can either script this yourself or tick the interface options, Hide Party in Raid (function still gets called, but does a lot less work).

    --
    Zek - X-Perl
    Posted in: Unit Frames
  • 0

    posted a message on Aguf laggy...
    Quote from jyllana »

    I'll have to look at the xperl frame code, I think they have it on a delay when it enters an instance/bg too.

    Although there's been some reports that it's fixed it, I'm fairly sure it just shifts the problem somewhat and it can still fail under similar conditions.

    For the curious who where asking. It just delays displaying all raid frames. Does 1 group per OnUpdate (yes, yuk, I know). Check the XPerl_Raid.lua file and look for 'displayGroup' and you'll find all the relavant code.

    I'm more and more convinced it's related to memory, rather than some problem in the mods themselves.
    Posted in: Unit Frames
  • To post a comment, please or register a new account.