llMoveToTarget tips

I need to script a fairly high-prim elevator that needs to be able to move people who are standing on it. So far, the best solution seems to be to make the actual elevator phantom and use non-physical movement on it, and have a transparent physical prim follow it closely that's the actual elevator. Keeping the visible elevator phantom will prevent collision and/or inter-penetration issues between the objects. Once they get to the top, make sure the physical elevator is above the other one, turn the other one non-phantom, delete the physical one. Or something like that... I'll figure out how to end it without throwing everyone off.

My question is with the damped movement of llMoveToTarget itself. Instead of spending a lot of time figuring it out, I thought I'd ask here. What has been your experience with this? Do you need to add some overshoot to get it to fire an at_target event with tight tolerance? Has anyone tried to make llSetPos movement closely track llMoveToTarget movement? Any handy formulae I could use? I know the damped movement isn't linear, and the two objects separate quite a bit if I use a linear step in the non-phy movement.

Any tips that can jump-start my experiments would be most appreciated And/or any other ideas on how best to achieve this.

Ziggy

Hi Ziggy

I passed you a script in world that came from a freebie elevator.

The key line seems to be

llSetStatus (STATUS_ROTATE_X|STATUS_ROTATE_Y|STATUS_ROTATE_Z, FALSE); 

to constrain the lateral movement of this physical beast.

Not sure if it still works

Thanks, I'll look at it when the grid comes back up. I added the rotation constraints to the state entry function. I'm still having trouble with actually getting to the destination. So:

vector foo;

llTarget(foo, 0.1);
llMoveToTarget(foo, 30);

That should move to foo in 30 seconds, and let me know when it's within 0.1m of foo. The at_target event never fires. If I use a range of 0.5m, it fires. If I move to foo + overshootMargin, it fires.

OK, I looked at that script, and I'm pretty much doing what that's doing I need slower movement though, ~30m in 30s. And that still leaves the issue of getting the non-phy object to track the phy object, or vice versa.

I could hack it I guess... get the phy object to spit out its position every 0.2s, stick those in a list, and make the non-phy object move to those coordinates. Average it out over a few runs. Yech.

Is anyone else noticing changes in the physics engine with today's update? An object that stayed up with an llSetBuoyancy(1.0) call yesterday falls to the ground today.

Also, llMoveToTarget seems pretty jerky on the client. I think it's moving right as far as the server is concerned, because i made the prim say it's position on a timer.

integer Target;

default
{
    state_entry()
    {
        llSetStatus(STATUS_PHYSICS, 0);
        llSetStatus(STATUS_ROTATE_X|STATUS_ROTATE_Y|STATUS_ROTATE_Z, 0);
    }

    touch_start(integer num)
    {
        llSay(0, "moving... physics");
        
        llSetStatus(STATUS_PHYSICS, 1);
        
        llSetTimerEvent(0.2);
        Target = llTarget(llGetPos() + <0, 0, 30>, 0.1);
        llMoveToTarget(llGetPos() + <0, 0, 33>, 30);
    }
    
    timer()
    {
        vector v = llGetPos();
        llOwnerSay((string)(v.z - 30));
    }
    
    at_target(integer tnum, vector v1, vector v2)
    {
        llTargetRemove(Target);
        llOwnerSay("done");
        llSetTimerEvent(0);
        llSetStatus(STATUS_PHYSICS, 0);
        llStopMoveToTarget();
    }
}

The chat output shows a smoothly increasing height, but the client shows the object jerking upwards, at what looks like 1second update intervals. This continues for a few seconds, after which it starts moving smoothly. Removing the timer call doesn't make a difference (I wondered if extra script processing was somehow affecting physics, which it shouldn't).

Again, can someone else try to reproduce this?

I've made a good physical elevator script using llMoveToTarget, but it is designed to work with physical elevator cars (<32 prims).

You have to remember that the issue with physical objects is energy and mass, and using things like llSetForce and llSetBuoyancy eat up a lot of your energy. Energy deficits affect llMoveToTarget as well.

The elevator I made for a friend was hollowed out as much as I could hollow it to get the mass down, and I used a trick to make sure that llMoveToTarget had enough oomph to get it to each destination.

Well, my physical elevator can be one prim, it doesn't matter, because it will be invisible. I need it to closely follow a phantom non-physical elevator, so that it looks like it's the non-physical elevator that's lifting people.

And I understand that buoyancy eats up energy. What I don't understand is why it eats up more energy today than it did yesterday

I'll try hollowing the prim to see if it makes a difference. Thanks for that tip.

I saw another complaint abut llSetBouyancy() in another thread. Maybe you are on to something...

More weirdness, this time with client updates.

integer Target;

default
{
    state_entry()
    {
        llSetStatus(STATUS_PHYSICS, 0);
        llSetStatus(STATUS_ROTATE_X|STATUS_ROTATE_Y|STATUS_ROTATE_Z, 0);
    }

    touch_start(integer num)
    {
        llOwnerSay("moving");
        
        llSetStatus(STATUS_PHYSICS, 1);
        
        Target = llTarget(llGetPos() + <0, 0, 20>, 0.1);
        llMoveToTarget(llGetPos() + <0, 0, 22>, 30);
    }
    
    at_target(integer tnum, vector v1, vector v2)
    {
        llTargetRemove(Target);
        llOwnerSay("done");
        llSetStatus(STATUS_PHYSICS, 0);
        llStopMoveToTarget();
    }
}

It gets to the height of 20m, and says done. But the client shows me that the object is still climbing. If I right-click on the object, it snaps back to the height it's supposed to have stopped it.

Edit: It won't do that if I'm standing on the object, but a small cube rising a little distance away from my av will do that. I'm guessing this is a side effect of some 'optimization' about reducing the frequency of client updates

I've seen this behaviour for some time now in the clients.

It usually seems to be partly triggered by physical objects 'passing' through or close to non-phys objects on their llMoveToTarget route. They will just not be rendered in the right position anymore and basically stop showing their movement.

On the dampening effect. I tend to calculate a 'further target' by taking the distance vector between the starting pos and the target pos and multiply this with the target pos and a factor based on the time delta in the move to target. (using llVecDist), you'll get a new target pos in line with the old target, but further away.
I then use llTarget(originalTarget) to see if the actual target pos is reached and switch of the llMoveToTarget.

Thanks. That's what I'm trying to do, and I need to figure out how far the offshoot needs to be. And you're right, it appears to be related to the distance traveled, and the time taken.

My Elevator doesn't seem to have that problem unless there is an extreme amount of lag.

What I do, is set the car to physical, give the lltarget call .2 meters and call llMoveToTarget with a .2m buffer zone. Then, when the at_target event fires, I llSleep the script for 2 seconds (to give the car 2 seconds to finish it's tiny leftover movements after the at_target event fires) and set it non physical. The point of the sleep is to let the car finish moving at the client side before setting it non physical. If I take the llSleep out, the car, from the client perspective, will float into space.. even though you can stand on the empty space where the elevator should be and when I leave the sim and come back, the elevator will be in it's proper spot.

This indicates that giving llMoveToTarget proper time to complete on the client side is important.

OK, I'll try that. That describes what I'm seeing - I can stand on empty space, while the elevator keeps climbing through my body.

One of the tricks I use is a final llSetPos after I turn the car non-physical, but you have to use an at_target which is small, otherwise, it will jump and people can fall through the floor.