ImmersionRP (Continued) 

I have a vague notion of adding Profile support, but there are a few difficulties in doing so with the way the transmission protocol works. I'm pretty sure I know how I want to get around them, but new features are lower on my priority list than bugs and polishing existing features.

So you can look forward to hearing about it Soon™.

This is not a bug. The purpose of binding the button to the primary chatframe is to ensure that only a single button is created, in a fashion that plays nicely with common UI designs tendency to have multiple chatframes visible and to utilize the first chatframe as the only chatframe used for actual interaction with other players. Your modification will not be included in the ImmersionRP codebase and will remain unsupported.

It has been brought to my attention that on at least one server, someone has begun systematically denying functionality to users of RP Add Ons by gaining ownership of the communication channel, and locking it with a password.

Blizzards custom chat channel interface requires that a user be considered the "owner" of the channel at all times. This is determined initially by the person who "creates" the channel by first joining it. Thereafter, should the owner leave the channel without designating a new owner manually with a slash command, ownership automatically passes to the character that has the lowest ID number (which is an incremental indicator of your characters creation date and time relative to every character ever created on that Realm since the Realms went online).

What this means is, that this terrorist can almost assuredly acquire ownership in an alternative channel s/he becomes aware of in the same fashion, and shut it down as well.

ImmersionRPs solution to this act will be to enable the channel-less communication system I developed, and I implore the other add on authors yet again to update their add ons technology in order to repel this attack upon our users, as I have implored them before to do it for the sake of their convenience.

Thank you for keeping your snarky responses to yourself. I certainly feel like dropping what I'm doing to implement, test, and bugfix a users modification in order to support a highly uncommon UI design scenario with the way you're behaving. I really feel the love.

Now if you don't mind, I have work to do, per my most recent comment.

The new communication method will be compatible with Mary Sue, yes. Which is requiring a rather substantial rewrite of the peer to peer code I originally wrote, and probably the inclusion of Ace Libraries into ImmersionRP.

In theory, if there are no more 'Disasters' around my house, I'll get it done today or tomorrow, and have the bugtest phase finished by this weekend.

Okay, you know what, I appreciate your enthusiasm, I really do, but you don't even have the correct line of the file in question, much less syntactically correct code. At a glance, my estimate is that your change, if applied to the correct portion of the file, would cause IRP to fail to modify a tooltip no matter which one it was.

If you have a bug report or feature request, please utilize the supplied features of this website and I'll look into them (now that I know the website isn't sending me emails notifying me of new submissions and therefore I have to check the pages manually, anyways >.< ).