User talk:Dora Gustafson

From Second Life Wiki
Jump to navigation Jump to search

llGetCenterOfMass

You seem to have done some testing for llGetCenterOfMass. I'm curious, if you change the shape of the object in ways that should change the center of mass while it's non-physical, but after it has been physical (so that there is a cached value for the center) does it invalidate the cached value? So if you call llGetCenterOfMass does it then return the invalid value or the value of llGetPos? If you move the entire object does it return a position adjusted cached value for CoM? -- Strife (talk|contribs) 18:32, 3 December 2010 (UTC)

The answer to the first question is: no. The 'cached' value remains unchanged in non-physical mode.
The answer to the second is that llGetPos() is only assumed in a newly created prim, one that was never made physical and never computed the center of mass in physical mode.
When the non-physical virgin prim is moved around llGetCenterOfMass() returns the updated llGetPos() for the new positions.
When the non-physical prim where llGetCenterOfMass() was computed at least once in physical mode, the cached value persist.

Here is a script I used for testing: <lsl>default {

   touch_end(integer num)
   {
       llSetPrimitiveParams([PRIM_SIZE, <2.0, 2.0, 2.0>, PRIM_TYPE, 0, 0, <0.125, 0.375, 0.0>, 0.0, <0.0, 0.0, 0.0>, <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>]);
       llOwnerSay("Box cut in 1/4, non-physic: "+(string)llVecDist(llGetCenterOfMass(),llGetPos()));
       llSetStatus( STATUS_PHYSICS, TRUE);
       llSleep(0.5);
       llOwnerSay("Physic box cut in 1/4: "+(string)llVecDist(llGetCenterOfMass(),llGetPos()));
       llSetPrimitiveParams([PRIM_TYPE, 0, 0, <0.375, 0.875, 0.0>, 0.0, <0.0, 0.0, 0.0>, <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>]);
       llSleep(0.5);
       llOwnerSay("Physic box cut in half: "+(string)llVecDist(llGetCenterOfMass(),llGetPos()));
       llSetStatus( STATUS_PHYSICS, FALSE);
       llSleep(0.5);
       llOwnerSay("Box cut in half, non-physic: "+(string)llVecDist(llGetCenterOfMass(),llGetPos()));
       llSetPrimitiveParams([PRIM_TYPE, 0, 0, <0.0, 1.0, 0.0>, 0.0, <0.0, 0.0, 0.0>, <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>]);
       llOwnerSay("Full box, non-physic: "+(string)llVecDist(llGetCenterOfMass(),llGetPos()));
       llResetScript();
   }

}</lsl> Output from above script:

First in newly created prim:
Box cut in 1/4, non-physic: 0.000000 // primposition returned for center of mass, NOT correct
Physic box cut in 1/4: 0.706897 // square root(0.5), correct
Physic box cut in half: 0.500004 // 0.5, correct
Box cut in half, non-physic: 0.500000 // saved value, correct
Full box, non-physic: 0.500000 // saved value, NOT correct

Second run:
Box cut in 1/4, non-physic: 0.500000 // saved value, NOT correct
Physic box cut in 1/4: 0.706915  // square root(0.5), correct
Physic box cut in half: 0.499993 // 0.5, correct
Box cut in half, non-physic: 0.500001 // saved value, correct
Full box, non-physic: 0.500001 // saved value, NOT correct

Third run:
Box cut in 1/4, non-physic: 0.500001
Physic box cut in 1/4: 0.707092
Physic box cut in half: 0.500009
Box cut in half, non-physic: 0.500001
Full box, non-physic: 0.500001

...
The results are unchanged in 2. 3. 4. ... run except for minor rounding differences

I have not tested other prim types and not linked sets, just a single BOX_TYPE prim --Dora Gustafson 13:05, 16 December 2010 (UTC)

llSetMemoryLimit

Thanks for adding the caveat. Small question: if you previously set it to say 63KiB, and then set it to 2KiB and that failed, it would reset it to 64KiB? If that is the case, I'll add it as a sub-caveat. Thanks for the detailed response to my previous query, it's excellent. -- Strife (talk|contribs) 21:59, 28 February 2012 (PST)
You are right in your assumption; The limit will not be reset to max, it will be untouched. I made this test script: <lsl> string ballast="use some memory"; default {

   state_entry()
   {
       integer i=64;
       list heavy=[];
       while (i--) heavy+=[ballast];
       llOwnerSay("No limit set ever\nMemory used: "+(string)llGetUsedMemory()+" Free memory: "+(string)llGetFreeMemory());
       llSetMemoryLimit( llGetUsedMemory()/2);
       llOwnerSay("Memory limit set to "+(string)(llGetUsedMemory()/2)+"\nMemory used: "+(string)llGetUsedMemory()+" Free memory: "+(string)llGetFreeMemory());
       llSetMemoryLimit( 2*llGetUsedMemory());
       llOwnerSay("Memory limit set to "+(string)(2*llGetUsedMemory())+"\nMemory used: "+(string)llGetUsedMemory()+" Free memory: "+(string)llGetFreeMemory());
       llSetMemoryLimit( llGetUsedMemory()/2);
       llOwnerSay("Memory limit set to "+(string)(llGetUsedMemory()/2)+"\nMemory used: "+(string)llGetUsedMemory()+" Free memory: "+(string)llGetFreeMemory());
   }

}</lsl> Which produce this output:

No limit set ever
Memory used: 5636 Free memory: 59900

Memory limit set to 2928
Memory used: 5856 Free memory: 59680

Memory limit set to 11712
Memory used: 5856 Free memory: 5856

Memory limit set to 2928
Memory used: 5856 Free memory: 5856

I made a change in the Caveats. Dora Gustafson 06:07, 29 February 2012 (PST)