Long Distance Communications & Delays

Once I used this teleport system that had a "Request Teleport" system setup to it. This is so if the teleporter is say way up in the sky someone down below can request the teleporter to come back down for transport.

Now, from what I understand is that for a request (call system) to request the object/avatar being teleported at long distances (say like 400 meters up) your only option is to use llEmail(). Am I correct on this?

If this is the case then I may end up having to use router based script e-mail system to get around delaying the main script.

This sound like the case?

If the teleport pad was farther than 100 meters away then yes, shout wouldnt work. If you dont want to use llEmail() then I would suggest setting up 'relays'. I.E prims set every 100 meters that listen for the request and shout it again, on up the chain until the shout finally reaches the pad. I believe this would be much faster than llEmail.

Btw, if you go this route, make sure to put in a sleep after the shout or your relays will be constantly chattering away at each other. I would imagine a sleep of 5 should work nicely.

Just my 2 lindens worth

Why don't you send a link message to a second script, and have that script send the email and incur the delay? Assuming you won't need to send an email again within 20 seconds, this should work fine, and won't delay your main script. If you absolutely need to , you could extend that to say 5 child scripts, and the main script calls each one in turn - that gives you 5 emails per 20 seconds, or on average 1 email every 4 seconds. I doubt the main script would need to react faster than that Like I said, do this only if you absolutely need to, because this will load down the sim as you add more emailing scripts.

hmm

The nice thing about the shouting-relay system is that you don't have to recode your email address if you re-rez something with a new key-id.

I've been wondering about how to avoid the re-shout problem, for a similar situation.

Haven't tried it yet, but I'm thinking that each shouter does:

vector here = llGetPos();
here.x = llRound(here.x); // make it a shorter string
here.y = llRound(here.y);
here.z = llRound(here.z);

string hereS = (string)here;

if(llSubStringIndex(message,hereS) < 0) // we havent touched it yet
{
message = hereS + message;
llShout(RELAY_CHANNEL,message);
}

So it wont reshout a message that it has touched.
Could also use your key, but the string will get so long so quickly.

No, the sleep wouldn't help. Events triggered during a pause or processing are queued, not ignored.

You could set up the listeners so each relay only listens to the two relays adjacent to it. Since this is a 'line' of relays and you're not trying to cover an area, that should be fairly easy to implement, and should work fine. You'd just have to name the objects in sequence, and then you could use your own name to figure out what your neighbor's names are, and ignore messages from anyone else.

Or include the destination's name in the message. So you're relay N, you only respond to messages with your name in them, and when you send on a message you set the destination name in the message to N-1 or N+1 depending on which direction the message is going in.

instead of just using llSleep to create the delay, why not use a different state?

This would add in the delay but the messages wouldn't queue up.

like this:

integer messageChannel = 1;
integer sleepTime = 2;

default {

  on_rez(integer num) {
    llResetScript();
  }

  state_entry() {
    llListen(messageChannel, "", NULL_KEY, "");
  }

  listen(integer channel, string name, key id, string message) {
    llShout(messageChannel, message);
    state delay;
  }

}

state delay {

  state_entry() {
    llSleep(sleepTime);
    state default;
  }

}

Just use llListenControl and toggle off the listen for a second or two, then use it again to reactivate the listen for further messages.

Sleeps and delays in programming are specifically intended for situations like - put it into the oven, wait 10 minutes, take it out.
They are often abused and used out of place, and this practice should be avoided; particularly in an event-driven language like LSL.
I think is your best bet, especially for the teleport system described where the destination name IS the message.

You can build chains of repeaters using different channels.

Say, repeat everything received on channel A onto channel B, and everything heard on B is repeated on A.

your emitter: /A blah => /B blah => /C blah => /D blah => your target

your target: /D answer => /C answer => /B answer => /A answer => your emitter


[Edit]
And then, we might start using Djikstra or OSPF for routing messages

Now that would be fun to do! Just for the hell of it IP router prims no more than 95m apart spread over a few sims. With a few HTTP servers, and some XY_Text browsers. Who need LL to give us HTML-on-prims? We'll do it ourselves, woot

Eeeexcellent

I thought about making little HUD attachments that deploy when clicked and display whatever textures they get sent by a RPC server when clicked some more...

I'll be making a simpler version.

[Edit]
If I could specify an URL for a texture, I'd make a .php script that renders a page into a .png then use this as texture for a prim... effectively bringing HTML-on-prims. Now to make the links clickable it'd require more complex massaging of script, and probably a whole new protocol for telling the prim what parts of the texture is clickable and what to do when it's clicked

I interpreted your message as saying that a delay would work in this case, is that correct? Delays will NOT work in this case, try this script:

default
{
    state_entry()
    {
        llListen(0,"",llGetOwner(),"");
    }

    listen( integer chan, string name, key id, string msg )
    {
        llOwnerSay(msg);
        llSleep(10);
    }
}

And then say two things in quick sucession.

Jesrad, that's an awesome idea. Maybe LaTeX rendering? Wikipedia does it...

No, not what I meant - as you say, that won't work.
It's actually very difficult to come up with a valid use for sleep in LSL - because of two main reasons.

1. LSL is event driven, and does supply us with timers
   
2. Scripted objects in SL exist to be interacted with - pretty much anything they do should be interruptable by an avatar
   

Now every rule does have its exceptions, but in general sleeps only belong in simple systems like a RL security light - those ones with the IR sensors outside your house, that switch on for 30s if someone walks past. Simple, single-threaded processors that do

while (1)
{
  WaitForSensor(); // blocks until IR detects presence
  SwitchOn();
  Sleep(30000);
  SwitchOff();
}

(I realise these things are ususally implemented in hardware - this is just analogy)
In LSL, however, during that 30s sleep, someone may want to touch/talk to the light to change its config, or whatever, so a Timer should be used rather than a Sleep.

I might go with the relay system myself, but am using courier bullets at the moment to reach a space elevator. Communication is transferred to courier bullet which then zips up to the elevator and delivers the message. Looks kinda cool, but not enough to put up with the intermittent problems encountered. But I'll miss that "whoosh, there goes the communique!"

The nice thing with using a courier though is you've got a lot of freedom in the routes-- not limited to prelaid tracks.

I'm a complete noob but would it not be possible to propell the first in the relay untill It got within 100m of the teleport, then it shouts?

Genius.