Goto page 1, 2  Next Public Macros Your Mission if you choose to accept-Mez, radius adds remezz
Reply
Your Mission if you choose to accept-Mez, radius adds remezz
Ok .. this is one I have been looking at for a while. ATM I have it where me or my wife targets an add and say in group chat to "mez it" and chanter mezzs it. Works pritty good.. so far. Mezzing is a hefty thing though. One of the main things that if you can get right then you got a pitty good group going in some difficult places.

I'm researching the code and snippits for it ATM.. not alot out there.. I hate pre-written bot macs that have a ton of settings to mess with. Plus I'm enjoying not only playing EQ again but writting these macros.. they are kinda fun.

I will be posting snippits and bits and pieces of code and forming a nice and pritty easy to follow code structure as I start putting the pieces together I will be posting what I have for editing and learning untill we have a working mez code.

I have seen alot of macros for it so far but all of them either have something wrong with them, are VERY complex to where I can't even make heads or tales out of them or they just aren't all there if ya kow what I mean.

This is the basic structure I would like to see.

:searching for NPC loop that can be easily incorperaited into a macro

/if statement that looks for the NPC .. IDs each indavidual NPC

/calls on maybe a sub that will handle keeping track of the mez

something that detects some kind of mez break

Oh something that would make sure enchanter doesn't keep trying to mez the tanks target

and most important... re-mezzs target as needed.

Doesn't "sound" to hard.. just havn't seen alot of code to point me in the write dirrection.. I see the information a code for most of this on MQ2 Wiki just don't know how to write it correctly or havn't seen much of an example of how to use it yet.
Anyway, this is my next chalange =)
Mon May 28, 2012 8:02 pm
Animations for a way to detect
ok was looking through MQ2 wiki last night after I posted looking for different ways you might do this.
I came across something interesting and had maybe my first thought on this.

ANIMATIONS!

Ok so... you have some way the chanter (in the "Sub Main") loops 3 things (along with what ever else you might have under the Sub Main).

1. scans withing a radius
2. detects NPC Spwan with certain animations (aggresive animation IDs)
3. identifies weather or not the NPC is the tanks target

After that it call on a mez cast and with the main loop it continues to watch for those agressive animations (if mez breaks it would detect the animations again and remez).

Sounds easy enough .. hmmmm
Tue May 29, 2012 3:27 am
OH!
almost forgot...

Besides like the animations that are obvious like hit,run and such, there are "casting" animations that are identified as:
castin1, casting2,casting3..etc..
I figure this is for the casting of certain types of spells...
Is there a way I might be able to set up a /echo looping macro to test and have it tell me (I guess when I use certain spells) what kind of spell I'm casting so I might be able to find out what kind of casting animation goes with what...
Unless someone can identify these ( I wish MQ2 Wiki had discriptions of these )
Also just noticed looking there are some Melee IDs like this to... hmmm...
Tue May 29, 2012 3:33 am
I'd be very interested in this once you get it written. I'm having a lot of trouble keeping track of mezzes with my bard, and my coding skills so far are pretty much hopeless. Good luck!
Tue May 29, 2012 9:19 am
Oh something that would make sure enchanter doesn't keep trying to mez the tanks target


I use ${Melee.Target} to track the ID of the mob the tank is currently killing. Ignore that spawn ID as you cycle through the mez routines.

Besides like the animations that are obvious like hit,run and such, there are "casting" animations that are identified as:
castin1, casting2,casting3..etc..
I figure this is for the casting of certain types of spells...
Is there a way I might be able to set up a /echo looping macro to test and have it tell me (I guess when I use certain spells) what kind of spell I'm casting so I might be able to find out what kind of casting animation goes with what...
Unless someone can identify these

As you cycle through checking mobs, you can /echo their animation and place the animation ID in a string to see what animations mobs use. However, start simple. Mez a mob and record it's animation. If the mob has an animation other than the mez animation, it probably isn't mezzed.

You will need to find all the mez animations first. There are several. Some mobs have one mez animation and some mobs have another mez animation. It might vary by expansion and graphics engine (ogre luclin model might have a different animation than ogre pre-luclin model). Animations might also vary by client.


( I wish MQ2 Wiki had discriptions of these )

MQ2 Wiki is very incomplete when it comes to animations. Even the animation wiki entry is missing several animations used: melee/Pierce/BS (2), GotHit (13), and a couple more sitting (38, 73) animations are missing.
Tue May 29, 2012 2:26 pm
Senior Project Member
And some of us have stripped animations out of our eq installs...
Do not ask me how I managed to do that but for a very large number of NPC models I do not see any animations.
/sigh
/wrist
Tue May 29, 2012 6:31 pm
Listen to This Guy
Detecting different animations
Animation is just 1 thing I thought of to make this as simple as possible without righting a book of code. Keep it simple. Unless I can think of another "simple" way to stick with this for the moment. I may explore other possibilities (even things I may be able to add to this code to make it better).

While we are on the subject... a little test I came up with and work great so far for helping me to detect and list what animations mobs are using in the game while I'm interacting with it. Something fun to play with and at the same to make you go "oh really?!"...

I have a macro I use just for testing called "testing.mac" so there are usualy bits and peices in it that I don't use but I will try to just include the code I'm using.

More +

Sub Main

:detect
/echo ${Target.Animation.}
/delay 2s
/goto :detect
return


pritty simple eh?

Anyway this is what I have found out so far.

Most basic mobs do the following when mezzed.

Animation ID / Animation
_________________________
32............stand2
26............stand_animated2
72............stand_animated1
71............stand1

This is all I have seen so far from humanoid (of several types so far) and different types. Will continue and check out like undead.. suits of armor and things like that see if I get anything different.

Ok this is what I have gotten from mobs when mezz breaks. Same mobs I have tested so far up top with mezzes.

Animation ID / Animation
________________________
44............casting3
5.............melee
8.............Not Listed-Dwarf slave in CB hitting,only one like this so far
1.............kick
18............running-of corse when it runs toward you

Old world animations for most mobs? will try in different place like Luclin, Kunark and where ever my 45ish chanter can check. So far the animations have been pritty consistant on a humanoid and animals alike.. even wisps.

Also for those who have stripped your animations... use the code above to test it and see if the animations are still echoed by the server and you just don't see them or if they are really not there at all. I'm curious about that one.. sounds messed up.
Also in the code need to make sure to include [pet] detection so chanter doesn't try mezzing pets.. not sure if making sure it is just an NPC will cover that or a pet is conisered an NPC. I "think" that part will be simple enough.
anyway I will keep updated as I learn more in my research.
Tue May 29, 2012 7:18 pm
the tag is [ syntax ] not [ code ] for proper syntax highlighting.

One would think you may miss an animetin in a 2s delay. Try this.
Macro
More +
|Animation.mac

Sub Main
  /declare LastAnimation int local 0
:DetectLoop
  | check if the NPC is using the same animation as before
  /if ( ${LastAnimation} != ${Target.Animation} ) {
    | save the current animation
    /varset LastAnimation ${Target.Animation}
    | feedback to know what the new animation is
    /echo ${Target.CleanName} using animation: ${LastAnimation}.
  }
  | 1 decisecond delay to avoid slamming the client too needlessly
  /delay 1
  | loop and check again
  /goto :DetectLoop
/return

_________________
Sorvani
Tue May 29, 2012 8:18 pm
Senior Project Member
Ok "so far" ...
The ONLY other animation I have seen and finaly identified tonight is animation ID 12.
It is such a brief one that it took a couple of mobs to relize what it was since it is another animation not listed. And yes, I didn't catch everytime because it isn't one that is repeated alot during a mob fighting with you especially if your letting the mob hit you to see what all it is doing. If your a melee (using my enchanter) and your hitting the mob you might see it more often.
Guess what it is yet!
Yes it is the "reaction" animation when a mob gets hit. so not worried about animation.id 12 =P
but have been to Luclin... SoV expantion and couple of kunark zones... I see same animation from every mob so far.. Guess that is to be expected though considering most mobs do the same thing unless they are something special. which havn't come accross any yet that are different.
Haven't looks at wurms or dragons yet.. Don't think though I will prob be mezzing a dragon.. will keep playing with this a while longer. But i'm confident I just about have what I need to start working on a decent code for this.
oh and ya I like that little bit of code now I looked at it... I will play around with it some tomorrow and see what I get and let everyone know here what the results where.
Tue May 29, 2012 8:30 pm
OH.. also was thinking. The basic animations for standing there doing nothing for that mob is consistant with what they do mezzed so far. So mostly all I have to do is watch mobs stand around and see if there are any other animation to include in them just standing there without doing anything to them. Theory so far....

I was also thinking maybe including the animations for what I have found in the "broken mezz" and the "mezzed" to decrease the chance of mezzing something that isn't or wouldn't be a target. Hmmm... But if we are only looking at a defined radius around the group and it isn't started (macro) till you have gotten where you want to be or working up to that point, then I don't think that would matter anyway because if your someplace fighting mobs and they get close enough to aggro.. you probably aren't any place where you need to worry about mezzing a friendly that comes into range. I can't think of anyplace like that.
Anyway, just thinking through all the situations.
Tue May 29, 2012 8:42 pm
Hey that is a good point I didnt think to try.
Just because I cant see it doesnt mean the server isnt pushing the information to my client.
Keep up the ideas, I like having something to read when I check the boards and these posts have been good.
Fri Jun 01, 2012 6:12 pm
Listen to This Guy
Isn't there supposed to be a message on mezz break seen by the entire group?

------

If a mob is aggro and not mezzed, it will either be moving, casting, or facing the aggro target. It's possible to use the spawn Heading, HeadingTo and HeadingToLoc data to figure out of a mob is facing one of your toons.

When an unmezed mob is beating on a target, it will be a predictable distance from it's target. I think the distance is based on some calculation involving the height of both mobs.

The aggro mob will also have a target. Targeting the mob to see it's target might be too slow for detecting aggro (have to wait for server to update after you target a mob), but it is a good thing to check right before casting mez (just in case it has no target and isn't aggro). Mezzed mobs still have a target, but at least you can detect if it's aggro.

You probably shouldn't be looking for mobs to mez unless you are fighting an unmezzed mob. Wait for the first mob to come in range and be fought, then look for mez targets.

Also, at some point, you might want some checks to avoid mezz immune mobs. First check are mobs not capable of being mezzed with the spell you are casting (level based, by spell). The second check is for mobs that are flagged mezz immune. That's usually handled by placing the name of a mezz immune mob, once encountered, in an ini separated by zone name.
Sat Jun 02, 2012 11:43 am
Senior Project Member
Work in Progress
Ok,
Sorry been a few days... I have been busy.
Lets see.
I like the idea of mob facing and possition/location. That is something I might play with and add to it later. The only thing I see that might be a problem is (and I might be wrong) alot more veribles on that then what I want to mess with at the moment. There are aspects of writting macros that I haven't messed with yet. My biggest thing is when I go to write a macro if there are elements I haven't messed with before then alot of times I have to try to find examples of how to use these elements in order to figure out how to use them and that is the hard part most of the time. But always the challange I sometimes either enjoy or get frustrated about because I can't figure it out.(hehehe)
Anyway I have started playing with some code. I "have not" tested it out yet. It's time for me to get to bed and I won't have a chance to play with it till Friday more then likely. It's my brain storming in progress. Plus, the list thing, I think that is a very good idea.. That is about the only way I can think of keeping her from continuosly trying to cast on a mob that is immune to mezz. Or a temporary way to keep track of the mob untill it is dead. (Think keeping temporary track of the mob might be better if possible because even though the one mob of the same type may be immune isn't it possible that another of the same type might not be. I want to say, again maybe wrong, I have seen that before)
Anyway, case in point.. I have tried for now just to keep it simple.
Here is my brainstormed/untested snippet I have so far:
Macro
More +

#turbo

Sub Main
/declare MobRadius int local 50
/declare Mobs int loacl 0
/varset Mobs ${SpawnCount[npc targetable los radius ${MobRadius} zradius 30]}

/if (${Mobs}>=2) {
/for i 1 to ${Mobs}
| ${Target[noalert 1]} OR ${Target[noalert 1].ID} OR ${Spawn[noalert 1]}???
/target ${Target[noalert 1]} npc radius ${MobRadius} zradius 30
/if (!${Target.Animation[32|26|72|71|17|18]} && ${Target.PctHPs}>=90 && !${Melee.Target}) /call MezzingTarget ${Target.ClearName}
}
/next i

/return


Sub MezzingTarget
:mezzing
/call cast "${MezzSpell}"
/if (${Macro.Return.Equal[CAST_SUCCESS]}) {
/g [ %t ] is Mezzed!
/return
}
/if (${Macro.Return.Equal[CAST_IMMUNE]}) {
/g [ %t ] is IMMUNE to Mezz!
/squelch /alert add 1 id ${Target.ID}
/return
}
/if (${Macro.Return.Equal[CAST_RESISTED]}) {
/g [ %t ] Resisted Mezz! Trying again!
/goto :mezzing
}
/return

Again it's ruff and need fixing and tweeking.. but that is the start of what I have so far....

Edited...
Changed up/simplified the MezzingTarget Sub

Edited 6/6/12
hmm.. scrapped the "ini" thing untill I get more information about it (examples). I think I'm closer with the alert and noalert. Still not tested yet but it just feels closer to a way of working this then with the ini. It's easier to find examples of how to use the alert and noalert then it is about generaiting and checking the ini.
Last edited by chrismed on Wed Jun 06, 2012 8:34 pm; edited 9 times in total
Tue Jun 05, 2012 8:47 pm
INI hmmmm
ok this is the information on the generation of Ini that I have found.

Ini[filename,section,key,default]
example:
Macro
More +

/echo ${Ini[sample.ini,KeyOne,value1]}          


ini "filename" "keyname" "valuename" "value"
example:
Macro
More +

/ini "stuff.ini" "Section2" "ANewKey" "Some Data!"


I can pritty much figure out how to add something, like a mob to the ini list, but how would you make it check against the list for the mob?
Either way, an example would be nice.
And yes I think this would work well for the enchanter macro so it's not trying to mezz the same mob over and over. Unless the problem I listed in the previous post is true.
If that is a case would need a way that only that mob would be remembered while it is alive or only that mob is tagged in some way so that it is not continously tring to be mezzed.
Wed Jun 06, 2012 4:54 pm
INI and Alert
ok after a few hours of playing with "ini" I have been able to add mobs to a list in veriuos ways. From what I can tell you can't have just a name, you have to add like a section/key and then the data to be added.. it worked when I did it that way. It also works well with the ${Target}. I just haven't figured out how to advance the keys without typing each one or how to "check" ${Target} against the ini.
I also have been researching alternative ways to do this. I found "alert" command. It can add a mob(or what ever) to a temp list of sorts. I just haven't figured out how to use it yet.

Here is the example I have found:
Macro
More +

    /if (${MobCount}>=1) {
        /for i 1 to ${MobCount}
            /target npc radius ${CountRadius} zradius 30 noalert 1
            /if (${Target.PctHPs} < ${LowestHPs}) {
                 /varset LowestHPs ${Target.PctHPs}
                 /varset LowestHPsID ${Target.ID}
            }
            /squelch /alert add 1 id ${Target.ID}
        /next i

yes this is a snippet of a macro I found that I have been modeling my enchanter macro from. I didn't think about the alert untill I looked it up today to see what it actualy does.(Learned something new)
Wed Jun 06, 2012 7:57 pm
Goto page 1, 2  Next Public Macros Your Mission if you choose to accept-Mez, radius adds remezz
Reply