communicate information from one script to another

[ender Alchemi]

Hi -

I am trying to control a non linked prim via a centrally located control panel. I am using llRegionsay and things are working great. The controller snippet is:

touch_start(integer total_number)
    {
        if (llDetectedKey(0) == llGetOwner())
        {
            llSay(0, "Owner Touched.");
            llRegionSay(-4000, "go");
        }
        else
        {
            llSay(0, "You are not the owner!");

 

And the prim being controlled snippit is:

integer iChan = -4000;
integer iHndl;      // the listen_handler

default
{
    state_entry()
    {
        iHndl = llListen(iChan, "", "", "" );
    }

    listen(integer channel, string name, key id, string message)
    {
        if(channel == iChan)

 

I would like to be able to set many sets of these out - but would like to avoid them all being on the same channel - is there a way to set the talk / listen channel in the two seperate scripts via a menu or something? This will be used by purchasers of the final product and I would like to avoid them having to get into the script itself to change numbers.

Hope that was a clear enough question! Not really sure how to control two seperate scripts in two seperate unlinked objects.

Thanks in advance for any insights!

 

[Rolig Loon]

One typical solution is to use a communication channel that is based on the owner's UUID.  You can do that in many ways.  My favorite is to write

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

where offset is an integer.  If all scripted objects that should communicate to each other have the same definition in them, they will listen to each other but not to similar objects owned by someone else.  They also won't listen to other objects owned by the same person but using a different offset.  For convenience, you could have your script read the offset from your object's Description field, perhaps.  That way you wouldn't need to dig around in the script itself if you decided to change it.

This is not a "secure" system.  It's not meant to be a secret code, just a reasonably unique large negative number to do the job.Just remember to put a changed event in your script that resets when the object changes ownership.

[Innula Zenovka]

In addition to Rolig's method, if you want to ensure the prims only respond to commands from their owner's control panel, then you could test for this in the listen event.   Like this:

listen(integer channel, string name, key id, string message)	{		if(llGetOwnerKey(id)== llGetOwner()){			//do stuff		}	}

 

[Miranda Umino]

* If you have only one listening object for one talking object , you should give up llRegionSay and use llRegionSayTo .

So, you won t  multicast but you will unicast your messages .

*  Think you may  add some other filters to the listener . 

In your instance , your talking object send only the message "go" , but your listening object listens all kind of messages from any objects .

You could filter your listener by key . Of course the key of the sender may change .. But you may update  the filtered key in your listener script by different ways

If you don t know how to refresh the keys  , you could filter your listener by message . Indeen , in your instance , you don t send any varaibale informations in your messages ( as a position or anaything variable . You send just a lind of signal , So use the filter by message

For instance , if you have many sets of pairs , you could have

talker1 : sends message go1

talker2 : sends message go2

talker3 : sends message go3

listener1 : listens by llListen(iChan, "", "", "go1" );

listener2 : listens by llListen(iChan, "", "", "go2" );

listener3 : listens by llListen(iChan, "", "", "go3" );

* Think to send a message with different parts  by llDumpList2String and llParseString2List.

So you cound sent other informations to help your listening object to filter better ( a passphrase known only by the communicating objects for instance )

* Think to  use unique identifiers and to communicate them inside the me messages

You may use the funtion llGenerateKey for this ( even if the function doesn t appear in red in teh editor , it s known by the compiler )

[Ela Talaj]

An example of a simple handshake protocol in a star-topology network (which is what yours is) would be as follows:

On control unit restart it broadcasts a "hello" message via whatever common channel. Receiving controlled nodes broadcast back its own "hello" on the same channel. The control unit makes a list of responded nodes ids and now can select from that list to send via llRegionSayTo. The nodes now know the control unit id so can send via llRegionSayTo too.

On a controlled node restart it broadcasts a "hello" to the control node via comm. channel. Control node adds it to the list and sends back an "ack[nowledgement]" so both know each other ids in this case too.

There are a couple of holes in this protocol, for instance the control node is not aware of a controlled node de-rez, but there are several ways to handle that, and in most cases it works fine anyways.