Float height - pool -Linden water

[Marianne Little]

I have a floating raft that float in Linden water. Dropping it in a pool, it sinks to default water surface. It rotates slowly there.

The scripts inside is modify.

Can I change float height to the surface of the pool, thus have a working pool float? And also stop rotating - the pool is too small to make rotating look good. Is the place to edit maybe here?

state_entry()
    {
        float_height = (llWater(ZERO_VECTOR) + offset);
        llSetStatus(STATUS_ROTATE_X | STATUS_ROTATE_Y, FALSE);
        llSetStatus(STATUS_PHYSICS | STATUS_PHANTOM, TRUE);
        home = llGetPos();
        llSetTimerEvent(0.1);

 

 

[Qie Niangao]

Without seeing the rest of the script it's hard to tell how changes here will affect the object's behavior. Some things here are interesting, though:

• There's a ten-times-a-second timer doing something. That seems awfully busy, for a pool float. I wonder what it thinks it needs to do that often. Even bobbing up and down in the water should be way less frequent than that.
• It's going physical. That's pretty excessive for a pool float, unless there's some buoyancy also being used, and even then... why?
• I'm guessing the rotation is an llTargetOmega() either called in the script or left over in prim properties. That's easy enough to cancel, but it's also possible it's rotating by something else in the script.
• Overall, this snippet suggests a much laggier pool float than anybody would script on purpose, maybe the result of unrelated scripts kinda smushed together until some floaty behavior emerged. The one encouraging thing I see is that "float_height" is already using an "offset" -- but this doesn't hint how that offset is assigned, and we're only guessing that float_height actually has something to do with the height of the object.

Not sure what to suggest. In theory, we could look at the whole script and try to disentangle it for you, but there might be another script in the library or somewhere that would be a better starting point.

[Marianne Little]

1 hour ago, Qie Niangao said:

Without seeing the rest of the script it's hard to tell how changes here will affect the object's behavior. Some things here are interesting, though:

• There's a ten-times-a-second timer doing something. That seems awfully busy, for a pool float. I wonder what it thinks it needs to do that often. Even bobbing up and down in the water should be way less frequent than that.
• It's going physical. That's pretty excessive for a pool float, unless there's some buoyancy also being used, and even then... why?
• I'm guessing the rotation is an llTargetOmega() either called in the script or left over in prim properties. That's easy enough to cancel, but it's also possible it's rotating by something else in the script.
• Overall, this snippet suggests a much laggier pool float than anybody would script on purpose, maybe the result of unrelated scripts kinda smushed together until some floaty behavior emerged. The one encouraging thing I see is that "float_height" is already using an "offset" -- but this doesn't hint how that offset is assigned, and we're only guessing that float_height actually has something to do with the height of the object.

Not sure what to suggest. In theory, we could look at the whole script and try to disentangle it for you, but there might be another script in the library or somewhere that would be a better starting point.

Thank you. I was not sure if copying the whole script is permitted, since it isn't a freebie. I just tried to pick a part. I think I'll go for something pool-ready.

[Rolig Loon]

You should be able to find a simple freebie script. Try googling for something like "raft script second life". There's one basic floatie script out there that has been used in SL since the Days of Philip. ?

 

[Miranda Umino]

// 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);      
    }
     
}

 

Edited June 4, 2018 by Miranda Umino