Softening jerky movement

Hi guys,

I made this little script, from a Lee Ponzu original, to put in a coin, for a coin-toss effect. It is incredibly bad.

a) The coin never starts from where I rezz it, always likes to drift to where I first rezzed it when I first put the script inside.

b) Sometimes the spin on the coin seems to do 10 quick rotations, then stops for a split second, then repeats. At other times it just vibrates.

c) I need to modify the script so that it decellerates as it reaches the nadir, then accelerates as it falls, (regular gravity effect).

Any suggestions for improvement most welcome.

Rock

vector startpos;
vector topoftoss;
float interval;
integer going = 1;

default
{
    state_entry()
    {
        llTargetOmega(<1,0,0>,2*PI,2.5);// Spins the coin: vector, spin rate, gain (not really used)
       
        here = llGetPos(); // Starting point
        topoftoss = startpos + < 0,0,2>; // Top of the toss (2m upwards)
        interval = 4;
        llSetTimerEvent(interval);
        llMoveToTarget(here,interval);
    }
    
    timer()
    {
        vector next;
        if(going)
            next = topoftoss;
        else
            next = startpos;
            llMoveToTarget(next,interval);
            going = !going;
    }

}

start by moving your state entry code to on rez, since state entry only gets called on compile or script reset, that would be why it's remembering it's old position.

inteval should really be a float.

you should probably either inline your if/else staments, use braces, or at least unindent you last 2 lines in timer, since they are visually confusing.... and since you never stop the timer (I'd assume you'd want to do that in the else part) it'll just keep bouncing up and down...

if you want a gradually slowing rise, and a speedier fall, you'll want to do the move to target in more steps, either varying the time between calls, or the amount moved...

as for the weirdness with spinning, that's probably an issue with rendering speed, so not so big a deal since it's per client

Never trust physical movement or rotation to be accurate or predictable.

There are way too many factors that can make it behave differently than it "should".

Also, there is a constant TWO_PI which you should use instead of 2*PI. Saves you 1, 2 μsec...

Many thanks guys for the suggestions. I have incorporated them all (apart from the gravity effect, which I am still trying to figure out).

The new code is as follows:

vector StartPos;
vector TopOfToss;
float interval;
integer going = 1;
integer tosses = 5;

default
{
	on_rez(integer start_param)
	{
		llTargetOmega(<1,0,0>,TWO_PI,2.5);// Spins the coin: vector, spin rate, gain (not really used)

		StartPos = llGetPos(); // Starting point
		TopOfToss = StartPos + < 0,0,2>; // End point (2m upwards)
		interval = 4.0;
		llSetTimerEvent(interval);
		llMoveToTarget(StartPos,interval);
	}

	timer()
	{
		vector next;
		if(going) next = TopOfToss;
		else next = StartPos;

		llMoveToTarget(next,interval);
		going = !going;
		--tosses;

		if(tosses == 0)
		{
			llDie();
		}
	}
}

In order that it doesn't continue to spin and toss forever I have put in a 'Tosses' variable, which is set here at 5, and counts down to zero at which point the coin dies (hope this is what you meant Void).

Again, any comments or suggestions welcome.

Rock

Just an (untested) thought, but since it's calling llMoveToTarget, this already must be a physical coin, so... is there some reason not to just "toss" it with a little llApplyImpulse? Or, if it's rezzed by script (as from an attachment, say, using llRezAtRoot or llRezObject), perhaps just give it an upward initial velocity? the idea being to lose the llMoveToTarget altogether and let "gravity" do its own work.

Are you sure? I thought the built in constants were faster...

@Rock:
I was thinking of a single coin toss (as in what you do to choose sides before a game?) but if you meant like a habitual thing where it's constant (which I didn't think of immediately) then whatever limit is fine...

@Qie:
good idea, one problem. how does the coin know where to stop letting gravity do it's work... I suppose you could steal inital position from a rezzed version, and use that... dunno about specifics of where rez at root actually IS on an attachment... would it default to av center (ie where the sun don't shine)?

@Bobby:
yes, the built in constant should be faster, that's what squirrel was saying

@Rock again:
if you split upward movemnt into for steps of 1 second, and called move to target at a smaller interval each time (.4, .2, .1 perhaps) with a matching tau of 1, and then reversed those steps on the way down that could mimic gravity

Oh, hah! I get it. I was gonna have it fall on the ground, as in a "proper" sporting event. If it's instead supposed to keep flipping back into the avatar's hand, then the problem is complicated by the fact that the hand will be a moving target--and llMoveToTarget is in region coordinates, so that's not going to work very well, especially if the avatar is walking around flipping his coin. If that's the desired effect, I kinda think the coin will work better as an attachment, and the motion (smoothed by several slave llSetPos scripts?) synchronized with a (non-looping) toss animation.

Yes guys, the coin toss is not for a game.

My friend is creating the pose of the 1950s cool dude, back to a wall, left leg bent backwards so the sole of his foot is on the wall, cross-armed, he then puts his hands into his pockets, and after 6 seconds takes one of them out (with the coin), and then starts to flip his coin up and down, say, 5 or 6 times, then hands back in pockets, then back to start of animation.

I was given the job (despite my very limited scripting skills) of producing the coin-toss motion

So, given that the coin should rise from the hand and fall back to the hand, 5 or 6 times, and with the appearance of gravity, and maybe with the hand moving slightly (or possibly to be extended to a walking anim) would the forum recommend I go the physical object route? I also thought of an attachment (invisible) on the hand that rezzed the coin, which did its toss, but which died after falling back to its original Z-axis value, then the attachment spawns another, and does this 6 times. Any merit in that approach?

TIA

Rock

If the avatar was gonna stand still during the toss, I'd be inclined to try that approach. I'd have to experiment, though, to make sure the coin could always quickly enough detect when it falls back through the original Z. (Also, this won't work on no-build parcels. And none of this will work on no-script parcels unless it's in an attachment that has taken controls before entering the parcel.)

But if the agent is ever going to move (not just the animation moving the avatar, but walking around), then this is gonna look very strange unless the thing being tossed is itself an attachment, so it can move back and forth relative to the attachment point (which will appear to track the avatar's animated motions).

I also toyed with making the coin be a particle emitted by an attachment. It should be pretty easy to get the up and down motion to look perfect with particles (have it target self, with an initial upward acceleration), but the spinning part seems pretty hopeless: the emitted particle could change its x or y scale during its path, but at best that would look like it spun a half-turn over the whole arc. Or, one could call llParticleSystem in a loop to emit particles of different scales (or even different textures), forming an arc, but I'm not sure it could be done fast enough to effect compellingly continuous motion... maybe.

A very different approach might be to turn it from a scripting to a texturing problem, with the whole coin toss being an animated texture on a simple prim. For that to look reasonable, though, animation of the point of attachment would have to be perfectly still during the toss, and agent motion (walking around) would be pretty constrained. (It might look okay if he walks forward while the coin texture is flipping, but it would look pretty weird if he turned and the coin turned in mid-air along with him. Although I guess that applies to the attachment approach, too.)