• You've discovered RedGuides, an EverQuest multi-boxing and scripting community 🧙‍♀️⚙️. We want you to play several EQ characters at once, come join us and say hello! 👋

  • A TLP without truebox has thawed (Very Vanilla ready)
    Frostreaver

Tip - MQ2 React Collection

  • Thread starter Thread starter drwhomphd
  • Anyone can edit the first post of this thread WikiPost WikiPost
  • Start date Start date
Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.
Dragonslayer said:
If I understood right, Kissassist doesn't like mq2cast. When starting kissassist, it eveb searches for mq2cast and if active, it will be unloaded.
what would be a working solution for:
action: /cast Zrelik's Recourse
condition: ${Me.SpellReady[Zrelik's Recourse]} && ${React.Global[IC]}"

if I dont want to use anything from mq2Cast? Shall that be the solution without mq2Cast?
globals:
IC: "${Me.CombatState.Equal[COMBAT]}"
NotCasting: "!${Me.Casting.ID}"
ZrelikGem: "8"
OneBelow50: >-
${Group.Member[0].PctHPs} <= 50 || ${Group.Member[1].PctHPs} <= 50
|| ${Group.Member[2].PctHPs} <= 50 || ${Group.Member[3].PctHPs} <=
50 || ${Group.Member[4].PctHPs} <= 50 || ${Group.Member[5].PctHPs}
<= 50

action: /cast ${GemZrelik}
condition: >-
${React.Global[NotCasting]} && ${React.Global[IC]} && ${React.Global[NmoveNinvNsit]}
&& ${React.Global[OneBelow50]} && ${Me.SpellReady[${GemZrelik}}

It doesn't cause any error message.
Is there a better condition for "any groupmember below 50% hp?
Click to expand...
intInjured[XX]Will return the numbers of people in the group that has a hp percent lower than 90

Suspect the XX mean the percent (you will have to test it)
/echo ${Group.Injured[50]}

Fleeting did a few echos and looks like you give the percentage.
 
Last edited by a moderator:
Here is how it looks like now:
shamans big groupheal asap when atleast 1 groupmeber falls below 50% hp without any need of mq2cast
NB: the gem which holds the spell, has to be set at globals: "GemZrelik"

globals:
GemZrelik: 8
IC: "${Me.CombatState.Equal[COMBAT]}"
NmoveNinvNsit: "!${Me.Moving} && !${Me.Invis} && !${Me.Sitting}"
NotCasting: "!${Me.Casting.ID}"
Sub50: "${Group.Injured[50]} > 0"

ShmZrelik:
action: "/multiline ; /stopcast ; /cast ${GemZrelik}"
condition: >-
${React.Global[IC]} && ${React.Global[NmoveNinvNsit]}
&& ${React.Global[Sub50]} && ${Me.SpellReady[${GemZrelik}}
 
My PullerTank is an SK. They get a self-cure AA called Purity of Death (AA #2031).

The spiders in ToV Crystal Caverns will sometimes root my puller and if there are enough of them on my back they'll kill me.

This React is my first pass on trying to cure myself so I have a better chance of getting back to the group alive.

[CODE lang="yaml" title="Puller cure YAML"]
CurePuller:
action: >-
/multiline ; /stopcast ; /delay 1 ; /nav pause ; /mqp on ; /keypress
F1 ; /delay 1 ; /echo Attempting to cure my snare or root ; /alt
act 2031 ; /mqp off
condition: "${Me.Snared.ID} || ${Me.Rooted.ID} && ${Me.AltAbilityReady[2031]}"
[/CODE]

Edited to add: I tried @jande's method immmediately below this post but wasn't successful. I updated my code here to reflect what appears to work for me now. Also found that I needed even more help keeping the SK alive so I added another React to use his Harmshield if the cure didn't work!

[CODE lang="yaml" title="Puller Save YAML"] SavePuller:
action: >-
/multiline ; /stopcast ; /nav pause ; /mqp on ; /keypress F1 ; /echo
Attempting to save myself ; /alt act 821 ; /mqp off
condition: >-
${Me.Snared.ID} || ${Me.Rooted.ID} && !${Me.AltAbilityReady[2031]}
&& ${Me.AltAbilityReady[821]}
[/CODE]
 
Last edited:
B_I_G__D_A_D_D_Y said:
My PullerTank is an SK. They get a self-cure AA called Purity of Death (AA #2031).

The spiders in ToV Crystal Caverns will sometimes root my puller and if there are enough of them on my back they'll kill me.

This React is my first pass on trying to cure myself so I have a better chance of getting back to the group alive.

[CODE lang="yaml" title="Puller cure YAML"] CurePuller:
action: >-
/multiline ; /stopcast ; /nav pause ; /mqp on ; /keypress F1 ; /echo
Attempting to cure my snare or root ; /alt act 2031 ; /mqp off
condition: "${Me.Snared.ID} || ${Me.Rooted.ID} && ${Me.AltAbilityReady[2031]}"
[/CODE]
Click to expand...
need /timed for the /mqp off
/multiline tries to run all without delays

Don't think purity of death has a cast timer so /mqp not needed
Selfcure too so no need for F1

/multiline ; /stopcast; /echo Attempting to cure my snare or root; /alt act 2031;
Should be enough
 
Here my first 3 working reacts:
they work without Mq2Cast so they can be combined with i.e. Kissassist
motivation:
I created these 3 reacts, as sometimes I have the feeling, kissiassist is not in all situations sufficient responsive
Zrelik still has it's normal conditions in kissassist as well so both systems can launch them at will; the emergency-Heal "Primordial Intervention" I left full under the control of kissassist, as well as all other not mentioned heals.
The Shamans BP and the AA-emergency-heal "Soothsayser's Intervention" are now under the sole control of react, expecting that react will be faster in using them when needed

[CODE lang="yaml" title="Shaman Groupheals"]globals:
GemZrelik: 12
IC: "${Me.CombatState.Equal[COMBAT]}"
NIC: "${Me.CombatState.NotEqual[COMBAT]}"
NmoveNinvNsit: "!${Me.Moving} && !${Me.Invis} && !${Me.Sitting}"
NotCasting: "!${Me.Casting.ID}"
Sub30: "${Group.Injured[30]}"
Sub50: "${Group.Injured[50]}"
Sub70: "${Group.Injured[70]}"
Sub90: "${Group.Injured[90]}"
TNamed: "${Target.Named}"
bTank: "${Group.Member[0].MainTank}"

ShmH1Zrelik:
action: "/multiline ; /stopcast ; /cast ${React.Global[GemZrelik]}"
condition: >-
${React.Global[NmoveNinvNsit]} && (${React.Global[Sub70]} || (${React.Global[Sub90]}
&& ${React.Global[IC]})) && ${Me.SpellReady[${React.Global[GemZrelik]}]}
ShmH2BP:
action: "/multiline ; /stopcast ; /useitem ${InvSlot[Chest].Item.Name}"
condition: "${React.Global[NmoveNinvNsit]} && ${React.Global[Sub30]} && ${Me.ItemReady[${InvSlot[Chest].Item.Name}]}"
ShmH3SoothAA:
action: /multiline ; /stopcast ; /alt act 619
condition: >-
${React.Global[NmoveNinvNsit]} && ${React.Global[Sub30]} && !${Me.ItemReady[${InvSlot[Chest].Item.Name}]}
&& ${Me.AltAbilityReady[Soothsayer's Intervention]}[/CODE]

For testing I used them with the condition "Sub70" and the AA-Canni. In this tests they work as expected.
From tomorrow they will be tested and used under "life" conditions.

Zrelik has a long casttime, so its used if either one groupmember is below 70% hp, or incombat and 1 below 90% hp
If one Groupmember is dropping below 30% hp, the shamans BP is used for heal, if the BP is on Cooldown, as last ressort the Shamans AA "Soothsayers Intervention" is used to delay any deaths.


If you plan to use them you may take care of:
globals:
GemZrelik: 12 -> put here the gem where you placed Zrelik's Recourse

ShmH1Zrelik:
condition: >- -> may check if the codition matches your needs, a maybe simpler and working one would be:
${React.Global[NmoveNinvNsit]} && ${React.Global[Sub70]} && ${Me.SpellReady[${React.Global[GemZrelik]}]}
 
Dragonslayer said:
If I understood right, Kissassist doesn't like mq2cast. When starting kissassist, it eveb searches for mq2cast and if active, it will be unloaded.
Click to expand...
KA is perfectly fine with MQ2Cast. Kiss only does this if you have UseMQ2Melee=0. Set that =1 and it will stop unloading mq2cast (yes, one setting controls both plugins).
 
@SA_krycek tyvm, until your information I was under the impression, that there had been some interferences/compatibility-issue. Why would a macro force a /plugin unload if a plugin does no harm? It doesn't feel intuitive, that this behavior was linked to the wish to not use mq2meele.
 
I'm not so sure that YAML is a good thing. It's "white space sensitivity" seems like an artificial and error-prone constraint?

I use Notepad++ to edit the yaml file and what I've found is that I have to turn off Wrapping and code without line breaks and wrapping. Then I let the module itself reformat it for me when I enable the specific react.

In the long run, it's not a big deal and the plugin itself is awesome!
 
I'm not so sure that YAML is a good thing.
Click to expand...
I'm completely sure it's a good thing based on the amount of code required to handle it in the plugin. Considerably less error prone (mini-yaml serializer issues aside) than doing INI parsing as well. I value my personal time far too much to NOT use yaml for a configuration format. Plus the next major version of mq2 will have yaml built-in and many plugins will most likely transition in this direction (personal opinion).

It's "white space sensitivity" seems like an artificial and error-prone constraint?
Click to expand...
It is arguably less error pone in the long run both from a programmer and configurator perspective. It was purposefully designed to be whitespace sensitive -- there's considerable work out and about in the world about the benefits of whitespace sensitivity in syntax design. Much of this is solved by using a good text editor (notepad++, Visual Studio Code, vim, emacs, or anything that isn't notepad.exe)

Then I let the module itself reformat it for me when I enable the specific react.
Click to expand...
Sadly a drawback (benefit?) of the mini-yaml library. It's serializer uses its own preferred formatting rules when the file saves.

In the long run, it's not a big deal and the plugin itself is awesome!
Click to expand...

Thanks. The other nice thing about it is the meat and potatoes of it all fits within 50 lines of code. The rest is just handling TLOs and the slash-commands.
 
Maybe some of this is already possible. I use yaml a lot in my work so I naturally want to do a couple things here that I don't think you can:

Can you make condition accept a list of implicit "and" conditions:

condition:
- A > B
- C < F

and similarly make action accept a list of actions:

action:
- /stand
- /cast whatever

and maybe

maction:
- /stand
- /cast whatever

Would automatically build a /multline from the list of actions . This might make reacts a little easier to read.

Just an idea. Awesome plugin. (sorry, should have put this in the main mq2react thread)
 
Last edited:
My general preference is to not do anything special for the user so they can have specific control over both to avoid issues with automation conflicting with other parts of the gameplay. At a certain point, if you had a lot of actions you were tying together, you should just write a macro.
 
drwhomphd said:
My general preference is to not do anything special for the user so they can have specific control over both to avoid issues with automation conflicting with other parts of the gameplay. At a certain point, if you had a lot of actions you were tying together, you should just write a macro.
Click to expand...
I dunno. Looking at the samples so far I see a trend toward the action and condition sections getting denser and harder to follow. I think being able to break it out a little for readability would be a boon for react configs. At least I have my idea out there in case you change your mind :). Sorry, didn't mean to inject a discussion into this thread. I'll post my merc burn/revive reacts after a little more testing to make up for it :).
 
Looking at the samples so far I see a trend toward the action and condition sections getting denser and harder to follow.
Click to expand...
My design advice is if you're getting to the point where you have complex actions, or a series of complex actions, I'd start adding binds to the regularly used macros or just create a macro with an empty main loop (with a delay and event processing) that purely handles binds. You can then call the binds from mq2react. /multiline isn't particularly robust (i.e., you can't use /delay with it and /timed is problematic for other reasons) and you really shouldn't be doing complex automation in a plugin (this is an area of design disagreement in the mq2 community -- but it's far too easy to have plugins and macros fight with each other).
 
drwhomphd said:
.../multiline isn't particularly robust (i.e., you can't use /delay with it and /timed is problematic for other reasons)...
Click to expand...

This was news to me and led me into a 15 minute session right now trying to find out where this information is documented. I believe you! But I can't find a definitive reference on this limit to using /delay in a /multiline statement.

Indeed, your example React uses the /delay command in the Action section!

Again, I don't doubt you, but this makes writing robust actions very difficult if you can't pace the action to allow for lag and other external factors. I had never seen or used the /timed command before. But you say that's problematic also?

The only other solution I can envision would entail the use of Global Reacts to act as a sort of cascading sequence of triggers so that succeeding actions take place on successive pulses as the previous action toggled. And then you'd have to reset all these toggle conditions back to their original state when completely finished.
 
This was news to me and led me into a 15 minute session right now trying to find out where this information is documented.
Click to expand...

Only place I've ever seen it "documented" (and I use that term loosely) is discussions with Kaen and some others on discord. I don't believe it's noted anywhere in the wikis.

Again, I don't doubt you, but this makes writing robust actions very difficult if you can't pace the action to allow for lag and other external factors.
Click to expand...

Correct. Generally why they should be done in binds. Would have been the same issue with mq2melee's holys/downs too I believe. All it's doing is making you write out the whole if statement yourself and calls it the same way you'd just type it in.

But you say that's problematic also?
Click to expand...
It works -- it's just not a replacement for delay. It says wait so many tens of seconds then execute the command so you're basically having to guess when the last command completes... and start working on funny math... etc.... So it's fine for something simple.

The only other solution I can envision would entail the use of Global Reacts to act as a sort of cascading sequence of triggers so that succeeding actions take place on successive pulses as the previous action toggled. And then you'd have to reset all these toggle conditions back to their original state when completely finished.
Click to expand...
And this is why I suggest folks write macros for complex automation. Considerably easier to read, understand, and debug. With #include_optional there's no reason all automation macros shouldn't just have a #include_optional rgcustom.inc (selfish push for standard naming) at the top of their macro to let folks include their own custom binds that perform more advanced automation (and then they can use /delay too!)
 
Now, that I tried mq2react for serveral days, I can state that I am very happy with its responsiveness. I am able to survive camps, where formerly I had to help manually to keep the team alive. Now I can do them more relaxed, as there is no longer the need for manual interventions. For my experience I can state, that it does all, what I hoped for.
Thank you for this nice tool.
 
Expanding on the issue of delays in multilines -- you can think of multiline's implementation as if you are hitting all of the "lines" in rapid succession. If it helps, think if it as each multiline being executed at the same time. So while the delay can be executed, it is it's own "line" and is not "waiting" for something else to execute.

Given that the lines are executed at the "same" time, /timed can be used to mimic a delay, but /timed is a bit confusing because it needs to be issued from a "cumulative time" standpoint. Meaning that if you want one command to happen 2s after another command, if that first command is also using /timed then you need to add that to your 2s. So for example, a 2s timed occurring after a 1s timed actually needs to be a 3s timed (accounting for the first second -- again, think of it like all commands executing at the same time).

There's a good thread on it somewhere around here.
 
On TLPs I always find myself leaving enduring breath items on my chars 100% of the time because I spent a lot of time in water zones and navigating through even a little water can drown you. Then I picked up tanking AoW the other day and realized my rebreather was still on so I decided to use MQ2React with MQ2Exchange to automatically switch between items whenever I get into the water and back out.

Notes: You will need to maintain this as you get new items. I also set it up to work for 12 chars with different items which meant I copied the code below 12 times and renamed the items and the reacts to be "LandReactCharname" on. I didn't want to get spammed when staying on land or in the water so it turns that react off and the other one on so it is waiting for you to switch states. There is probably a more efficient way to do that but this works for me.

YAML: 
reacts:
  LandReact:
    action: >-
      /multiline ; /echo Putting normal item back on ;  /exchange "Insidious
      Halo" head ; /react enable WaterReact ; /react disable LandReact
    condition: "!${Me.FeetWet}"
  WaterReact:
    action: >-
      /multiline ; /echo Putting on EB item ; /exchange "Rebreather" head
      ; /react enable LandReact ; /react disable WaterReact
    condition: "${Me.FeetWet}"
 
Is there a condition for when auto attack is on? For example I have a react that will automatically kick if I'm in combat, but I'd like it to kick only if I have auto attack on instead of just in combat.
 
madruk20 said:
Is there a condition for when auto attack is on? For example I have a react that will automatically kick if I'm in combat, but I'd like it to kick only if I have auto attack on instead of just in combat.
Click to expand...
I would use mq2melee for that. You could turn off all the other parts of it except the combat abilities like kick
 
madruk20 said:
Is there a condition for when auto attack is on? For example I have a react that will automatically kick if I'm in combat, but I'd like it to kick only if I have auto attack on instead of just in combat.
Click to expand...

Depending on your class and server you may just want to use /autoskill kick and let the EQ client take care of that for you.
 
I figured it out. It's ${Me.CombatState.Equal[ACTIVE]}. I play on a tlp server pre-planes of power so can't use autoskill yet. It's been useful for placing my melee manually for certain fights.
 
runcade said:
On TLPs I always find myself leaving enduring breath items on my chars 100% of the time because I spent a lot of time in water zones and navigating through even a little water can drown you. Then I picked up tanking AoW the other day and realized my rebreather was still on so I decided to use MQ2React with MQ2Exchange to automatically switch between items whenever I get into the water and back out.

Notes: You will need to maintain this as you get new items. I also set it up to work for 12 chars with different items which meant I copied the code below 12 times and renamed the items and the reacts to be "LandReactCharname" on. I didn't want to get spammed when staying on land or in the water so it turns that react off and the other one on so it is waiting for you to switch states. There is probably a more efficient way to do that but this works for me.

YAML: 
reacts:
  LandReact:
    action: >-
      /multiline ; /echo Putting normal item back on ;  /exchange "Insidious
      Halo" head ; /react enable WaterReact ; /react disable LandReact
    condition: "!${Me.FeetWet}"
  WaterReact:
    action: >-
      /multiline ; /echo Putting on EB item ; /exchange "Rebreather" head
      ; /react enable LandReact ; /react disable WaterReact
    condition: "${Me.FeetWet}"
Click to expand...
I'd asked for help writing this, and it's such a clever solution. Thank you @runcade!
 
locals:
MyId: 1
globals:
NextId: 1

SetId:
action: >-
/multiline ; /echo id Active ; /cast 2
; /setvar NextId = ${React.Local[MyId]}
condition: "${React.Global[NextId]} == ${React.Local[MyId]}"

Is something like this possible?
Question 1: How can I define local variables? What would be the right syntax?
Question 2: How can I set the value of a global variable to the value of a local variable?
Question 3: How can I compare the value of a global variable to the value of a local variable?
 
This is what I use for my monk, swapping between bando's when fists of fury procs. he's 110, so if you're 115 you'll have to change it from II to III. I have it enabling and disabling out of preference. Must have the "fists" and "twohander" bandolier.

YAML: 
  fists:
    action: >-
      /multiline ; /bandolier Activate fists ; /react disable fists ; /react
      enable twohander
    condition: "!${Me.Song[Fists of Fury II].ID} && !${Me.Bandolier[fists].Active}"
  twohander:
    action: >-
      /multiline ; /bandolier Activate twohander ; /react disable twohander
      ; /react enable fists
    condition: "${Me.Song[Fists of Fury II].ID} && !${Me.Bandolier[twohander].Active}"
 
Paladin Self Purification for Snare, Root, Restless Ice, and Skewer

[CODE lang="ini" title="PallySelfCure:"] PallySelfCure:
action: >-
/multiline ; /echo Attempting to cure my snare or root ; /alt act
286
condition: >-
${Me.Snared.ID} || ${Me.Rooted.ID} || ${Me.Song[Restless Ice].ID}
|| ${Me.Buff[Skewer].ID} && ${Me.AltAbilityReady[Purification]}[/CODE]
 
If you run a fellowship vitality group may find this useful when you want to grind on the vitality receiver and on the vitality senders at the same time
It turns sharing on/off depending on mob hp. It seems to work my AA vitality is slowly creeping up.

XTar 1 has to be the group assist, so that the hp of the mob can be checked

You need to set jFellow to your slot position in the fellowship window
I do it by having a entry in zoned.cfg as my fellowships do not change all that much.
Code: 
/if (!${Defined[jFellow]}) /declare jFellow int global
/varset jFellow ${Window[FellowshipWnd].Child[FP_FellowshipPage].Child[FP_MemberList].List[${Me.CleanName}]}

YAML: 
  FellowXP:
    action: >-
      /multiline ; /nomodkey /notify FellowshipWnd FP_MemberList listselect
      ${jFellow};
    condition: "${Defined[jFellow]} && ${jFellow} && !${Window[FellowshipWnd].Child[FP_FellowshipPage].Child[FP_ToggleExpSharingButton].Enabled}"
  FellowXPoff:
    action: >-
      /multiline ; /nomodkey /notify FellowshipWnd FP_ToggleExpSharingButton
      leftmouseup; /react disable FellowXPoff; /react enable FellowXPon
    condition: >-
      ${Me.XTarget} && ${Defined[jFellow]} && ${jFellow} && ${Me.XTarget[1].PctHPs}<15
      && ${Window[FellowshipWnd].Child[FP_FellowshipPage].Child[FP_MemberList].List[${jFellow},7].Equal[sharing]}
  FellowXPon:
    action: >-
      /multiline ; /nomodkey /notify FellowshipWnd FP_ToggleExpSharingButton
      leftmouseup; /react disable FellowXPon; /react enable FellowXPoff
    condition: >-
      (!${Me.XTarget} || ${Defined[jFellow]} && ${jFellow} && ${Me.XTarget[1].PctHPs}>20)
      && ${Window[FellowshipWnd].Child[FP_FellowshipPage].Child[FP_MemberList].List[${jFellow},7].Equal[not
      sharing]}
 
Last edited:
These are a few of the reacts I use:

Mq2Nav doesn't work that great with lev so I use the following simple react for when moving with lev on:
INI: 
LevDown:
    action: /multiline ; /keypress End hold
    condition: ${Navigation.Active}

Also, the shaman dissident/composite lines block the SK Impertinent Influence discipline pet buff, so I use the following to fix that problem:
INI: 
  PetDisc:
    action: /removepetbuff Dissident Roar 4
    condition: >-
      ${Me.ActiveDisc.Name.Equal[Impertinent Influence Rk. II]} && ${Pet.Buff[Dissident
      Roar 4]}
  PetDisc2:
    action: /removepetbuff Composite Roar 2
    condition: >-
      ${Me.ActiveDisc.Name.Equal[Impertinent Influence Rk. II]} && ${Pet.Buff[Composite
      Roar 2]}
 
ljc said:
This is what I use for my monk, swapping between bando's when fists of fury procs. he's 110, so if you're 115 you'll have to change it from II to III. I have it enabling and disabling out of preference. Must have the "fists" and "twohander" bandolier.

YAML: 
  fists:
    action: >-
      /multiline ; /bandolier Activate fists ; /react disable fists ; /react
      enable twohander
    condition: "!${Me.Song[Fists of Fury II].ID} && !${Me.Bandolier[fists].Active}"
  twohander:
    action: >-
      /multiline ; /bandolier Activate twohander ; /react disable twohander
      ; /react enable fists
    condition: "${Me.Song[Fists of Fury II].ID} && !${Me.Bandolier[twohander].Active}"
Click to expand...

Does anyone have something similar to the above for swapping between 1-hander+shield and a 2-hander bandolier for a tank class?

I'm trying to figure something out where my tank would use a 2-hander unless he was being hit/had agro on a mob ... at which time he would automatically swap to sword+board.
 
Sum1 said:
Does anyone have something similar to the above for swapping between 1-hander+shield and a 2-hander bandolier for a tank class?

I'm trying to figure something out where my tank would use a 2-hander unless he was being hit/had agro on a mob ... at which time he would automatically swap to sword+board.
Click to expand...

Define 2 bandolier slots shield / 2hd (or change the react to use your names)
YAML: 
  SwapShield:
    action: /invoke ${Me.Bandolier[Shield].Activate}
    condition: "${Me.Bandolier[2hd].Active} && ${Me.XTAggroCount} != ${Me.XTarget} && ${Me.PctHPs}<90"
  Swap2hd: 
    action: /invoke ${Me.Bandolier[2hd].Activate}
    condition: "${Me.Bandolier[Shield].Active} && ${Me.XTAggroCount} == ${Me.XTarget} && ${Me.PctHPs}>90"

Checking HP so that you only switch at that health levels. Could drop the XT part and just switch on health.

PS: tested the condition parts with /echo, this is not one I use.
 
Last edited:
Sum1 said:
Does anyone have something similar to the above for swapping between 1-hander+shield and a 2-hander bandolier for a tank class?

I'm trying to figure something out where my tank would use a 2-hander unless he was being hit/had agro on a mob ... at which time he would automatically swap to sword+board.
Click to expand...
or
${Me.XTarget}> 2 || ${Target.Named}
 
Robban said:
or
${Me.XTarget}> 2 || ${Target.Named}
Click to expand...

I'm using this in situations where there will usually be more than 2 on xtarget and probably always a named, as well (raids).

Given my particular use case, I would probably opt to keep the MQ2React focused on swapping from 2-hander to 1-hander+Shield. I would manually swap back to 2-hander when I deem it safe enough to do so. I'm mostly just trying to ensure that if I go from dps to tanking that I swap in the tanking weapon setup asap.
 
Sum1 said:
I'm using this in situations where there will usually be more than 2 on xtarget and probably always a named, as well (raids).

Given my particular use case, I would probably opt to keep the MQ2React focused on swapping from 2-hander to 1-hander+Shield. I would manually swap back to 2-hander when I deem it safe enough to do so. I'm mostly just trying to ensure that if I go from dps to tanking that I swap in the tanking weapon setup asap.
Click to expand...
aggro > 99 ?
 
Robban said:
aggro > 99 ?
Click to expand...
Wouldn't that only work if I had agro on my target?

Say I'm whacking on a boss with my 2-hander but get agro on an add. I don't want to die to the add while my 2-hander is out and before I can swap to the add with my 1-hander + shield.

Also, checking hps only works if the event doesn't have crazy wild ramp... which all raid events nowadays do.
 
Sum1 said:
Wouldn't that only work if I had agro on my target?

Say I'm whacking on a boss with my 2-hander but get agro on an add. I don't want to die to the add while my 2-hander is out and before I can swap to the add with my 1-hander + shield.

Also, checking hps only works if the event doesn't have crazy wild ramp... which all raid events nowadays do.
Click to expand...
Yeah, I thought you could swap to s&b if aggro > 99
 
Can anyone clear this line up for me? I am getting an error of 'invalid quote' when I start MQ2react for this:
Memento:
action: /useitem Memento of the Ungod's Suffering
condition: !${Me.Invis} && !${Me.Moving} && !${Me.Buff[Aura of the Void II].ID}
Click to expand...
 
You must log in or register to reply here.
Tip - MQ2 React Collection
Next unread thread 🦁

Users who are viewing this thread

Total: 1 (members: 0, guests: 1)
Back
Top
Cart

Cart

Total -