[Addon] LibRpc-0.2 / LibTrust-0.1

[Chorizotarian]

New Addon 1: LibRpc-0.2
LibRpc is an embeddable library for making remote procedure calls ('http://en.wikipedia.org/wiki/Remote_procedure_calls') between WoW clients. An addon running on one client can call any global API on another client as long as the appropriate security permissions have been set using LibTrust. (Normal in-combat restrictions may also apply.) For example:


LibStub("LibRpc-0.2"):RemoteCall("Katator", nil, "SendChatMessage", "hello world")

http://wqogjq.tuk.livefilestore.com/y1pw-OseSnxflmorsAtU98E0NxLYebvXM7zmxyGr_nC-mnQmU2zKxPzqmTvsSheDmTILtnq86t-nNE/LibRpc1a_sm.jpg ('http://wqogjq.tuk.livefilestore.com/y1pw-OseSnxflm1epbbI93-UcJLGmhOqw3074ldhFiJxrITji6DKWFu0Y8WCD-HP9FwTvHg1sUWkho/LibRpc1a.jpg')

LibRpc also supports registration for remote events:

(On Iaggo)

/script function printEvent(...) SendChatMessage(table.concat({...}, " ")) end
/script LibStub("LibRpc-0.2"):RegisterRemoteEvent("Katator","AUTOFOLLOW_BEGIN", printEvent)

(On Katator)

/follow Iaggo

(On Iaggo)
http://wqogjq.tuk.livefilestore.com/y1pw-OseSnxflmByYufWNakUaIG7dU9FtI_VqT26OrM6qVA5rbDjiff aLtM-qXWyrdZEX-AuWFc3_Q/ev1.jpg

Remote procedure calls can be made through a cmdline interface:


/rpc Katator SendChatMessage "hello world"

LibRpc uses AceComm-3.0 for RPC messages and AceSerializer-3.0 for marshalling function arguments. Any type that AceSerializer can handle should be usable as a function argument.

New Addon 2: LibTrust-0.1
LibTrust is an embeddable library for establishing trust relationships between characters. You don't want just anyone with LibRpc installed making WoW API calls on your toon -- they could mail all of your gold to another account, for example. LibRpc lets you say who you trust, presumably just your other characters.

LibTrust starts out with an empty database of permissions. To enable trust between your characters use the "/trust allow" command. There are also commands to deny trust and allow/deny on specific APIs. Type /trust for more info.

Installation:
1) Download the zip files for both addons: LibRpc-0.2 ('http://wqogjq.tuk.livefilestore.com/y1pw-OseSnxflk_RD6PSkTK9UAzui9dInxskN1x85BM5cJRMUTU8nAr mHsGBy52JuPJL5bHp4LQubc/LibRpc-0.2.zip?download'), LibTrust-0.1 ('http://wqogjq.tuk.livefilestore.com/y1pw-OseSnxflkF_2xMWdFlIaY23MfevuJPtpunFd14Wk6SLRVMVpGH Xl_rxvR-B6w2HmZUE_ra550/LibTrust-0.1.zip?download')
2) Unzip to [WoW]\Interface\AddOns
3) Close WoW and restart

You should see both LibRpc-0.2 and LibTrust-0.1 listed in your installed addons. Make sure they are enabled.

Configuration:
Log onto 2 of your toons. Let's call them Iaggo and Katator. Our goal will be to make Katator dance with Iaggo via a /rpc command:

(On Iaggo)

/rpc katator DoEmote dance Iaggo

Initially if you type this LibRpc will pop a LUA error on Katator: "RPC message from untrusted sender: Iaggo". Katator doesn't trust Iaggo, so she rejects the message. To fix this type the following:

(On Katator)

/trust allow Iaggo

Now when you run the /rpc command above Katator will start dancing with Iaggo. However, you'll also get an error message on Iaggo: "RPC message from untrusted sender Katator". The second message is Katator sending back the return values from the DoEmote call. In this case the return value is empty, but there is still a message sent. To get rid of the error we need to tell Iaggo to trust Katator:

(On Iaggo)

/trust allow Katator

Now the /rpc command will work correctly with no errors.

http://wqogjq.tuk.livefilestore.com/y1pw-OseSnxfllKq1a4Dz3ZjtsTKXQQl8_GO7dN0uFHLbpqirvrmUsl ZAQP5Czxs8DjUMC8ZaCoJ88/LibRpc3_sm.jpg ('http://wqogjq.tuk.livefilestore.com/y1pw-OseSnxfllXpvgpM3NVKO6Xu2IDlGBbBPNjE0C4FzclG67Z9ex-YmbebtN-icQFaOrOHYfgoT4/LibRpc3.jpg')

Here's another example with a return value:


/rpc katator UnitArmor player

http://wqogjq.tuk.livefilestore.com/y1pw-OseSnxfllD_wReRReMvR6HnPMPglkl2BfqWYxdN7ifleb9PcuU gZ6bC2iR9J-f_5r7XgHiu-o/LibRpc4_sm.jpg ('http://wqogjq.tuk.livefilestore.com/y1pw-OseSnxflkHvcAJaT3a0E89eYIUjjf45q-gourM3zmw8HjIpXq9U472crKGjDZH5kwiRDqLn38/LibRpc4.jpg')

WTF Can I Do With This?
I started working on this for another mod, to be called MetaMacro. The idea is to reprogram macros on all of your clones dynamically, so you can easily switch which default totems your shaman clones drop, which characters are in your target macros, etc. I decided to release the RPC stuff first though because I want feedback and I thought that the /rpc command might be generally useful in macros.

Some other ideas:
<add here>

To Do:
- Upload to Ace SVN
- API documentation
- Improved configuration for LibTrust, possibly a GUI
- LibRpc option to limit debugging spew
- Support for remote event registration
- Demo remote event registration
- Slash commands for events
- Require string id instead of self in API calls if LibRpc is used non-embedded (like CallbackHandler-1.0 ('http://www.wowace.com/wiki/CallbackHandler-1.0/User_API'))
- Smart event unregistration on UI reoload
- Better way to get the source of a fired event
- /rpc party ... to avoid repetitive commands in macros
- Bucket events
- AceEvent message support (user events)
- Unit tests

Issues:
- Callback function info does not include return value
- Event args not being passed properly
- I have learned that embedded libs can't have saved vars, so LibRpc has to be an addon
- Event unregistration w/ multiple client addons may cause conflicts

Updates:
- 4/15/08: Fixed bug with callback function not geting return value, partial code for remote events
- 4/17/08: LibRpc-0.2, remote event support
- 4/18/08: Event args now passed correctly
- 4/23/08: Debuging messages off by default, "/rpc debug" to toggle
- 4/23/08: Removed overly picky error when calling UnregisterAllRemoteEvents with no events registered
- 4/26/08: Fixed embedding implementation for both libs, should now be embeddable
- 5/17/08: Fixed a LibTrust bug that garbled names containing out-of-locale characters (e.g., accented chars)

[Chorizotarian]

Reserved

[Chorizotarian]

Reserved 2

[Blubber]

Very nice idea! This enables a host of nice stuff for multiboxers, like showing every characters XP or Faction on their respective party frames. Very nice indeed, going to give it a try right away :).



/rpc <alt> UnitXP player
/rpc <alt> UnitMaxXP player


To retrieve the amount of XP a character respectively has and needs in total to ding.

Edit: Any way you can let remote clients register for events?

[Djarid]

Oh Chorizo, you are the man! ;)

what an awesome mod! I am in awe and almost started speaking l33t ;)

[Chorizotarian]

Thanks you guys, I'm glad you like.


Edit: Any way you can let remote clients register for events?

Yeah, that's a great idea. Should be easy to do.

[Stix]

tagging for DL at home


nice addon function btw


question.. would it be possible to lets say me leading a raid .. hit a button and stop all 24 others from casting (via escape or stop casting event ??/) LOL


assuming we all DL'd it n etc and they allowed me on them ..

[Chorizotarian]

question.. would it be possible to lets say me leading a raid .. hit a button and stop all 24 others from casting (via escape or stop casting event ??/) LOL

No, I don't think so. Any API that would cancel casting is probably protected, so you can only call it from a secure button / unit frame / etc.

[Blubber]

question.. would it be possible to lets say me leading a raid .. hit a button and stop all 24 others from casting (via escape or stop casting event ??/) LOL

No, I don't think so. Any API that would cancel casting is probably protected, so you can only call it from a secure button / unit frame / etc.
Definitely protected. For anyone that wants to know more, take a look at the World of Warcraft Global API ('http://www.wowwiki.com/World_of_Warcraft_API') on wowwiki.com. The functions with PROTECTED next to them can only be invoked by a button press on the client itself. All other functions can be called using LibRpc.

mmm, been thinking about some stuff that one could make with this addon:
XP/Faction bars for all party members. Remote global cooldown spark, maybe even with lag compensation. (Might be handy for casters, not really sure). Remote cooldown warning, i.e.: like sct_cooldowns does for your own cooldowns. Quest objective tracking for all party members.You can come up with a whole lot more I guess :).

[Sentack]

Very very interesting Addon! I like. Hrm, Finding a use for this will take time but it does seem pretty damn neat.

[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 ('http://www.wowace.com/wiki/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.

[Kaynin]

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.

[Chorizotarian]

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:


local handler = GetSinkCallbackHandler(target)
if handler then
handler.UnregisterAllCallbacks(self)
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.

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.


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:


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.


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.

[Chorizotarian]

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.

[Chorizotarian]

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.

[Xzin]

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?

[Blubber]

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).

[Chorizotarian]

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?


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):


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

Your sheep macro would then be:


/click SetFocus
/cast Polymorph

[Chorizotarian]

There's a good discussion of issues w/ Proximo-like targeting for mobs on the Ace forums:
Proximo-like mob targeting revisited? ('http://www.wowace.com/forums/index.php?topic=12490.msg198180')
Re: PerfectTargets / SmartAssist type addon? ('http://www.wowace.com/forums/index.php?topic=6518.40')

The short version is:

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.

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.

[Blubber]

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 :]).

[Chorizotarian]

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):

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

[Chorizotarian]

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 :]).

Oops, missed one! Yeah, you could manipulate the LibTrust settings remotely via LibRpc, but only if you have sufficient permissions. If you just do "/trust allow <main>" on your clones then you've granted full trust. At that point the main can already run whatever remote API he wants, so there's no point in trying to hack the LibTrust settings.

You could also enable finer-grained security settings: "/trust allow <main> <api>" or "/trust deny <main> <api>". If you only allow the specific APIs that you need then you probably could lock down things enough that it wouldn't be possible to manipulate the trust settings remotely. You'd have to be careful though because LUA provides ways to create and run code on the fly. On the whole I think that trying to lock things down beyond which chars you trust is probably overkill.

[Blubber]

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):

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

Problem is, I embedded both LibRpc and LibTrust, but libtrust doesn't seem to save anything. Only when I add the SavedVariables to the tOC it starts saving.

[Blubber]

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 :]).

Oops, missed one! Yeah, you could manipulate the LibTrust settings remotely via LibRpc, but only if you have sufficient permissions. If you just do "/trust allow <main>" on your clones then you've granted full trust. At that point the main can already run whatever remote API he wants, so there's no point in trying to hack the LibTrust settings.

You could also enable finer-grained security settings: "/trust allow <main> <api>" or "/trust deny <main> <api>". If you only allow the specific APIs that you need then you probably could lock down things enough that it wouldn't be possible to manipulate the trust settings remotely. You'd have to be careful though because LUA provides ways to create and run code on the fly. On the whole I think that trying to lock things down beyond which chars you trust is probably overkill.I don't think it's really anything to worry about, as you point out, it should be reasonably safe at the moment. However, there are some pretty powerful API functions out there, that I don't want anybody else calling :).

[Chorizotarian]

Problem is, I embedded both LibRpc and LibTrust, but libtrust doesn't seem to save anything. Only when I add the SavedVariables to the tOC it starts saving.

I found a problem with the embedding implementation (as in I hadn't provided one, oops). Fixed now. Here's a sample that works for me. (You'll need to change the char names in the source.)

[pipakin]

Interesting macro possibilities

like this one on the main char:


/invite ALT1
/invite ALT2
/invite ALT3
/invite ALT4
/rpc ALT1 AcceptGroup
/rpc ALT2 AcceptGroup
/rpc ALT3 AcceptGroup
/rpc ALT4 AcceptGroup


one button invite/accept that doesn't need a keybind :)

or my favorite, the dance party macro


/dance
/rpc ALT1 DoEmote dance party1target
/rpc ALT2 DoEmote dance party1target
/rpc ALT3 DoEmote dance party1target
/rpc ALT4 DoEmote dance party1target
/s Dance party time!
/rpc ALT1 SendChatMessage "Dance party time!"
/rpc ALT2 SendChatMessage "Dance party time!"
/rpc ALT3 SendChatMessage "Dance party time!"
/rpc ALT4 SendChatMessage "Dance party time!"

[Chorizotarian]

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.

This is wrong apparently :( Libs can't have saved variables, so LibRpc needs to be an addon. Will be fixed in the next version (in progress).

[emgee]

the LibTrust seems to have an issue with special characters.
my shammies are named Akishâ, Akishá and Akishà
so i enter /trust allow Akishá
and it ends up beeing only Akish on the list

i also put them manually in the Lua file and they also show up in /trust list
but still i get "....answer from untrusted character Akishá..." etc

anyone experienced similar stuff or maybe even fixed it ?

[Chorizotarian]

Looks like there is a console issue with inputing special chars. In the next version you will be able to use "target", "party1", etc., which should fix it.

> i also put them manually in the Lua file and they also show up in /trust list but still i get "....answer from untrusted character Akishá..." etc

I'll look into this tomorrow and try to get you a fix.

[emgee]

you rock!

[Chorizotarian]

Found the problem:


Character classes follow the current locale set for Lua. Therefore, the class '[a-z]' can be different from '%l'.
http://www.lua.org/pil/20.2.html

I patched the LibTrust-0.1 zip linked at the top of the thread. Download a new copy and you should be all set.

[emgee]

working like a charm now! thanks alot!

[razorbax]

Was trying to troubleshoot around this one. Lets say I have Tank(partyleader) and Healer. With Trust set up already, i think this code, when run from the Tank, will create a macro on the healer that will cast heal on the tank.

/rpc Healer CreateMacro("Heal1", 1, "/cast [target="+UnitName(Party1)+"]heal", 1, 1)

If we add another member, say DPS, then it would look like this.

/rpc Razorbax CreateMacro("Heal2", 1, "/cast [target="+UnitName(Party2)+"]heal", 1, 1)

You would probably have to run something like....

/rpc Razorbax DeleteMacro("Heal1")
....first, but i think has promise.....

NB. I am not a coder so I won't take offence to being corrected;)

[razorbax]

OK, so I am home now and I have had a play.

This works as straight text with no variables..

/rpc Razorslax CreateMacro "Heal1" 1 "/cast [target=razorbaxftw]heal" 1 1

But when I do the version with the variables

/rpc Razorslax CreateMacro "Heal1" 1 "/cast [target=" .. UnitName(Player) .. "]heal" 1 1

It errors and only graps the first "/cast [target=" part. Anyone know what is used as joiners? I have tried ".." and "&" and "," and "and".

[Jafula]

But when I do the version with the variables

/rpc Razorslax CreateMacro "Heal1" 1 "/cast [target=" .. UnitName(Player) .. "]heal" 1 1

It errors and only graps the first "/cast [target=" part. Anyone know what is used as joiners? I have tried ".." and "&" and "," and "and".The concatentation ('http://www.lua.org/manual/5.1/manual.html#2.5.4') operator is .. try it without spaces (blah..blah..blah) and also on that page at linked there is a section 2.1 - Lexical Conventions which explains what I say below.

UnitName ('http://www.wowwiki.com/API_UnitName') takes a string (type of variable); so you'll need to pass "player" to it for it to work. But because you are using " in UnitName, you need to use [[ and ]] instead of " around the complete string.

so you might like to try:

[[/cast [target="..UnitName("player").."] heal]]

I make no guarantees that this will work for you; good luck in your macro manipulation quest. (Do you get a phat reward when you hand it in?)

[Chorizotarian]

I'm not playing WoW anymore (at least not until the next time I get sucked back in :)). If anybody is still using this and wants to pick up the last version I was working on the code is here:
http://code.google.com/p/wow5box

Check out the projects MultiboxRoster and Remoting.

[Jafula]

I'm not playing WoW anymore (at least not until the next time I get sucked back in :)). If anybody is still using this and wants to pick up the last version I was working on the code is here:
http://code.google.com/p/wow5box

Check out the projects MultiboxRoster and Remoting.I'll have a look, thanks for sharing your work!