Springboards/jump pads?

I've been messing with some different ideas for an arcade theme, and one was to make it Sonic the Hedgehog themed. The idea was to have part of it accessed by the classic springs they've had, as well as trying to have another spring to a friend's plot on the other side of the sim. The problem is, there doesn't appear to be a way to give the avatar a very specific trajectory; Their velocity on impact affects it, and quickly, a chain of springs is useless for travel when they miss the second one.
Are there any suggestions on how to do this so that I can have people bouncing up to my arcade?

Have you tried applying an impulse of the negative of the current velocity before applying a new one?

Is it possible to get the velocity of the avatar?

llApplyImpulse seems to be for the trajectory/velocity of the object that the script is in, which doesn't sound like it would work, since I'm looking for a stationary object to affect a person... Unless I'm misunderstanding?

No, you're right; llApplyImpulse only effects the object it's in. You want llPushObject.

Which is what I was using for the initial push of just <0,0,150>... So I'd have to set it up...

llPushObject(llDetectedKey(0), (<0,0,150> - llDetectedVel(0)), <0,0,0>, FALSE);

Does that sound right?

Yeah, looks like it should send the avatar straight up to me. My first post was stupidly worded, soz, you're quite right that it should all be done in one.

Thanks for all the help. I've done very little with physical objects and pushes, so I'm still learning about these things. It does seem to help, but I'm still getting some drift to one way or another...

Afraid I've only been playing with them the last few days myself. There does seem to be too much drift in general, I guess it's something to do with the script and the physics engine not being in sync.

You could probably add some volume detect prims in the path to apply extra pushes in the x and y axes to stop it going too far off course.

Well, the other idea I had was to do a ring boost system, like later Sonic games have had... however, the reason for the springs was to make it low-prim, and if I have to make a guiding system to correct along the path, or a path of rings, it sort of defeats its own purpose.

May I recommend a trip to "The Future" sim. Seifert Surface has some interesting transportation methods which involve pushing your avatar around, perhaps you could find out how he managed to negate the avatars current velocity.

You could rez temporary ones when someone jumps on the spring. Temp on rez is awesome.

I've been playing around with this today and here's what I've got so far. Put the script in a small phantom prim, set the des_pos as a vector some distance from the prim. Then stand close to the prim and click it (<strike>I didn't include any code to check how close the avatar is, will do that eventually</strike> EDIT: updated the script with the distance detection). The prim moves to the avatar's coords and pushes with sufficient impulse to give it a velocity to reach position "des_pos" in time "time" seconds. If you'd like to give it a go come along to my place and click the tiny cylinders.

//Springboard script by nand Nerd
default
{
    state_entry()
    {
        //llVolumeDetect(TRUE); // for use with collision_start
    }
    
    touch_start(integer num_detected) // this could be collision_start
    {
        integer Detected;
        for(Detected = 0; Detected < num_detected; Detected++)
        {
            vector cur_pos = llDetectedPos(Detected); // used to calculate the offset between avatar and destination (below).
            vector store_pos = llGetPos(); // used as a return position when we move prim to centre of avatar.
            if (llVecDist(store_pos, cur_pos) > 5.0)
            {
                llSay(0, llDetectedName(Detected) + " please stand within 5m of the springboard prim.");
            }
            else
            {
                key DetectedKey = llDetectedKey(Detected); // store the key of the avatar we're going to push.
                //vector cur_vel = llDetectedVel(Detected); // for attempting to counteract avatars current velocity (didn't work).
                //vector cur_vel = ZERO_VECTOR; // see above.
                float mass = llGetObjectMass(DetectedKey); // used for velocity to impulse calculation.
                vector des_pos = (vector)llDeleteSubString(llGetScriptName(),0,llSubStringIndex(llGetScriptName(),"<") - 1);
                //vector des_pos = <109,196.5,46>; // destination, tweak this to get the desired jump. 
                                                    // This could more accurately described be the apex of the jump.
                float grav = -9.8; // acceleration due to gravity.
                float time = 2; // time in seconds you'd like to take to reach destination (apex of jump). 
                                //  This defines the speed (and violence) of the springboard.
                
                float dist_z_apex = des_pos.z - cur_pos.z;  // Z-component of distance to apex.
                float vel_z = (dist_z_apex - 0.5 * grav * llPow(time, 2.0)) / time; // Z-component of velocity using v = ut + 1/2 a t^2
                
                vector horiz_displacement = <des_pos.x, des_pos.y, 0> - <cur_pos.x, cur_pos.y, 0>;
                float dist_horiz = llVecMag(horiz_displacement); // distance of horizontal displacement.
                float vel_horiz_mag = dist_horiz / time; // v = s / t
                vector vel_horiz = vel_horiz_mag * llVecNorm(horiz_displacement); // multiply the magnitude with the direction.
                
                vector vel = <vel_horiz.x, vel_horiz.y, vel_z>; // combine horizontal and vertical components of velocity.
                
    //            vel = vel - cur_vel; //attempt to overcome initial velocity (doesn't work for me).
            
                vector Impulse = vel * mass; // calculate impulse required to move mass at velocity vel.
    
    //            Impulse = Impulse * llPow(llVecDist(llGetPos(), cur_pos), 3); // counteract 1/r3 falloff.
    
                llSetPos(cur_pos); // move to avatar's position, this way you reduce the 1/r3 falloff to zero.
                llPushObject(DetectedKey, Impulse, ZERO_VECTOR, FALSE); // Apply impulse.
                llPlaySound("bc8c684d-d3a8-448b-91ae-0286255e6cea",0.6); // Just wouldn't be right without a sping sound.
                llSetPos(store_pos); // and return to initial position.
            }
        }
    }
}

It looks like you're compensating for distance, so I've got to wonder why you're doing that.

I could never get consistent results using the radius cubed method. Moving the prim to the avatar means it works 99.9% of the time. An alternative I have not yet tried might be an initial push to move the avatar closer to the springboard prim and then fire the push without moving the prim but for the extra work involved and the fact that the avatar would move sideways to begin with just doesn't appeal to me. In the end rezzing an invisible temp-on-rez prim and moving it to the avatar to give the push might not be an elegant solution but it could be the most consistent.

That's interesting to know. I've only just started playing with the physics engine myself, so I'd just assumed it was accurate enough for things like that to work okay. I'm starting to see now that it's pretty damned squiffy.

Well this mainly applies to llPushObject and it's drop-off of 1/r^3. It could be something to do with energy levels too since I'm using a relatively small prim. I'm just happy to have found a method which works. Further experimentation should provide alternative methods.

Checked out your land today; I was impressed all-around. Lot of neat little items, and the spring setup you've devised is surprisingly accurate. The only problem I've run into is that if the character is too far away, then issues can arise with the destination.

Indeed, this can be solved by having the avatar sit on an object which then unsits them and applies the llPushObject. Alternatively you could reduce the range allowed in the script I posted on the previous page, this would require the avatar to stand closer and improve accuracy.