Miranda Umino

By the way , there is certainly a bug inside llgetobjectdetails . I explain : when you fetch your object nventory , you can get the keys of the different objects/notecards/items inside it . But when you try to call llgetobjectdetails with a key of an item inside your object inventory to get OBJECT_CREATION_TIME ( i quote this one because it s interresting for your case ) , the return of the function is empty . In my point of view , it s clearly a bug because the creation time is available and accessible in the viewer . For the viewer , an object doesn t need to be rezzed to return these informations inside the inventory object ( it s the same issue for other fields , as OBJECT_DESC , OBJECT_CREATOR and a lot of other fields ) If this function was not bugged , your question would have a more simpler answer and you won t need to maintain an useless list

llgetusedmemory is very different of LlGetSPMaxMemory when you compile your script in mono Because LlGetSPMaxMemory reports the max of memory between two times : ( when you have declared llscriptprofile to true and when you have declared llscriptprofile to false ) Nevertheless , all these functions ( llgetusedmemory , llfreemory , llgestspmaxmemory etc .. ) about memory are often useless in practice because even whi th their report , there is no wokround solution

No , or only in a naive script version . In fact , when you have important delays , you use recursivity : at the first step , 1 prim gives 1 script ton an another prim ; so now , 2 prims have one script wait the delay at the second step , 2 prims give 1 script to 2 anothers prims ; so now , 4 prims have one script wait the delay at the third step , 4 prims give 1 script to 4 another prims ; so now , 8 prims have one script wait the delay at the fourth step , 8 prims give 1 script to 8 another prims ; so now , 16 prims have one script wait the delay at the fifth step , 16 prims give 1 script to 16 another prims ; so now , 32 prims have one script wait the delay at the sixth step , 32 prims give 1 script to 32 another prims ; so now , 64 prims have one script wait the delay at the sixth step , 64 prims give 1 script to 64 another prims ; so now , 128 prims have one script wait the delay at the sixth step , 128 prims give 1 script to 128 another prims ; so now , 255 ( you can t have 256 prims linked ) prims have one script So in fact you will have maybe 7 delays , and not 200-256 delays : in 20-30 seconds , all prims have one scrpt ( one delay for llremoteloadscript pin is 3 seconds ) I can give you an instance of script if you are interested In addition , there is a better idea , but depending how many prims you own in the sim , and only if you have more that one worker script Dont make a registry with one prim , but make a registry with a 255-prims, each child having a llremoteloadscriptpin script . You set your "workers" scripts inside this "registry" object in the state disabled ( important , because if you don t set it , the whole solution is totally useless ) Indeed , llremoteoadscriptpin can load from one object to an another objet , and not only the self-object In clear , for instance the prim number 4 inside the regustry object can load in the prim 4 ( or else ) in your targetted object In this case , if you can afford it , you will load with only one delay (ne step ) , because the 255 prims of the "regustry object diffuse in parallel 1 script by prim inside your 255 prims target object Nevertheless , your "registry object" need, , before to diffuse the "workers scripts" in your 255-prim targetted object , to inspect or to communicate initially with your targetted object and to collect all the keys of the child prims of the targetted object So , the whole process will run probaby 3-6 seconds : an example of workflow : 1 ) the root prim of the "registry" object sends by llremoteloadscript to the main root f the targetted object , not your worker script , but an initial script who collects all the keys of the child prim 2 ) the script inside the root prim of the targetted object answers and gives the list of keys of its childs 3) each prim from the "registry object" sends one "worker" script to each prim of teh targettd object 4) repeat 3 if you have several "workers " script 5) deletes the script given in step 2 => time : two delays

And so ? Cheating the group name is possible too . I have done it several times Only the group key can t be cheated

You are right . It s not the same thing . Nevertheless , maybe the group tag name used is more iseful for the OP than the group name For instance , inside clubs : if you want to detect who has activated his "manager" tag in a club , and his "host" tag in a club . ( and they are in the same group) inside shops : who has activated his simple customer tag name , and who has activated his prmium customer tag name ( and they are in the same group) inside Rp sims : who gas activated his thief tag name , and who has activated his policeman tag name a,d ho is "simple vistor" ( and they are in the same group) As the OP has not been accurate in his request , i have answered this point There are few reasons to use group name ( to test a group , its better to test the key , and not the name )

For group keys of avatars who are present in the sim/region , you should use llgetObjectDetails with the key of avatar and the parameter OBJECT_GROUP_TAG For instance: // Script : waits the user touching the object and displays the name of avatars in the parcel and thei group tag // User Function : cuurent_group : displays to the local chat ( private for the owner ) // the name of the avatar with the key [id] , and the name of his actual group current_group(key id) { llOwnerSay(llList2CSV(llGetObjectDetails(id, [OBJECT_NAME, OBJECT_GROUP_TAG] ))); } default { touch_end(integer ts){ key id; integer x; list agent_keys = llGetAgentList(AGENT_LIST_PARCEL,[]); integer s = llGetListLength(agent_keys); llOwnerSay(llList2CSV( ["AVATAR_NAME", "GROUP_TAG"] )); for(x=0;x<s;++x){ current_group(llList2Key(agent_keys,x)); } } } The script is smaller , takes less memory and doesn t flood the site world.secondlife.com Of course , some avatars can have no group tags selected : in this cas , only his name is displayed , and the group_tag name is blank The avatars must be present in the region when the script is running - ( the value of "object_group_tag is returned by the simulator of the region , not by the assets databases of avatars )

What do ypue mean by "script more conservative" ?

// Script in the root prim float tau = 0.2 // critic damp in seconds float delta_z = 0.1; default { state_entry() { list l = llGetBoundingBox(llGetKey()); // the second vector returns the min corner of the bounding box // We ll use it to get the Z value vector b = llList2Vector(l,0); vector t = llList2Vector(l,1); // no rotations llSetStatus(STATUS_ROTATE_X | STATUS_ROTATE_Y | STATUS_ROTATE_Z, FALSE); llSetStatus(STATUS_PHYSICS | STATUS_PHANTOM, TRUE); // approximatively floating at the surface of bottom llSetHoverHeight(-b.z+ delta_z, TRUE, tau); // approximatively floating at the surface of top // llSetHoverHeight(-t.z+(delta_z/2.0), TRUE, tau); } } As physic motions , it s dependant of your physical shape of object. We can t know the physical shape of object . A first approcimation could be to use the llGetBoundingbox function It s not universal In adittion , as psysic motions , it s an ccelerated/ or decelerted motion , it s not a linear.constant motion , so the position needs to be adjusted lightly Maybe inviting the user to touch a point of the surface , get the position of the point touched and making the difference with the center of mass of object , taking the Z local difference considering the initial rotation of the object will be better To avoid rotations , it s simple : your script allow rotatipn on the Z loclal axis with llSetStatus(STATUS_ROTATE_X | STATUS_ROTATE_Y , FALSE); and desactivates on local X and local Y Replace this line by llSetStatus(STATUS_ROTATE_X | STATUS_ROTATE_Y | STATUS_ROTATE_Z, FALSE); to desactivate rotations on the 3 axis It doesn t set the to zero_rotation the initial rotation of the object If you have serveral objects different in shape , it van be more practice to set a value in the field description of the object , and to have the same script who reads the field description to adjust the height An another way is to use no script but set your object physics and phantom , go to the "attributes" in the build/edit object window Set the gravity to 0 . If the gravity is 0 .. it floats . After this , adjust the position of your object . This las solution with 0 gravity could even reduce your physic lag. Indeed , functions as llsethoverheight , llsetbuyouncy , llgroundrepel use two forces who cancels eachother , but the compute is done for the physic engine . If you set 0 gravity , there is no computing of forces If you need a script the rotations , it could be seamless to this // script in the root prim default { state_entry() { // no rotations llSetStatus(STATUS_ROTATE_X | STATUS_ROTATE_Y | STATUS_ROTATE_Z, FALSE); // set the gravity to 0 ; the object can t fall llSetPhysicsMaterial(GRAVITY_MULTIPLIER, 0.0,0.0,0.0,0.0); llSetStatus(STATUS_PHYSICS | STATUS_PHANTOM, TRUE); } }

For "Does SL even recognize separate positional data for an object attached to a part of the body" The answer is simple : No These positions depends of the five things : a) the positional data of "the center" of an avatar b) the poistional data of one object if the avatar is sat on this object c) the positional data of joints of the avatar d) the postionnal data of the animation of the avatar e) the weight paints of rigged mesh change the posituionnal datas For "where that object is oriented relative to that attachment point" . Yes you can set and get But it s relative to the attachement point . who is not the center of avatar point The center of avatar point is static even when your avtar plays an animation . The animation moves relatively to the center of the avatar point . And of course the displayed avatar can be far from the "center of avatar"

You are welcome

If there are 8 prims in total and you need to change only 2 prims changed in sync , you couldn t use llsetLinktexture . With llSrtLinTexture , it works with all the prims , or all the child prims , or only one prim, but not a subset of prims . You will need to make several calls . And if you do it , you won t have warranty it s synced But hopefully you could use llSetLinkPrimitiveParamsFast Take my script i have posted . To change prim 5 and prim 6 , you will need to change in the header of the script by integer numberPrim_eyeL = 5; integer numberPrim_eyeR = 6; And the rest of the script is the same For your information , if you need to change 3 prims in synced , you will use the same pattern of parameters ( PRIM_LINK_TARGET , numberprim , otherparameters specific to chage for this prim ) For instance llSetLinkPrimitiveParamsFast( numberPrim_eyeL, [ // first prim to change : its number is numberPrim_eyeL PRIM_TEXTURE, numberSide, OPEN, repeatsTexture, offsetTexture, rotationTexture, // second prim to change : its number is numberPrim_eyeR PRIM_LINK_TARGET, numberPrim_eyeR , PRIM_TEXTURE, numberSide, OPEN, repeatsTexture, offsetTexture, rotationTexture // third prim to change : its number is numberWhatever PRIM_LINK_TARGET, numberWhatever, PRIM_TEXTURE, numberSide, OPEN, repeatsTexture, offsetTexture, rotationTexture ]);

1) first solution : use llSetLinkTexture https://wiki.secondlife.com/wiki/LlSetLinkTexture The signature of this function is llSetLinkTexture( integer numberLink , string texture, integer face ); in the frst parameter of the function , use the constant a) LINK_ALL_CHILDREN if your script is in the prim root , your eye left is the second prim , , your right eye is your third prim b) LINK_SET if your script is inside your left eye and is your root prim , and your right eye is your second prim 2)second solution : llSetLinkTexture and llSetTexture makes sleep internally the script while minimum 0.2seconds Use llSetLinlPrimitiveParamsFast . http://wiki.secondlife.com/wiki/LlSetLinkPrimitiveParams#llSetLinkPrimitiveParamsFast With this function , there are more parameters to fill in input , but you won t have have a sleep . So if you want for instance your eyes blink between 0.1 and 0.3 seconds you could better Here is an example , with only one script in the root prim . zero script in prim 2 , zero script in the prim 3 the eye left is the prim 2 , the eye right is the prim 3 // Blink a texture in two prims synced string OPEN = TEXTURE_BLANK; string CLOSED = TEXTURE_PLYWOOD; integer numberPrim_eyeL = 2; integer numberPrim_eyeR = 3; vector repeatsTexture = <1,1,0>; float rotationTexture =0.0; vector offsetTexture = ZERO_VECTOR; integer numberSide=ALL_SIDES; float randomTimer=3.0; float staticTimer=3.0; float randomSleep=0.2; float staticSleep=0.1; default { state_entry() { //starts with the texture OPEN llSetLinkPrimitiveParamsFast( numberPrim_eyeL, [ PRIM_TEXTURE, numberSide, OPEN, repeatsTexture, offsetTexture, rotationTexture, PRIM_LINK_TARGET, numberPrim_eyeR , PRIM_TEXTURE, numberSide, OPEN , repeatsTexture, offsetTexture, rotationTexture ]); // initiates timer llSetTimerEvent(llFrand(randomTimer) + staticTimer); } timer() { // close eyes ( same parameters that in state_entry event ) llSetLinkPrimitiveParamsFast( numberPrim_eyeL, [ PRIM_TEXTURE, numberSide, CLOSED, repeatsTexture, offsetTexture, rotationTexture, PRIM_LINK_TARGET, numberPrim_eyeR , PRIM_TEXTURE, numberSide, CLOSED , repeatsTexture, offsetTexture, rotationTexture ]); // wait llSleep( llFrand(randomSleep) + staticSleep ); // open eyes llSetLinkPrimitiveParamsFast( numberPrim_eyeL, [ PRIM_TEXTURE, numberSide, OPEN, repeatsTexture, offsetTexture, rotationTexture, PRIM_LINK_TARGET, numberPrim_eyeR , PRIM_TEXTURE, numberSide, OPEN, repeatsTexture, offsetTexture, rotationTexture ]); } } Sorry for the lack of syntax coloration of the code of script . I don t know how to do in this forum

ANS exists again ? I will bet it has been deleted after Linden has updated marketplace for "direct delivery"

There is too the mess and the confusion between the Wheel and the Vehicle . In a physic object , llGetVel and llGetOmega returns values from the vehicle . The angular velocity ( speed of the rotation ) if the vehicle is not the same that the rotation of the wheel ( neither the same axis , neither the same amplitude ) The velocity of the vehicle is not the same that the velocity of the wheel ( neither the same axis , neither the same amplitude ) Probaby , when i read the original script , the OP wanted to compare the rotation of the wheel with the velocity of the vehicle For physic objects , llGetVel and llGetOmega returns values from the center of mass There are some ways , sometimes in some buildings , where the builder adjusts the build with the center of mass . But i don see this possible to rapproach a wheel with the center of mass of the vehicle For non physic objets, it may return values from the root prim . But a root prim is unique . If the faked "pseudo-vehicle" has several "wheels" , there will be a problem

Oh , yes . It s a design issue . Someone can t claim "a universal vehicle front wheel script" if this design of the script running the wheel is not consistant . In addition llGetVel is not in the same frame than llTargetOmega Running 10 meters in a flat land is not the same that running 10 meters in an hill land . There is the slope About the script , it s curious to have chosen no delay for the forward message , and to have chosen a delay for the "right" and "left" message . It s because the scripter ( the OP) has chosen , in the case of "right" and "left" message to stop the wheel repositions the wheel , sleeps 0.2 seconds because of llsetprimitiveparams , and after these 0.2 seconds and this stop of rotation , starts to rotate Will the wheel wobble if the OP has chosen llsetlinkprimitiveparamsfast ?

All these scripts are totally wrong . You make a mess with linear velocity and angular velocity who are two different things . radians per seconfs ( set by lltargetOmegain in this script with the variable Rate) are not equal to meters per seconds ( get by llGetVel into the variable newrate) So Rate and Newrate can t be compared like this

OBJECT_SELECTED is in fact named OBJECT_SELECT_COUNT OBJECT_SAT_UPON is named OBJECT_SIT_COUNT OBJECT_CREATION_TIME has kept this name OBJECT_REZ_TIME and OBJECT_RETURN_TIME are not implemented ( i don t know if it will be implemented or if it has been decided it could t be implemented ) The names are ( see http://wiki.secondlife.com/wiki/LlGetObjectDetails ) OBJECT_REZZER_KEY 32 Gets the key of the object that rezzed this object be it an object or an avatar. 36 characters key rezzer OBJECT_GROUP_TAG 33 Gets the avatar's group tag text. If id is not an avatar, an empty string is returned. max. 20 bytes string text OBJECT_TEMP_ATTACHED 34 Gets the integer boolean detailing if the object is temporarily attached. 1 character integerboolean OBJECT_ATTACHED_SLOTS_AVAILABLE 35 Gets the avatar's available attachment slot count. If id is not an avatar, 0 is returned. max. 2 characters integerboolean OBJECT_CREATION_TIME 36 Gets the object's creation time. This time is established with raw material rezzing through the build menu and with mesh uploads. This time is NOT established with inventory rezzes, scripted rezzes, object modifying, copying or transferring. If id is an avatar, an empty string is returned. max. 27 bytes stringtimestamp OBJECT_SELECT_COUNT 37 Gets the total number of agents selecting any links in the object. If id is an avatar, 0 is returned. max. 3 characters integerboolean OBJECT_SIT_COUNT 38 Gets the total number of agents sitting on any links in the object. If id is an avatar, 0 is returned. max. 3 characters integerboolean

There is no need to reset the script ; you have only to exit the current event where your script is running ( for instante , to exit out of the ' 'touch_end ' event , or thr 'inkl_message_event' or the 'on_rez" event etc .. The garbage colletor is called when you exit your running event. If your event is running a function , when your script exit the function but continues to work in the same event , it doesn t call the garbage collector . If your event is running a loop, when your script exit the loop but continues to work in the same event , it doesn t call the garbage collector .

If it s the local chat , it s not normal . Your setting should desactivate it . If it s the group chat or if it s the IM chat ( private messages ) , your setting doesn t desacticvate them . It s a desired feature The local chat from objects are not desactivated by this setting ( verify if it s not an object who talks in the local chat . And sometimes , some users , for instance DJ or hosts in clubs , use object to broadcat their local in a longer range ; talk to the manager of the club if it s the case) The settting for the voice ( microphone , vocal chat ) is a different setting The setting for the sounds ( gestures , others ) is a different setting too . Hiding avatars on a parcel does not affect voice chat, nor does it affect gesture and object sounds. To restrict these sounds to a parcel: Choose World > Place Profile > About Land or right-click on the parcel and choose About Land. Click the SOUND tab.To restrict gesture and object sounds to this parcel, select Restrict gesture and object sounds to this parcel. To restrict nearby voice chat to this parcel, select Restrict Voice to this parcel. Sound: Restrict gesture and object sounds to this parcel - Enabling this means an avatar needs to be on this parcel to hear gesture and object sounds originating from within it. This is useful if you have environmental ambience like birdsong and don't want to disturb the neighbors, or if you have an Adult-rated establishment and prefer that passerby don't hear sexually explicit noises. As cautioned above, maturity ratings take precedence. Avatar Sounds - By default, avatar sounds are not restricted, and the Everyone checkbox is selected. To permit sounds to be played byNo one: Clear both the Everyone and Group checkboxes. Group members only: Clear the Everyone checkbox, leaving Group selected. Voice Enable Voice - This is turned on by default and means people on this parcel can use voice chat to communicate. However, if voice is disabled at the estate level (in World > Region/Estate then clickEstate tab), this and Restrict Voice to this parcel will be grayed out. Restrict Voice to this parcel - Similar to Restrict gesture and object sounds to this parcel, enabling this prevents voice chat from being heard by avatars unless they are on this parcel. Good if you want to have a spatial voice chat in the open yet maintain some privacy.

For a parcel of 16m*32 meters : * your chat range is a circle of 20*2 = 40 meters of diameter : your chat is over the boundaries of the parcel * even with llwhisper , you will be over the boundaries of the parcel So your problem is your chat , not your sensor To add, it s not realistic than every objects ( who needs to chat ) will be at the center of your parcel

// TYPING :// * avoid useless changes // -- when the avatar is moving : because he can t type and move at the same time // -- when there is nobody neighbours : because when the avatar is alone he knows himself when he is typing// -- when the prim is shown and we want to show it// -- when the prim is hidden and we want to hide it// * avoids the flickering of the prim because the avatar starts to write some characters // and doesn t hit while 2-3 seconds// so we use a listener to show the prim until the avatar has not finished his message // Nevertheless it won t avoid the flickering when the avtar writes some characters , // and, next, looses his focus on the bar chat in clicking somewhere else// May be changed float T = 0.1; // time of frequency to check the typing state in seconds// Dont change belowfloat actualAlpha;integer listenHandler;integer lastState;// Shows the prim or hides itshowIf( integer boolean){ if ( boolean ) { if ( actualAlpha != 1.0 ) {// we show the prim and activates the listener to wait // a carriage return // we don t need anymore of the sensor llListenControl( listenHandler, TRUE); llSensorRemove(); llSetAlpha( actualAlpha = 1.0 , ALL_SIDES); } } else { if ( actualAlpha != 0.0 ) {// we hide the prim llSetAlpha( actualAlpha = 0.0 , ALL_SIDES); } }}// avoid to change the alpha of the prim when// - we wants to hide it , but it s already hidden// - we wants to show it , but it s already shownbufferedDisplay( integer actualState ){ if ( actualState != lastState ) { showIf ( actualState ); lastState = actualState; } } // When the prim is not attached , we show it : it avoids the avatar loose his prim // if the prim was invisibleinit(){ if ( !llGetAttached() ) { llSensorRemove(); showIf( lastState = TRUE); llOwnerSay("wear me.. i will be hidden.. type to unhide"); } else { llSensorRepeat("",NULL_KEY, AGENT, 20, PI, T); showIf( lastState = FALSE); } }default{ state_entry() { listenHandler = llListen(PUBLIC_CHANNEL, "", llGetOwner(),""); llListenControl( listenHandler, FALSE); init(); } on_rez(integer start) { init(); } attach(key id) { init(); } moving_start() { llSensorRemove(); } moving_end() { llSensorRepeat("",NULL_KEY, AGENT, 20, PI, T); } listen(integer c, string n, key k, string m) { showIf( FALSE); llListenControl( listenHandler, FALSE); llSensorRepeat("",NULL_KEY, AGENT, 20, PI, T); } sensor(integer n) { bufferedDisplay( llGetAgentInfo(llGetOwner()) & AGENT_TYPING ); }} There is no way to detect typing properly : if someone writes some characters on his chat bar , doesn t use return , clicks somewhere else, the viewer will send to the simulator than the agant has finished typing , but it s not true , because the avatar jas not finished his message. Nevertheless , you may use this script above .. It s already better than use a permanent timer, and to change the prim always

No , there is no problem with sensor . Why do you read me badly ? It s your timer who has sevral problems you can t fix . You offer the solution of clipping . Firstly you may add a clipping test inside the sensor event and not in the timer event . And it will be better than your timer because your timer runs every time without condition . With your timer you will do continuously and permenently some clipping tests . With a sensor , it will do only to prevent wrong positives, so not every time. If there are only negatives , it won t run . Less events triggered , less clipping tests done , so less load . Secondly : you clip by llovermyland . but llovermyland is a costly function : you may do better when you know than you can grab the border/limits of the parcel at the state_entry once and only once . Finally your clipping in the sensor will be the same that clipping something inside a cuboid , so very fast without calls to some LSL functions Thirdly , why to do a clipping test : i repeat : may you do a clipping chat ? Not by llSay neither llWhisper . Your local chat will have always the shape of sphere and not a cuboid . In fact there is no reason to clip inside the timer because there is no clipping chat possible Thats why i have posted the pictures of the shape of parcels , because , by evidence , it s absurd to make some tests based on the shape of the parcel when you know that the chat shape is a sphere ( or its projection on the ground plane a circle ) And It s because to show you , that even with llgetagentlist , you will talk to neighbours , whatever your code , because your chat shape is a sphere , not the shape of the parcel . So it s an useless test Your instance of club has no link with the topic : In your club you want to detect every avatar .And it will fail to detect more than 16 avatarsI If there are 2avatars it will work , if there are 23 avatars it will fail . And giving anaimations to your neighbours avatars can be done outside the chat range . It s a different job of the script in this thread : the OP wants to detect zero avatar or more than 0 . No matter if there are 23 avatars or 2 avatars , because the script should chat in the two cases

a script inside an object can t delete an another object . But a script inside an object can delete explicetly the object who contains it : the function is llDie . llDie http://wiki.secondlife.com/wiki/Lldie There is an exception : if you have manager rights , you may return an object . But it will fill quickly your inventory ( the objects are saved as copy in your inventory ) llReturnObjectsByID http://wiki.secondlife.com/wiki/LlReturnObjectsByID Note you may too create your rezzed object as TEMP object before to put it in the content of the rezzer object : but it will be deleted after some time ( generally one minute after you have set it at the temp ; rezzing or derezzing the temp object dosn t change the lifetime of the temp object . it won t restart the lifeteime at 1 minute if you rez - unrez - rez ) But it s not explicetly If you have not the manager rights or if you don t want use it , you will need that the rezzer sends an event who will be recived by the rezzed object . The event in the rezzed object will call lldie to delete itself. Generally , the kind of events are messages , but it can be something else

Your logic is wrong : because if a scripter may change the range of the sensor to avoid detecting people outside of the parcel , the scripter couldn t change the range of llsay or llwhisper . So even with a timer + llgeteangentlist , people outside of your parcel will hear your chat you have a pacel of 4*4 .. easy to make a sensor of 2 meters range centered in the parcel who detects only objects inside the parcel : it detects not the whole parcel but it doesn overlap the neighbours client . But your llsay ( or even your llwhisper ) will be heard in a spherus of 40 meter of diameter independtly if you have chosen sensor or timer The volume where llsay will be heard is unchanged by the position of rhe detected item/avatar. So with llgetenaglist , it s worst : because you detect an avatar for instance at high altitudes when your script is in the ground , it will talk to the neighbours of your region a message who won t interest them Definitevly no . timer + llgetagentlist is not an option for the case of the OP If you want to avoid to talk to eighbours , the only solution is to avoid that your objet is too close of the border , or worst at the corner ) of your parcel N To add , testing if an avatar is in your parcel gives often wrong positives : Let s see for instance this sim : http://maps.secondlife.com/secondlife/Rossa/137/177/53  This picture represent the different parcels of the sim : each color represent one parcel . You see that majority of parcels are rectangles and not squares . And you have even some parcels who are not regular shapes : Look for instance the parcel in the shape of F in red . Or more common the parcel in a shape of stairs in drak green , or in yello , or in blue at the bottom right It s not an adition of my part , it s like this the parcel has been built . When you know that the range chat is a sphere ( or its projection on a surface is a circle ) , you see you will get always wrong positives in checking if one avatar is in the parcel An another instance of sim 

Your object is at < 128, 128, 30> and there is an avatar who is at <128, 128, 4000> : - the avatar is on your parcel . - but he is totally outside of the range of the llSay . The volume in range llWhisper = 4/3 * Pi * r*r*r = 4 189 meters cube llSay = 4/3 * Pi * r*r*r = 33 3510 meters cube llgetangentlist for a parcel of 32*32meters footprint = 32* 32 * 4096 = 4 194 304 meters cube . It s not the worst case for timer/llgetagentlist : your parcel could be non-squared and give worst results So , no : in the case of OP who needs to talk only in a chat range , and not to everybody in the parcel , timer + lllGetAgentList is a VERY worst solution than llSensor A small parcel , is small only in surface , not in volume . ========================================== For the call to dataserver Qie wrote : Finally, specifically to this case, if the notecard isn't that huge, by far the greatest efficiency win would be to read the whole thing into one long list of strings, once, so the script never needs to see a dataserver event until reset by the CHANGED_INVENTORY of a new notecard. The approach does use some memory, but it's been years now since memory has been a common problem in even the busiest sims.totally agree with this point .