Page 8 of 61
Posted: Mon Jun 07, 2004 12:16 pm
by Vexix
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
Posted: Mon Jun 07, 2004 2:07 pm
by Jerle69
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 :)
re: /drag
Posted: Tue Jun 08, 2004 12:02 am
by TrippyTom
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?
Posted: Tue Jun 08, 2004 11:51 am
by Jerle69
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.
Posted: Tue Jun 08, 2004 12:04 pm
by TrippyTom
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.
Posted: Wed Jun 09, 2004 12:07 am
by Jerle69
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]
Posted: Wed Jun 09, 2004 12:07 pm
by Programmer
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.
Posted: Wed Jun 09, 2004 12:51 pm
by TrippyTom
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.
Posted: Wed Jun 09, 2004 3:25 pm
by Jerle69
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!
Posted: Wed Jun 09, 2004 9:40 pm
by Programmer
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.
Posted: Wed Jun 09, 2004 10:59 pm
by Jerle69
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 :)
Posted: Thu Jun 10, 2004 8:20 am
by Programmer
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

Posted: Thu Jun 10, 2004 8:29 am
by Jerle69
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,
Posted: Thu Jun 10, 2004 10:10 am
by grimjack
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.
Suggestion
Posted: Sat Jun 12, 2004 3:18 am
by tranze204
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
