Low lag communication

I'm trying to set up a communication link between multiple prims, and make it as low prim but easy to set up as possible.

The idea I'm working on it a lighting system where you have a light switch to control certain lights (still keeping within the SL light limitations). The simple way would be for the light switch to be touch controlled and when it runs to broadcast a message on a set channel. All the light prims would listen for the message, and when they get it, toggle the lights on or off.

Using this idea, it would be simple enough to program multiple sets of lights through menus or chat configs, to that you can have more than one set of lights in the same area.

The problem that i forsee is that using this setup would require each and every light to be running a listen script constantly, which would lag a system bad.

I've thought about trying to design it so that the light switch will generate a touch command on each light, but for one thing, i don't know if that's possible, and second, it would make it very difficult to program the switch to the lights (would probably have to code the UUID for each prim or something like that)

Does anyone have any ideas on this? I've been trying to build the plans in my head for weeks now ...

A listen on channel 0 produces far more lag than say, a negative channel. The software would only need to scan for that channel's listeners when something is said on that channel.

So if i script to use say, channel 2895, the only time the listen scripts would lag the system would be if anyone (meaning any light switches in the sim) issues a command, and since the scripts would be very short ones (long enough to toggle the light setting) it would only lag the system for no more than a second?

I did a system similar to this a while back - and used sensor instead of listen.

What you do is have a round switch ( like a dimmer )

You touch it and select your light intensity - or whatever - and the switch rotates to a new position ( still parrallel to the wall ).

All the lights have to do then is a sensor for the object name - check it is owned by the correct person and adjust their intensity to match the rotation ( 0 = off 1 = on etc )

You can tweek the system by adjusting how often the lights do a single sensor ping by using the timer and can make it so that the lights always respond to the nearest switch owned by you.

If you can live with a spherical light switch you can also use all of the other rotation axis to control other things as well ( eg RGB with R,G & B assigned to individual axis )

It worked quite well and is being used in a number of commercial houses now

( Of course you are limited to the light being within 96m of the switch )

Use heavily filtered listens on a negative channel.
Also, consider having your light automatically switch on for SL Night and switch off for SL day.

Interesting idea ... probably a bit more detailed than what i needed ... my basic idea is to have an ability to have overlapping lights, like long flourescent tubes (A2 below) on the ceiling of a room, and small accent lights (A1 below) on the sides, but with each having seperate controls (S1 and S2), kind of like this:

A1 A1

A1 A2 A2 A1

A1 A1

S1 S2

I really think the chat option would work best, and most likely the 20 meter talk range would work ... shout is what, 90 meters or something?

llShout is 100m radius.

I'm pretty sure that a listener on a non-zero channel will cause a lot less lag than a repeating sensor will.

Thats why i said put a sensor "ping" ( ie single sensor ) on a timer - not llSensorRepeat

( 1 sensor every 3 minutes or so cannot possibly be as intensive as a constant listen )

However, timers are themselves laggy as well. Any type of communication between object will cause lag, it's just a matter of finding the right combination of what is the least. I would suggest a negative chat channel, and if your really worried about lag, filter it as was mentioned before.

a single sensor sweep has to do a VAST amount of 3d computation to determine what is or is not in range - essentially against every single entity in the entire sim - potentially thousands of objects.

A listen on a non-zero channel has to do an integer comparison against the channel ID for every message sent.

So, unless there are thousands of messages spoken per time period, I wouldn't be so sure that a Sensor is the better option.

I'd suspect listen hooks are event driven, i.e. they sit in some sim-wide table and as long as there isn't message on channel explicitly involving them, they don't get invoked. In this sense 'constant listen' has very low impact on sim performance. As opposed to sensors which have to perform geometric sweep of area to determine what is placed in their 'scan slice' and then follow up with checks vs all discovered items...

Same project (I went with the integer channel listen approach, and even running it in a high-lag sim has had no negative effects ... particles are a thousand times worse) but a new issue has cropped up. Using the 20 meter talk range still has the potential to trigger objects that the user doesn't want to trigger. So what I want to do is have the user pick a cipher (1 to 5, nothing big) on rez of the prim, and then it saves that key as an integer in the script. The best way I can find to do this is through the llDialog script, and when I link it to a touch command it works perfectly, but when I try to put it in an on_rez or state default script, it just ignores the script. Here's what I have so far, can anyone help out with it?

CHANNEL = 2894;
list MENU_MAIN = ["5", "6", "Ping All", "1", "2", "3"];
integer LIGHT_KEY = 1;

default
{
    state_entry()
    {
        llDialog(llDetectedKey(0), "Please select which key this switch is running from", MENU_MAIN, CHANNEL);
    }

    touch_start(integer total_number)
    {
        llDialog(llDetectedKey(0), "Please select which key this switch is running from", MENU_MAIN, CHANNEL);
    }
}

Maybe you should define the protocol used in a bit more detail?

What other objects are triggered?
Are you sending on/off???

If it's part of a system, do not just send a blind "on","off", "hide","unhide" but encapsulate with some identifier of your system.

Like the message "MaidHeahter_LightningSystemN" and "MaidHeahter_LightningSystemFF". Chances will be very low other objects using the same channel, reacting to the same messagesystem. You only need to know how to combine strings in the switch and to split them in the receivers.

Or even better, make your objects smarter. Make lights which turn on automatically at night, doors which open automatically when collided with or touched, windows which tint when touched, and put in a white list access system so that only you and your friends can control things.

Also consider using states and better filters on your listeners.

That is also what I'd consider protocol definition...

- Lights on automatically? Why? If there is no one there no need to have a script check day/night every once in a while...
- Collision doors? Sensors (repeat or timer) cause lag if not programmed well.

In this case it's clearly a switch that need to communicate with other objects over distance and they're not linked. SensorRepeat is more expensive in terms of cpu cycles then listening on a negative based hash channel....

*edited to fix damn typo's

That's because llDetected... functions only work in events during which something actually gets detected (sensor events, touch events etc)

Incidentally though, you don't need user to pick any codes if you use llDialog -- just open the listen channel after dialog is shown to user, and shut it after the command is received (or if enough time passes to presume user cancelled the dialog box)

There's some more discussion on close range objects in thread here:

/54/51/124125/1.html#post1174095

But using the collision_start() event doesn't require a sensor and could be used to trigger lightswitches, doors etc.

This event also works fine in my doors to trigger opening.

Ofcourse... Bump your head into the lightswitch....
Because that's wat we're talking about here...
For doors, I agree. but not for other small innate objects.

But then again... bumping ones head to activate... I bet the touch_start would be easier...

all kidding aside, I failed to see you mentioned it with doors only

And even then, there would still be a command to go out from the lightswitch to the lights. This will cause lag no matter how it's done, and the llListen option seems to be the least dangerous. As to why I don't filter it more is because it's designed to be used in public areas, as well as the fact that I'm going to be selling it and I want to make sure that no one else has any problems with using it.

The whole mess with the llDialog is because I can see issues with lights too close to each other. For instance, with the house that I'm testing this in, I have two lights and a switch in the bedroom, but 15 meters away there's 3 lights that I want to put into the kitchen. I can code them by hand to have each let listen for a different key phrase (and no, I'm not using something like on, off or something basic like that) but hand coding won't work well for something being sold. What I want is for whenever a light or switch is rezzed (or the script is reset), it will ask what cipher to use, and give the user a choice of five different ciphers. Bu doing this, the entire system will be enclosed in one script for each object, and there won't be any cross-talk between them.

I have the whole plan worked out in my head, except that I haven't gotten a way worked out to run the llDialog command in the on_rez or state_default settings. I can't find a valid value to put in the key argument.

How about llGetOwner() ? The key argument is the key of the avatar you want the dialog to be shown to.

Use the random function to generate your llDialog command channel. Values could range from negative 2 billion to positive 2 billion. Works for me, but I am not able to access my scripts right now.

I am officially an idiot. that was exactly what I needed, since the dialog only runs once (on script reset, which only the owner can do). I think that should take care of all the problems. Thank you very much Angela

Well any NORMAL scripting engine that would be true. But sadly not for LSL.

Listens on a non zero channel and even link listens produce a constant and significant amounf of sim lag, even if they are never activated. Hell a script with nothing in it other than a start state also produce a constant lag.

Now setting up a small number of listens or link listens is not so bad. But if you have ever had someone come into your sim with a 500 link message color changing dragon you will notice your sim script time jump from 3ms to 10ms instantly and sustain that level until they leave. All due to hundreds of event handlers that SHOULD NEVER BE CALLED and yet.. apparently are.

So no, nothing is free, everything costs and the minimum cost is rather large. My motto on using scritps at all is "make it count". Every script should be a significant addition to your sim or parcel, or just don't bother.

Though yes for a 5 listen script group the constant sim lag will be far less than even the occasional sensor sweep which can take upt to 0.2ms to complete.

Farallon