Hydra - Multibox Leveling Helper

Hydra is a multibox leveling helper that aims to minimize the number of times you need to actively control secondary characters.

Scroll down for a full list of features. Options are accessible by typing “/hydra” or by browsing to the Hydra panel in the Interface Options window. Several common commands can also be keybound in the standard Key Bindings window.

Please note that Hydra is not a replacement for key cloning software — addons can’t cast spells, target units, or perform many other actions, so you will still need some way to send your key strokes and mouse clicks to your secondary characters’ instances of WoW.

Hydra operates on the basis of “trust”. You tell it which characters you trust, whether they're your multibox characters or just your questing buddies, and features are enabled or disabled depending on whether you’re in a party with trusted characters or not. For example, whispers are only forwarded to party chat if everyone in the party is on your trusted list.

You can add or remove names to your trusted list in the options panel. There's also an option to add everyone in your current party to your trusted list, for quick setup for multiboxing groups.

Automation

Accepts summons and resurrections.

Declines duels, guilds, and arena teams.

Repairs equipment and sells junk to vendors.

Chat

Forwards whispers to secondary characters to party chat.

Forwards responses in party chat back to the sender as a whisper from the secondary character.

Follow

Notifies you when a party member starts or stops following you.

Type “/followme” or “/fme” to command all party members to follow you.

Type “/corpse accept” to make all other party members who are ghosts accept their corpse.

Type “/corpse release” to make all other party members who are dead release their spirit.

Mount

Causes other characters in the party (and in range) to mount when you mount.

Party

Accepts party invitations from trusted characters.

Request a party invitation by typing “/inviteme name”, where “name” is the target. If no target is specified, your current target unit will be used.

Request a promotion to party leader by typing “/promoteme”.

Quest

Accepts quests that another trusted party member already accepted, or all quests

Turns in completed quests (you still need to choose a reward if there’s a choice)

Abandons quests abandoned by trusted party members

Taxi

Autoselects the last taxi node selected by anyone in the party in the last 60 seconds.

Type “/cleartaxi” to manually clear the selection for the current character.

Hold the Shift key when interacting with the flight master to bypass this module’s functionality.

Limitations & Caveats

Chat module limitations:

Whispers containing a high number of “spam words” (words that commonly appear in goldselling, powerleveling, phishing, or other spam) are forwarded as “POSSIBLE SPAM” instead of the actual text, to avoid having your account appear to send spam. If you want to see the actual message, check the receiving character’s chat log.

Whisper forwarding is disabled in non-trusted parties, and there is currently no notification if someone whispers a secondary character in this situation.

Primary character detection:

Hydra currently offers two methods for detecting the primary character. By default, it assumes that the primary character is the party leader. You can use the options panel to switch to checking for applicaton focus instead, but this method will not work if you are using multiple physical machines, and may not work if you are running multiple clients in windowed mode.

Advanced Chat Usage

If whispers from multiple senders are forwarded to party chat, your responses in party chat are assumed to be directed toward the sender of the most recently forwarded whisper. You can respond to a previously forwarded whisper by prefacing your message in party chat with “@name”, where “name” is the name of your character that forwarded the whisper.

If whispers from multiple senders are forwarded by the same character, you can respond to a previous message by whispering that character with “@name message”, where “name” is the name of the person you want “message” to be whispered to. You can also use this feature to have your secondary characters send whispers to people who haven’t already whispered you.

Version 7.0.3.0

Updated for WoW 7.0

Fixed the Follow module not actually deactivating when un-checking its "Enable" option

Fixed an error in the Loot module

Version 6.2.0.31

Fixed an error in localization

Version 6.2.0.30

Updated for WoW 6.2

Added an option to disable automatic loot method switching

Fixed an issue with taxi destination sharing

Fixed some issues with option checkboxes

Renamed the "Party" module to "Group" since it also works for raids

Version 6.0.2.206

Updated for WoW 6.0

Taxi sharing now works immediately for secondary characters who already have the taxi map open

Improved dismount detection for noobs who click off auras to dismount

Fixed junk selling profit report for stacked items

Added alchemy and engineering specialization quests to the ignore list

Version 5.4.8.187

Fixed textures overlapping on the "remove name" dropdown when there are no names to remove

I have a 5 man multibox team. I'm not in a raid. All toons are on the same realm. All of my team members are in the trusted list.
When one of the team mounts or dismounts, the other members of the team do nothing.
I've tried different mounts.
The options for the Mount module:
Mount with group - ON
Use random mount - OFF
Dismount with Group - ON

I have a 5 man multibox team. I'm not in a raid. All toons are on the same realm. All of my team members are in the trusted list.
I'm using ISBoxer and Hydra.
When I switch from controlling one toon to another, I have ISBoxer send "/promoteme" to toon that I just switched to.
All of the toons except the current party leader are whispering the soon to be party leader: "I cannot promote you, because I am not the group leader.".
I also get this error if I manually type "/promoteme" on the toon that I want to be the party leader.
The LUA code causing this is in "Hydra\Modules\Party.lua" at line 62 of version 5.4.7.167.
For now, I've simple changed that line to be "return" with no arguments.

I just found the addon "Hydra". Before now, I was using Jamba. Hydra is much easier to setup and does what I need it to along side of the ISBoxer program. I saw some posts about the author not playing WOW. Just wondering if I should get emotionally attached to this addon (smile)?

Yep, Curse takes anywhere from 5 minutes to several days to approve new versions, so it will always be out of date immediately after a new version is released. Feel free to complain to them.

Edit:
It looks like the new version simply vanished on Curse, as it wasn't even shown as pending approval anymore. I've re-uploaded it, so barring another black hole, it should appear for download there sometime in the next 1-3 days.

Yet again, "it doesn't work" is not even remotely helpful. I need specific details -- are you in a party or raid group? Is everyone in the group on your trusted list, or only some characters? Is everyone on the same server, or different servers? What settings are you using for the mount module? What messages do you see when you enable debugging for the mount module and then summon a mount, both on the character who mounted, and on one of the other characters?

Yep, those are all known issues, but I haven't done any multiboxing in at least 2 years, am not even actively playing WoW at the moment, and don't have that much time to spend debugging addons anymore, so pretty much they'll be fixed when they're fixed. If you have addon programming experience and can provide a tested and functional patch I'm happy to incorporate it, but otherwise, just telling me over and over what's broken isn't going to magically give me more spare time or get it fixed faster, sorry.

Want to say how much I have appreciated this addon. Has made the multiboxing I do so much nicer.

But at this point it has been broken for months now. Some parts still work (vendor selling, group joins, announcing follow break, etc.).

The functionality of auto refollow, /followme, /promoteme, taxi, and mount/dismount with group don't work at all anymore. The bulk of the issues start when realm merges happened. And you could sometimes revert to an older version and have some of it still working.

As of a couple months ago though (wow 5.4.7 patch?) something changed and no versions work correctly.

Seems to all be charname-realmname related. Hydra seems to be trying to pass charname-realmname to the follow and promote commands, but they only accept charname.

It is not a trusted name issue as far as I can tell. Have tried populated the trusted listed with just charname, with just charname-realmname, and with both.

I have tried running with all other addons disabled. I have deleted out all hydra configs and directories. Doesn't fix the problem.

Anyway. I have loved the addon for a long time, and have been limping along with standard wow macros. But hoping we see an update sometime soon to make this fully work with connected realms.

What action(s) could an addon take to prevent another addon from receiving events?

It would have to explicitly unregister the event on the other addon's frame, and it seems extremely unlikely that any addon is actually doing that, so if some frames are receiving the event but not others after certain types of errors occur, it's most likely a game client bug.

If that's the case, there's probably just nothing I can do about it. When it happens, does any part of the default UI's quest display stop working? If you register for the same events in another addon, are they received there?

At this point, I have seen the problem crop up even when there are no LUA errors for the session. I will go ahead and instrument another addon, to see if the events are received elsewhere.

What action(s) could an addon take to prevent another addon from receiving events?

i don't know where these are coming from. this is attributed to PetTracker, which makes no reference to "CompactRaidFrame1" nor invokes method "ClearAllPoints" on anything anywhere.

I haven't seen that particular error, though PetTracker does raise an error for me if I'm in combat the first time the pet journal is opened in a given session...

Originally Posted by acapela

update: i have instrumented some of Hydra's quest event handling... when this problem occurs, it looks like the events are simply not being delivered.

If that's the case, there's probably just nothing I can do about it. When it happens, does any part of the default UI's quest display stop working? If you register for the same events in another addon, are they received there?

OmegaMap does call "ClearAllPoints" on a wide variety of things, but does not directly reference anything called "CompactRaidFrame1".

in both cases, there is no error trace through the cited addon (PetTracker, OmegaMap, etc). these are generated into BugGrabber's Frame:ADDON_ACTION_BLOCKED/ADDON_ACTION_FORBIDDEN handler. i have enabled taint logging (i think/hope), and will take a look when i get a chance.

are these actually causal, do they just correlate, or are they completely unrelated? i don't know.

update: i have instrumented some of Hydra's quest event handling... when this problem occurs, it looks like the events are simply not being delivered.

I am finding quest autoshare/autoaccept functionality stops working as soon as any addon catches a LUA error. As far as I can tell, the perpetrating addon can be anything, and completely unrelated to Hydra.

That's pretty weird. None of the quest API functions are protected in any way, so taint shouldn't be a factor. At least with that info I can try to reproduce it.

Originally Posted by acapela

P.S. feature request: abandoning a quest should clear the quest out of all of the "accept" record-keeping in Hydra. Autoshare/autoaccept works differently (i.e. doesn't automate) after abandoning and re-acquiring a quest, versus acquiring the quest the first time.

Sounds reasonable, and the change is trivial, so that'll be in the next release.

I am finding quest autoshare/autoaccept functionality stops working as soon as any addon catches a LUA error. As far as I can tell, the perpetrating addon can be anything, and completely unrelated to Hydra.

In fact, I am seeing LUA errors that apparently originate and propagate entirely within Blizzard FrameXML code which seem able to cause this.

I assume this is some sort of taint issue, and beyond Hydra's control. (Don't know enough about secure code to know whether/how Hydra configures its Quest functionality, though the relevant Blizzard API is documented as "secure"; follow/mount functionality doesn't seem to be affected.)

So, pending further testing and isolation of a (reproduceable) case where Hydra has trouble when this is NOT true, I am retracting my assertion that this part of Hydra is "not working"... doesn't look like a Hydra problem, and as far as I can tell there is no problem (Hydra's or otherwise) under a "clean" UI session. Hopefully that will save Phanx some testing effort.

P.S. feature request: abandoning a quest should clear the quest out of all of the "accept" record-keeping in Hydra. Autoshare/autoaccept works differently (i.e. doesn't automate) after abandoning and re-acquiring a quest, versus acquiring the quest the first time.