Need object communication as far as 500meters.

I need a way to have a common variable or pass the data in it between two objects, which are 200 to 500 meters apart. It will sort of act like a remote control. I want anyone to be able to touch a prim in a Skybox and have a prim on the ground change texture in response. The object would be in the same sim.

I suspect this can’t be done because I have not seen an example of something in SL responding remotely.

llEmail(), llGetnextEmail(), methinks...

Or do a simple search here in the forum .... This topic has come up several times

Till Stirling

3 easy ways off the top of my head

1) Email, per Jillian, will need to be setup on a timer.

2) Have the script change the name of the control object and use llKey2Name (again on a timer) and depending on the name, do a specified action in the controlled object. Both have to be in the same sim, and not really as elegant as email, but maybe just a bit more trustworthy (if the info to be passed is pretty small).

3) Multiple relays that listen on a hdiden channel and shout it back out. Need to code it so you don't get reverb but not too hard. Course, this is not a preferred solution.

The first 2 solutions requrie a timer, you will need to find an appropriate balance between sim resources and reaction time of the controlled object. If it updates in the next minute is that fast enough? Next 15 seconds? 0.1 seconds would likely be overkill.

To avoid reverb, you could have each repeater shout a new phrase that doesn't match what they listen for. That way they pass along the message phone game style, but don't go nuts when they hear the next repeater say what they are listening for.

Control: Says 'DO 5' on channel 55
Repeater1: Says 'START 5' on channel 55 when it hears 'DO 5'
Repeater2: Says 'INIT 5' on channel 55 when it hears 'START5'
Target: Does whatever 'DO 5' is supposed to do.

You can also try channel hopping:

Control: Says 'DO 5' on channel 55
Repeater1: Says 'DO 5' on channel 5 while listening for 'DO 5' on channel 55
Repeater2: Says 'DO 5' on channel 15 while listening for 'DO 5' on channel 5
Target: Does whatever 'DO 5' is supposed to do.

While this method may be prim count heavy, you could make up for it by having the repeaters visible, and when they get a command, have them flash, or glow, or change colors for neat effects.

Aha but I did do a simple search and I didn't find what I wanted. I also had read the wiki on communication. (If only the forum search would work as well as Google.)

Jillian, I didn't notice that each object effectivly had it's own email address. The llEmail() function may be suitable for my needs. All I need to do is toggle an action on a receiving object and it does not need to acknoledge receipt or return anything to the sender. A 15 second, (30 max), delay should be aceptable.

I've thought about dasiy channing the message through repeaters. It would be fast but it does require a prim for each shout distance and that would be a lot of prims to string over a 400 to 500 meter distance.

5 prims is a lot?

It sounds like it will be on your own land, so having permanent phanton repeaters could benefit you in the long run. if you connect them to an auto update script you could end up with a controllable,upgradeable communications/sensor network

He might think he should link them all and use llMessageLinked. Just place each around 100m and let them shout!

The “Shout” method seems easiest to code. I would use three chat channels alternating the use of them as I go down the string of buoys. Remember, this only needs to communicate in one direction.

I took a Listen example from the tutorial and modified it. If I understand how the code works the following should receive a message on channel 22 and then “Shout” the message out on channel 23.

default
{
state_entry()
{
llListen( 22, "", NULL_KEY, "" );
}

listen( integer channel, string name, key id, string message );
{
llShout( 23, message );
}
}

(Arg!! the forum removed the leading spaces)

This would be in the 1 of 3 object. Code with llListen set to channel 23 and llShout set to 24 would be in object 2 of 3. Code with llListen set to channel 24 and llShout set to 22 would be in object 3 of 3. I would set these three to cover about 200 to 300 meters. Of course whatever objects need to talk over this relay will be set to use the right channel. I imagine code could be added so they set the channel them selves but this is a one-time setup.

One more question. How will this affect the sim performance? The messages will not be very frequent.

What would you like to compare this to? This will affect the sim performace less than three ppl are there.

When I did shout relays ages ago, I thought of using multiple channels for upstream and donwstream, but I decdied to avoid it for lag concerns (default stance, listens are usually bad, course whether it would really matter in this case is a trickier issue).

My solution was to prepend a code to each message, signalling if the message was going upstream or downstream and which repeater it was coming from. I don't rememeber the exact details, I was lazy about it and the first few iterations got echos, but I eventually got it right so it can be done.

I figured an extra bit of string processing was better than multiple listens per object. But, YMMV.

Is there a distance limit on llRemoteLoadScriptPin, besides the same-sim requirement? Any reason why this couldn't be used to send a texture-change script to the target object with start_param specifying the desired texture?

Okay, I tested long distance communications with 3 prims basically.
It was capable of pretty much any distance but was not the quickest form of communication.

For 500m it might not be that bad.
It worked like this:

One prim was the starting point at say A(0m) and the other end is at B(500m) on the same axis.
A comm prim was given a message on one channel and then moved from point A to point B. Once it reached point B, or was within a 100m range of point B, it shouted the message.
Point B could then shout the response and the comm prim moved back to point A, or within 100m, and shouted the reply.
It works well, uses 3 listen channels and for a 500m distance the comm prim would only have to move about 300m in either direction.
The other thing I did was rez the comm prim from either point to start the communications and then let it die when it was done. That way it doesn't need to sit there listening the whole time.

I like this idea. BTW, what about sending script by llRemoteLoadScriptPin to let them listen. Of course after that you can send no listen script. I wonder if there is little difference between rezzing objects and copying scripts.

Seagel,

You could load the scripts that way....but you are limited to the same sim.
With the moving communications prim in between 2 points you have almost no distance limits.
The only thing slowing you down would be the amount of time it takes to travel in between points.
If you are only sending data in the same sim then the llRemoteLoadScriptPin is probably much faster.

The original poster said, "The object would be in the same sim." And "A 15 second, (30 max), delay should be aceptable", too. So what I just though was how to remove listen while they didn't comunicate each other.
I've made a color change script for some clothes. The clothes are separate each parts. And the cliant hoped she could use the dialog box. I thought it was nonsense that I used llMessageLinked even though the dialog box could speak to every parts. But I could not help but leave llListen passive in each parts.
So I just thought that it might be useful to remove llListen when I used llRemoteLoadScriptPin. But also wonder if we should be so nervous.

There shouldn't be any need for listens if all communication is done via llRemoteLoadScriptPin in the manner I suggested previously. Since we know both objects will be in the same sim, I really can't imagine a simpler, faster, and more efficient solution than that.

The llRemoteLoadScriptPin command sounds like a great idea. I would only need to send two different scripts depending on if an agent is occupying a skybox or not. The only thing is where are the scripts to be sent being kept. They must be independent of my inventory. This system is being built for someone else. I looked up llRemoteLoadScriptPin in the wiki and found the explanation to be difficult to follow as most of them are. I need to see how it is used in real code. I am no noob to the concepts of programming. But I’m only vaguely familiar with C+ code. Could someone better explain how to use llRemoteLoadScriptPin? The amount of scripting time I’ve done in SL is something like 15 hrs. So I’m an infant at SL coding.

I got the Shout method to work last night. If I can get code using llRemoteLoadScriptPin to function like the Shout code I wrote, it would eliminate the need for shouting and the relays.

Thanks to everyone helping me with this. When I have settled on what I will use I will post a comment here to let you know.

That seems to be the best method for communicating in the same sim.

I am currently implementing it as a product updater, so I have done some testing.
Here is how it works:

All of the target prims that will be receiving the scripts must call this function before the remote load will work llSetRemoteScriptAccessPin(integer pin_number).

// This script goes in the target prims
integer access_pin = 150792;

default
{
       on_rez(integer pass_param)
       {
              // Setting the remote access pin
              llSetRemoteScriptAccessPin(access_pin);

              // If all goes well we should receive script "my_remote_script"
              // and get a pass param of 42
       }
}

Basically, you are setting the password on all of the targets.

When you are ready to load the script from the source prim you call this function:
llRemoteLoadScriptPin(key target, string name, integer pin, integer running, integer start_param)

string pass_script = "my_remote_script";
integer pass_param = 42;
integer remote_pin = 150792;
key target1_key = "4e25d408-5541-1d34-c3a3-33238add67b9";

default
{
       touch_start(integer total_number)
       {
              // Start to pass the script. You will need all of the keys of
              // your target prims.
              // I would use a list of the stored keys and go through them 
              // with a while or for next loop.
              //  But for now we will just do one.
              llRemoteLoadScriptPin(target1_key, pass_script,remote_pin,TRUE,pass_param);
       }

} 

In the "my_remote_script" you will need this code to get the parameter of 42 that was passed remotely:

default
{
       state_entry()
       {
              // Used to get the passed parameter from the remote script
              integer pass_param = llGetStartParameter();
       }
}

Hope that helps

So where is the remote script kept, in the inventory of the owner? Also I assume the pass_param can be a different number.

The remote script is in a prim that would be in the same sim as the targets.
One prim holds all of the scripts to be passed, like a server, and hands them out to the targets.

All the target prims need is the script to set the remote access pin really.

You could also just use the give inventory function. The only difference being that you get to pass a parameter with this and set the status of the script when it gets into the target's inventory.

Yes, the pass param can be any integer. I just picked a random number.

Note that while this is fast for passing one parameter to one prim, it delays the calling script 3 seconds. This may be a problem, one workaround would be to have 10 or so identical scripts that each take responsibility for passing one message in turn.

// Script must be named with its id, 0, 1, 2, ... 9
integer my_id;
integer next_id;

default
{
  state_entry()
  {
    my_id = (integer)llGetScriptName();
    next_id = my_id + 1;
    if(next_id > 9) next_id = 0;

    if(my_id == 0) state responsible;
    state waiting;
  }
}

state waiting
{
  link_message(integer from, integer num, string message, key id)
  {
    if(id==NULL_KEY) // if no target, we're switching scripts
    {
      if(num == my_id)
        state responsible;
    }
  }
  on_rez(integer param)
  {
    llResetScript();
  }
}

state responsible
{
  link_message(integer from, integer num, string message, key id)
  {
    if(id==NULL_KEY) // not target, if switching to someone else go back on the bench
    {
      if(num != my_id) state waiting;
      return;
    }
    llMessageLinked(LINK_SET,next_id,"tag",NULL_KEY);
    lllRemoteLoadScriptPin(id,message,remote_pin,TRUE,num);
    state waiting;
  }

  on_rez(integer param)
  {
    llResetScript();
  }
}

To use, llMessageLinked(LINK_SET,parameter,script_name,target_prim);.

Actually, llGiveInventory would not work for something like this. When giving a script, llGiveInventory always sets it to non-running in the target object. The only way to send a running script is with llRemoteLoadScriptPin.

(This is to make clear what I'm tring to achive.)


“on_rez”, this sounds like a one shot event. I may not have explained well enough what is the purpose of all this. Say you have a club with a Skybox for private use by anyone in the club. There have been times when a club member couple TPs to the Skybox only to embarrassingly fine out it is already occupied and now has to apologize for the intrusion and leave. I want an indicator by the TP to so ppl will know if someone is or is not in the Skybox. And I want this indicator to not require any action on the part of a user. This system needs to update the indicator, “flag”, continually at reasonable intervals. It would be ok to have a 10 second delay but I think 20 seconds would be too long and a rate faster than 1 sec is a wast of sim time.

Now I have a Shout method that works, it just needs repeaters for every 90 meters past the first 90. My so-called “Flag” changes texture, which has a printed message on it with a colored background, for the two state of the Skybox, (room in use, room is ready). There are multiple Skyboxes, which are TPed to from the same base location on the ground and having a “Flag” for each is desirable. The repeaters would be shared among the transmitters and recivers of all the Skyboxes.

I really really appreciate the help but unless I’m wrong I think some of you are making this harder than it needs to be. Now that you know more about what I’m really after you would know if your suggestion is appropriate.