[Addon] LibRpc-0.2 / LibTrust-0.1

Sooo.

You can whisper casts without delay (well, chat delay, which is far less).

Sooo, if you have your main target a mob for a while, then you immidiatly need to swap to another mob. And then, in a split second (instantly!) click a button that casts Lightning Bolt and whispers to your alts a /cast [target=%t] Lightning Bolt

It will actually cause your alt to instantly cast lightning bolt on the right target and not the first target? (As it would do with focus and client lag.)

Or is the above situation considered 'illegal'?

edit: Actually, %t won't work very well on mobs with similar names. I just realized this. But like, the idea of this is pretty against the ToS though? To implement whispercasts. this way.

Quote:

---

Originally Posted by 'Blubber',index.php?page=Thread&postID=55914#post5 5914

The only available event concerning party member joining/leaving is PARTY_MEMBERS_CHANGED. But there is no way to find out which member actually joined or left, if any. So the only option I have, is to unregister the remote events for all party members, and re-register them. However, when a new member joins, this will give an error No events registered for target <nane>, so basically, there should be a method to query whether or not a certain event is registered, or maybe just ignore unregister requests in this case.

---

I think that the error was a little picky in this case, so I just removed it:

Code:

---

    local handler = GetSinkCallbackHandler(target)
    if handler then
        handler.UnregisterAllCallbacks(self)
    end

---

Quote:

---

The second problem is related, when I do /console reloadui on my main client, the remotely registered events get wiped, which is ok. However, the remote client will still have the event registered. So there should be a method of checking whether or not a event is registered on the remote client.

Edit: mmm, you should be able to register for the remote PLAYER_ENTERS_WORLD event, and delete all registered events for that player.

---

Yeah, good point. I'll add that to the todo list. For now you should be able to do an UnregisterAllRemoteEvents before creating your new events. That will wipe any leftover garbage.

Quote:

---

Edit2: there doesn't seem to be any way of figuring out what client fired a remote event, the only arg the callback receives is the event name, or am I missing something?

---

No, I'm missing something :) You could provide a different method for each target that includes the source name:

Code:

---

local function bitch(source, ...)
SendChatMessage(source .. " missed again!")
end

lib:RegisterRemoteEvent("Katator", "CHAT_MSG_COMBAT_SELF_MISSES", function(...) bitch("Katator", ...) end)

---

That's kinda clunky though. I'll put it on the todo list to come up with something better.

Quote:

---

Edit3: There seems to be a bug that prevents the debug flag from getting saved, which means that I have to re-set it after every /console reloadui (not sure if it's a bug or a feature ;).

---

You say bug, I say design limitation :) To save the state of this one var WoW would have to read / write a new file every time you reload. I'm not keen to add 20 ms or so of seek time to everyone's startup. I dunno. I guess if it's a huge pain I can save the state.

Quote:

---

Originally Posted by 'Xzin',index.php?page=Thread&postID=55943#post5594 3

YES! I have been waiting for somebody to write this!! Please flesh it out - this is a huge upgrade for boxers.

---

Glad you like it Xzin :) I hope that mod authors find it a useful building block.

Quote:

---

Originally Posted by 'Kaynin',index.php?page=Thread&postID=55971#post55 971

You can whisper casts without delay (well, chat delay, which is far less).

Sooo, if you have your main target a mob for a while, then you immidiatly need to swap to another mob. And then, in a split second (instantly!) click a button that casts Lightning Bolt and whispers to your alts a /cast [target=%t] Lightning Bolt

It will actually cause your alt to instantly cast lightning bolt on the right target and not the first target? (As it would do with focus and client lag.)

Or is the above situation considered 'illegal'?

edit: Actually, %t won't work very well on mobs with similar names. I just realized this. But like, the idea of this is pretty against the ToS though? To implement whispercasts. this way.

---

There's nothing outside Blizzard's macro system here, so whatever you can do should be ok w/ respect to the ToS. However, I don't think you'll be able to run any protected APIs remotely due to normal restrictions on what can be done from a non-secure addon. That's why mods like WhisperCast died after 2.0.

Is there any way to add some kind of precombat targeting functionality? Meaning like Slot 1 - 4 sheep targets. Out of combat, you could "save" those 4 variables then enter combat and click the SHEEP NOW button and target 4 separate targets? Make the main "leader" responsible for coordination of this system and have it pass the variables..... maybe something like Proximo?

Quote:

---

Originally Posted by 'Xzin',index.php?page=Thread&postID=56031#post5603 1

Is there any way to add some kind of precombat targeting functionality? Meaning like Slot 1 - 4 sheep targets. Out of combat, you could "save" those 4 variables then enter combat and click the SHEEP NOW button and target 4 separate targets? Make the main "leader" responsible for coordination of this system and have it pass the variables..... maybe something like Proximo?

---

The only real way of targeting is either clicking on a mob, or using assist (or target=focustarget), because addons can only target by name. They can't target mobs by ID. So It's impossible for a addon to know which mob you are actually talking about, unless they have a different name, or you have them selected. So the short answer is 'no', you can't use this to target mutliple mobs (at least not with accuracy).

Quote:

---

Originally Posted by 'Fursphere',index.php?page=Thread&postID=56025#pos t56025

Hey Chorizotarin - Post our ingame meeting the other night, if you need help testing this in game, let me know. (doubtful since you've got 5 accounts of your own... but maybe you'll think of something that needs 10+ characters). :D

---

Fur, good chatting with you. Sorry if I missed some of your tells -- I'm usually only paying attention on my pally (Iaggo), and I haven't gotten around to setting up a message forwarding system yet.

I'll give you a yell if I need help testing, or if I manage to crank on 35 levels in short order and am ready to 2-man Kara :P What's your main guy's name again?

Quote:

---

Originally Posted by 'Blubber',index.php?page=Thread&postID=56051#post5 6051

The only real way of targeting is either clicking on a mob, or using assist (or target=focustarget), because addons can only target by name. They can't target mobs by ID. So It's impossible for a addon to know which mob you are actually talking about, unless they have a different name, or you have them selected. So the short answer is 'no', you can't use this to target mutliple mobs (at least not with accuracy).

---

Yeah, that sounds right. You might be able to do something for PvP though. I'm not sure if you can call the targeting functions like FocusUnit directly since they are all protected. You could definitely create a remote macro to focus a player of choice though (while out of combat):

Code:

---

/rpc Katator CreateMacro SetFocus 12 "/focus Xzin" 1 1

---

Your sheep macro would then be:

Code:

---

/click SetFocus
/cast Polymorph

---

There's a good discussion of issues w/ Proximo-like targeting for mobs on the Ace forums:
Proximo-like mob targeting revisited?
Re: PerfectTargets / SmartAssist type addon?

The short version is:

Quote:

---

That has already been mentioned in this thread - Proximo can do it because player names are unique. You can set a macro "/target <player name>" to a secure template button when out of combat. It won't work in-combat.

A PvE version can also do "/target unit name" but since names aren't unique, it won't always work. It WILL work in fights like Moroes where the names are unique however.

---

Quote:

---

GUID's can be used to uniquely identify mobs and to get the mob ID (i.e the ID you see on sites like wowhead). They cannot be used for targeting purposes.

---

2 Little questions regarding LibTrust.

1) I embedded LibTrust in my addon, and added SavedVariables: LibTrustDB to the TOC. It works, it saves the trust stuff, however, it doesn't seem to share it with other addons. At least, the trust stuff that I setup before, on the same account, was gone. Is it a bug, or just me not understanding saved variables?
2) Is it possible to use LibRpc to allow or disallow a third client via libtrust, in other words, can I use LibRpc to remotely manipulate libtrust? If so, it might be a bit of a security concern. (Could just read the code, but asking is more fun :]).

You shouldn't need to add the saved variables. The idea is that LibTrust saves the settings in it's own SavedVariables and you call the public API.

I actually haven't tried embedding it yet. Maybe it's not working right. Can you post a code sample?

Here's what I do for LibRpc (non-embedded):

Code:

---

local libTrust = LibStub("LibTrust-0.1")
if not libTrust then error(MAJOR .. " requires LibTrust-0.1") end
...
if not libTrust:IsAllowed(sender) then
    ...
end

---