Giving pet weapons
Moderator: MacroQuest Developers
Not that I disagree with any of the help that you've received in this thread--almost all the advice here has been pretty sound, but I'd like to point out something fundamental that most macro developers for MQ2 miss:
Writing a macro for MQ2 often involves getting a slight grip on multi-threaded code (or at least the BEHAVIOR of multithreaded code). This is VERY hard for a new programmer to get their mind wrapped around.
Your dilemma is a classic example. You have three basic tasks:
1) Make a pet and/or target an existing pet.
2) Make a bunch of summoned gear.
3) Give summoned gear to the pet.
Seems pretty easy! It's not actually. The problem involves MQ2 executing macro statements as fast as it can but Everquest (client and more importantly the server) not being ready for the issuance of the subsequent statements. The easy fix (but not always the best one) is to hard-wire some delays inbetween activities to ensure that the client (or server) is ready for follow-up commands. For some things (such as this quick-and-dirty macro) using delays probably makes the most sense.
What if you wanted your macro to be a little smarter though? How bout "Can I make it such that if I move my Mage around after I start the macro that it won't try to make the next summoned item until I stop moving?" What if you forget to memorize one of your summon-item spells? What about if you get attacked in the middle of this? Can we make it stop? Your pet will be busy and hard to target. Hell, your pet may die from the time you fire the macro up until the time it finishes!
I know I know... That's all rediculous (if not rediculous, pretty remote at least) and you didn't ask for a macro that complex or robust. All I wanted to say is that it would behoove most macro-writers to start thinking of "game states" and "client states" when writing their macros, and check the MANY conditions when continuing with a macro activity before moving on to the next subsequent section of their macro.
Personally, I'd do this:
A macro designed like this will be able to handle lag, and even pop-up situations that may get you in trouble. It's FAR from complete. There are so many things that can happen to make it fail it's mind-boggling. Your job is to catch the 99% solution and pray the other 1% doesn't happen!
Good luck,
--Jerle
Writing a macro for MQ2 often involves getting a slight grip on multi-threaded code (or at least the BEHAVIOR of multithreaded code). This is VERY hard for a new programmer to get their mind wrapped around.
Your dilemma is a classic example. You have three basic tasks:
1) Make a pet and/or target an existing pet.
2) Make a bunch of summoned gear.
3) Give summoned gear to the pet.
Seems pretty easy! It's not actually. The problem involves MQ2 executing macro statements as fast as it can but Everquest (client and more importantly the server) not being ready for the issuance of the subsequent statements. The easy fix (but not always the best one) is to hard-wire some delays inbetween activities to ensure that the client (or server) is ready for follow-up commands. For some things (such as this quick-and-dirty macro) using delays probably makes the most sense.
What if you wanted your macro to be a little smarter though? How bout "Can I make it such that if I move my Mage around after I start the macro that it won't try to make the next summoned item until I stop moving?" What if you forget to memorize one of your summon-item spells? What about if you get attacked in the middle of this? Can we make it stop? Your pet will be busy and hard to target. Hell, your pet may die from the time you fire the macro up until the time it finishes!
I know I know... That's all rediculous (if not rediculous, pretty remote at least) and you didn't ask for a macro that complex or robust. All I wanted to say is that it would behoove most macro-writers to start thinking of "game states" and "client states" when writing their macros, and check the MANY conditions when continuing with a macro activity before moving on to the next subsequent section of their macro.
Personally, I'd do this:
Code: Select all
Pseudocode/Logic:
1) Check for a pet.
a) If I have a pet, memspell summonpet (if not already), cast it.
b) If I don't have a pet, memspell makerathepet (if not already), cast it.
2) In a loop that checks for ${Me.SpellReady[${gem_slot_of_summoned_shit_spells}]} && !${Me.Moving}:
a) Make an item, and loop
3) Check if your pet is nearby, if not (maybe fail with a popup warning about him fighting) otherwise target it.
4) In a loop checking your cursor for an item, give stuff to your pet til cursor is empty.
Good luck,
--Jerle
--Jerle
Jerle, i post very few macros that are afk ready. For a very specific reason....
People running macros AFK draws attention to us....
I dont like attention.
True, i could have given him 98 lines of code, and a macro that would check, summon, protect, heal, covet, and jerk off the little pet. but instead, he has a macro that is useful for only the specific task he asked for, and with no checks to make sure bad shit is not happening.
True, he may add things to make it work for him while AFK, if he does, more power to him.....
Plus, I feel that people make their macros overly robust. Macroquest is to aid you, to enhance the experience of playing Everquest. Why would we play EQ if we wanted Macroquest to do it for us? Look at the macros I have posted... Sure, they all work.... Do any of them let you go afk and sleep, and wake up to 26 new AA? Fuck no. And no macro I ever post will.
No macro I post will let you go afk and come back to 30k plat, or go from 1 to 200 in a tradeskill.
......
I suppose you could run the beer macro... afk........
all that will get you is a new account though
People running macros AFK draws attention to us....
I dont like attention.
True, i could have given him 98 lines of code, and a macro that would check, summon, protect, heal, covet, and jerk off the little pet. but instead, he has a macro that is useful for only the specific task he asked for, and with no checks to make sure bad shit is not happening.
True, he may add things to make it work for him while AFK, if he does, more power to him.....
Plus, I feel that people make their macros overly robust. Macroquest is to aid you, to enhance the experience of playing Everquest. Why would we play EQ if we wanted Macroquest to do it for us? Look at the macros I have posted... Sure, they all work.... Do any of them let you go afk and sleep, and wake up to 26 new AA? Fuck no. And no macro I ever post will.
No macro I post will let you go afk and come back to 30k plat, or go from 1 to 200 in a tradeskill.
......
I suppose you could run the beer macro... afk........
all that will get you is a new account though
Smokey the Lax says only you can prevent reproduction.
I prefaced my reply with a "these macros are fine" comment, and I really meant that. I just wanted to point out to others who run by this post that it helps if they think of their macros in terms of concurrent threads running WHILE EQ is going on, and not an injector that handshakes with Everquest, that's all.
I just used his request as an example for the thrust of my discussion. Your macro(s) are fine =). I never meant to imply they weren't good enough or appropriate. I actually get some satisfaction out of making the computer do mundane decisions for me so I can chat more while they execute :)
I just used his request as an example for the thrust of my discussion. Your macro(s) are fine =). I never meant to imply they weren't good enough or appropriate. I actually get some satisfaction out of making the computer do mundane decisions for me so I can chat more while they execute :)
--Jerle
My above post is basically a while loop. It doesn't follow the standard while loop syntax, but compared to cpu time, my example would run just as fast.Chill wrote:eep, dont like that personally.
/while, /do while, and/or /do until structures would be nice tho. Lax?
rearrange things if you want it to be a little more to what you're used to...
:doWhileLoop
/commands
/if TRUE /goto :doWhileLoop
so, in the above example,
:loop
/delay 1
/if (Window[GiveWnd].Open) /goto :loop
IF Lax were to put in a do/while loop, it'd probably end up looking something like:
/do {
/delay 1
} while (Window[GiveWnd].Open)
when the goto loop is just fine personally.
yeah I was going to ask Lax if it were possible to get a /while command, but I don't want to get shot in the forums :)
/while ( condition expression ) {
}
and also:
/do {
} until (condition expression)
would be sweet. I cringe every time I use /goto, but that's the many, many years of hearing "GOTO IS BAD!!!!" just eating at my subconcious :)
/while ( condition expression ) {
}
and also:
/do {
} until (condition expression)
would be sweet. I cringe every time I use /goto, but that's the many, many years of hearing "GOTO IS BAD!!!!" just eating at my subconcious :)
--Jerle