LSL script - simple lag reductions

I was recently faced with building a security system to cover a 1/2 sim. I found some REAL ODD stuff, that somehow killed every approach from being really useful, neat and so on. First comes a brief background to what I mean - and the sugegstions are at the end, if you like to skip right to it.

Background:
Here are my ideas, and all the stuff I ran into...

Idea 1:
Multiple sensoring objects, placed around the place. Communicate via link messages. Advantage: Low lag. Disadvantage: Impossible. Liked objects to far from each other... You'd have to blow a dozen prims on building 10m long wire-prims to connect it all. Not neat.

Idea 2:
Multiple sensoring objects, placed around the place. Communicate via shouts. Much laggier. Much harder to make secure when trying to avoid other people sending false messages. Possible, but very annoying to do, and laggier. Not neat.

Idea 3:
Create a roaming robot. One single prim - that flies around with llMoveToTarget() and scans at certain coordinates. Advantages: All communications problems avoided - by eliminationg the need for it. Impossible! You can only use llMoveToTarget() for distances of, like 50 meters... If you want to fly all over - you need to repeat shorter move commands over and over and over - which lags the place unnecessarily. Not neat.

Idea 4:
Same robot - but non-physical. Just use llSetPrimitiveParams() to teleport around! Impossible! You can only move a prim 10 meters! Instead, you must repeat the move a dozen times like this, by "spamming" orders into the llSetPrimitiveParams() function:

warpPos( vector destpos ) 
{   //R&D by Keknehv Psaltery, 05/25/2006
    //with a little pokeing by Strife, and a bit more
    //some more munging by Talarus Luan
    //Final cleanup by Keknehv Psaltery
    // Compute the number of jumps necessary
    integer jumps = (integer)(llVecDist(destpos, llGetPos()) / 10.0) + 1;
    // Try and avoid stack/heap collisions
    if (jumps > 100 )
        jumps = 100;    //  1km should be plenty
    list rules = [ PRIM_POSITION, destpos ];  //The start for the rules list
    integer count = 1;
    while ( ( count = count << 1 ) < jumps)
        rules = (rules=[]) + rules + rules;   //should tighten memory use.
    llSetPrimitiveParams( rules + llList2List( rules, (count - jumps) << 1, count) );
}

That ought to increase server load unnecessarily too, don'tcha think? Not neat.

Idea 5:
Ok... Idea 5 - and this was something I had given up on when idea 3 fell through. Wouldn't it be neat if the bot flew up to trespassers and introduced itself? It's possible you know - by adapting the simplest of "flying following pet"-scripts.

It's also dumb as hell when you think about it... I was expecting that once my llSensor() sweep detected an avatar and I got the key - there would be a low-lag llGetAvatarPos(key) function so I could chase it down - but there isn't! Not even for use over MY land! Instead, you have to do what all the following-pet scripts do - spam out llSensorRepeats at high rate. That is SO not good.



Ok. Suggestions:

1) Raise the range of llMoveToTarget() to 256m. Let it work all over a sim. Good: Reduce repetetive scripts and reduce lag. Bad: *shrug* We can already do it. It just eats CPU.

2) Raise the range of llSetPrimitiveParams() to 256m. Let it work all over a sim. Good: Reduce repetetive scripts and reduce lag. Bad: *shrug* We can already do it. It just eats CPU.

3) Add llGetAvatarPos(key avatar) and return a vector. Good: Less need for very laggy sensor sweeps in all kinds of following. Bad: *shrug* We can already do it. It just eats *lots* of CPU.

4) Raise effective distance of linking objects together. Good effects: Safe, effective, and low-lag communications. Bad: Not sure here. I just have no clue. Is it bad somehow? You should still be able to do this with invisible phantom prims - yeah? It would just need less prims.

----

Just some thoughts. All these things struck me as SO odd. It's like LSL was *designed* to make people create laggy fixes for linguistical shortcomings. I think these issues need to be adressed (along with a million others no doubt, but these are the ones I have found.)

I guess I could jsut be failing to see a bigger picture here. Is there some reason for all these limits that just seem,... inconvenient? Is it just leftover bad LSL, or is this all intentional?

Ariya Draken

llDetectedPos is what your looking for in the sensor event, it will return the vector position of the object/avatar (depends on what you are scanning for of course). Thats how flying following pets detect the avatar they follow. As for the rest Idea 4 is probably not _that_ laggy, why not actually test your assumptions and quantify how big that server load increase will be. I'd guess it's less load than actually looping the object through llSetPos's to get it to the destination. Anyhow, this is more of a scripting post than a current version feedback in my opinion, perhaps you'd see a better response if you posed your question in the Scripting Tips forum.

I think you may be overly concerned about the lag produced by some of your options, Especially the llMoveToTarget() OPTION. Your bot is already running a llSensorRepeat, presumably, so update the target inside the sensor or no_sensor event. That doesn't cost too much.

For ideas 1 & 2, communication to an off-world database would be great. You could even monitor and manage the security system without being in SL. HttpRequest could replace whatever your Link Message was doing, and has the added benefit of automatic return data.

Yes, I know how to use llDetectPos. How do you think I made my robot work? Magic? You have to admit being forced to blast out a sensor sweep every time i want the exact location is kind of dumb. I know he's in range. I know he's over my land. I know his name, his key - why can't I just get his position straight up? Is there a reason I have to spam out sensor sweeps nedlessly? Especially over long ranges... Spamming out 96m sweeps is so not good - even when limited to sensing for a single Avatar.

Besides... How am I supposed to quantify my script's server load? I have no idea how much I'm loading the servers, and as far as I know I have no access to any such tools. This would be one of the reasons I'm extra careful.

This post is about scripting - but it's very much a version feedback. I'm not asking for tips, help or sharing my knowledge - I'm asking "why do these functions have such silly limitations, when the limits lag the servers unnecessarily?"



Well, when chasing a target down - I would be running a sensor repeat (see Idea 5 for that one...) But the rest of the time I would not be running sensor repeats, but rather make a sweep every 10 seconds to looks for intruders. In the meantime - I'd still move via llMoveToTarget over and over and over, to fly the bot between the waypoints.




Not sure a solution like this would prove fast enough most of the time. Besides - it requires access to an off-world database - something I do not have, or really want.


---------------


Thanks for the attempts at helping me out here. None of the replies though, are actually aimed at the point I was trying to make here - since I'm not looking for help.

Here's the point again:

Why are some functions as if designed to be repeat-spammed - instead of "fixed" once and for all? Why do I have to spam sensor sweeps just to get a nearby AV's <x,y,z>? It's overkill - like hunting bunny-wabbits with thermonuclear weapons. Why do all object movements have to be repeat-spammed - instead of just letting us do the movement in one single operation? None of this makes any sense to me.

Ariya Draken


PS
For the record, with the servers acting they way they are - never advice anyone "I think you may be overly concerned about the lag produced by some of your options." I think it's when people stop being concerned that the shit hits the proverbial fan.

Why are some functions as if designed to be repeat-spammed - instead of "fixed" once and for all? Why do I have to spam sensor sweeps just to get a nearby AV's <x,y,z>? [...]

The way sensors work was originally designed to avoid load on the sim, by "batching" requests for information... you would perform the sensor and then perform a series of information requests on the results that returned cached data from script-local storage (outside the 16k of the script's data, but still close enough to be efficient). As time went on and people started using sensors in unexpected ways this decision turned out less than optimal.

There is apparently a project to provide a set of parcel- and estate- wide calls to get information about agents and objects on the land that's better suited to the needs of security and traffic scripts than llSensor. You might want to ask what its status is in the Answers forum.

What about this: (I don't know if possible Im just thinking and writing without too much "brain preprocessing".

You place sensor objects at about 96 meters of distance one from the other. You also have a Central object to colect the data and make whatever you need to do with the info.

1 - Sensor 5 detects a person.
2 - Sensor 5 saves the data in a external MySQL database using llHTTPRequest
3 - Sensor 5 rez a "bullet" with great velocity in direction to the Central Object.
4 - The Central object detects the bullet via llSensor or with the collition.
5 - Central Objects uses llHTTPRequest and http_response to request the data from the external database.

I think this may have some time between the sensing and the action becose of the https communications, but there is no need for communications between objects, you can use the less objects amount and you can use the database as a permanent historical archive.

Is this a crazy idea? I need to quit with the wine? Is this a nice smilie ?

This is *very* expensive... rezzing objects and operating the physics engine are both very expensive operations. Using llShout() would be orders of magnitude more efficient.

// in the slave
list old;

sensor(integer n)
{
  integer i;
  list new = [];
  integer change = llGetListLength(old) != n*2;
  for(i = 0; i < n; i++)
  {
    vector pos = llDetectedPos(i);
    if(llList2Vector(old,i*2+1) != pos)
      change = 1;
    new += [llDetectedKey(i),pos];
  }
  if(!change) return;
  old=new;
  llShout(11018,llList2CSV(new));
}

Now you'll only get a shout when the slave sensors see a change. For a full sim you will need a maximum of 4 sensor objects and 3 relay objects, for a maximum of 7 shouts a second WHEN there are moving agents in all four quadrants of the sim.