[Addon] LibRpc-0.2 / LibTrust-0.1

[Blubber]

There seems to be a bug in LibRpc-0.1 where the rval table isn't correctly set when using a callback function.

[Chorizotarian]

There seems to be a bug in LibRpc-0.1 where the rval table isn't correctly set when using a callback function.

Uh oh, I'll take a look. If you can reply back with repro steps.

[Chorizotarian]

Ok, I got it. You can repro like this (replace "Iaggo" with you char name):

/script local function f(info) message(table.concat(info.rval, " ")) end; LibStub("LibRpc-0.1"):RemoteCall("Iaggo", f, "UnitArmor", "player")

Uploading fix now. It also includes some non-functioning code for setting remote events. That part is in progress.

[Chorizotarian]

Added a new version of LibRpc with remote event registration.

[Blubber]

Couple of questions:
1) What happens if you register for a remote event more then once?
2) Are remote calls always handled in the same order as they where dispatched? I guess this is more of a question about the underlaying wow mechanic. Basically, can packets, and indeed, whole chat messages get dropped?

[Chorizotarian]

1) It depends on how you access the lib. If you embed it in your addon (preferred) each addon gets it's own per-target set of callbacks. If you get a direct pointer to the lib via LibStub(...):GetLibrary(...) then the last event hander wins (still per-target, per-event of course).
2) I don't think you should expect any strong guarantees about this. Remember that the messages have to go out to the server and back, so it's very possible that the order could get garbled even if the event sender dispatches them in a consistent order.

[Chorizotarian]

Actually I realize you should also be able to do the following:

local libRpc = LibStub("LibRpc-0.2")
libRpc:RegisterRemoteEvent("Katator", "myEvent", somefunc)

-- don't do this, it will stomp the previous call
libRpc:RegisterRemoteEvent("Katator", "myEvent", someotherfunc)

-- instead do this
libRpc.RegisterRemoteEvent("some string id", "Katator", "myEvent", someotherfunc)

By using the dot notatation rather than libRpc:RegisterRemoteEvent you substitute "some string" or "some other string" for self as the index that LibRpc uses to index the callback. See the CallbackHandler-1.0 User API for more info. I should probably add a check to enforce this pattern if LibRpc is used non-embedded.

[Chorizotarian]

Added a new version with debugging messages off by default. "/rpc debug" to toggle.

[Blubber]

So I ran into a little problem with my PartyXPBars. The situation is as follows:

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. Fixed this one with a dirty kludge for now, but it's less then ideal

--assert(handler, "No events registered for target: " .. target)
if not handler then return end

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.

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?

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 .

[Xzin]

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