MacroQuest64

BuffBeg toggle on/of, because sitting AFK and goveling for buffs from every passerby or other AFKer is just embarasing. Been fiddeling with this code for my monk macro, which is slowly looking less like the origional Rogue Helper one and more like RaidDruid. :p

RDevents.inc Edit: re-thunk it 3 times already, need to test it.

It's already a built in toggle in Buffbeg, here's the code straight from the inc:

Thinking of adding a failsafe condition to the CH logic that will duck CH and toss a pad heal if CH has more than say.. 4? seconds left, and the tank's HPs are below 20? %. Any other suggestions as to what the failsafe conditions should be? Or should I make them configurable via the ini? I originally had it in there based on the tank's Time To Live value, but I've found it to be less than reliable since mob DPS is so spikey, so I pulled it. I ended up losing a tank due to starting a CH too late last night without it though.

Maybe pad if the tank's HPs are less than half of the Tank Heal Pct and the CH is only half finished? Even then I could see it doing some early pads, but it's hard to say. Maybe I could even use the MATarget's HPs as a deciding factor as well, since there's no reason to duck CH if the mob's dead. Hmmm, this ought to be fun to code.

I have my cleric macro to duck out and pad as a function of whatever is set as Heal %. Here's the code.
Basically if the tanks HP are less than 1/2 of the Main Tank Heal Point and there is more than 3.7 seconds left in CH it will intereupt and cast Light.

feel free to use any or none of that :)

Documentation on my website updated to v5.1 and inclueds the BuffBeg info I just found out.

That's basically what I had in mind Neo, thanks.

You're the man Fallon. Oh, and /feedme is also a toggle built into feedme.inc to turn auto force-feeding on and off if you want to include that. Shuold probably update the Tank Heal stuff in the .ini section too, since it still says Tank Healing isn't yet implemented.

Updated again.

Added pad healing logic to the CH code. Test it out, worked fine for 6 hours in fire today. Only time the tank died is when someone trained Pyronis on us accidentally.

I must be retarded or something...

Got all the files, spent like an hour or so with the ini's setting up all my different options, loaded it in game and got the following (Not Cut-n-paste, so wording could be off) It takes about 2-3 minutes to end, but reguardless of if I'm in a group, raid, or jsut solo it does this. At work right now so can't paste my INI's... If requested I'll do that in a few hours when I can break away and run home for a few minutes.

FWIW, I'm using 5.0 - didn't notice 5.2 was up, so will update my code and give that a go, also. All other plugins and macros work fine, so I've almost completely eliminated the possibility that I just have a fucked up MQ.

Will be pouring over the code and the documentation for it today - really wanna get this to work, it looks to be a sweet macro.

(Edit: Just want to be clear that I don't think this plugin is farked, I most certainly think it's something I'm doing - Posting here to get a hand because I've poured over everything thus far and can't find what i screwed up.)

Try deleting (or re-name) your .ini files first. The macro will create defaults if none exist.

Step 2... Re-create all the filles via cut 'n paste, you probably clipped off a bracket or something.

add in "/echo some text here" tags in the various routines, and if that text pops out before the macro ends, you can tell if it got to that point in the macro.

You can also download the .zip file listed in the first post. I haven't updated it in a few versions, but it was working for me a week or so ago when I last used it.

Hey moron, when you replace /goto with /mqgoto in the source, and compile, then every macro you copy/paste needs to be changes as well, because /goto is no longer recognized by MQ.

Heh just thought of this... made the changes, will test it later tonight. Hopefully, that's all that I had forgotten...

Told ya it was something retarded I was doing.

WTG. At least you were able to figue it out on your own. Enjoy my life's work.

nm

Interesting thoughts.

The potential problem I see with a script this involved is that it will be spending more time thinking than doing. I already catch RD bogging down every now and then when my PC gets busy and I have a lot of the toggles turned on. If I were to add as much funtionality as you've laid out, I fear that it will spend more time parsing strings for class names, ignore lists, etc; than it will actually do anything. Genbot had similar issues for me due to it's complexity as well. I'd like to keep things as smooth as possible, and still be able to run this on my PC when I 2 box.

The spam healing without canceling thing can be done by setting the healpct to 100 and the cancelpct to 0 already. As long as your MAs don't suck ass /assistheal is the spam heal the MA function you asked for. I don't particularly like the idea of metering out heals based on the mob's HPs. If someone needs a heal, I'm going to give it to them. With the cancelpct set to 90 and healpct set to 70, I never tend to run oom unless we're REALLY short on healers. If it's an AE fight and we're using AE heals to help counter, then I set the healpct to 50. We rarely ever lose tanks on raids, and generally only lose a person to AE if their resists are ass, now that I've got a few guildies running this script.

If you want to make it just completely ignore monks, just add an /if to your version, or remove the Target.State check. I think I may add an /if to the CheckHP sub for HealFD that will cancel your heal if the monk happens to stand up before the heal finishes, now that you mention it.

I'm going to have to read through your post a couple more times to digest everything. I'll probably have more comments later

nm