Plroblems with llSetPos

Hello,

I am working on a bot (LSL, based) that should roam sims.

The information where to go to, i.e. the "course" or "path" to follow, is given.
Each leg of the course will span several sims and thus cross several sim borders.

For that reason and for the sake of simplicity I decided to use llSetPos and the usual looped approach based on that instead of some of the available "warper" algorithms.

So I calculate the next target and make step into that direction by using llSetPos until I reach the target.

The operation height of the bot is 1000 meter or higher so I should be well above any problems based on "scripts not allowed" or "objects not allowed to enter", right?

All this works well 95% of the time. But I often I observe the following:

- llSetPos (with a new position definitely different from the current position) does not yield in any movement neither visible nor checked with a subsequent llGetPos.
- This does NOT happen with movements where the expected step (<=10meter!) will cross a sim boundery or even worse, will go off-world! Indeed this usually happens near the sim center (128/12. The "courses" where it happens are also perpendicular to the next sim boundary to make sure no sim *corner* is involved.
- This happens only with certain sims or it happens there so often that other occurences got through unnoticed.
- This always happens on a course change, i.e. a change of direction for 90°.
- This "stucking" does not happen, when an avie sits on the prim
- This "stucking" happens with a certain and high probability (about 90%) but not always

What I tried to work around this:
Step into an other direction --> still stuck
Reset the script that does the movement --> still stuck
Limit step widths to below the magical 10 meter limit --> no change
Use llSetPrimParameter instead of llSetPos --> no change
Switch the prim to physical for a moment to move it to another height --> works but after switching back llSetPos still refuses to work.



Any ideas or helpful hints?

Best regards
Cynthia

Some things I know of that can cause llSetPos to stop working:

1) Distance moved > 10.0m (not just on any axis, but the true 3D distance)
2) Parcel has "no object entry" set
3) Parcel has "No Script" set.

To me, it sounds like #1, except when you say it works if an avatar sits on it. That sounds more to me like you are running into #2.

Outside of that, would have to have access to the script to diagnose it further.

Here's the script

The subroutine is called (by a timer) until the return value is <>0

In case of a return value of 2 different strategies have been tried as this indicates the "stuck" case.


vector getPosAbs() {
return llGetRegionCorner()+llGetPos();
}


integer moveToAbs(vector posAbs) {
vector diff=posAbs-getPosAbs();

vector regionBefore=llGetRegionCorner();
vector posBefore=getPosAbs();

vector newPosRel=llGetPos()+diff;
llSetPrimitiveParams([PRIM_POSITION, newPosRel]);
// llSetPos(newPosRel);

vector regionAfter =llGetRegionCorner();

if (regionAfter!=regionBefore)
llSleep(5.0); // region crossing. Let things settle

vector posAfter=getPosAbs();

if (posAfter==posBefore) {
dbgSay("Giving up";
return 2;
}

///////////
diff=posAbs-getPosAbs();
if (llVecMag(diff)>0.1)
return 0;

return 1;
}



if it's really some parcel rights problem..... i thought they don't matter at 1000 meter(?)
BTW, the script is not disabled, it works fine. Only llSetPos doesn't work.


Cynthia

Did the parcel entry setting get extended up to 4km, since that's how high the building/non-physical movement height was extended?

It would make sense, because as I understand it the height limit is there so that high-flying vehicles can get around, and vehicles are (traditionally) physical.

you may also want to consider the jumpPos method.

(without knowing what's going into newPosRel it's hard to say)

Hi void,

I assume you mean posAbs. newPosRel is calculated locally.

posAbs is the next "target" on the course list, expressed in absolute coordinates.

diff is the vector distance to that target (as a distance it doesn't matter if it's in rel or abs coordinates!)

newPosRel is the new position expressed in the local frame of coordiantes. Note: This means, that posRelNew might point to a location several sims away!!!



Does that mean the vehicle must be physical to be allowed to enter?

Cyn

vehicles by default are a type of physical object (with special handling by the sim). so in the case of non-physics vehicles....yes. (not sure how it's treated if an NPV takes controls)