Jump to content

Region Sensor


Turokhan Legion
 Share

You are about to reply to a thread that has been inactive for 2167 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Hi Guys,

This ones been baffling me for weeks now and was wondering if anyone could shed some light.

I am writing a script to teleport to an avatar or at a basic level, report the agents in the region.

llSensor has a maximum range of 96m but i have seen devices that can display agent names at any position, i.e. if i am at 3500m, i can see my friend at 21m.

Thanks in advance :)

Link to comment
Share on other sites

First you have to define what you mean by "devices" - viewers can do that - LSL, as you realized can't - at least not in a straight forward way. Apart from the 96m restriction, there is the 16 reported units restriction on top. You can, to a certain degree - avoid these restrictions by using more than o sensor. If you have them all over the sim so that the complete sim is within the range of at last 1 sensor, you can cover the complete sim.

Link to comment
Share on other sites

Most of those HUDs and devices have a 'scan' option.  That is what initially populates the list.  It may also do it periodically on its own.

Once the object HAS that list, it can request data on those agents/objects regardless of how far up they might be.  And if they leave the sim, then (after a short while) the requests will start returning null or other signal values, so the script knows they've left the area.

 

During a 'scan', it may rez a temp object at various heights/positions.  Such a scanning object could be very simple.  It rezzes, runs a scan, saves what it finds, moves up ~150m, repeats.  Does this as needed (say, to a max of 4096m height), including going DOWN if the start position it rezzes at is greater than llGround() by at least half the sensor range.  Then once it finishes it's run (which won't take long, unless the sim is VERY crowded) it sends the results to the main object via a llRegionSay()  (now we can use llRegionSayTo() to be more efficient) and then deletes itself.

Done once every 5-10 seconds would be easily doable......one could be more efficient by having several kinds of scanner objects to rez, and rezzing those that scan FAR away only every 30 seconds or more, and rezzing ones that only scan to 1024m every 10 seconds........and the HUD object itself can run a sensor on the nearest 96m itself every 5 seconds.  Still a bit much, but wouldn't be TOO excessive.....

 

Link to comment
Share on other sites

You can beat the 16 person limit with a couple of tricks.  One is to make a more complicated scanner that is either made of more than one prim (each scanning a different conical sector of the area) or is a single prim that does several rotations in rapid succession, each scanning a different small sector.  I have tried both methods successfully.  Void Singer once made a dodecahedral scanner that was a wonder to behold. 

The other trick is to use a single scanner but move it in a preset pattern that covers the entire area, doing a fresh scan at each spot in the pattern.  I built one like that for a client recently.  If you use either of those tricks, you will inevitably get duplicate hits, which means doing some filtering to get rid of them.

Link to comment
Share on other sites

there's lots of tricks to scanning a whole region....

Phoenix, Cool, and a few other TPV's can spit out the keys of all avatars in their region on a chat channel... this is used by many people to populate lists on huds or other items... but requires using a viewer that has this feature.

there a monster megaprim trick using volume detect that will grab the first 16 avs in a region regardles of position.

standard sensors have a 96m max radius... you can fully cover the first 16 avs at that range from an attachment with no problems.

expanding on that to cover a whole region, 4 sensors at the same height placed at 64m intervals inside of a region covers a height of +/-32m at 100% (and a fair amount of extra). subtract ground height from 4096 and divide by 64 to see how many sensors that takes =).

rather than using one sensor for each position, having one senor move though all the positions is effective.

changing the sensor to use conic sections and rotating the sensors facing will increase the number of possible detections inside a spherical space. but this doesn't work for attachments (no matter what you do only the forward arch is detected by attachments)

putting all of these together, I built a single prim sweep sensor, that rezzes, jumps to the positions it needs to be in, runs a basic 96m sensor, and if it gets more than 15 results, does a conic sweep in a dodecahedron pattern, adding any new keys to a list, and chatting them to the region, then jumps to the next position... this routine takes less than a minute on a fully occupied region. at the end it dies (this way if it ever gets stuck the next one isn't affected)

the sensor sweep code I use is based on this generalization.....

 /*//-- dodecahedron rotations --//*/list    gLstDir = [< 0.000000,  0.000000,  1.000000, 0.000000 >,                   <-0.000000,  0.262846,  0.808951, 0.525842 >,                   < 0.000000,  0.850583,  0.000000, 0.525841 >,                   < 0.000000,  0.262846, -0.808951, 0.525842 >,                   < 0.000000, -0.688110, -0.499994, 0.525843 >,                   < 0.000000, -0.688135,  0.499960, 0.525842 >,                   < 0.000000, -0.162495,  0.500105, 0.850582 >,                   <-0.000000,  0.425401,  0.309104, 0.850581 >,                   < 0.000000,  0.425415, -0.309083, 0.850582 >,                   < 0.000000, -0.162495, -0.500105, 0.850582 >,                   < 0.000000, -0.525841,  0.000000, 0.850583 >,                   < 0.000000,  0.000000,  0.000000, 1.000000 >];integer  gIdxCnt;rotation gRotBas;float    gRadSns;list     gLstRpt;uSensorExpansion(){    if (gIdxCnt){         /*//-- Set rotation before we call the sensor --//*/        llSetLocalRotRot( llList2Rot( gLstDir, gIdxCnt++ ) );        llSensor( "", "", AGENT, 95, gRadSns );    }else{         /*//-- we called all our Sensors, now report the findings --//*/        llOwnerSay( (string)((gLstRpt != []) / 2) + " Avatars detected:\n" );         /*//-- (gLstRpt != []) == llGetListLength( gLstRpt ) --//*/                gIdxCnt = ([] != gLstRpt);         /*//-- ([] != gLstRpt) == -llGetListLength( gLstRpt ) --//*/        while (gIdxCnt){            llOwnerSay( "\nName: " + llList2String( gLstRpt, gIdxCnt++ ) + "\n @ " + llList2String( gLstRpt, gIdxCnt++ ) );        }         /*//-- we're done, clear our list --//*/        gLstRpt = [];    }}default{    state_entry(){        llOwnerSay( "Touch Me to Start" );        gRotBas = llGetLocalRot();        gRadSns = llAngleBetween( llList2Rot( gLstDir, 0 ), llList2Rot( gLstDir, 0 ) ) / 2.0;    }        touch_start( integer vInt ){        gIdxCnt = ([] != gLstDir);        uSensorExpansion();    }        sensor( integer vIntTotal ){        list vLstTmp;         /*//-- loop backwards to reduce variables --//*/        while (vIntTotal--){         /*//-- don't use (--vIntTotal), we want to subtract AFTER checking --//*/            vLstTmp = [llDetectedPos( vIntTotal ), llDetectedName( vIntTotal )];             /*//-- is it NOT in our list already --//*/            if (!~llListFindList( gLstRpt, vLstTmp )){             /*//-- (!~llListFindList()) == (llListFindList() = -1) --//*/                gLstRpt += vLstTmp;            }        }        uSensorExpansion();    }        no_sensor(){        uSensorExpansion();    }}

 somewhere I have a smaller tighter version of this but I can't find it at the moment.... the premise is to create a cone whose tip is centered in a regular polyhedron, facing one side, and the cones edges pass through all vertex points of that side.... the pointing the cone at each side in succession and running the sensor. this works with any of the platonic solids, so 4, 6, 8, 12, and 20 cones are possible. these are the most efficient shapes, although any polyhedron is possible to use ( I keep meaning to do the soccer ball version). the 12 sided figure has the least duplication of space, and the 20 the most..... more sides == less potential to miss a detection because of the limit of 16 detections.

 

other considerations when using overlapping sensors are that you should save all detections, and when you make new ones, only add them to the saved list if they aren't already in there. once a detection has been made, you can track it without further use of a sensor by using llGetObjectDetails, and similar methods that can retrieve information based on the key

  • Like 1
Link to comment
Share on other sites

  • 6 years later...

Looking for a serious solution upon this prim count issue on my parcel, I'm wandering around on the web, finding surprising script-based solutions while I was looking for the tip on where to find the menu entry in my firestorm viewer... Anyway, this topic is one of the most interesting on the subject, and Void Singer made an outstanding work with the dodecahedron move ! Just one small thing :

On 28/08/2011 at 6:33 PM, Void Singer said:

llSetLocalRotRot

this is an unknown command from Linden's scripting database :D, better take a rotation off this line... xD

Thanks again !

Link to comment
Share on other sites

On 4/21/2018 at 9:54 PM, Thiogaran Aries said:

Looking for a serious solution upon this prim count issue on my parcel, I'm wandering around on the web, finding surprising script-based solutions while I was looking for the tip on where to find the menu entry in my firestorm viewer... Anyway, this topic is one of the most interesting on the subject, and Void Singer made an outstanding work with the dodecahedron move ! Just one small thing :

this is an unknown command from Linden's scripting database :D, better take a rotation off this line... xD

Thanks again !

Oh, thread so dead.
Writhing in pain.
Arise arise, to post again.

This thread is from 2011 and doesn't have anything to do with prim counts.

P.S. We've had llGetAgentList since 2012.

Edited by Wulfie Reanimator
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 2167 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...