llMoveToTarget in hops, when that target is over 65m away

[Ares Halostar]

llMoveToTarget has a limitation of 65m, but I need to move something over that distance, and it can be hundreds of metres away.

I know how to calculate the amount of "hops" needed, if I break it up to 50m movements.  But how to do calculate the positions that the project needs to travel to.

I've looked at the old warppos, but that is meant for llSetPos and uses llSetPrimitiveParams PRIM_POSITION, which I can't use.

 

I hope I have explained myself enough.

[panterapolnocy]

Maybe this will help.

vector gTargetPosition;

default
{

    touch_start(integer nd)
    {
        gTargetPosition = <123, 123, 123>;
        llSetTimerEvent(0.25);
    }

    timer()
    {
        vector currentPos = llGetPos();
        vector positionLeft = gTargetPosition - currentPos;
        float distanceLeft = llVecMag(positionLeft);
        if (distanceLeft < 1.0 || gTargetPosition == currentPos)
        {
            llSetTimerEvent(0);
            llStopMoveToTarget();
        }
        else
        {
            if (distanceLeft < 65)
            {
                llMoveToTarget(gTargetPosition, 0.05);
            }
            else
            {
                llMoveToTarget(currentPos + llVecNorm(positionLeft) * 60, 0.05);
            }
        }
    }

}

 

[primerib1]

Why not use llVecDist(currentPos, gTargetPosition) ?

EDIT: Ahh, I see. You still have to do an llVecNorm() anyways, so you already need a relative vector, and therefore just fold up the calculation using llVecMag() for simplification.

Edited January 13, 2023 by primerib1

[Quistess Alpha]

If I recall, llMoveToTarget has some ease-in/ease-out that make interpolation like that not-smooth. For long movements have you considered llSetKeyframedMotion() instead?

Edited January 13, 2023 by Quistess Alpha

[Qie Niangao]

3 hours ago, Ares Halostar said:

I've looked at the old warppos, but that is meant for llSetPos and uses llSetPrimitiveParams PRIM_POSITION, which I can't use.

I suppose the object is physical, so that won't work, but generally warppos is pretty janky anyway, and llSetRegionPos() is way more efficient (even if one needs a sequence of them to span multiple regions). For more leisurely non-physical motion, there's also llSetKeyframedMotion which is unpredictable at region borders but moves very smoothly over great distances.

So, to the actual question, it's possible to get reasonably smooth slow physical motion over multiple stages of llMoveToTarget() using sequential llTarget settings (nearer than the move target, so the next target can get set before the motion damps) and at_target events rather than a timer. On the other hand, if the objective is to move to the destination as quickly as possible, the timer seems simpler. Note that either way, it's physical motion, so need to deal with contingencies like blocked paths.

[Quistess Alpha]

15 minutes ago, Qie Niangao said:

(even if one needs a sequence of them to span multiple regions)

Tangent, but last time I did that for a client, they complained about it leaving "ghost objects" behind. (The server didn't send nearby viewers a message that the object wasn't there anymore)

[Ares Halostar]

Thanks panterapolnocy for your reply, and yes, that fixed my problem.  For anyone else interested, this was for moving a clone that I had made in Opensim.  But it could be applied to a primset as well.  That is why I couldn't use other movement solutions.