The Quandry

If you add this line of code, it seems to correct the scaling. But I'm still curious if it's my code thats wrong or if it's second life.. // add this..inVolume *= 3500.0;// above this.. inVolume /= 1000.0;

The following code calculates the cubic volume in millimeters of a prim each time its resized. It then uses that value to give you the prims volume in milliliters. Volume of a cube = length * width * height 1 cubic millimeter = <0.01,0.01,0.01>; //smallest prim1 cubic millimeter = 0.001 ml My question is this, is the code wrong or is it a scaling issue with second life? Try it, drop this code in a box and resize it. Try doing 236 ml (1 cup). Look how huge it is! Check out the image at the very bottom. A single cup can easily fit in the palm of your hand, but going by the scaling in second life it looks more like several gallons. I'm trying to come up with a standardized ratio of millimeters cubed to milliliters in second life. Any suggestions? Is it my code? vector SmallestSize = <0.01, 0.01, 0.01>; float GetWidth() { vector inScale = llGetScale(); float inWidth = inScale.x; return inWidth; } float GetLength() { vector inScale = llGetScale(); float inLength = inScale.y; return inLength; } float GetHeight() { vector inScale = llGetScale(); float inHeight = inScale.z; return inHeight; } CalculateVolume() { // get the size float inWidth = GetWidth(); float inLength = GetLength(); float inHeight = GetHeight(); // multiple by 1000 // avoid precision loss inWidth *= 1000.0; inLength *= 1000.0; inHeight *= 1000.0; // calculate volume for a cube float a = inWidth * inLength; float b = a * inHeight; // divide by 1000 // to get the actual value float inVolume = b / 1000.0; llSay(0, "Volume " + (string)inVolume + " mm³"); inVolume /= 1000.0; llSay(0, "Volume " + (string)inVolume + " ml"); } default { state_entry() { llSetScale(SmallestSize); CalculateVolume(); } changed(integer change) { if(change & CHANGED_SCALE) { CalculateVolume(); } } }

Thank you Dora I really appreciate it. I've sent you a copy of the scripted prims in world. Would you mind taking a look at it?

Rolig Loon wrote: The easier (and smoother) approach is to make the large prim the root of the linkset and give it a single llTargetOmega script that rotates the entire linkset at once. By 'large prim' I assume you mean the Large Sphere? To further clarify the primary link (the Base), does not rotate. It must stay fixed. Only the two child spheres rotate. Following this suggestion would result in the entire link set rotating, correct? That won't work. I would rather not resort to llTargetOmega, or timers. Is there no way to do this mathematically? Also I am not looking for a continous orbit, this random z alteration will only occur once. By this I mean (for example) you touch() the prim and the Small Sphere jumps to a random orbit and both Spheres rotate accordingly.

I've been hammering away at this all day and can't seem to figure out the mathematics behind it. I am really hoping someone can give me a hand.. I have three linked prims. Prim/Link 1 : The Base Prim/Link 2 : A Large Sphere Prim/Link3 : A Small Sphere 1. Z = A random rotation between 0 and 360 degrees ( Z AXIS ) 2. Rotate the Large Sphere child prim to Z degrees. 3. Rotate the Small Sphere child prim to Z degrees. The code I have works up to this point. I understand how to rotate both spheres to face the same random direction.. The problem I am having is moving the position of the Small Sphere in orbit around the Large Sphere to match the rotation change. E.g. Keeping both Spheres in geosynchronous orbit..