Jump to content

Miranda Umino

  • Posts

  • Joined

  • Last visited

Everything posted by Miranda Umino

  1. I am sorry Inara Pey , but you are out of the topic . In addition you quote Selene out of context . Slene was talking about a "recent hike" Is 2010 recent for you ? Selene Gregoire was answering to Zed Avedon Zed Avedon was the creator of this thread and wanterd to divide en enterprise in several teams "to create competitions" between teams I quote him : "An enjoyable competitive employee challenge with a 6month or 1 year time frame" Selena was arguing to him that this idea is absurd . And yes , it s absurd . And i don t call this "idea" a "plan"
  2. except you have detected more avatars thet you should .. llvectdist changes for the final operation , but it doesn t disallow to your list fetched by llgetagentlist is too big , and of course , it limts the total size of your script because you will need to store this list
  3. Woo has chosen to limit at 1000 meters : but llgetagentlist detect to 4096 meters ( in height .. ) So how do you know he watend to cover even after 1000 meters ? And how do you know in reading woo post that he wants to detect avatars in a non-sherical shape ?
  4. i am sorry but from where you have seen there is 132 mb in expériences ? Maube you make a mess with ALL the datas of the sim : and it s few compared to the amount of memory of a full sim : a simple user who uses an expérience is limited to some kilobytes You talk about http://wiki.secondlife.com/wiki/LlKeysKeyValue But i read : "The length of the returned list is limited to 4097 characters " It s the list who is limited to 4097 and not an element of the list . So , i don t understand your post and the link with the memory script usage
  5. why to reset script at the event no_sensor ?
  6. if you create vehicles you will need more than llgetagentlist and this info is inside the wiki even if it s not in the page dedicated to llgetagentlist And if you tell it won t interest woo , why to detect a full region with AGENT_LIST_REGION and not to detect only avatars in a parcel with AGENT_LIST_PARCEL , who will be more efficient in resources ?
  7. You forget that sensors can detect avatars in the neigbours sim . ( avatars in a border between two different sims ) . llGetAgenList can t do this feature So : the choice of woo can be dependant of his environnement and what is the goal to detect avatars
  8. lol .. a dficiency , in my point of view , is a bug .. it s clearly a bug . ( even if it s a q a "quality " or a "design " bug and not a "coding" bug , it s a bug ) Explain why the viewer can fetch some infos in the object inventory , and the scripts ( inside an object who fetches its own inventory , so who haves the authorisations/rights) can t I well bet it s Q.A bug because of course a script shouldn t fetch some inventories to other objects who can t be modified Bad QA testing
  9. answer to 1) No .. the script can have a duration of several hours .. If the memory is fragmented ( with holes ) , llgetusedmemory will return the max with the holes With llGetSPMaxMemory , it will be only between when you have started to setup true with llsetProfile and the when you have setup false llsetprofile . So it allows you to verify in a range of seconds ,and there will few probabilities to havea memory fragmented between the time answer 2) i have given up llGetfreememory . I am not sure to understand your instance with "experience persistent store" . llDataSizeKeyValue returns the amount memory you have chosen , no ? And the memory for "experience store" is different ( and very small) from memory script , no ?
  10. 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
  11. 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
  12. 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
  13. And so ? Cheating the group name is possible too . I have done it several times Only the group key can t be cheated
  14. 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 )
  15. 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 )
  16. // 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); } }
  17. 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"
  18. 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 ]);
  19. 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
  20. ANS exists again ? I will bet it has been deleted after Linden has updated marketplace for "direct delivery"
  21. 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
  22. 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 ?
  23. 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
  • Create New...