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

oorglebot6000 · Post by **oorglebot6000** » Mon Jun 21, 2004 10:52 pm

The one case where you can get your ass beatdown by enrage, even without aggro, is if you're stuck on a wall. RH will report that you're stuck, but not try to strafe. If, during that time, you are facing the target, enrage will kill you. Another case is if you are behind the mob, you use the enrage event to see (at that time and only at that time) if you should shut off attack or not. If something bad happens (say the tank dies) and the mob spins and faces the rest of the raid, the enrage event has already fired; in this case, you'll whack away on the mob and also die.

Check my changes to event_gothit and event_gotmissed. The instant you take a riposte that hits or misses, it will turn off attack. Provided you don't get one-rounded, you will turn off attack and live.

Jerle69 · Post by **Jerle69** » Tue Jun 22, 2004 12:19 pm

Ahh, you are correct sir. I've ummm, fought some things recently that hit for 4k, and swing a couple times a second. I think I'll write some predictive positional stuff that should turn off attack based on orientation instead of event-response (from getting hit). Your mods certainly work, but I'll see if I can make it a wee-bit better :)

oorglebot6000 · Post by **oorglebot6000** » Tue Jun 22, 2004 12:46 pm

The problem that I see with something that changes attack status based on which way the mob is facing is that ping time can still cause you problems. If you are pinging 500ms (in a raid? what am I thinking), and the mob turns around, you still have a pretty good chance of your ping time causing you to turn off auto-attack on the server's side after one of your own rounds attack the enraged mob. It is my belief that a spinning enraged mob will eat you alive if you try to macro in a way to continue attacking through enrage no matter what you do. Maybe just make it so that the code of attacking through rage is disabled on mobs at level 70 and higher?

Programmer · Post by **Programmer** » Tue Jun 22, 2004 1:08 pm

I think attacking through enrage on high end mobs is perhaps more important than leaving attack on for the yard trash. Often its these encounters that demand every bit of dps your raid can squeeze.

A possible consideration though is to turn off autoattack and yet still attack via the macro, one stab at a time. The macro's processing loop can decide based on how many degrees towards facing you the mob is and, if its within the right arc, attack (via the attack button) without enabling auto attack.

Just a thought; I don't know how much overhead this would introduce. All I can say is that I've been tuned towards self-enabling auto-attack when it gets turned off by the macro, and at those times I just have to pay closer attention to the npc. I normally won't die when doing this, but of course enraged mobs have a tendancy to turn when you're secure that they wont.

mcdebug · Post by **mcdebug** » Tue Jun 22, 2004 3:50 pm

hey jerle ive been trying to modify this to where it would work well for a monk and so far have been pretty successfull considering my lack of macroing skills. I made it kick instead of bs and i made it fd when it arrived at its anchor, then stand up again when it needed to begin attacking or the anchor moved. But i wanted to add an option to either turn auto fd on or off and according to everything ive seen inside the macro it should work but for some reason it crashes after it gets past the event called from the -------======( status )=====------ thing, it gets down past the different statements like assists and all that but right after that it just freezes eq. was hopin you could take a look at it since after all, it basically is your work 8) thanks man

http://macroquest2.com/phpBB2/viewtopic.php?t=7937

mcdebug · Post by **mcdebug** » Tue Jun 22, 2004 3:51 pm

hey jerle ive been trying to modify this to where it would work well for a monk and so far have been pretty successfull considering my lack of macroing skills. I made it kick instead of bs and i made it fd when it arrived at its anchor, then stand up again when it needed to begin attacking or the anchor moved. But i wanted to add an option to either turn auto fd on or off and according to everything ive seen inside the macro it should work but for some reason it crashes after it gets past the event called from the -------======( status )=====------ thing, it gets down past the different statements like assists and all that but right after that it just freezes eq. was hopin you could take a look at it since after all, it basically is your work 8) thanks man

http://macroquest2.com/phpBB2/viewtopic.php?t=7937

escapegoat · Post by **escapegoat** » Wed Jun 23, 2004 1:08 pm

Jerle69 wrote: escapegoat:

Hrmm, you're right. When autofollow is active, only events queuing takes place. Since the remote control tell processor is an event, you cannot remotely stop autofollow. The only way to allow this to queue events is to process events from within the autofollow event. I guess I can try this--I'm not sure if event-handling from an event causes MQ2 to explode, but I guess we'll try and see if it does

As far as your attacking from the front thing, my friend and I had this problem once too. Make sure you have /assist off or it will screw up (it'll also autostick at 100% instead of your set percentage)! He and I both accidentally toggled (or tried to) /autoassist on, and this set the main tank's name to "on"... Well, the next time you get autoassist to fire, it'll execute /autoassist on (thereby turning your attack on assist back ON). This will, in turn, bust RH when you fix your main tank's name!

Thanks for the response! You're right, I had switched systems I was using it on and had forgotten to turn off attack on assist..

Now, if I could just remotely stop autofollow everything would be perfect.

Great job man!

EG

Jerle69 · Post by **Jerle69** » Wed Jun 23, 2004 6:13 pm

Folks:

I'll look into enrage tuning soon, and try to come up with a cosmic solution. Escapegoat, glad you're working. McDebug, I've repsonded to you in your Monk Helper thread, and posted the appropriate clue(s) to help you repair that macro :)

Jerle69 · Post by **Jerle69** » Thu Jun 24, 2004 2:50 pm

I'm pretty much done with 5.4 I'll test it tonight and get it posted later on if there are no bugs in it. The event system has changed a little (now there is a flag to track what event is going on) and there's some snappy enrage code to control combat activities REALLY smartly. Will post it soon...

A_Rogue00 · Post by **A_Rogue00** » Thu Jun 24, 2004 6:45 pm

Hey, can you throw in a way to stop attacking/autosticking when the mob gates? It looks weird when I'm in BoT and start running into the wall when a mob gates if I'm not paying attention.

Jerle69 · Post by **Jerle69** » Thu Jun 24, 2004 10:19 pm

New version of RH posted, here's the new stuff:

Code: Select all

[color=cyan]
| VERSION 5.4:
|
| This version involves more performance tuning and tweaks.
|
|     . Reduced assist timer from 2 seconds down to 1 second (this is much better in
|       raid situations with multiple pulls.  You're more responsive (and more like a
|       fast, good human player).
|
|     . Changed the way the /autoassist command reacts to "/autoassist on"  Before, you
|       could type "/autoassist off" to turn off autoassisting.  This led to the logical
|       conclusion you could use "/autoassist on" to turn it back on; this command, even
|       though it makes sense, would actually set the main assist to to a tank named "on"
|       and reactivate autoassist.  Worse, when you actually autoassisted, RH would
|       execute an "/assist on" command, turning ON attack-on-assist, which would then
|       break the functionality of autosticking, strike, and subsequent autoassisting.  
|       As such, I added the "/autoassist on" functionality to stop this side-effect.
|       If you are experiencing "broken sticking" or other strange autoassist behavior,
|       make certain you execute "/assist off" as noted at the very top of the RH macro
|       documentation!
|
|     . Completely revamped how RH reacts to enraged mobs.  Now, when a mob enrages, 
|       attacking is not automatically suspended.  If you are NOT behind a mob, RH will
|       cease attacking and report that it has done so due to Enrage Risk.  If you are
|       still targeting that mob during it's enrage period and at any time it turns, or 
|       you turn or otherwise move, if you end up behind the mob, and you're autoassist 
|       is on, you will resume fighting it.  If at any time it spins, or you turn, you 
|       will automatically toggle attack on or off, depending on your positional vector
|       relative to the target.  Keep in mind if you're not using autoassist, RH will
|       cease attacking if you're about to be riposted due to enrage (and only then),
|       but RH will not re-engage attacking if it becomes safe again (as it does when
|       autoassisting is activated).
|
|     . Added a global variable "lastevent" to contain the name of the last event that
|       fired.  This variable is used (for now) to allow interruption of autofollow by
|       other events.  If any event fires while autofollowing, successful or not, auto
|       follow terminates after the blocking event fires.  This allows for things such
|       as the use of remote control "/" commands while autofollow is on.  This also
|       makes autofollow very "fragile" as any RH event can now interrupt it (not just
|       you manually changing your target to something else).  Also note autofollow will
|       not block itself, so it's inadvisable to engage in autofollow while you are
|       already in it.  RH *should* recursively handle this situation, but it's sorta
|       dumb to push your luck here.  Autofollow *COULD* conditionally continue based on
|       the event that just fired, but I'm guessing that's not really necessary, and in
|       some cases it would be bad.

[/color]

Jerle69 · Post by **Jerle69** » Thu Jun 24, 2004 10:31 pm

A_Rogue00:

I gave your request/idea some thought and I'm in a pickle as to how to solve that problem. It's technically very easy to detect a gating target, the problem is how to change RH's behavior when your target actually gates. You see, if you turn off attack, your rogue will certainly stop autosticking the target (but you will RESUME if your main assist doesn't target something else in under a second, which is not likely to happen) so that doesn't help much. I could force it to have you untarget the mob (but this won't help much since you'll reassist the tank shortly and reacquire the same gated target likely). Neither of these solutions work, they only postpone you actually charging off like a dumbass into a wall.

The only thing that's really comprehensive (and it's a controversial patch, so I won't include it in the main file) is to have autostick NOT STICK to a mob that's more than X feet away from you (say 500 feet). In other words, if something runs too far away, force autostick to "give up" trying to stick to it. This could be due to a target gating, or if it's fleeing and has a much higher run speed than the rogue.

To activate this optional change, find the following autostick code:

Code: Select all

|- Are we suposed to stick to a target? (Don't if we're tanking!) 
   /if ((${Me.Combat} || ${strikeReady}) && ${Target.ID} && ${doStick} && ${Target.Type.Equal[NPC]} && !${aggrotimer.Value} && !${Me.TargetOfTarget.Name.Equal[${Me}]}) {

and replace it with this...

Code: Select all

|- Are we suposed to stick to a target? (Don't if we're tanking!) 
   /if ((${Me.Combat} || ${strikeReady}) && ${Target.ID} && ${doStick} && ${Target.Type.Equal[NPC]} && !${aggrotimer.Value} && !${Me.TargetOfTarget.Name.Equal[${Me}]} && (${Target.Distance}<500)) {

With this change, if a mob gates (and winds up more than 500 feet from your location) or runs too far away, autostick won't pursue it. Again, I won't put this in the baseline as it's not necessarily globally desirable, but it may be nice for some users. Feel free to change the 500 to a smaller number if you like--I just pulled that one out of the air... I imagine 200 to 500 is about right.

Flebbit · Post by **Flebbit** » Fri Jun 25, 2004 7:04 am

How about weight distance to mob vs distance to main assist before moving into attack range on the mob. (I.e. if mob is x further away than MT, wait before moving into range ) ?

This would have the benefit of also not doing insane things like charging incoming mobs that someone pulled with a lucky arrow crit if you have assist threshhold set high.

GreenPlastik · Post by **GreenPlastik** » Fri Jun 25, 2004 9:16 am

I'm sure someone has asked this somewhere, but have you considered using moveutils for your sticking needs?

Jerle69 · Post by **Jerle69** » Fri Jun 25, 2004 11:17 am

Flebbit:

That's a great idea. If I do add this functionality there will be a new /command to allow the user to control the "max distance from tank" sticking threshold as well as the "max distance from mob" sticking threshold. I will initialize these parameters to something like 100 for the tank and 400 for the target. The behavior will be such that you'll persue the target until you reach that threshold and then you simply won't move any farther after that.

GreenPlastik:

I've thought about using moveutils, but after looking at it, I find that writing my own streamlined set of movement code allows me to do something very important within this macro: optimize for speed. This is one of the fastest and most robust combat engines to date (so I've heard from large group of fans and users of other bots) and using a modular INC file of handy things full of features that we may or may not require could bog down the macro quite a bit. As an analogy, I'm sorta writing this with the mindset that an assembler coder would approach it, not a C++ software engineer :)

Thanks,

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

MQ2MoveUtils