Ok you may have seen my hunting script posted in the Macro Depot. I have been trying to get it to deal effectively with random aggroing mobs. Currently it uses an event based on the 'YOU for' text that is picked up when you are hit. Unfortunately this doesn't work to well as sometimes I target the wrong mob.
I tried iterating through the nearest mobs and assisting them to see if i am the target but this is not really very satisfactory cause it screws up my casting if i am running it on a caster toon.
Soooo... Anybody any ideas on a better way of doing this??.
Fippy
Checking Aggro
Moderator: MacroQuest Developers
-
Snappahead
- orc pawn
- Posts: 19
- Joined: Sun Oct 27, 2002 4:41 am
Maybe you could back up a few paces then target the nearest mob. If you are not currently fighting anything, then something hits you and you backpedal a bit, the mob should stick on you and follow you.
Not sure how you would actually implement it though (as in coding it), but from looking at your hunting macro, I reckon you might be able to work it out.
Cheers,
Snappahead
Not sure how you would actually implement it though (as in coding it), but from looking at your hunting macro, I reckon you might be able to work it out.
Cheers,
Snappahead
Damn i didnt mention this in the first post so thanks for he posts so far and Gengis's suggestion works great if i want to deal with each mob one after another, however. What I am trying to do is add Nerfy's idea of a hate list so if a more powerfull mob than the one you are currently attcking hits you I will switch targets.
I guess an MQ variable called $attacker would be ideal but i dont know if the eq client has that information.
Maybe ill do some searching for memlocs and see.
I guess an MQ variable called $attacker would be ideal but i dont know if the eq client has that information.
Maybe ill do some searching for memlocs and see.
You're right Fip - hadn't realized what a problem this would be. Guys, he's not looking for the name of what hit him, he's looking for it's ID. Big difference. And yes, Perl is a wonderful way to to store your hate list - but you still have to figure out what to put into that hate list. Perl did not add any new commands to MQ with respect to interacting with EQ, it just allows some versitility with scripting language and (especially) variable handling.
Now we have three instances where we pick up an unwanted guest:
> While fighting, someone joins in the fray
> While resting, something picks a fight
> While going to a fight, something aggros on us
As a matter of fact, these three instances actually corralate to the three states that your toon is in during a hunting session. Rest, seek, and destroy. Ok, there may be a fourth that happens while you're looting - but I'd classify that as a Rest state. So, we now need to keep track of (and keep updated) a variable CurrentState. I'd say:
> -1 : Resting
> 0 : Seeking
> 1 : Fighting
Anyway, you need to moniter what action the toon is taking at the moment. Keep that event in there, as a matter of fact I'd also set up one for 'MISSES YOU' so that we don't wait until we take damage. If it's a greenie that's aggroed (say while you've been medding) then you may be sitting for a while until he clocks you.
Anyway, you now have these two events that your looking for. MissesYou and HitsYou. On either event, call Sub BeenAttacked. BeenAttacked then looks at our variable CurrentState. If you're currently Resting or Seeking, it's a no brainer. FIrst change current state to fighting, then fight the baddie. Or you can perform some escape procedure if the baddie is too high a level. Say he's a yellow con. Then you may want to FD, or stun/root/gate. Class dependant exit routines are another fun addition I'd like to put into Hunter.Mac - but one thing at a time.
So we have Resting attacks and Seeking attacks taken care of. What happens if we're in fight mode?
Well, while fighting we're going to be firing those HitsYou and MissesYou events a good bit. This is where our HateList comes into play. Of course, now that we've got bigger arrays to play with (yay!) I'd suggest storing more than just a 1d array of MOB id's. First off, set a standard for the way that you organize a monster list. Our type monsterList would be:
3d array where:
> 0 = id
> 1 = level
> 2 = aggro state (-1:Not|0:Unknown|1:Yes)
Now I would have a function that fills this array with all MOBs near to you. Say, within a 7 range. Default the 3rd position to -1 (not aggroed). Now put your current target into that array and set it's aggro state to 1. If you order this list first by AggroState, then by level - then you now have the order in which you should fight these things. Add in a check to only kill those things with an aggro state of 1, and you will not be wasting your time on killing everythying in a given radius of yourslef. This includes that Priest of Discord over there. This also changes our list from simply a hatelist to a NearbyNPCList, but I'll still call it a hate list just cause it's easier.
Now to handle the random aggro. Two kinds of random aggro can happen. One is that a MOB with a new name comes onto the scene, the other is that a MOB with a similar name shows up. Different name first:
So you have this list. It's correctly ordered and you are fighting 'a wolf'. There are 2 'fire beetles' nearby, but being green they aren't paying you any attention. Every time that wolf attempts to, or succeeds in biting you, your events fire. Theres a check in that event to see if he's already in your list. Since he is - you simply return with no action.
Then Fippy Darkpaw comes onto the scene and hits you for ruining his lands or some other nonesense. Event gets fired, we see that Fippy is not in the HateList, so we add him. He tried to smack us, so we set his AggroState to 1. Since the hatelist is ordered by AggroState, Level - the wolf is moved to second place. Fippy sits in first. We fight Fippy.
Ok, now the real problem. Back to our scenario of fighting a wolf, 2 beeltes in range but with AggroStates of -1. Then say another wolf joins in - only this one is a level higher. Being a level higher, he also cons blue and therefore could inflict a good deal of hurt while we're wasting time on the green wolf. Now - the events are still firing, but because we are fighting 'a wolf' and there are two 'a wolf's that are at our throats we would normally not know to switch to the new one. This gets complex.
Simple solution: set all mobs with similar names that are in that HateList (remember, we're monitering all things near) to an AggroState of 1. This means that you will kill all wolves near to you in order of their level.
Slightly more complex: Set up level ranges based on your con to a creature. So that you know if the creature cons green, blue, etc. Then if the new creature cons green and is nearby - you know that he DID NOT aggro on you. Green cons only aggro if you're sitting on your tail end medding and/or healing. So if that new wolf that has entered your aggro radius is green to you, don't add him to your list - you know he's not big enough to be challenging you.
Ok, forgive the stream of thought on this one - but I'm at work and I just wanted to get these ideas down. Let me know if I can clarify any of the above. Back to work for me.
Now we have three instances where we pick up an unwanted guest:
> While fighting, someone joins in the fray
> While resting, something picks a fight
> While going to a fight, something aggros on us
As a matter of fact, these three instances actually corralate to the three states that your toon is in during a hunting session. Rest, seek, and destroy. Ok, there may be a fourth that happens while you're looting - but I'd classify that as a Rest state. So, we now need to keep track of (and keep updated) a variable CurrentState. I'd say:
> -1 : Resting
> 0 : Seeking
> 1 : Fighting
Anyway, you need to moniter what action the toon is taking at the moment. Keep that event in there, as a matter of fact I'd also set up one for 'MISSES YOU' so that we don't wait until we take damage. If it's a greenie that's aggroed (say while you've been medding) then you may be sitting for a while until he clocks you.
Anyway, you now have these two events that your looking for. MissesYou and HitsYou. On either event, call Sub BeenAttacked. BeenAttacked then looks at our variable CurrentState. If you're currently Resting or Seeking, it's a no brainer. FIrst change current state to fighting, then fight the baddie. Or you can perform some escape procedure if the baddie is too high a level. Say he's a yellow con. Then you may want to FD, or stun/root/gate. Class dependant exit routines are another fun addition I'd like to put into Hunter.Mac - but one thing at a time.
So we have Resting attacks and Seeking attacks taken care of. What happens if we're in fight mode?
Well, while fighting we're going to be firing those HitsYou and MissesYou events a good bit. This is where our HateList comes into play. Of course, now that we've got bigger arrays to play with (yay!) I'd suggest storing more than just a 1d array of MOB id's. First off, set a standard for the way that you organize a monster list. Our type monsterList would be:
3d array where:
> 0 = id
> 1 = level
> 2 = aggro state (-1:Not|0:Unknown|1:Yes)
Now I would have a function that fills this array with all MOBs near to you. Say, within a 7 range. Default the 3rd position to -1 (not aggroed). Now put your current target into that array and set it's aggro state to 1. If you order this list first by AggroState, then by level - then you now have the order in which you should fight these things. Add in a check to only kill those things with an aggro state of 1, and you will not be wasting your time on killing everythying in a given radius of yourslef. This includes that Priest of Discord over there. This also changes our list from simply a hatelist to a NearbyNPCList, but I'll still call it a hate list just cause it's easier.
Now to handle the random aggro. Two kinds of random aggro can happen. One is that a MOB with a new name comes onto the scene, the other is that a MOB with a similar name shows up. Different name first:
So you have this list. It's correctly ordered and you are fighting 'a wolf'. There are 2 'fire beetles' nearby, but being green they aren't paying you any attention. Every time that wolf attempts to, or succeeds in biting you, your events fire. Theres a check in that event to see if he's already in your list. Since he is - you simply return with no action.
Then Fippy Darkpaw comes onto the scene and hits you for ruining his lands or some other nonesense. Event gets fired, we see that Fippy is not in the HateList, so we add him. He tried to smack us, so we set his AggroState to 1. Since the hatelist is ordered by AggroState, Level - the wolf is moved to second place. Fippy sits in first. We fight Fippy.
Ok, now the real problem. Back to our scenario of fighting a wolf, 2 beeltes in range but with AggroStates of -1. Then say another wolf joins in - only this one is a level higher. Being a level higher, he also cons blue and therefore could inflict a good deal of hurt while we're wasting time on the green wolf. Now - the events are still firing, but because we are fighting 'a wolf' and there are two 'a wolf's that are at our throats we would normally not know to switch to the new one. This gets complex.
Simple solution: set all mobs with similar names that are in that HateList (remember, we're monitering all things near) to an AggroState of 1. This means that you will kill all wolves near to you in order of their level.
Slightly more complex: Set up level ranges based on your con to a creature. So that you know if the creature cons green, blue, etc. Then if the new creature cons green and is nearby - you know that he DID NOT aggro on you. Green cons only aggro if you're sitting on your tail end medding and/or healing. So if that new wolf that has entered your aggro radius is green to you, don't add him to your list - you know he's not big enough to be challenging you.
Ok, forgive the stream of thought on this one - but I'm at work and I just wanted to get these ideas down. Let me know if I can clarify any of the above. Back to work for me.
----------
* Nerfy *
* Nerfy *
Great ideas! But how would I fill an array with nearby spawn ids? Best I can figure is to set an alert for creatures within the radius. But how to you get their ids?Nerfy wrote: Now I would have a function that fills this array with all MOBs near to you. Say, within a 7 range.
Zertful *too newbie for this*
- those who sling mud, lose ground -
im reading this in bed so i am NOT repeat NOT saying this in context, just an fyi
fippy, remember if you get hit with no target, your target becomes attacker mob.
fippy, remember if you get hit with no target, your target becomes attacker mob.
#macroquest op
Macroquest Official Documentarion
Macroquest Board Moderator
All around cool guy
[img]http://medicomuerte.users.btopenworld.com/images/fairy_bounce08.gif[/img]
Macroquest Official Documentarion
Macroquest Board Moderator
All around cool guy
[img]http://medicomuerte.users.btopenworld.com/images/fairy_bounce08.gif[/img]
When you are hit, a packet arrives that specifies damage, verb ("bashes", "slashes", "crushes" -- oh my!), and attacker.
Now if only you had a way to intercept the packets and do something clever with them, you wouldn't have to rely on text grepping (searching) at all. You'd know instantly which mob ID's have hit you. Actually, with a live packet stream, you'd know much, much more -- that's just the most obvious tip of the iceberg.
My client already is detouring and processing the packet stream and passing useful bits along to Perl. I gave Plaz my information about the location and calling convention of the PacketProcess function, so look for that functionality in a future MQ. Maybe.
Now if only you had a way to intercept the packets and do something clever with them, you wouldn't have to rely on text grepping (searching) at all. You'd know instantly which mob ID's have hit you. Actually, with a live packet stream, you'd know much, much more -- that's just the most obvious tip of the iceberg.
My client already is detouring and processing the packet stream and passing useful bits along to Perl. I gave Plaz my information about the location and calling convention of the PacketProcess function, so look for that functionality in a future MQ. Maybe.