Problem with LLMoveToTarget

Hi,

I am trying to make an object move smoothly back and forth between two positions. So rather than using llSetPos, which made the movement to jerky, I have made my practice cube physical and am using llMoveToTarget. Up to a point, my script works and the cube is moving back and forth.

Two problems:

a) the scripts stops sooner or later for no apparent reason. The cube stops moving, no error message appears. I suspect that it might have something to do with physics, but can´t find anything.

b) the cube emits particles when changing direction. Is there a way to stop that?

All help appreciated.

I don't really know, what the causes the first problem - maybe if you post your script, we could find out what the problem is.

The second is quite easy though - only you see the «particles» it's when the script fires the llMoveToTarget and indicates that something's happening now. And you, as the creator, gets a feedback on this with this particle ring...

Thanks Haruki,

It is a relief to know that I am the only one seeing the particles - it looks silly.

I have posted the script underneith, as it is right now. I am pretty new to scripting, so be merciful

What baffels me even more than the fact that the cube stops at all is that it sometimes stops after just a few changes of direction, and sometimes lasts longer. If it had to do with physics, shouldn´t it then behave predictably?

Penn

Script:

integer targetId;
integer number;
vector erstePosition = <89.4, 245.3, 68.1>;
vector zweitePosition = <94.4, 245.3, 68.1>;
float speed = 1.5;
float braking = 0.5;
vector target;


default
{
touch_start(integer total_number)
{
llSetRot(ZERO_ROTATION);
llSetPos(erstePosition);
llSetStatus(STATUS_PHYSICS, TRUE);
target = zweitePosition;
targetId = llTarget( target, braking);
llMoveToTarget (target, speed);
llSay(0, "starting from default, going to zweite Pos.!";
}

at_target (integer number, vector ourtarget, vector ourpos)

{
llSay(0, "arrived at zweite POistion";
llTargetRemove(targetId);
target = erstePosition;
targetId = llTarget( target, braking);
llMoveToTarget (target, speed);
state fro;

}


}

state to

{

state_entry()
{
llSay(0, "state to!";
}

at_target (integer number, vector targetpos, vector ourpos)

{
llSay(0, "arrived at zweitePostion";
llTargetRemove(targetId);
target = erstePosition;
targetId = llTarget( target, braking);
llMoveToTarget (target, speed);
state fro;

}

touch_start(integer total_number)

{
state stopCube;

}


}

state fro

{

state_entry()
{
llSay(0, "state fro!";
}

at_target (integer number, vector targetpos, vector ourpos)

{
llSay(0, "arrived at erstePositoion";
llTargetRemove(targetId);
target = zweitePosition;
targetId = llTarget( target, braking);
llMoveToTarget (target, speed);
state to;

}

touch_start(integer total_number)

{
llSay(0, "gestopped";
state stopCube;

}

}

state stopCube

{

state_entry()
{
llStopMoveToTarget();
llTargetRemove(targetId);
llSetStatus(STATUS_PHYSICS, FALSE);
llSetRot(ZERO_ROTATION);
llSetPos(erstePosition);
llSay(0, "Fertig";
state default;
}


}

make it stop talking, and the particles will stop.

Hi Winter,

I commented them out, and the particles stopped. Thank you. THat is one problem solved.

The other persists. Sometimes the cube stops after 4 changes of direction,sometimes after 6 or 5, a few times after 30 or 40..

I noticed that every now and then there are slight hickups in the movement, when the cube goes back a little ways, and then continues in the right direction.

Any ideas?

Perplexed greetings,


Penn

Hi Pennsylvania

I think I'm having a very similar thing with one of my physical objects that uses llMoveToTarget.

Everything works perfectly for an unpredictable amount of time; often overnight but usually between, say, an hour and two. Very occasionally for a few minutes only. Then it just stops.

Has been driving me nutz for the last few months. I've sat watching it, timing it, counting it and can not find any pattern.

I've found tho', that if I give it a "nudge" (left or right-click), and without doing anything else, off it goes merrily on its way for another, again, unpredictable amount of time before stopping.

Perplexing and frustrating. My fingers are crossed that Havok4 might help, altho' I haven't yet been over to Beta to try.

So sorry I can't be more help, but do empathise.

Hopefully someone might be able to make a few suggestions, and I'll be watching this thread with interest

perhaps it's running out of Energy?

I fumbled around a little with the script (and stripped it down a little and I've got the object moving now for quite a while without stopping...

Try it - maybe it works for you as well...

btw - when you print out Debug-Informations, use llOwnerSay instead of llSay - this way, only you can see the print-outs and the main chat won't be spammed...

integer targetId;
integer number; 
vector erstePosition;
vector zweitePosition;
float speed = 1.5;
float braking = 0.5;
vector target;

integer whichPosition;  // determines in which direction we're going
integer running;        // BOOLEAN -> state of the object

default
{
    state_entry()
    {
        erstePosition = llGetPos();     // Get the actual Position of the object
        zweitePosition = erstePosition;
        zweitePosition.x += 10;         // 2nd-Position X-Value is original Position X-Value + 10
        
        running = FALSE;
    }
    
    touch_start(integer total_number)
    { 
        if(running == FALSE)
        {
            running = TRUE;
            whichPosition = 1;             // For the first move, we're going to the 2nd position
        
            llSetRot(ZERO_ROTATION);
            llSetPos(erstePosition);
            llSetStatus(STATUS_PHYSICS, TRUE);
            
            // Do not rotate the object around any axis while moving - comment this out, if you 
            // want it to rotate while moving
            llSetStatus(STATUS_ROTATE_X | STATUS_ROTATE_Y | STATUS_ROTATE_Z, FALSE);
            
            target = zweitePosition;
            targetId = llTarget( target, braking);
            llMoveToTarget (target, speed);
            llOwnerSay("starting...");
        }
        else
        {
            running = FALSE;
            llStopMoveToTarget();
            llTargetRemove(targetId);
            llSetStatus(STATUS_PHYSICS, FALSE); 
            llSetRot(ZERO_ROTATION);
            llSetPos(erstePosition); 
            llOwnerSay("stopping...");
            state default;
        }
    } 

    at_target (integer number, vector ourtarget, vector ourpos)
    {
        //llOwnerSay("arrived at zweite Positiontion");
        //llStopMoveToTarget();
        llTargetRemove(targetId);
        
        if(whichPosition == 1)
        {
            whichPosition = 0;
            target = erstePosition;
            
            //llOwnerSay("Going back to first position");
        }
        else
        {
            whichPosition = 1;
            target = zweitePosition;
            
            //llOwnerSay("Going to 2nd position");
        }
        
        targetId = llTarget( target, braking);
        llMoveToTarget (target, speed);
        
        //state fro;
    }
}

HTH...

Haruki,

you are a genius. As I type that the cube is nicely going back and forth, no slacking, no indecision, no hickups. And has been for a few minutes.

I will now stare at your script until I figure out why it works and mine doesn´t...

You are right about llSay of course, but then how can I make innocent passers by help me debug my cube? Misery needs to be shared, and I was very frustrated yesterday.

Thanks a lot. After Debbies post I was beginning to worry that I had discovered a bug in LSL in my second script ever...



@ Debbie

You are right, that is exactly the behaviour my cube was showing. It would stop, and after clicking it, it would start again, but usually tumbling and rotating wildly. And frequently it would keep going for quite a while, but tumbling is no use to me, I need my object well behaved...

Maybe you can figure out from Haruki´s script where the problem is..


@ Winter

I had read about objects running out of steam someplace but couldn´t find it again. Thats why I wondered if it was not some strange feature of pysical objects...But it didn´t really make sense, then it would have had to stop after about the same time each time. And besides, wouldn´t llMoveToTarget impart new energy every time?

Not that I know what I am talking about. But thanks for the link, it´s very educational. Maybe I will figure this out eventually.




Oh no,just when I finished writing this, the cube stopped again....

This cube will drive me insane, I know it.

Penn

opps. Sorry to hear that.

I just this minute returned to this thread to sit down & examine the differences between your original script & Haruki's ~ but doesn't seem much point now

I will have a look at the possible effects of "energy" tho', as suggested by Winter



Yep!

Hi Debbie,

yes, I have been rereading the part on energy myself..But it still does not make sense. Which does not mean that is not the answer

From what the article says, small objects aren´t much bothered...So how much mass has the generic 0.5 x O.5 x 0.5 plywood cube? How do I find out the mass anyway? And can I change it?

So many questions to be solved...

Penn

Penny

Sorry to hear, that the script stopped working... I'm a little confused myself by this behaviour... But I'll have another look at it...

As for the tumbling... I recently had the same problem and some nice person here pointed me to llSetStatus(STATUS_ROTATE_X | STATUS_ROTATE_Y | STATUS_ROTATE_Z, FALSE); - this makes a physical object steady...

I'll have another look at the script later and let you know...

P.S. I highly doubt that it's an «energy problem», though...

I'll be back after «House» & «Heroes»

Haruki,

never mind - your script is still running much better than mine. Maybe Debbie and I HAVE discovered a bug in LSL

In the meantime I am having fun dissecting your script. Thanks


Penn

That is one approach. On the other hand, you might like the realism of having it tumble a little when it bumps into things, so another approach is to calulate the rotation you want it to have, and then use llSetRot() now and then (such as once per second or something).

lee

Update,

I have copied the cube with Haruki´s script in it, stretched it much bigger, and got the mass of both cubes. The generic little cube had a mass of about 1.25 lindens, the big cube of more than 86 lindens.

Then I set them to race. The big one lasted a LOT longer..

According to the article on energy the little one should be able to regenerate energy much faster than the big one, so the big one should run out of steam earlier.

Seems to indicate that is is in fact NOT an energy problem...

Still baffled,

Penn

I really don't think that energy is the problem - otherwise it would always stop after a certain amount of turns...

Trying a slightly different approach now - I'll let you know when I succeeded

ok - next try

I moved the script-part, where I turn the object and give it a new direction to a function and added a llStopMovingToTarget in the at_target-event...
It's working for about 20 Minutes now...

Maybe, you wanna give it a try?

integer targetId;
integer number; 
vector erstePosition;
vector zweitePosition;
float speed = 1.5;
float braking = 0.5;
vector target;

integer whichPosition;  // determines in which direction we're going
integer running;        // BOOLEAN -> state of the object

move_it()
{
    if(whichPosition == 1)
    {
        whichPosition = 0;
        target = erstePosition;
        
        //llOwnerSay("Going back to first position");
    }
    else
    {
        whichPosition = 1;
        target = zweitePosition;
        
        //llOwnerSay("Going to 2nd position");
    }
    
    targetId = llTarget( target, braking);
    llMoveToTarget (target, speed);
}

default
{
    state_entry()
    {
        erstePosition = llGetPos();     // Get the actual Position of the object
        zweitePosition = erstePosition;
        zweitePosition.x += 10;         // 2nd-Position X-Value is original Position X-Value + 10
        
        running = FALSE;
    }
    
    touch_start(integer total_number)
    { 
        if(running == FALSE)
        {
            running = TRUE;
            whichPosition = 1;             // For the first move, we're going to the 2nd position
        
            llSetRot(ZERO_ROTATION);
            llSetPos(erstePosition);
            llSetStatus(STATUS_PHYSICS, TRUE);
            
            // Do not rotate the object around any axis while moving - comment this out, if you 
            // want it to rotate while moving
            llSetStatus(STATUS_ROTATE_X | STATUS_ROTATE_Y | STATUS_ROTATE_Z, FALSE);
            
            target = zweitePosition;
            targetId = llTarget( target, braking);
            llMoveToTarget (target, speed);
            llOwnerSay("starting...");
        }
        else
        {
            running = FALSE;
            llStopMoveToTarget();
            llTargetRemove(targetId);
            llSetStatus(STATUS_PHYSICS, FALSE); 
            llSetRot(ZERO_ROTATION);
            llSetPos(erstePosition); 
            llOwnerSay("stopping...");
            state default;
        }
    } 

    at_target (integer number, vector ourtarget, vector ourpos)
    {
        //llOwnerSay("arrived and turning");
        llStopMoveToTarget();
        llTargetRemove(targetId);
        
        move_it();
    }
}

Hope it works for you too!

I will, right away..

Penn

Sorry,

tried it twice, and it stopped.

So I wondered if it had anything to do with our Sim - after all if it lasts for 20 min in yours and only am minute or two in ours, maybe it is the sim.

What I noticed is that our physics FPS fluctuate pretty much. It oscillates between 44 and 25. While the cube was running it even went down to 5 or 6.

Is that sort of thing normal?

Penn

No, that's not normal - and I'm quite baffled that this simple script tears the engine down to 25... THAT's strange...
I don't have that much stuff on the sim I tested it, so it might really be some SIM-Problem...
But if the script uses THAT much of power, I'd recommend not to use it

I'll have a look what it does on my SIM... But It'll take some time - just ran into a B-Day-Party in SL

I'll get back to ya...

No, the fluctuation between 25 and 45 is without the cube running. But when it was running it went down to 5 or 6.

Of course there might be something else going on at the sim, but i don´t know what it might be. I don´t think we have anything else physical going on. Maybe the neighbors.

Take your time, it is past 11 pm in my timezone, and I should be getting to bed anyway..

This debugging is addictive..

Thanks for your help again,

Penn.

update: Even without the cubes, the fps just went down to 3. there seems to be something seriously amiss around here.

IGNORE: Sorry! Thought I was in a different thread. Of course physical movement may affect physics FPS. I thought I was in the thread about texture animation. Sorry! (IGNORE --> Right. This really shouldn't affect physics FPS. The server has to inform clients about animations, but once it does all the actual rendering is done by the client. <-- IGNORE)

ok - altered the script again (slightly)...

I now make sure that the at_target event only takes action, when it's really the targetID we're calling. Also, I added a llSetPos when the object reaches the target, since the at_target-event fires, when the object comes into the range (0.5) of the target. So it might be, that the moving between two points might confuse the targets over time (this is just a really vague guess, though

Then I increased the speed slightly, just to find out, whether it makes any difference...

Also - make sure you select «Reset Scripts in selection» before starting the whole thing again....

integer targetId;
integer number; 
vector erstePosition;
vector zweitePosition;
float speed = 1.2;
float braking = 0.5;
vector target;

integer whichPosition;  // determines in which direction we're going
integer running;        // BOOLEAN -> state of the object

move_it()
{
    if(whichPosition == 1)
    {
        whichPosition = 0;
        target = erstePosition;
        
        //llOwnerSay("Going back to first position");
    }
    else
    {
        whichPosition = 1;
        target = zweitePosition;
        
        //llOwnerSay("Going to 2nd position");
    }
    
    targetId = llTarget( target, braking);
    llMoveToTarget (target, speed);
}

default
{
    state_entry()
    {
        erstePosition = llGetPos();     // Get the actual Position of the object
        zweitePosition = erstePosition;
        zweitePosition.x += 10;         // 2nd-Position X-Value is original Position X-Value + 10
        
        running = FALSE;
        
        llTargetRemove(targetId);
        llSetStatus(STATUS_PHYSICS, FALSE); 
        llSetRot(ZERO_ROTATION);
    }
    
    touch_start(integer total_number)
    { 
        if(running == FALSE)
        {
            running = TRUE;
            whichPosition = 1;             // For the first move, we're going to the 2nd position
        
            llSetRot(ZERO_ROTATION);
            llSetPos(erstePosition);
            llSetStatus(STATUS_PHYSICS, TRUE);
            
            // Do not rotate the object around any axis while moving - comment this out, if you 
            // want it to rotate while moving
            llSetStatus(STATUS_ROTATE_X | STATUS_ROTATE_Y | STATUS_ROTATE_Z, FALSE);
            
            llOwnerSay("starting...");
            
            move_it();
        }
        else
        {
            running = FALSE;
            llStopMoveToTarget();
            llTargetRemove(targetId);
            llSetStatus(STATUS_PHYSICS, FALSE); 
            llSetRot(ZERO_ROTATION);
            llSetPos(erstePosition); 
            llOwnerSay("stopping...");
            state default;
        }
    } 

    at_target (integer number, vector ourtarget, vector ourpos)
    {
        if(number == targetId)  // Is it our target?
        {
            llTargetRemove(targetId);   // Remove the Target ID so we can set a new one
            llSetPos(ourtarget);    // Make sure the Object ends up at the destination
        
            move_it();
        }
    }
    
    on_rez(integer bla)
    {
        llResetScript();
    }
}

and - it doesn't really affect the physics-engine of my SIM - I have values between 45 and like 40/39...

looking forward to hearing the results

Nice to see you both sticking with it...

My observations of this behavior have not made a connection with Physics FPS. It is a rare day indeed that our sim Physics FPS will go lower than 43, or 42.

Not only that, and as part of testing on this, I've simulataneously rezzed a multitude of the blasted things...and they stop functioning at different (unpredictable) times. Eg: At 4:05pm today I rezzed two; at 4:36pm one stopped but the other is still happily bounding along as I write.

From what I've seen of this, 20mins is far too short a time period to declare success. Often I have seen them go for hours on end & have gotton to a point of thinking I've cracked it, only to wake up the following morning to find a cube begging for a lil to nudge to get him moving again.

The next test I've been meaning to do is to try it out on Havok4 on Beta, but somehow I dont seem to get around to it...perhaps in next few days.

EDIT: Hi Haruki

Just saw your latest script and popped it into a prim.
The 'stop' occurred almost immediately I'm afraid.
I observed it do two different types of stop:
1) a jerky "I'm-trying-to-move-but-can't-quite-do-it" kinda stop and
2) an immediate "stop-in-tracks"
Both respond to a lil nudge.

In my own case I've only observed 2), and have not seen the jerkiness in my own objects.

the thing about Energy.. and why I brought it up.. is that it's not quite as clearcut as it looks on paper.

I made a gun, a hud rezzer. And the idea was really simple, follow the camera orientation and fire. that simple "set buoyancy thing" is all the physics scripting going on in the bullets.. but no matter what I did, even making the bullets fairly small, the trajectory wasn't flat. Even SetBuoyancy was slowly eating away at the energy, enough to the point that the bullet would eventually drift downwards.

I don't remember the incline, but it was something like .5m per 20m. I tried compenating for it, but it was clearly an arc.

I really have my suspicions that among other things, your object may be reacting to "unpredictable chaos" (the particular minute contours and impercections of the ground it's on, the particular rotation, the speed of the wind, etc). It MAY be that you're experiencing friction on the ground, which is bunging up your program, using up energy to the point that it just stops working and runs it's tank empty.

I'm no expert though.. this is WAY out of my area. I just know that energy has done unexpected things to my work.. and that I don't work with physics SPECIFICALLY because of the unpredictable nature of it.