+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 21

Thread: Interrupt Macro

  1. #1
    Join Date
    Aug 2009
    Posts
    6

    Interrupt Macro

    Hi guys,

    I need a macro that send out a message whenever I interrupt the target.

    I need this macro to only send out once (even if i spam it xxx times)
    I need this macro to only send out the message only if it successfully interrupts.

    This is what I have at the moment

    /cast Pummel
    /run local a,b,c,d = GetSpellCooldown("Pummel"), UnitCastingInfo("target"); if GetTime() - a < 0.3 then if d then SendChatMessage("Kicked %t's ".. d, "Yell"); else SendChatMessage ("Missed", "Yell"); end; end;

    The only problem is that it doesn't seem to work all the time, and I need to spam it a few clicks for it to even broadcast once.

    It shld work on theory. 0.3 is the lag time I entered.

    Can anyone help? Thanks
    Last edited by Seraphblade; 01-13-2010 at 06:35 AM.

  2. #2
    Join Date
    Aug 2009
    Posts
    6
    I've found out the problem to be due to latency.

    GetSpellCooldown doesn't return the proper casting information right after the /cast Pummel. It only gets the spellcooldown info once it is actually casted (due to latency).

    I've found a work around this which is to use the below macro:

    #showtooltip Pummel
    /run s = UnitCastingInfo("target");
    /cast Pummel;
    /run c = GetSpellCooldown("Pummel"); if c == 0 then if s then SendChatMessage("Kicked %t's ".. s, "say"); else SendChatMessage("Missed", "say");end;end;

    However, there is another problem here. If u have around 400 ping, and u spam the button really quickly, you can get around 2 - 3 messages in.

    Chains of events:
    Pummel is pressed on ur client side...
    Info is passed to server... prolly 300 ms later,
    Pummel is actually casted!
    Thus during this 300ms, this macro will think that pummel is castable, and will definitely go off. (It doesn't consider out of range at the moment). And any number of times it is pressed, it will trigger within this 300ms =(

    WTB a workaround this latency =(

  3. #3
    Join Date
    Nov 2009
    Location
    WI, USA
    Posts
    2,614
    There is a fundamental flaw in any macro you will write attempting to do this.

    Your Machine <> The Server
    Events occur at different times and at different speeds. You don't want your code announcing the interrupt to fire unless it actually interrupted something. In order to do that, you need confirmation back from the server that your ability succeeded... you need to parse a combat log event. Because of that you have to use an addon, it simply isn't possible to do all this in a macro alone.

    You send the cast request to the server... the server does it and sends you back the result... you then process the result (process the combat log event). At the time you are sending the cast request to the server, you don't know if it will actually succeed until the server comes back to you and tells you the result.

    There are addons out there for announcing things like interrupts and taunts, I'd recommend looking into one of those addons. You could also try CastYeller2 addon which should meet your needs.
    http://www.wowace.com/addons/castyeller2/

    Bottom line, what you are trying to do is functionally impossible in a macro (which is why you need to click it multiple times to work). You need an addon which will process the combat log events (these addons because they add additional slash commands and functions could then be called from your macros).
    Last edited by Quinafoi; 01-13-2010 at 09:47 AM.

  4. #4
    Join Date
    Feb 2011
    Posts
    10
    Although I agree that an addon is required if you need a 100% success rate I do think that a macro option should be available should you not want to install that mod (every mod you install adds a dependency and maintenance overhead) or would like a UI that works pretty most with the same functionality should you play on a different computer, etc...

    Code:
    /run t='target';s=UnitCastingInfo(t)or UnitChannelInfo(t);r='Rebuke';g=GetSpellCooldown;c=g(r);d=' (10sec)';
    /cast Rebuke
    /in 0.2 /run if c==0 and g(r)~=0 then SendChatMessage(s and r..'d ['..s..'] on '..UnitName(t)..d or r..' used'..d, 'SAY')end
    This is the best solution I've come up with so far. It discriminates between interrupts which potentially hit and those that potentially didn't and shouldn't ever spam. The negatives are that you have to wait 0.2 seconds (seems to be the sweet spot for me) before you get the message to pop up, it sometimes doesn't fire at all if you hit the interrupt immediately before it comes off cooldown (the initial call to GetSpellCooldown isn't updated properly) and, contrary to my above statement, you need the Ace library installed for the "/in 0.2" part to work (most people will have this if they have some addons installed).

  5. #5
    Join Date
    Jan 2009
    Location
    Karlsruhe/Germany
    Posts
    4,007
    http://wow.curseforge.com/addons/rsa/

    you could have a look at this addon, it uses a total of about 200kB of addon memory according to my addon usage addon.

  6. #6
    Join Date
    Nov 2009
    Location
    WI, USA
    Posts
    2,614
    Ability being used determines whether or not it goes on cooldown. It does not determine what, if anything, was interrupted by it. The only true way to do this is with combat log event parsing (event handling addon). Using a macro does nothing more than to say you used your ability, while you can get the spell that was being cast when you used it, you can not determine if your interrupt actually interrupted it. You could either miss, or perhaps someone else interrupted it. You can only correctly do this with an addon. It's not functionally possible to do it all with a single macro.

    Additionally, your macro requires the installation of the Ace framework. So it in itself is not a macro, but a macro that requires addons behind the scenes in order to function. You can't do it in just a macro alone, you even require addons to write a macro to write it in a dumbed down, less functional version. If you already are making sure your Ace framework is up to date, what's the problem with actually using an addon to do this functionality correctly.
    "In anything, if you want to go from just a beginner to a pro, you need a montage." /w TankSpot WTB Montage for Raiders.

  7. #7
    Join Date
    Feb 2011
    Posts
    10
    All of what you just said was already recognised in the post I made, you don't need to make it again. I don't think, though, that the Ace dependency is a big deal as it's a dependency that almost everyone with addons will commit to and there's no overhead in its maintenance as it's already bundled with your current maintenance activities.

    So, there's a balance to be made and I wouldn't say that there's no place on that scale for an interrupt macro of that kind. But you're right in that the 'perfect' solution cannot be done in a macro, though I have been able to get it done in two:

    Important: for a 4.1 version of the macro see below. Installation instructions are the same.

    Macro 1, this goes where you'd like to bind your interrupt.
    Code:
    #show <Spell>
    /run r='<Spell>';t=' (<Cooldown> sec)';X=X or  CreateFrame('Frame');X:RegisterEvent('COMBAT_LOG_EVENT_UNFILTERED');p=UnitGUID('player');m='SPELL_MISSED';h='SPELL_INTERRUPT';y='SPELL_CAST_SUCCESS';c=SendChatMessage;
    /click <Button>
    Macro 2, this goes on any spare action bar slot. You can put it there and forget about it, you don't need to press it. It can even go in a slot that's on a bar that's hidden.
    Code:
    /run X:SetScript('OnEvent',function(_,_,_,l,o,_,_,_,n,_,_,s,_,_,i)  if o==p and s==r then if l==m then c(r..' !!!MISSED!!! on '..n..t)  elseif l==h then c(r..'d ['..i..'] on '..n..t)elseif l==y then c(r..' used'..t) end end end);
    /cast <Spell>
    To make this macro work for your interrupt you need to replace the bits of the code marked in bold.
    <Spell> is simply replaced with the name of the interrupt you care about, for example Rebuke.
    <Cooldown> is the time it takes for that interrupt to be ready again, for example 10
    <Button> is more complicated. To find out what needs to go here you need to find out what the 'name' of the action bar slot where you put Macro 2 is. Type '/fstack' and press enter/return, a new window will pop up. This window lists the different UI elements that are currently under your mouse's cursor. Move the cursor over the slot in which you placed Macro 2, the name of the slot is now in the window that typing /fstack brought up, it will look like MultiBarRightButton1 or similar, or in the case of an addon such as Bartender it will look like BT4Button24.

    I present the macros again, this time filled out with my use case (that I am currently using) as an example of the outcome of making the substitutions listed above.

    Macro 1
    Code:
    #show Rebuke
    /run r='Rebuke';t=' (10 sec)';X=X or CreateFrame('Frame');X:RegisterEvent('COMBAT_LOG_EVENT_UNFILTERED');p=UnitGUID('player');m='SPELL_MISSED';h='SPELL_INTERRUPT';y='SPELL_CAST_SUCCESS';c=SendChatMessage;
    /click MultiBarLeftButton1
    Macro 2
    Code:
    /run X:SetScript('OnEvent',function(_,_,_,l,o,_,_,_,n,_,_,s,_,_,i)if o==p and s==r then if l==m then c(r..' !!!MISSED!!! on '..n..t)elseif l==h then c(r..'d ['..i..'] on '..n..t)elseif l==y then c(r..' used'..t)end end end);
    /cast Rebuke
    Best,
    Dan.

    Edit: 4.1 Version
    Only Macro 2 is changed.
    Code:
    /run X:SetScript('OnEvent',function(_,_,_,l,_,o,_,_,_,n,_,_,s,_,_,i)   if o==p and s==r then if l==m then c(r..' !!!MISSED!!! on '..n..t)   elseif l==h then c(r..'d ['..i..'] on '..n..t)elseif l==y then c(r..'  used'..t) end end end);
    /cast <Spell>
    P.S. It would be great if this could be done in a single macro and I'd welcome suggestions on how to compact it.
    Last edited by fakeh; 03-11-2011 at 08:14 AM. Reason: 4.1 version

  8. #8
    Join Date
    Nov 2009
    Location
    WI, USA
    Posts
    2,614
    If you're going to go through the effort of creating frames on the fly, registering events, and parsing combat log entries. You may as well just go through the process of writing your own addon. You basically already have everything you need already.

    On a different note, you don't need to have the SetScript in the rebuke, rather, once the script is set it is continually being run on the registered event until the event is unregistered or the frame destroyed. You would need 2 macros for the creation of the frame and event handler simply because the length of the syntax is too long. However once run, you don't need to rerun that. Simply casting Rebuke would trigger the event handler (at which point it wouldn't have to be in a macro).

    Ideally though this should be done in an addon though. While you can create frames and register events in macros, doing them in addons will provide you with more flexibility. If you are an advanced enough user to be using scripts like this and maintaining them, you're advanced enough to create your own interrupt alerting addon. For that matter, you basically have all the code required already to write a simple addon.

    In the regard of maintenance. Now instead of relying on someone else to update a standard addon, when Blizzard releases changes to their combat log events or APIs available, the individual user has to update it themselves. This actually is harder to maintain than simply getting a third party addon to do it for you. Since this macro requires a higher understanding of Blizzard APIs and combat log event parsing, an average user will not be able to maintain it should Blizzard change something.
    "In anything, if you want to go from just a beginner to a pro, you need a montage." /w TankSpot WTB Montage for Raiders.

  9. #9
    Join Date
    Feb 2011
    Posts
    10
    I'm thrilled you're still posting!

    Quote Originally Posted by Quinafoi View Post
    If you're going to go through the effort of creating frames on the fly, registering events, and parsing combat log entries. You may as well just go through the process of writing your own addon. You basically already have everything you need already.
    The only effort anyone (other than you or I) is going to is copying and pasting - unless you're considering the game client's feelings and I really don't think it'll mind about an extra frame.

    Quote Originally Posted by Quinafoi View Post
    On a different note, you don't need to have the SetScript in the rebuke, rather, once the script is set it is continually being run on the registered event until the event is unregistered or the frame destroyed. You would need 2 macros for the creation of the frame and event handler simply because the length of the syntax is too long. However once run, you don't need to rerun that. Simply casting Rebuke would trigger the event handler (at which point it wouldn't have to be in a macro).
    I know how it works, but I didn't post this to prevaricate, or tell people how they should go about their business or to show off my knowledge - I posted it because some people want interrupt macros (with good reasons as I pointed out above) and some people want their interrupt information displayed in a reasonably accurate way. And sometimes these are the same people! Yes, this is an 'addon inside a macro' but that's no excuse for making it hard to use - like manually running a 'setup' macro at the start of each session would be.

    Quote Originally Posted by Quinafoi View Post
    Ideally though this should be done in an addon though. While you can create frames and register events in macros, doing them in addons will provide you with more flexibility. If you are an advanced enough user to be using scripts like this and maintaining them, you're advanced enough to create your own interrupt alerting addon. For that matter, you basically have all the code required already to write a simple addon.
    The brilliant thing about internet forums and the internet in general is sharing. You seem to be worried that this AddOn vs Macro debate is going to spark people into using an interrupt macro that doesn't live up to your functional expectations or that they're going to spend time doing what I did and make a macro that does. The only thing that's going to happen is that some people that want a good interrupt macro are going to get what they want (without an addon) and maybe also enjoy the protracted debate as much I have - is that such a big deal? If you're worried about the time I spent writing it, don't be! I enjoyed that too.

    Quote Originally Posted by Quinafoi View Post
    In the regard of maintenance. Now instead of relying on someone else to update a standard addon, when Blizzard releases changes to their combat log events or APIs available, the individual user has to update it themselves. This actually is harder to maintain than simply getting a third party addon to do it for you. Since this macro requires a higher understanding of Blizzard APIs and combat log event parsing, an average user will not be able to maintain it should Blizzard change something.
    Although I'm not sure what a 'standard' addon is, the point you make here is a good one. Maybe when Blizzard changes their API in a non-compatible way in a few years time I'll have given up 'maintaining' this five line macro and the same thing that happens when an addon bites the dust will happen here - someone will care enough to share their improvements with the world. The internet is a marvelous place. Addons are not magic, they don't update themselves - in fact, it's the same faceless people that write addons that facelessly write macros.

    Now, just think - whenever someone searches google for an interrupt macro they'll come here and not only have several versions of what they want readily available they can also read about all the pros and the cons that affect their decision. Take that, television!

    Dan.

  10. #10
    Join Date
    Nov 2009
    Location
    WI, USA
    Posts
    2,614
    I'm one that often embraces the "use the right tool for the job" mentality. Hence the many posts I've made in the past about modifiers being used in macros when what the user is attempting to do is better accomplished by keybindings. This actually follows similar direction. Just because you can, doesn't necessarily mean it's the ideal approach. When it comes to creating UI elements with event handlers (even if not visible), the right tool for the job is addons (because the registering and unregistering of said events can be automated rather than manually done).

    Best practice doesn't mean there aren't alternatives, it just means it is the prefered or recommended method.
    "In anything, if you want to go from just a beginner to a pro, you need a montage." /w TankSpot WTB Montage for Raiders.

  11. #11
    Join Date
    Feb 2011
    Posts
    10
    Just because that interruption alert addon one downloads should unregister combat log events when out of combat in order to follow best practice, etc doesn't mean it will - with that mentality you have to write every single feature you'd like provided by an addon or macro for yourself, or check every aspect of someone else's work before conceding to use it. There's nothing wrong with that either but the reality is that something along the lines of copy and paste is a much more attractive option for the majority of people.

    We could annihilate this whole conversation if I just had more than 255 characters to play with. Wouldn't an AddOn storage system hosted by Blizzard be great? They stream a whole ton of data to the client these days anyway - a few thousand lines of code shouldn't hurt. You could search for your addon in the client and just slide it in and not worry about transferring it to another computer or updating it because as soon as it's updated you could have it.

  12. #12
    Join Date
    Nov 2009
    Location
    WI, USA
    Posts
    2,614
    I'm not saying an addon author would necessarily follow best practices for coding an addon. I'm saying that in an addon is the best place for code like this since it relies on the creation of UI elements and event handlers. Coding of UI elements and event handlers is best suited to be done in an addon. I think you're confusing best practice of "where to put the code" which is what I'm talking about and confusing it with best practice of "how to code" (syntax, rules, ect).

    That code you wrote is better suited to be in an addon than in a macro. Just because you did it in a macro, doesn't mean a macro is the best place to do it. That's what I'm saying by best practice. It isn't "how" you coded it, but "where" you did it. There is another alternative system, addons, which is better suited for what you are trying to do. Just like how keybindings can often be used instead of modifiers in macros and are the better system (when functionally possible to accomplish the same effect). You do your customizations in the right place. You use the right tool for the job. Sure you can hammer a nail with a screwdriver, but a hammer still works better.
    Last edited by Quinafoi; 02-25-2011 at 12:19 PM.
    "In anything, if you want to go from just a beginner to a pro, you need a montage." /w TankSpot WTB Montage for Raiders.

  13. #13
    Join Date
    Feb 2011
    Posts
    10
    I thought you had a point when I thought you were talking about the actual code used, since the space available to us in macros forces you to cut corners and be inefficient. But if you're talking about the concept of the place where it's saved then I'm afraid you're going to have to be more specific to convince me, just saying that addons are the 'best place' is not enough. We're not talking about rolling out enterprise software here, we're talking about a few lines of code. The code that runs through macros is interpreted in the exact same way as that injected via addons, frames are still frames, handlers are still handlers, the API is the same, you interact in everything the same way. You even said it yourself, I'd written most of the necessary pieces for an interrupt addon in that macro.

    Your analogy is flawed, it should be "Sure you can hammer a nail with a device functionally equivalent to a hammer, but I'm saying that's not the right way to do it".

    No one's saying macros are the 'best way' to do anything, even the topic in discussion. But I'm yet to be convinced that, unless you want different/more functionality, if the code I wrote moved itself to an addon it would have made itself somehow intrinsically better.

    Dan.

  14. #14
    Join Date
    Feb 2011
    Location
    West Coast
    Posts
    170
    I don't think interrupt messages are useful or practical and I would like to put forward a different approach. You should build an attack plan instead and alternate interrupts with another person. You call "interrupt" on the headset as you are pressing the button and if the cast bar doesn't go away then your backup interrupt person fires immediately. If you are in a pug group your macro could help out but I don't recommend pug groups.. LOL

    Messages can work if the person knows to fire interrupt immediately when they see the party message or whisper. But honestly building an attack plan makes everything go so smooth.. You don't have to say I failed the interrupt we are all seeing the same thing as you.. We just need to know you fired it so we can see if it worked.. and getting that info in our ear leaves my eyes available to do other things.

    P.S. Clique is a macro addon that lets you use unlimited characters in your macro.. I LOVE clique

  15. #15
    Join Date
    Feb 2011
    Posts
    10
    I agree with you in almost every particular.

    Quote Originally Posted by Contravene View Post
    P.S. Clique is a macro addon that lets you use unlimited characters in your macro.. I LOVE clique
    The macros that clique allows you to create, though, are stored client side which means you can't take them with you automatically when you move computers which is one of the advantages (even if the very concept of these alerts is flawed!) of a macro over an addon.

  16. #16
    Join Date
    Nov 2009
    Location
    WI, USA
    Posts
    2,614
    The reason why you don't want to create event handlers inside of a macro is because of the code scope and how the World of Warcraft client application handles errors in LUA. If your script was executed in line, it would exist in the macro scope and result in a LUA error immediately. However the SetScript API call when called directly does not validate that the syntax being passed will actually execute correctly. It's a bit of a hard case to prove why without forcibly killing the World of Warcraft client with a faulty syntax that can be killed by the addon killing method built into the application.

    You ever get an error message from the World of Warcraft client application where an addon has encountered an error and it gives you the option to disable the addon or ignore the error. This is because of the code scope being executed where the error occured was traced to an addon and the application's built in error handling routines were able to capture the error and prevent it from leading to system instability. When you create a frame and add an event handler to it, that code is executed every time that event occurs. However if you do this in a macro or similarly by simply typing it in directly, it doesn't have an scope to tie it back to. Any errors in this would in turn be raised to the user or lead to system instability because the World of Warcraft client can't simply kill the whole scope (disable the addon). It doesn't exist in any scope. Once the macro has already run, the frame exists and the event handler is running outside of any scope.

    The reason why you want to do this in an addon is because of how the World of Warcraft client application handles and interprets what to do with errors.

    Simply put, if the code repeatedly tries to do something it shouldn't, World of Warcraft client application can't do anything about it, there is no addon to kill. Scripts inside of macros should be limited to scripts that are run immediately within the scope of the macro such that if an error occurs it has something to terminate (the macro scope). The event handler you create continues to run even when your macro is complete.

    I'd really rather not spend my time writing a macro that will kill the World of Warcraft client and then an addon that does the same thing and pops up the warning to disable the addon.

    If there is an error in the code, it has no scope to kill. Since it can't kill a sub process scope, the World of Warcraft client continues to run the faulty code.
    "In anything, if you want to go from just a beginner to a pro, you need a montage." /w TankSpot WTB Montage for Raiders.

  17. #17
    Join Date
    Feb 2011
    Posts
    10
    There're three types of relevant in-game errors I can think of. Syntax errors, run-time errors and taint. And you must be talking about taint; syntax errors are caught even when that syntax is in a function callback and run-time errors (something that could conceivably crash the client) are handled just as well in macros as they are in addons. So we're talking about taint and we can ignore those scary things you said about it being easier to write a macro that crashes the client than writing an addon which does (there's no difference).

    Taint is Blizzard's way of preventing lua code from accessing things which should be controlled manually by a player - for example you can't access the functions that cast spells, otherwise you could do things like automatically choose a certain healing spell depending on the health of its target (like we could in vanilla ). As soon as an addon touches something it shouldn't that addon becomes 'tainted' and its execution is stopped which is the point at which you get that 'error' Quinafoi mentions where you get the option to disable it.

    I mention all of this because I want to be clear that the response of the game client upon encountering a taint error isn't a scary one, it doesn't shut itself down and munch on your hard-drive or spew out errors it just tells you something went wrong and the worst thing that can happen is that what you were expecting to occur simply didn't. It's true that there is no option to disable the macro, though that just means that you may see the error again; you still lose the functionality you were hoping for just as you would if you disabled an equivalent addon.

    If an addon causes tainting issues (and yet you still want the functionality) then it has to be fixed by the author, this is no different to a macro with the same problem and it's no easier on the user, either way.

    Addons aren't magic.

    If an addon author has written code that raises tainted execution errors and s/he releases this addon to the public he probably hasn't noticed it during testing - this is a lot more likely to happen in an addon where functionality can be a lot more complicated than in a macro, especially in a macro like the one we're actually discussing that couldn't conceivably even create the whiff of a tainted execution path (unless I guess if something else taints CreateFrame, RegisterEvent or SendChatMessage, but by that point your whole UI is screwed by something else anyway).

    In short, I agree that if everyone starts cramming advanced addons into macros it might be harder on the user to distinguish which addon has gone wrong but (unless they're the developer or another lua coder) they can't do anything about it anyway. I stand by my opinion that there is a place for lua code in macros and that it isn't inherently flawed, and certainly not on the grounds of it being more error prone or more likely to crash the client.

    Dan.

  18. #18
    Join Date
    Feb 2011
    Location
    West Coast
    Posts
    170
    I saw this Addon called Interrupt Spam and I thought of the OP.. Not sure if this would help you out.

    http://wow.curse.com/downloads/wow-a...rruptspam.aspx

  19. #19
    Join Date
    Aug 2009
    Posts
    145
    Quote Originally Posted by fakeh View Post
    If an addon causes tainting issues (and yet you still want the functionality) then it has to be fixed by the author, this is no different to a macro with the same problem and it's no easier on the user, either way.

    ...

    In short, I agree that if everyone starts cramming advanced addons into macros it might be harder on the user to distinguish which addon has gone wrong but (unless they're the developer or another lua coder) they can't do anything about it anyway. I stand by my opinion that there is a place for lua code in macros and that it isn't inherently flawed, and certainly not on the grounds of it being more error prone or more likely to crash the client.
    There's another aspect of all this that hasn't been brought up at all so far - readability. In my opinion, the moment you start needing two macros to perform one task, move the task to an addon. Sure, there might be ways that you can save character counts by assigning repeatedly used function names to variables, but regardless, once a script has reached 255 characters, it should likely go into an addon.

    The other thing that I can't understand about creating an event handler in a macro is that now the onus is on the user to run that macro any time that he/she wants the event to be handled. If it's something like combat log parsing (as the OP was asking about), why not have it register the event automatically when appropriate (entering world, joining a party, etc etc)?

    As a final note - unless the user can do so themselves, if a script that someone else has written causes errors it's still up to the author to fix it regardless of whether the script is run as a macro or an addon.

  20. #20
    Join Date
    Feb 2011
    Posts
    10
    Quote Originally Posted by Zxian View Post
    There's another aspect of all this that hasn't been brought up at all so far - readability. In my opinion, the moment you start needing two macros to perform one task, move the task to an addon. Sure, there might be ways that you can save character counts by assigning repeatedly used function names to variables, but regardless, once a script has reached 255 characters, it should likely go into an addon.
    I don't think readability is a concern (uses don't generally read code in macros or otherwise) but I certainly agree that as soon as you go into two macros you lose ease of 'installation', it's one of the things you sacrifice for better portability.

    Quote Originally Posted by Zxian View Post
    The other thing that I can't understand about creating an event handler in a macro is that now the onus is on the user to run that macro any time that he/she wants the event to be handled. If it's something like combat log parsing (as the OP was asking about), why not have it register the event automatically when appropriate (entering world, joining a party, etc etc)?
    Because I didn't want to further hinder ease-of-use by having a macro you had to run at the beginning of your session. This is why I think an addon would be better at this task, you can code it better so that you can have it only when you want it and the client doesn't have to spend a nano-second running the setup script every time. But that wasn't what the argument was about.

    Hilariously, patch 4.1 is going to break COMBAT_LOG_EVENT event scripts by adding in a new parameter. Faithfully serving the no-doubt thousands of 'interrupt addon in a macro' users out there I will be editing the original post to reflect the necessary changes in order to keep the dream alive.

+ Reply to Thread

Bookmarks

Posting Permissions

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