Ralph Honi Posted February 26, 2012 Share Posted February 26, 2012 Hi all,I have an scripted object, attached to my Avatar, that is currently taking commands from me, thru a HUD on a chat channel with a "llListen" routine. I would like it to also accept commands from an Avatar seated next to me, through a HUD attached to them. I need to be careful with permissions because others with the same equipment could be in the area on the same channel. I've read thru all the Keys and ways to id the avatar ... but am still confused.The 2nd Avatar avatar2 is identified when he sits on the sit target;else if(avatar2 == llAvatarOnSitTarget()) I have this working and can get the UUID to "say" thru a (string) avatar2I thought about trying to pass this information somehow passing avatar2 as a string? I also thought about id'ing the Avatar thru a simple message then id the sender;when he sits on the "Sit Target" I say ... llSay(CHANNEL1, "copilot_id"); I thought I would identify the Avatars id thru him saying this an getting the id who sent it and filter future messages.Then I could filter the "listen" to either myself or the other Avatar only; listen(integer channel, string name, key id, string message) { if(llGetOwnerKey(id) == llGetOwner() || *here is where I would filter for Avatar2*) Like I said ... I read all the avatar id info but am really confused how to accomplish this in the easiest way. Any help would be great! Thank you Link to comment Share on other sites More sharing options...
DoteDote Edison Posted February 27, 2012 Share Posted February 27, 2012 One way is to listen to the other seat and have it communicate its sitter. Example: 1) The pilot's HUD has two listens, one with the KEY filtered to the pilot's UUID, and a second with the NAME filtered to the pilot's UUID. 2) Pilot sits. The pilot seat (named "pilot") grabs the pilot's UUID via llAvatarOnSitTarget(), whispers the UUID, then sends it to the co-pilot seat via llMessageLinked(). 3) The co-pilot seat (named "co-pilot") receives the linked_message, renames itself with that UUID via llSetObjectName(), then whispers its own llAvatarOnSitTarget() ONLY if there is an avatar sitting there. At this point, the pilot's HUD is still listening to its owner and to the other seat. 4) The co-pilot sits with the same relative HUD listens. 5) The co-pilot seat (now named with the pilot's UUID) performs the exact same steps as the pilot seat. When the co-pilot seat whispers the UUID of the co-pilot, the pilot's HUD (listening to that seat) receives the co-pilot's UUID. It can then switch its second listen to the co-pilot's UUID. 6) At the same time, the pilot seat receives the link_message from the co-pilot seat, renames itself with that UUID and - because the seat is occupied - whispers the pilot's UUID. The co-pilot's HUD receives the new UUID and configures its secondary listen to that new KEY. When an avatar unsits, the opposite seat should be re-named back to the generic "pilot" or "co-pilot" name. Also, you'll need a HUD button or command to reset the listens when that happens, so that the HUD can listen out for a new pilot or co-pilot. Alternatively, instead of swapping the secondary listen from seat to avatar, you could open a third listen to receive comms from the other avatar and maintain a listen to the seat. The seat could then communicate when the other avatar unsits, allowing the avatar listen to close. Link to comment Share on other sites More sharing options...
Ralph Honi Posted February 27, 2012 Author Share Posted February 27, 2012 Thank you for the reply ... I think I understand your approach and I will give that a try ... but let me clarify what I have. I have a scripted object, attached to my avatar that takes commands from a hud also attached to me. I would like to keep the pilots seat the name of the vehicle (it is the root prim). I would like the copilot HUD to be able to send commands also. So ... when the copilot sits ... can't I whisper a message from the copilot seat, recieve it at the scripted attachement, if the message is a certain word like "copilot_id" , then the script id's the copilot sender with (key id) or ... pass the UUID via a (string). I don't know how to id using the (key id). I think I know how to pass via copilot = llAvatarOnSitTarget(). Then extract the UUID via (string)copilot hen can't the filter use (string)copilot to hear only myself or the copilot? The second part of my filter is where I am stumbling with this ... SL compiler isn't very helpful. What would be the structure in the filter? I think that is what I need help with if my thought process will work. listen(integer channel, string name, key id, string message) { if(llGetOwnerKey(id) == llGetOwner() || * once I have the UUID*) Link to comment Share on other sites More sharing options...
Ron Khondji Posted February 27, 2012 Share Posted February 27, 2012 If the copilot sits on a childprim that´s also attached to you, you should be able to use llAvatarOnLinkSitTarget() to get the key. You can even use llLinkSitTarget() to set the copilots seat from the script in the rootprim. There´s no need for a second script in the childprim. Link to comment Share on other sites More sharing options...
DoteDote Edison Posted February 28, 2012 Share Posted February 28, 2012 Awesome, more new functions. Maybe once I finally finish Skyrim, SpaceChem and a few other games that Steam sucked me into, I'll head back to SL and play with all the fancy new functions... barring more Steam sales. Ah, so the copilot sits on a vehicle seat, and you use whichever method works to send the copilot avatar UUID to an object attached to your avatar. That object needs to receive commands from both your HUD and the HUD worn by the copilot. All that's left to do is test if the hud owner is equal to either you OR the copilot. Assuming you've stored the copilot's UUID in a global variable, try this in your listen event: key hudOwner = llGetOwnerKey(id); if ((hudOwner == llGetOwner()) || (hudOwner == copilot)) { //process command } Link to comment Share on other sites More sharing options...
Ralph Honi Posted February 28, 2012 Author Share Posted February 28, 2012 Great! that is the part where I was stumbling ... the compiler offers no help other than to tell you you did it wrong. Thanks again Dote! Link to comment Share on other sites More sharing options...
Recommended Posts
Please take a moment to consider if this thread is worth bumping.
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now