Jump to content

llStopMoveToTarget() does not stop avatar


Badena Atheria
 Share

You are about to reply to a thread that has been inactive for 1560 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

I encountered the problem that once my avatar was launched to go to a location by llMoveToTarget() from a hud script she could be stopped by llStopMoveToTarget(). The script did not respond to any inputs as long as target has not been reached. The workaround I finally found in order to manage manually an early stop is  (1) to launch llMoveToTarget() in a separate script, and (2) to stop the motion at any time with llResetOtherScript(<script name where the llMoveToTarget is in>). Hope this is of some help :)

Link to comment
Share on other sites

Ahhh ... yes, you are right :) The problem is caused by a workaround to overcome the 64m limit of llMoveToTarget(). I had the idea to use a while loop with the norm vector, thus dividing whatever distance in fitting bits of sections. My avi walks then smoothly even across large distances within a region. Orientation on a golf course is a problem, to find your way to a certain tee box. So I can walk to any tee box in a region, with arriving in its vicinity. A manual stop is helpful when something blocks the path. Here comes the script (The menu is based on prim buttons).

integer distance;
integer distancePrevious;
integer link;
integer switch = FALSE;

vector target = <128.0, 128.0, 24.0>;
vector vGoTo;

default{
    touch_start(integer n){
        link = llDetectedLinkNumber(0);
        if(link == 33){
            switch = !switch;
            if(switch){
                distance = llRound(llVecDist(llGetPos(), target));
                distancePrevious = 1000;  // freely chosen for the start of the loop, larger than the distance to the target
                while(distance > 2){
                    if(distancePrevious != distance){
                        vGoTo = llGetPos() - 5.0*llVecNorm(llGetPos() - target); // walking 5m in 5seconds
                        llMoveToTarget(vGoTo, 5.0);
                        llSleep(5.0);
                        llStopMoveToTarget();
                        distancePrevious = distance; // keeping the current distance
                        distance = llRound(llVecDist(llGetPos(), target)); // calculating the new distance
                    }
                }
            }
            else{
                // neither of those work
                llStopMoveToTarget();
                llResetScript();
               // what works is to reset this script from another script with llResetOtherScript(<ThisScriptName>);
            }
        }
    }
}

 

Link to comment
Share on other sites

33 minutes ago, Badena said:

while(distance > 2){
    if(distancePrevious != distance){
        vGoTo = llGetPos() - 5.0*llVecNorm(llGetPos() - target); // walking 5m in 5seconds
        llMoveToTarget(vGoTo, 5.0);
        llSleep(5.0);
        llStopMoveToTarget();
        distancePrevious = distance; // keeping the current distance
        distance = llRound(llVecDist(llGetPos(), target)); // calculating the new distance
    }
}

The problem is essentially this loop. Until this loop has finished, the script cannot process another touch_start event.

The method of using another script to reset this script is one way to do it, but you could also convert the loop into a 5-second timer (to avoid the llSleep at the same time).

You don't have to stop before calling MTT either, it'll replace the current target just fine on its own.

Edited by Wulfie Reanimator
Link to comment
Share on other sites

What Wulfie said.

Instead of the loop:
  vGoToCalc / Move / start the timer

In the timer:
  check if you are close and stop Move and Timer else do the vGoTo calc and the llMoveToTarget.

Scripts don't have multithreading and no interrupts - so a loop will perfectly lock a script and make it unresponsive. For long loops you need to find another way. Timer in this case.

Link to comment
Share on other sites

Great, thank you :) I understand the matter now much better :)

I found a way to get into the loop of a timer btw. When the timer in its loop is "forced" to grab a string from prim description, the script can deposit  a string in the prim  description and thus the timer changes its  behavior according  to the new info :). Sounds useless, why not stop and restart the timer. But it is useful when you  have a timer running waiting until a  rolling golf ball comes to a halt where at the same time the player is moving. Actually a sensor runs first to detect the no-mod ball and hands over the ball UUID to the timer who in turn waits until the ball stops from where the distance to the player is checked...

 

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 1560 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...