Rogue Helper v6.0 [Complete Rogue Macro] (Updated: 10-26-04)

Post your completed (working) macros here. Only for macros using MQ2Data syntax!

Moderator: MacroQuest Developers

Vexix
Genbot Janitor
Posts: 245
Joined: Sat Apr 17, 2004 10:10 am

Post by Vexix » Mon Jun 07, 2004 12:16 pm

Jerle,

Hey! Very cool code. ;) I had no idea you could do dynamic events that way. Whoa. Will have to work that into my routines somehow.

I've also noticed that genbot drags down the framerate when running. What suggestions do you have for improving framerate, or how did you improve it with RH?

--Vexix

Jerle69
a hill giant
a hill giant
Posts: 263
Joined: Wed Apr 28, 2004 3:26 pm

Post by Jerle69 » Mon Jun 07, 2004 2:07 pm

A_Rogue00:

Hrmm, make sure that you have ATTACKER HITS and ATTACKER MISSES not filtered out in your options. If they're not on, then this won't work. I'll take another look tonight and see if it's working properly, but I know if you have those filters off, it certianly WILL NOT work.

Vexix:

Not sure how genbot implements autofollowing or executes running. I use the new shortcircuit logic in /delay coupled with 1 second window intervals while doing any movement (running, stafing, whathaveyou). This allows for rapid event updates and detection. It's pretty much a whole different engine strategy :)
--Jerle

TrippyTom
a lesser mummy
a lesser mummy
Posts: 75
Joined: Sun May 30, 2004 10:18 am

re: /drag

Post by TrippyTom » Tue Jun 08, 2004 12:02 am

I double checked before posting this and the macro does not put you into hide/sneak mode when you use this command. Can you put this into the macro?
May the eclipse of your soul never fade to light!

Jerle69
a hill giant
a hill giant
Posts: 263
Joined: Wed Apr 28, 2004 3:26 pm

Post by Jerle69 » Tue Jun 08, 2004 11:51 am

TrippyTom:

Well, I could (it's not that big a deal really), but I'm not sure why? I understand it's dangerous to drag corpses through hostile territory, but shouldn't it be your choice whether to hide and sneak while dragging corpses? I mean, after all it's not always necessary. The macro already does so many things you protect you from your own mistakes, I'm not sure this one is really all that needed.

If you want it in yours, just change the DragBodies sub to look like this:

Code: Select all

Sub Event_DragBodies(string Line) 
  /declare ArgNum int local 3 
  /declare bodycount int local 

  [color=yellow]:ForceHideSneak
  /if (${Me.AbilityReady["Sneak"]} && !${Me.Casting.ID} && ${Me.State.NotEqual[BIND]} && !${Window[TradeWnd].Open} && !${Window[MerchantWnd].Open} && !${Window[BigBankWnd].Open}) /doability "Sneak" 
  /if (${Me.AbilityReady["Hide"]} && !${Me.Casting.ID} && !${Me.Moving} && ${Me.State.NotEqual[BIND]} && !${Window[TradeWnd].Open} && !${Window[MerchantWnd].Open} && !${Window[BigBankWnd].Open}) /doability "Hide" 
  /if (!${Me.Sneaking} || !${Me.Invis}) /goto :ForceHideSneak[/color]

  :CountCorpses 
  /if (${Line.Arg[${ArgNum}].Length}) { 
    |- There's a body name for this argument 
    /varcalc ArgNum ${ArgNum}+1 
    /goto :CountCorpses 
  }  
  /varcalc ArgNum ${ArgNum}-1 

  /if (${ArgNum}==2) { 
    /echo ** No corpse names supplied! 
    /return 
  } else { 
    /echo ** Target self (F1) to stop dragging! 
  } 
  :DragLoop 
  /for bodycount 3 to ${ArgNum} 
    /if (${Target.CleanName.Equal[${Me.Name}]}) { 
      /echo ** Body dragging ceased. 
      /goto :CeaseDragging 
    } 
    /target ${Line.Arg[${bodycount}]}'s 
    /corpse 
    |- Lower this delay at your own risk; too many /corpse commands too fast = cheater! 
    /delay 4 
  /next bodycount 
  /goto :DragLoop 
  :CeaseDragging 
/return 
The additional code is in yellow. That'll do it for you.
--Jerle

TrippyTom
a lesser mummy
a lesser mummy
Posts: 75
Joined: Sun May 30, 2004 10:18 am

Post by TrippyTom » Tue Jun 08, 2004 12:04 pm

thanks!

I'll do that. I never drag bodies without being in hide/sneak mode. It's just a habit I've developed over the years.
May the eclipse of your soul never fade to light!

Jerle69
a hill giant
a hill giant
Posts: 263
Joined: Wed Apr 28, 2004 3:26 pm

Post by Jerle69 » Wed Jun 09, 2004 12:07 am

Version 5.2 has been posted... Here's the summary:

Code: Select all

[color=cyan]
| VERSION 5.2:
|
| This version introduced a new command as well as some enhancements for the new weapon-
| switch command.  Also some a couple of bug removals and tweaks were done.
|
|     . /targetswitch command added.  This command toggles your settings for automatic 
|       switching of targets to follow the main assist's target while in autoassist mode.
|       Prior to this setting, if you were using autoassist and the current assist tank
|       switched targets, you would switch to their new target as well, and engage it
|       if it's health was below your set assist health threshold.  If targetswitch is 
|       FALSE, you will fight the first target the main assist chose until it is dead
|       or you are.  When this first target is dead, you will then resume assisting the
|       main assist again on subsequent targets.  Default is TRUE (meaning, switch to
|       the main assist's target, always, even if the other one isn't dead yet).  Use
|       this switch command if you have rapid pulls and you're expected to "finish off"
|       the old target while the main assist pulls a new one (or engages a new one in a
|       raid).
|
|     . Created a subroutine to handle generic weapon swapping.  This sub is used by
|       weaponswitch code to swap out a specified weapon with a specified slot.
|
|     . Fixed a bug that prevented weaponswitching state to save to the INI file when
|       turning weaponswitching off.
|
|     . Weaponswitching has been vastly enhanced.  It is no longer primary-hand dependent
|       (bag to primary, bag to secondary, primary to secondary, secondary to primary
|       will all work).  Also, RH will interrogate the first weapon and determine if its
|       spell effect is a proc-buff to the wielder or if it's a detrimental debuff to a
|       combat target.  If it's a debuff, it'll swap out weapons at the end of a fight.
|       If it's a buff, it'll monitor your buffs and swap it back in if the buff drops.
|       Command syntax for /weaponswitch has not changed.  An example use of a buff-type
|       proc weapon is below.  For this example, it would be assumed you wanted to wield
|       your Primal weapon until it procs avatar, and then have it swap out for Ifir. If
|       the Avatar buff dropped at any time, the Primal weapon would be re-equiped,
|       swapping out Ifir (starting the process over again).
|         . Example:  
|           /weaponswitch "Primal Velium Spear" "Your body screams" "Ifir, Dagger of Fire"
|        
|     . Enhanced enrage detection by looking for your specific target becoming enraged
|       instead of looking for anything enraging.  This eliminates the "false positives"
|       of enraging pets or other NPCs that you're not actively fighting. 
|
[/color]
--Jerle

Programmer
a hill giant
a hill giant
Posts: 195
Joined: Mon Dec 01, 2003 2:41 am

Post by Programmer » Wed Jun 09, 2004 12:07 pm

Looks like some cool changes. I've one suggestion (fortunately it doesn't affect me, I haven't needed a proc'd avatar for quite a while) - instead of having the weaponswitch to re-proc avatar happen after the buf fades, perhaps give a means of specifying how soon in advance of it popping to re-equip primal. I used to swap in my primal whenever I had less than a minute left (it's a 6 minute buff) hoping to reduce chance of avatar not being there.

TrippyTom
a lesser mummy
a lesser mummy
Posts: 75
Joined: Sun May 30, 2004 10:18 am

Post by TrippyTom » Wed Jun 09, 2004 12:51 pm

If you have AA's for buffs, does it extend the length of time proc buffs last? You might want to consider this before setting a set time to re-proc.

Btw, I LOVE THIS MACRO. I don't have to switch to my rogue screen anymore.
May the eclipse of your soul never fade to light!

Jerle69
a hill giant
a hill giant
Posts: 263
Joined: Wed Apr 28, 2004 3:26 pm

Post by Jerle69 » Wed Jun 09, 2004 3:25 pm

Programmer:

Not sure I want to anticipate a buff downing and swap out weapons before it happens. It's certainly doable, but the tradeoff here is your putting in an arguably inferior weapon to get a buff that you feel is worth sacrificing optimum damage for (if that were not true, there's no need for weaponswitching at all). That being said, I'm not sure some people would want to "prematurely" swap out early to keep the buff up--it's a nice-to-have for most probably, and not a "don't-let-it-drop-or-I'll-die" sort of thing. However! Since I'm easily persuaded to enhance things, I'll go ahead and stick an optional modification to the code here, and if someone wants it to behave as you describe, then can change RH themselves:

Find the following code and make affect the changes that are in yellow:

Code: Select all

   |- Check on switching weapons (assuming it's a buff-weapon and buff is down) 

   /if (${doSwitch} && ${wstype.Equal[Beneficial]}) { 
     /varset itemspellname ${FindItem[${weapon1}].Spell} 
     /if [color=yellow]((${itemspellname.NotEqual[${Me.Buff[${itemspellname}]}]} || (${itemspellname.Equal[${Me.Buff[${itemspellname}]}]} &&  ${Me.Buff[${itemspellname}].Duration.TotalSeconds}<60)) && !${FindItem[${weapon1}].InvSlot.Name.Equal[mainhand]} && !${FindItem[${weapon1}].InvSlot.Name.Equal[offhand]}) [/color]{ 
       /echo ** Beneficial proc-weapon swapping... 
       /call Weapon_Swap "${weapon1}" "${weapon2}" 
     } 
   } 
With this, it will swap in the proc-weapon 60 seconds prior to the buff fading OR if you don't already have it up (and you're not already using the proc-weapon).

TrippyTom:

The change I posted above examines the raw buff timer remaining on the specifically proced buff, and will work for any proc'ed buff, AA extented or not (it has no impact on the logic at all).

Enjoy!
--Jerle

Programmer
a hill giant
a hill giant
Posts: 195
Joined: Mon Dec 01, 2003 2:41 am

Post by Programmer » Wed Jun 09, 2004 9:40 pm

One addition I've made to my own rh.mac:
|- Are we fighting?
/if (${Me.Combat} && !${Target.ID}) /attack off

/if (${Me.Combat}) {
|- ** We are fighting **
This turns off autoattack if I lose my target.

Jerle69
a hill giant
a hill giant
Posts: 263
Joined: Wed Apr 28, 2004 3:26 pm

Post by Jerle69 » Wed Jun 09, 2004 10:59 pm

Programmer:

Probably not a bad idea. I have to think if this will adversely affect anything else though; probably not, I'm just a little spooky about turning attack on and off without seriously thinking about it :)
--Jerle

Programmer
a hill giant
a hill giant
Posts: 195
Joined: Mon Dec 01, 2003 2:41 am

Post by Programmer » Thu Jun 10, 2004 8:20 am

I've actually been using that addition as long as I've been using your fine macro. When I'm on a raid and realize I'm attacking something I shouldn't (Programmer has awakened an angry mob. Programmer has awakened an angry mob. Programmer has evaded the enchanters.) my knee-jerk reaction is to clearm my target with the escape key. Of course that will cause a flow of spam if attack stays on, and I'm too lazy to manually turn it off ;)

Jerle69
a hill giant
a hill giant
Posts: 263
Joined: Wed Apr 28, 2004 3:26 pm

Post by Jerle69 » Thu Jun 10, 2004 8:29 am

Programmer:

Really? Hitting escape while fighting causes RH to spam? If so, I must never have actually done this--I'll try that tonight and see what happens. You said you may have attacked something you shouldn't on a raid. Is that due to not targeting the right thing and manually assisting, or did you discover RH doing something strange while autoassisting?

Thanks,
--Jerle

User avatar
grimjack
Macro Author
Macro Author
Posts: 525
Joined: Thu Nov 07, 2002 6:51 am
Contact:

Post by grimjack » Thu Jun 10, 2004 10:10 am

Jerle69 wrote:Programmer:

Really? Hitting escape while fighting causes RH to spam? If so, I must never have actually done this--I'll try that tonight and see what happens. You said you may have attacked something you shouldn't on a raid. Is that due to not targeting the right thing and manually assisting, or did you discover RH doing something strange while autoassisting?

Thanks,
If I remember correctly it spams that you have no target and have attack on. You can filter it but I used the no target as an attack off option in most of my rogue macros for this reason. That and it made sence to not attack when you don't have a target :P.
When they come to me, they're in trouble, or they want some. I bust people out of prison, hunt down vampires, fight alien gods -- All the fun jobs people are too squeamish or too polite to do themselves.

Call me a mercenary. Call me an assassin. Call me a villain. I am all that and more.

My name's John Gaunt, but out on the streets of Cynosure, I am called...
GrimJack

tranze204
a lesser mummy
a lesser mummy
Posts: 39
Joined: Tue Mar 02, 2004 6:26 pm

Suggestion

Post by tranze204 » Sat Jun 12, 2004 3:18 am

Hey i have another suggestion...not to sure if ya can do it or not but here it goes...a /anchor command so that it saves u current loc or something and will return to that spot...the /leash command is good but pisses people off alot, they think u are some kind of perv that needs to like breathe on them...just an idea :roll: