Mystery of the Bouncing Ball, Part II

The bouncing ball script below couldn't be simpler. I bounce the ball on a non-physical board (flattened cube) that is about 1 meter off the ground. I've also tried it on a physical version of this board that is on the ground.

More often than not after a few bounces the ball stops up in mid-air ("mid-bounce" rather than continuing to bounce lower and lower until in comes to rest on the board. Energy seems to be at 1.0 at all times.

Any and all insight as to the why and wherefore of this non-intuitive/non-physical behavior will be greatly appreciated.

Cheers, Moose

float startPulse   = 10.0;
float currentPulse = 10.0;
float damping      = 0.925;

setVelocity(vector newV)
{
    vector oldV = llGetVel();

    newV *= llGetMass();
    
    llOwnerSay("SET VELOCITY: "+(string)oldV+" ==> "+(string)newV);

    llApplyImpulse(newV, FALSE);
    
    llSleep(0.05);
}

default 
{ 
    on_rez(integer arg) 
    { 
        llResetScript(); 
        
        llSetStatus(STATUS_PHYSICS, TRUE);
        llSetStatus(STATUS_ROTATE_X | STATUS_ROTATE_Y | STATUS_ROTATE_Z, FALSE);
        
        currentPulse      = startPulse;
    } 
     
    state_entry() 
    { 
        llSetStatus(STATUS_PHYSICS, TRUE);
        llSetStatus(STATUS_ROTATE_X | STATUS_ROTATE_Y | STATUS_ROTATE_Z, FALSE);
        
        llListen(0, "", llGetOwner(), ""); 
        
        currentPulse      = startPulse;
    } 
     
    touch(integer num_detected)
    {
        currentPulse      = startPulse;
        
        setVelocity(<0, 0, currentPulse>);
    }

    listen(integer channel, string name, key id, string message) 
    { 
        list command = llParseString2List(llToLower(message), [" "], []);
        
        if (llList2String(command, 0) == "die")
        {
            llDie();
        }
        else if (llList2String(command, 0) == "reset")
        {
            llResetScript();
        }
        else if (llList2String(command, 0) == "bounce")
        {
            llApplyImpulse(-llGetMass() * llGetVel(), FALSE);
            
            setVelocity(<0, 0, currentPulse>);
        }
        else if ((llGetListLength(command) > 1) && (llList2String(command, 0) == "pulse"))
        {
            startPulse        = llList2Float(command, 1);
            currentPulse      = startPulse;
        }
    }

    collision_start(integer num_detected)
    {
        currentPulse *= damping;
        setVelocity(<0, 0, currentPulse>);
    }
}

If i recall right, this is server-side 'optimization' if you can call it that -- an item which is detected to move by less than some sort of defined distance from one frame to another is forcefully frozen and marked as no longer physical, to ease server load when calculating physics. So your ball is very likely to get stopped near the top of its bounce, where the movement for brief period is minimal.

I had fun with this one! I set damping = 1.1. Ball was in a room and then it gradually went faster and faster, just like the ball in Men in Black film. Eventually, it penetrated ceiling and disappeared! I dont know where it went.

After setting things back to normal damping...

I put a timer in the script to reset every 10 seconds, which prevents the stall, but this is not a good fix. Is there any solution to the stall that occurs? Even when it stalls, llGetStatus(STATUS_PHYSICS) returns 1.

I'm very much a scripting newbie and was quite amused when I rezzed a bouncing ball from a sky platform up some 452m and had to run down to the surface to retrieve the ball. On the following very basic script, what do I need to do to set the point of origin to 452 meters high so that the ball stays on that horizontal plane while bouncing up and down?

default
{
on_rez(integer x)
{

llResetScript();
}
state_entry()
{
llSetStatus(STATUS_PHYSICS,TRUE);
llSetStatus(STATUS_PHANTOM,TRUE);
llCollisionSound("c02681b3-52f3-dfa0-416b-3f414fb01aef",1);

}
land_collision_start(vector x)
{
llSetStatus(STATUS_PHYSICS,FALSE);
llSetPos(llGetPos() + <0,0,2>;
llSetStatus(STATUS_PHYSICS,TRUE);
}

}

After playing with the Pos parameters above, I'm quite thankful that some parcels have no Object Entry settings!

I appreciate anyone's help on this

Charmaine

Some suggestions re pin ball projects.

Working with physical objects is very tricky. They are easy to lose. While experimenting and testing, ALL physicl objects should have a doomsday timer in them so that after x minutes they llDie() if you lose them.

Keep local copies of all scripts in your computer. When they get lost or Die, the script goes with them unless you have an open copy on screen.

Physical objects will penetrate non physical barriers, and the criteria for penetration is obscure. It seems to be a mixture of velocity at impact and thickness of the barrier. I think it is also a function of the distance from the center of the object to the edge in relationship to the thickness of the barrier. Even at very slow velocity they can work their way through. For safety too, work in a hollowed out hole in the ground.

I also a script to recover lost physical objects. Listen for a SHOUT chat in a private channel and when hearing the Recover code do
llSetStatus(STATUS_PHYSICS, FALSE);
while (llVecDist(llGetPos(), home) > 0.01) llSetPos(home);
llSetStatus(STATUS_PHYSICS, TRUE);
where home is set by an llGetPos() at entry.

If doing a pinball, don't rely on the sloping panel and gravity to roll the ball to the bottom. Put it on a slope for appearance but add a horizontal force to the ball in the direction of the slope to simulate gravity. THat way it won't get stuck in invisible pockets.

I heard the best way to keep a ball moving is to make it hollow and place a small physical ball inside of it.

The interference between the two physical objects keeps the physics engine happy.

Heck I heard it was a hamster we were supposed to put on the inside.

Oh, so how do we place a small physical ball inside it?

did you hear that from Richard Gere?