Problem with LLMoveToTarget

Well - this is kinda driving me mad...

Debbie

I have the same behaviour with som turning object in which I use llTargetOmega. They turn fine but sometimes they just stop. When I right click on them (without actually choosing «edit») they start turning again.
I figured that this only happens, when I change the colors per script...

As for the energy: you're right, Winter - it might be that the problem emerges from friction, wind or whatever, as physical objects do respond to this.
What I will try now is put a surface made of glass (which should be «slippery») underneath the cube and see if it lasts longer then...

[edit]

I put a glass surface underneath the cube and made the cube «glass» as well. On the first attempt, it moved _once_ and then stopped and even giving it a «little nutch» didn't move it again...
I had to move the cube upwards, so when it starts moving it doesn't touch the surface underneath - now it's moving... I'll see for how long

2nd - I tried and set physics to FALSE when the object is at the target and turn phyics on again, befor I send it to the other location. Hoping, that this kinda «resets» the physics engine...

[edit 2]

ok - it's something like 3 hours now and the thing is still moving if it keeps moving, I'll post the updated script... but I guess that putting a surface underneath the cube helped... /me keeps fingers crossed

Well - it seems that it's working... at least, it didn't stop until now

below is the actual script... I do think though, that putting a glass-surface underneath the cube helped as well...

And - I shortened the distance between the movings a little - although, I don't think that this was an issue...


Really looking forward on what the results on your side are...

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");
    }
    
    llSetStatus(STATUS_PHYSICS, TRUE);
    llSetStatus(STATUS_ROTATE_X | STATUS_ROTATE_Y | STATUS_ROTATE_Z, FALSE);
    targetId = llTarget( target, braking);
    llMoveToTarget (target, speed);
}

default
{
    state_entry()
    {
        erstePosition = llGetPos();     // Get the actual Position of the object
        zweitePosition = erstePosition;
        zweitePosition.x += 8;         // 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?
        {
            llSetStatus(STATUS_PHYSICS, FALSE);  // Remove the physics so I hope they'll get a «reset»
            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();
    }
}

I believe the object material only affects the collision sound generated. As far as I know it has no effect on physical behavior.

Hmmm - as far as I know, it affects the sliding ability and maybe even the weight (I'm not _that_ sure on the latter one, though)...

[edit]

the weight is definitely NOT affected by the material...

@ Haruki,

I am almost afraid to post, but it is still moving, and has been for at least 15 min....


@ Hewee

I read somewhere that the material of the object influences the friction in physical objects. But don´t ask me where...


Penn

Penn,

I keep my fingers crossed for ya...

The LSL-Wiki clearly says, that glass has the least friction:

http://lslwiki.net/lslwiki/wakka.php?wakka=material

Thanks for your efforts Haruki. Your new code has been successfully running now for some 45mins or so.

I've made similar corresponding changes to my own code and have that running too.

In both cases it is too early to get overly excited, but certainly things look promising.

The changes I've made to my own code are summarised below. Perhaps it might be a good idea for you to summarise your thoughts/conclusions too, as this might be helpful to someone later on down the line. I must say, however that, like Hewee, I am not entirely convinced of the "glass" aspect, but would happily change my mind if it could definitely be shown that it does have an influence.

Summary of my code changes:

1) On initialising operation, use:
"llSetStatus(STATUS_PHYSICS | STATUS_PHANTOM | STATUS_ROTATE_X | STATUS_ROTATE_Y | STATUS_ROTATE_Z, FALSE);"
rather than just
"llSetStatus(STATUS_PHYSICS | STATUS_PHANTOM FALSE);"

2) Add as first line of 'at_target' event:
"llSetStatus(STATUS_PHYSICS, FALSE);"

3) Add as first two lines of the user-defined function that executes the actual move (your function "move_it()", my "MakeMove()":
"llSetStatus(STATUS_PHYSICS | STATUS_PHANTOM, TRUE);
llSetStatus(STATUS_ROTATE_X | STATUS_ROTATE_Y | STATUS_ROTATE_Z, FALSE);"

4) On shutting down the operation, use:
"llSetStatus(STATUS_PHYSICS | STATUS_PHANTOM | STATUS_ROTATE_X | STATUS_ROTATE_Y | STATUS_ROTATE_Z, FALSE);"
rather than just
"llSetStatus(STATUS_PHYSICS | STATUS_PHANTOM FALSE);"

Fingers are crossed

Per http://lslwiki.net/lslwiki/wakka.php?wakka=mass, "The mass of a prim or object, as reported by llGetMass or llGetObjectMass, depends only on its size and shape, not on its material type." (I actually tested this: it's true.)

(And as I think already established, per http://lslwiki.net/lslwiki/wakka.php?wakka=friction, "An object's friction can be changed by modifying its material type."

Thanks for the material/friction reference.

My objects do not run over the ground, and so are certainly not a factor in this case, but it is definitely information that will prove useful for other projects.

Well, it the cube is still going strong...

Since it performs a cute little curtsy at the ends of its travel, one can sort of see what it is doing. Sometimes it does that little curtsy even before it reaches to point of turnabout and then continues in the same direction. I guess the curtsy is the change between physical and nonphysical, or the result of a setPos function. Since it then recovers and goes on in the same direction, it might have discoved that it hadn´t quite gone for enough?

Haruki, apart from the fact that using a function and doing it all in the state default seems a lot more elegant than my script - do you have a idea why your script works much better than mine? I read all the wiki information on llTarget, but really am not much wiser than before. It seems Voodoo to me.

Penn

I don't think this was mentioned above, stick in a llOwnerSay((string)llGetEnergy()); now and then so you can see what's going on with energy. I suspect that it isn't running out of energy that's the problem, but this would confirm it.

If I understand right, the prim is bumping along the floor going back and forth? Have you tried the same script raised up so it's never touching the ground? It might also be possible to have a second script in the object checking the position every few seconds, and if it detects that the prim hasn't moved in a while, nudge the other script in one way or another (llResetOtherScript, or just llApplyImpulse to the prim?). Not sure about that but might be worth a try.

Hi Seifert,

actually, through no planning of mine, the practice cube does not have contact with the ground but is floating a bit above it. But it is no doubt something to keep in mind for the finished machine.

The energy script is a good idea; i tried something like that last night, but the cube stopped working altogether and I was too tired to figure out why.

The cube is still moving, by the way...


Penn

I have to be honest and tell you that I actually have no idea whatsoever why it's working...
It would be _very_ interesting, though, to find this out. All I did so far was guessing and using trial and error...

As soon as I'm inworld I'm gonna try some more stuff (actually, Seifert's hint is worth trying)...
One thought that came to my mind is: if it's really the glassy surface that does the trick, setting the buoyancy to 1 (letting it «float») might help as well...
I really would like to be able to let it bounce forth and back without removing the physical state and using llSetPos (as this really looks like a little hiccup and isn't as smooth as I would like it to have...)

I'll keep you updated on my findings

Have done this. Only ever saw a value of 1.0



This is here how my object operates, it doesn't touch the ground at all. It is also why I'm am unconvinced that friction is the primarily cause.



This might be worth a go, yes. I tried something similar but instead used the 'not_at_target ' event. This was of limited success.

However, I do now use 'not_at_target' to ensure that the object is within a defined area at all times, to cover for those times when physical objects act-up and decide to fall thro' floors, walls and other such wierd things.

EDIT: Air friction? wind friction? just grasping in the dark now!

Next chapter

The major change in this script is, that I took out the part that sets physics to false and turn it on again on the next move.
I turned on buoyancy (this word breaks my tongue), though, to make the object «float» above the ground. I still think, that the friction causes some energy-loss and that this makes the object stop the sooner or later.
I inserted a global variable for the distance, so one doesn't have to look for it within the script.
The setStatus-command is appearing only once, since I think it's enough to tell the object that it shouldn't «tumble» (which seems to work).

I moved the part that determines the 1st and 2nd position to the touch-event, so whenever you move the (stopped) object, it will start from this position when you touch it again.

It's moving for a little while now... but this doesn't necessarily mean, that it keeps on moving... I'm looking forward the the results you guys get

[edit]

I removed the script since the object stopped moving after 10 Minutes... *grrrrrrr*

Evening Haruki

Both yours & mine been going for a little over 5 hours now....so far, so good...

Well - it seems that my little guessing-stuff is working then... good to know...

I failed miserably on stripping it down without all the tweaks, though - which bugs me big time... but I keep on trying

Hi Haruki,

your guessing stuff must have been inspired, because the cube is still running this morning.

I am off to work and will check again late tonight (RL keeps interfering).

Penn

Ambiguous results....

Both your and mine were still running fine some 9 hours after I set them running.

Went to bed...

Checking again now, almost 15 hours after the test began, yours is running fine but mine has stopped. I little nudge sent it on its way again...

I'm starting to wonder if the product should be marketed as "Comes with free Auto-SwitchOff feature..."

Hi Haruki

Well, 26 hours on, and your is still moving to & fro. So, congrats on that!

Mine, however, continues to to what it always has; moves nicely for an unpredictable number of hours, giving the false impression that the problem has been solved, until stopping; even tho' I've tried to apply the principles of your code to mine

My code is a little more complicated:
0) Store the start position
1) Define a list of 19 random offset vectors from the starting position
2) Add as the first vector in the list an offset vector of <0.0, 0.0, 0.0> (return to start position)
3) Use 'llMoveToTarget' to cycle thro' the list of vector offsets
4) After performing the last vector offset, pause for a random amount time between 10 and 20 seconds
5) Repeat from 1)

Just to make it a little more exciting, the movement has to be performed on a raised platform ( a 5m x 5m x 0.10m square is plenty). For this, testing on the ground isn't enough.

For more details, on what it is trying to achieve, see /54/26/229025/1.html

If you feel up to another challenge, I'll post a cut-down version of the whole script containing only the relevant code. If, however, your sick-to-death of llMovetoTarget, I can't say I blame you

*smile*

Well, Debbie - I'd be more than happy to test it...
But meanwhile, I have the suspicion, that the llSetPos()-Command alongside with the llStopMoveToTarget() in the at_target-event, is what the problem solved...

But feel free to post the code snippet - I'll see if I can get it moving

Cheers

H

Hi Haruki,

The cube is still going I am ready to call it a success.

I will try to get the Set_status PHYSICS FALSE out of the script, though. I had a bit of a shock last night, because apparently you cant set an object to physical if it is intersecting another object. Since the idea is to build a saw that cuts through a block of stone, that is a problem..

I really wish llMoveToTarget would also work on nonphysical objects.

Penn

I think you might be able to if the physical object is also phantom....

OK, I will try that..

Having the other object phantom is not enough, I tried that.

Penn

..Proudly Presents: "The Script That Tricks You Into Believing It Works"

This striped-down version of my main script contains only the essential elements relating to llMoveToTarget. It has been running beautifully for nearly two hours now. If gambling had not been banned, I'd likely be taking spread-bets on when it will stop...

In summary:
1) Initialise
2) 'Touch' to save start position (vector 'startCheck'), populate the first list of random offset vectors (list 'checkPoint' is populated in function CheckPoints()). Get started
3) StartOperation() sets the initial llMoveToTarget() and llTarget() values. Its main purpose is to generate the first 'at_target' event
4) 'at_target' determines which list offset is to be used this move. When the last in the list has been processed, it resets the list counter, turns the physics off (in StopOperation()), generates a new series of random offsets and then pauses for between 10 and 20 seconds.
5) At the end of the pause time, timer() kicks-in to perform the next move.
6) 'not_at_target' simply attempts to detect if the object falls under the start position z-vector, and if so, re-postions & restarts the operation (as I write this, I'm wondering if this is where the problem lies)

Enjoy! or something....

integer CheckPointsSet = FALSE;
list checkPoint = [];
vector startCheck = <0.0,0.0,0.0>;
integer thisCheck = -1;
vector startingPoint = <0.0,0.0,0.0>;
float metersPerSec = 6.0;
integer targetHandle = 0;
float SoundVolume = 1.0;
float SleepMin = 10.0;
float SleepMax = 20.0;


CheckPoints()
{

    //start with a clean slate
    checkPoint = [];

    // NB: the order that the following lines appear in is important. Do not change or subject checkPoint to llListRandomize.
    // now we'll set some random jump points as offsets of the start position
    // jump to the left & right & up
    checkPoint += (list)<(0.40 + llFrand(0.35) * -1), 0.45 + llFrand(0.25), 0.75 + llFrand(0.55)>;
    // and return back down to the same z co-ord as Start Point, but with some right & left offset
    checkPoint += (list)<0.55 + llFrand(0.25), (0.45 + llFrand(0.45) * -1), 0.00>;
    // jump to the left & right & up
    checkPoint += (list)<(0.45 + llFrand(0.35) * -1), 0.45 + llFrand(0.25), 0.45 + llFrand(0.75)>;
    // and return back down to the same z co-ord as Start Point, but with some right & left offset
    checkPoint += (list)<0.35 + llFrand(0.25), (0.45 + llFrand(0.45) * -1), 0.00>;
    // jump to the left & right & up
    checkPoint += (list)<(0.55 + llFrand(0.50) * -1), 0.45 + llFrand(0.35), 0.65 + llFrand(0.85)>;
    // and return back down to the same z co-ord as Start Point, but with some right & left offset
    checkPoint += (list)<0.45 + llFrand(0.45), (0.45 + llFrand(0.45) * -1), 0.00>;
    // jump to the left & right & up
    checkPoint += (list)<(0.48 + llFrand(0.35) * -1), 0.45 + llFrand(0.30), 0.70 + llFrand(0.55)>;
    // and return back down to the same z co-ord as Start Point, but with some right & left offset
    checkPoint += (list)<0.45 + llFrand(0.35), (0.55 + llFrand(0.45) * -1), 0.00>;
    // jump to the left & right & up
    checkPoint += (list)<(0.45 + llFrand(0.35) * -1), 0.45 + llFrand(0.25), 0.95 + llFrand(0.35)>;
    // and return back down to the same z co-ord as Start Point, but with some right & left offset
    checkPoint += (list)<0.35 + llFrand(0.25), (0.45 + llFrand(0.45) * -1), 0.00>;
    // jump to the left & right & up
    checkPoint += (list)<(0.45 + llFrand(0.35) * -1), 0.45 + llFrand(0.25), 0.55 + llFrand(0.55)>;
    // and return back down to the same z co-ord as Start Point, but with some right & left offset
    checkPoint += (list)<0.35 + llFrand(0.25), (0.45 + llFrand(0.45) * -1), 0.00>;
    // jump to the left & right & up
    checkPoint += (list)<(0.45 + llFrand(0.35) * -1), 0.45 + llFrand(0.25), 0.75 + llFrand(0.55)>;
    // and return back down to the same z co-ord as Start Point, but with some right & left offset
    checkPoint += (list)<0.35 + llFrand(0.25), (0.45 + llFrand(0.45) * -1), 0.00>;
    // jump to the left & right & up
    checkPoint += (list)<(0.40 + llFrand(0.40) * -1), 0.45 + llFrand(0.35), 0.35 + llFrand(0.55)>;
    // and return back down to the same z co-ord as Start Point, but with some right & left offset
    checkPoint += (list)<0.35 + llFrand(0.25), (0.45 + llFrand(0.25) * -1), 0.00>;
    // jump to the left & right & up
    checkPoint += (list)<(0.45 + llFrand(0.35) * -1), 0.45 + llFrand(0.25), 0.55 + llFrand(0.75)>;
    // and return back down to the same z co-ord as Start Point, but with some right & left offset
    checkPoint += (list)<0.15 + llFrand(0.15), (0.15 + llFrand(0.15) * -1), 0.00>;
    // jump to the left & right & up
    checkPoint += (list)<(0.05 + llFrand(0.15) * -1), 0.05 + llFrand(0.15), 0.25 + llFrand(0.65)>;

    // the first offset in the list should equal the Start Position
    checkPoint = (list)<0.0,0.0,0.0> + checkPoint;
}


StopOperation()
{
    llSetTimerEvent(0.0);
    thisCheck = -1;
    llSetStatus(STATUS_PHYSICS, FALSE);
    llStopMoveToTarget();
    llTargetRemove(targetHandle);
    llSetPos(startingPoint);
}


StartOperation()
{
    startingPoint = llGetPos();
    thisCheck = 0;
    llMoveToTarget(llGetPos(), 0.5);
    targetHandle = llTarget(llGetPos(), 1.0);
}


MakeMove()
{
    llSetStatus(STATUS_PHYSICS | STATUS_PHANTOM, TRUE);
    //    llSetStatus(STATUS_ROTATE_X | STATUS_ROTATE_Y | STATUS_ROTATE_Z, FALSE);
    vector next = startingPoint + llList2Vector(checkPoint, thisCheck);
    targetHandle = llTarget(next, llVecDist(next, llGetPos())*0.2);
    llMoveToTarget(next, llVecDist(next, llGetPos())/metersPerSec);
}

default
{
    on_rez(integer start_param)
    {
        llResetScript();
    }

    state_entry()
    {
        llSetStatus(STATUS_PHYSICS | STATUS_PHANTOM | STATUS_ROTATE_X | STATUS_ROTATE_Y | STATUS_ROTATE_Z, FALSE);
        startCheck = llGetPos();
    }

    touch_start(integer total_number)
    {
        startCheck = llGetPos();
        CheckPoints();
        StartOperation();
    }


    at_target(integer tnum, vector targetpos, vector ourpos)
    {
        // llSetStatus(STATUS_PHYSICS, FALSE);
        llTargetRemove(targetHandle);
        if(thisCheck == llGetListLength(checkPoint)+-1)
        {
            thisCheck = 0;
            MakeMove();
            StopOperation();
            CheckPoints();
            float SleepDiff = SleepMax - SleepMin;
            float SleepTime = SleepMin + llFrand(SleepDiff);
            llSetTimerEvent(SleepTime);
        }
        else
        {
            thisCheck++;
            MakeMove();
        }

        // play sound effect when at Start Position z co-ord (odd number positions in list)
        if (((thisCheck % 2) != 0) && (SoundVolume > 0.00))
        {
            llPlaySound("c02681b3-52f3-dfa0-416b-3f414fb01aef",SoundVolume);
        }
        // at_target end
    }


    not_at_target()
    {
        vector TempVector = llGetPos();
        if (TempVector.z < startCheck.z)
        {
            StopOperation();
            StartOperation();
            thisCheck = (llGetListLength(checkPoint)+-1);
        }
    }

    timer()
    {
        llSetTimerEvent(0.0);
    //    StartOperation();
        MakeMove();
        // timer end
    }

    // default end
}

EDIT: value SleepMin should be 10.0, not 1.0