HUD and in world object private communication

[Robin Mapp]

Hi all,

Need some help after racking my brain on this one. I have developed a Hud that I need to talk to an in world object via chat, I have successfully developed scripts that communicate effectively on given channels, what I am now wanting to do is to be able to use randomly generated channels that the HUD and object can communicate with without having cross talk from another user with the same HUD.

 

Example would be a prim  attachment where the hud would control actions of the attachment, I also want to make this so the owner may give out HUDs to other users so that they can affect actions on the attachment owners prims.  

I was considering some type of channel registration done by the hud, but realized to do that I needed some way to recognize the attachment of individual avatar and then develop a channel registration process unique to each owner. Like scan for avatars, then scan for the attachment, then randomly assign a unique channel to communicate on.

Any ideas or suggestions would be greatly appreciated.

 

Thanks

[Innula Zenovka]

You could use this, based on an example from the wiki, to generate a predicatable channel that's not likely to collide with anything:

 

privchan = ((integer)("0x"+llGetSubString((string)llGetOwner(),-8,-1)) & 0x3FFFFFFF) ^ 0xBFFFFFFF;

 It might be an idea to add an offset to it (so they talk on privchan +23 or something) so you don't risk it colliding with stuff you own made by people who've had the  the same idea.   

Then, when the hud and the object have established communication and you're sure you're talking to the right thing, you could then have the hud generate a random channel, tell the object what it is,, and then they use llRegionSayTo to chat with each other on the random channel.

[Robin Mapp]

correct me if I am wrong, but won't the GetOwner call change as the HUD Owner and attachment owner may be different? 

[Ela Talaj]

Read my reply to a similar post in here:

http://community.secondlife.com/t5/LSL-Scripting/communicate-information-from-one-script-to-another/m-p/1541533#M11013

 

[Innula Zenovka]

Yeah, but I thought that's what the OP was wanting to do.

If I was mistaken, and anyone's hud can talk to any object, then I guess use an arbitrary common channel for the initial communication and then switch to llRegionSayTo and a random channel.

[Qie Niangao]

Some registration protocol similar to what you describe is probably what you'll end up doing for this. 

For some other application, the HUDs might be rezzed by the object that's going to communicate with them, and the channel set up when that object gets an on_rez event. This is unlikely to be what you want here, however, because it only works on build-enabled land, and also I don't know how you'd control who might grab and wear the rezzed HUDs.

So instead, it might go like this:

When attached, the HUD broadcasts on a known channel.

Listening objects confirm with their owners that they want to accept comms from that HUD. If so, the object sends back a secret, random channel number only to that HUD. (Easiest: use llRegionSayTo(). Before that function existed, llEmail() was the simplest way to keep this secret. )

The HUD confirms with its owner that they want to communicate with that object. If so, comms proceed on the random channel supplied by the object.

You can elaborate the protocol to arbitrary complexity, perhaps with HUDs switching among multiple target objects, objects later revoking access from a specific HUD, objects switching between accepting and ignoring new connection requests, etc.

[Edit to add: With llRegionSayTo(), it's not at all important that the channel remain "secret". It will be, but all the subsequent llRegionSayTo communications will be point-to-point anyway, so they could be over the same channel for everybody. That wasn't the case before the function existed, however.]

[Robin Mapp]

Ela,

your explanation in theory sounds perfect for what I am trying to accomplish, but to be frank, you went 10,000 feet above my head in practice i wouldn't know where to start scripting that!

[Robin Mapp]

I thought of an easier way to do this I think, by having a editable Notecard in the object and HUDs inventory, I should be able to manually set a channel by reading a Notecard line set by the owner, any ideas on how this might be wrote?

[Rolig Loon]

It's kind of a waste to read a notecard for just one value.  If you want the owner to be able to pass a private chat channel number to the script, just tell her to type it in the object's Description field and read it at run time with

integer Chan = (integer) (llGetObjectDesc() );

In general, though, Innula's answer is a straightforward, commonly-used one.  My own shortened version is

integer Chan = (integer) ("0xF" + llGetSubString(llGetOwner(),0,6)) + offset;

where offset can be provided in the object Description field as described above.

[Talia Davidov]

A bit of a side question, not applicable to the ops question

I am going to feel silly for asking this I bet . . . . . but here goes.

Is there a reason why using owners UUID instead of objects UUID?  If I use the object UUID instead of the owner, then each device has its own random channel?  That way if I rez two devices that are exactly the same I won't get cross talk?  Or am I missing something . ..just curious.

Thanks

[Rolig Loon]

---

Talia Davidov wrote:

[...]

Is there a reason why using owners UUID instead of objects UUID?  If I use the object UUID instead of the owner, then each device has its own random channel?  That way if I rez two devices that are exactly the same I won't get cross talk?  Or am I missing something . ..just curious.

Thanks

---

It depends on the application. I'll use the owner's UUID if I want several scripted devices owned by the same person to be able to communicate on a common channel.  I don't need to go to all the trouble of passing a new random channel to each device, since they all know the owner's UUID and can generate the unique channel automatically.  However, if I'm dealing with a situation in which a person may have several devices that shouldn't talk to each other, I'll use an object's UUID.  It's easy enough for an object to create a channel based on its own UUID, and there are several simple ways for other objects to get its UUID and do the same thing.

[Talia Davidov]

ah I get it now.  Thanks

[Nova Convair]

If some of your objects need a communication channel:

Use a method to get an channel from owner UUID and add an offset.
If you want an additional safety use in the listen event:

    listen(integer chan, string name, key id, string msg) {
        if (llGetOwnerKey(id)==llGetOwner()) {
           // do something
        }
    }

If some of your objects need different communication channels you can use the object UUID or just get a random channel. You will need to find a way to pass that channel to other objects for communication.

If some objects of different owners need to communicate: I just set up a randomly choosen fixed channel. The chance of crosstalk is 20 times lower than to win the lottery. If that ever happens in this millennium the message structure will prevent malfunctions. (my only object that needs this communication ignores all messages that do not match the criteria)

You can of course use an encryption if you need to verify the sender.

 

[Qie Niangao]

Oh, hmmm.  I've been assuming this is all going to take place within a sim. If so, llRegionSayTo() is still the right approach (and we have all sorts of ways of knowing who owns what). But if this is something where the HUDs are in other regions, this problem gets harder... especially if the object to which the HUDs are talking can move from sim to sim (and the solution to that gets more complex if the communications are to survive through sim restarts and viewer disconnections).