MacroQuest64

If you want a hacked up copy of the MQ2Utilities.cpp file you can download it through my sharemation URL ==>here <==.

Just copy this file over top of the MQ2Utilities.cpp file in the MQ2Main directory of your compilable source and recompile. It should get you working until the new Calculate code is completely debugged.

me want 5.3 =)

I'll put it up tonight :)

Hi - this is a nice macro, great work 8)

I have a couple of issues using it though, so I offer some suggestions for future enhancements !

1) I see you have addressed the problems with using NE5 to hide while moving in the next version, did not see mention of change to hide check condition though - I found that

/if (${doHideSneak} && ${Me.AbilityReady["Hide"]} && !${Me.Casting.ID} && ${Me.Sneaking} && ${Me.State.NotEqual[BIND]} && !${Window[TradeWnd].Open} && !${Window[MerchantWnd].Open} && !${Window[BigBankWnd].Open}) /doability "Hide"

worked well for me to solve the problem of hide triggering too fast and being broken because sneak had not registered yet ( this left you stuck waiting for the entire cycle time of hide before you can actually hide ).

2) If you are leashed to a stake, it will return to the stake before it checks for assists, which looks extremely odd as you ignore the obvious mobs right next to you, wander over to camp, then turn round and wander back again to assist. Further to this problem, if a mob enrages while you are staked you will return to the stake despite it not being dead yet. My recommendation would be to check that the mob is not dead and that there are no available assist targets before returning to stake.

3) The facestabbing timeout code is actually pretty counterproductive in my experience, as it does not distinguish between taking aggro and just getting missed by a riposte. This ends up with you assisting, getting caught by ripsote when the mob moves slightly and then spending the fight standing in front of it like an idiot. I just disabled the code entirely, I would prefer to circle something that I have aggro on rather than try to tank it under any circumstances, obviously that's personal preference but just thought I would let you know.

I used facestabbing all day today in velks getting a sword of pain for my n00b sk. It enabled me to continue to use rh and not swap to a crappy generic tank macro. I have seized opportunity so some of my backstabs land anyway. I like the fact that it doesnt go into an endless getbehind loop.

Great macro! Working fine again with the newest version of MQ2.

Been using some of the base features just to help out when I'm playing my rogue, but I've recently tried using the remote control and autoassist features to replace the rogue macro I used to use when playing my rogue on auto-pilot dual boxing. I've run into one thing I'm having problems with. I can't seem to get /autofollow to stop remotely or half the time even by just targetting myself on the rogue's pc without the macro hanging and not responding to further commands. Perhaps I'm just missing something? It'd be great to have an /autofollowoff command that I could send via /tell from a defined master.

Also in the latest version, it seems to me that when in autoassist mode the rogue no longer waits till he's behind the mob to execute the stike disc and begin attacks... rather if he's in front of the mob he'll start attacking from the front and then circle strafe behind. Again, it COULD just be me, but is there any reason this might be happening?

Thanks...

EG

"| . Added a special "aggro timer" that will detect if you're getting hit and
| reset a timer to 5 seconds. For those 5 seconds, RH will assume the
| rogue is tanking (or has the potential to tank again) and will prevent it
| from circle strafing toward the target's rear as well as chaotic stab.
| This method of rogue-self-tanking detection has augmented the use of
| TargetOfTarget since not everyone has the AA skill. Keep in mind if you
| have filtered out combat messages involving the rogue (hits you), then
| this feature won't work."

I don't think that this is working as intended. I was testing out this macro while two boxing and noticed that when the rogue got aggro he continued to try and get behind the target instead of tanking for the 5 seconds. I did double check to make sure that the combat messages were on, so this was not the source of the problem.

i have noticed this also.. is there maybe a setting we need to turn on or off..

Hello guys:

Trying to release 5.3 tonight. I may add a few of the suggested changes blow before I do, and test it.

Flebbit:

1) Thanks for the nice words! Yes, you'll see code to handle Nimble Evasion in the next version. I thought I'd get it out last night, but I got overwhelmed with father's day stuff.

2) Stake leashing is a little funky due to the way it's implemented. If you're returning to the stake, you do these for 1 second windows (unless you actually return to the stake). Because of this, sometimes you'll need at least one second to reaquire a new target, even if it's already available to fight. I can add some "short circuit" routines in here to check for a new target, or perhaps to not leash back to the stake if there's an NPC within, say 50 feet. I'll see what I can do to make this better.

3) It's a tradeoff. I often find myself tanking (even intentionally), when not grouped with a tank class. At those times, I need this code in there, or you cannot effectively tank (you'll strafe around forever). If you have target of target AA, you can just modify the two events controlling being hit or being missed and just change the /varsets to false in both, and voila, it won't affect you (very fast fix).

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!

Ghedrain & omper:

A friend of mine at work who also uses rogue helper told me about this behavior and after some Q&A with him we figured out why his didn't work:

Check your filters. Go into your ALT-O (options) and investigate your combat filters. Make sure you have attacker hitting you and missing you ON (such that you can see the messages). If these are on, and you still have problems with the aggro timer not functioning, you could have server side filtering enabled. After killing his server-side filters (/serverfilter) and making sure he had misses and hits visible via Alt-O, it worked for him.

I made a few changes to enrage the other day, but I havn't gotten to fully test them out... As we are rogues, we are attacking from behind most of the time. The changes I made to logic made it so that enrage will only stop attacking if you are tanking (HoTT or aggrotimer) or if ragevar is true and you get hit. As I said, this is untested, as every time I have seen rage go off, I havn't had a chance to let myself get hit or have aggro. It does attack when the mob is enraged and I am behind though :)

Anyway, here are the changes I made...

In Event_Enrage, instead of just the /attack off line

and in GotHit and GotMissed events, I added this line at the bottom of the event For the third time, these are UNTESTED. If they crash/kill the macro or just plain don't work, please tell me before jerle considers adding them to the base macro.

edit: removed extra ')' in first line of code... sorry, caused macro to end.

Ah hah! just tested it - mob enraged, i continued attacking... i got aggro, mob spun to me, i got hit, i stopped attacking. i like it :)

oorglebot6000:

Your code is syntactically correct, but logically flawed bud. Enrage really doesn't have anything to do with aggro, just orientation. If a mob is enraged and you're facing it, you're in trouble. I didn't write RH to monitor your target's orientation while it's enraged, but that could be done to fine tune enrage fighting perfectly. I'll consider that 5.4 since with the check_behind subroutine, that's very doable now.

Everyone:

Version 5.3 of RH has been posted.

A check if the mob is looking at a certain angle towards you while enraged would be a more safe method to evade the enrage, since the mob can whack you down with enrage if you dont turn attack off even if he doesnt have you in target at that time but the an_overuking_wizard07.
The code is nice tho to check in general if you have aggro or not. Nice idea!

It may be true that enrage and aggro aren't connected, but if a rogue is using autostick and has no aggro then he should be behind the mob to continue attacking. It may not be the absolute best way to get a rogue to attack a mob on enrage with avoiding the ripostes, but it works for all of the situations that I can think of. If you don't have aggro and get hit by ripostes due to being in front or someone spinning the mob, you will turn off attack due to the gothit and gotmissed events. However, if you do have aggro, it won't wait to turn off attack, but rather it will immediately turn off attack on enrage.

Whatever the case, I agree that a check_behind subroutine would be nice, but I still suggest turning off attack whenever enrage is on and you get hit or missed - the mob may have flakey aggro and spin around with you spamming /attack on and /attack off while you eat more and more ripostes :)

That's a fair statement. 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.

I'll put in some spiffy enrage checkers that analyze your vector and the target's and (if the target is enraged) will conditionally deactivate or reactivate attack.