Scan all over the SIM

Hi all,

I am thinking about SIM-wide scan. If I use sensor, I can only scan within 96 metres. But how can I do a SIM-wide scanning?

Thanks in advance!

The only way to do it is rez one heck of a lot of laggy sensors all over the sim.

Hi Chicken

If you do your maths right you can do it with four sensors that warp around the region.

or one that warps around.... but you'd need to worry about ban lines and object entry

the the height block for each set of scans from 4 positions 64 meters in from the corners is oddly enough +/- 32m from sensor height... so scanning 0-256m height = 16 moves for a single object with LOTS of overlap

triangular search has less overlap, but I'm not doing the math for that

Using either method you also need to take two things into account.

1st you need to make sure that if an area has more then 16 avatars in sensor range that it is hit from more then one sensor/location to get the total.

2nd you need to take the duplicates out of the final list.

But only for a vertical region slightly over 64m at a time.

I've written a scanner that has a sensor in it, and also listens for other objects telling it about av positions via llRegionSay. My next version will probably get rid of the other objects, and use the single scanner to attempt to grab the keys of avs in the sim, then use llGetObjectDetails to track them.

Hopefully, the proposed llGetAvatarKeysOn[Parcel|Region] functions will be added.

Thank you all! It is very kind of you! Your answers help!

I wrote a sensor this did this a while ago, be most careful about moving into 'no script' land, as then your sensor will instantly stop working without any notification. There is a command to check the state of the ground at a given location (for no object entry, no script, etc), it's llScriptDanger or something like that. Make sure you check the land in front of you before each warppos.

Also, now there's llRegionSay, that's easily the best way for your sensor to report back the data. I had to make mine come back to base to report it's findings.

TOOLS USED
_________________________
Sim management tools top scripts.
􀀀 a 90 meter full arc(Pi) agent(avatar) sensor
􀀁 a 10 meter full arc(Pi) agent(avatar) sensor
_________________________

top scipts shows the resource usage of the scripting pool of SIM resources.



scripting pool resources used full useage is 1.0
for the 90 meter sensor you have .013
for the 10 meter sensor you have .0002 useage

once you get down to 10 meters you are pretty much just maintaining the repeat of the sensor(hard to get the data if it's not a sensor repeat).

but at 90 meters all I can say is that you're being bloody greedy if you aren't the owner of the sim. you need to take into consideration that the owner has stuff running, that you're running other scripts as well, and that you have other people in the sim running scripts wouldn't be scanning otherwise.

edit:

the data is from last week. and these sensors did pretty much nothing with the data besides run a for statement with the number of users they detected.

script used:
default
{
state_entry()
{
llSensorRepeat("", "", AGENT, 10 OR 90, PI, .3);
}
sensor(integer numDectected)
{
integer a;
for(a=0; a<= numDectected; ++a)
{
integer b=5;
}
llOwnerSay((string)numDectected);
}
}

I'm not sure how you're deciding on these statistics.. The 'top scripts' in the estate manager shows you total script time in ms, not time out of 1.0. The 'maximum' script time, if you will, or the suggested limit of how much time scripts should use, is a total of 22.0 ms. So really, this means that if it's reporting a time usage of 0.013, it's about 0.05% of your total resources, assuming you don't want to go over 22.0 ms in script time. Generally, the whole sim starts doing a nosedive once the total time (things besides just scripts, can be seen on the debug menu - Ctrl + Shift + 1) goes over 25.0 ms. Also, these statistics are highly dependent on what is happening in the sim at the moment, and the sim hardware itself. Class 5 sims will show significantly faster results than older sims.

shrugs I don't own the sim I just asked the owner for the statistics and was told that it was out of 1 instead of a actual count.

edit: it's still a considerable amount once you start to actually add stuff to the script. instead of just creating a variable over and over.

Like all things its good to know their impact both when designing and running them. I have built a region scanner, with four sensors and a display unit, its average script time for these five units probably runs to about 2.2ms, I say probably, its hard to get definitive figures with the tools LL give us, but I have sat pressing the 'refresh' button repeatedly to try and get meaningful figures out of 'top scripts' to measure this.

How many people know though, that one active sit target (active - someone is sat on it) shows up in the 'top scripts' tool at around 0.4ms. So that shop on a 1024 parcel with two pose stands and three camping chairs in use is going to run pretty close to 2ms on those alone, nevermind whatever else is going on in the region at the time.

I think that's a little skewed. For one thing, you don't even need to keep the sit target script in the object; it's stored in the prim's data once it's set. But assuming they left it in anyway, 0.4s is a little steep, and I have trouble believing that's accurate. Scripts performing the same operation constantly over time won't always show the same result anyway. Changes in events, physics collisions, loading new agents and the like will cause reported time to increase, sometimes drastically, until operation returns to normal. If some poseball scripts are running 2.0 ms, your sim has issues. I'd suggest leaving the mainland, or killing your neighbors.

It's because the object's script time is combined with the script time of agents sitting on it

Curious, has anyone tried using llVolumeDetect with megaprims? P:

I think this has drifted away from the OP's question but I don't have a clue what to call a new thread, 'odd things about LSL/SL'? However, here is a simple test, compare:

1) rez a cube, name it something meaningful, create a new script, put a valid sit target in state entry, save the script, then sit on the cube. Check the script usage time for that object repeatedly until bored.

2) carry out step 1 above until the script is saved, then delete the script, (observe as expected it does not appear in 'top scripts'), sit on the cube, check the script usage time for that object repeatedly until bored. - Yes, it does appear there.

The fact a sit target has been set is not relevant. What matters is whether the object contains a script. If it contains a script (and the avatar is sitting on the prim) then the lag rating (i.e. the time usage rating) will be combined with all scripts in all the avatar's attachments. If the object does not contain a script (and again, the avatar is sitting on it) then all of the attached scripts will be ignored and it wont show up in the list. This is pretty easy to verify if you're an estate manager. Sit on a prim and confirm the prim's name does not show in the list. Now put any script in the prim (just hit the New Script button for the default script will be enough) and the prim will show up in the list. The more attachments you're wearing the higher the value. If you remove the script from the prim then the object will vanish from the list. At least this was the case when I looked into it a few months ago.