Strange SitTarget bug.

This particular bug has been around since at least 1.2, so it has nothing to do with the particular changes implimented, but I've got three different objects all within less than 1m of each other, each with the exact same script on them doing one thing and one thing only... each SitTargeting to an identical location approximately 37m off, and all three actually SitTargetting to three entirely different locations, only one of which is the correct one. The two that are off are <30,0,0> and <0,-15,15> off respectively.

These objects are at 114,64,93 in Game Dev 1 (high up on the mountainside). Each is set to llSitTarget to <-17.4,-32.34,16.26> with a <0,0,0,0> rotation.

This bug seems to be inherent to the prims themselves. Meaning changing the SitTarget in the script doesn't seem to really effect where the target is. (I haven't run exact tests to see how moving the prims about works, but moving them around either keeps the wrong offset, or ends up with a set -destination- rather than an offset. I haven't fooled around with it too much mostly because reproducing the effect is hit-and-miss.)

My only request to the Lindens is that they actually sit down and see what they might do to solve this issue, and NOT impliment a 10m limit on the function, as that's not guaranteed to fix it (and would, yet again, break even more scripts). Otherwise I'd rather live with and work around the bug than have a limit placed on it.

SitTarget accepts an offset, not a region-local position. So if you have the same offset on three objects in different positions, your avatar will be sat at three different locations.

If you need llSitTarget to sit your avatar at a region local position, use this code:

vector regionPosition = <x,y,z>; // Put the region-local position here.

llSitTarget(regionPosition - llGetPos(), <0, 0, 0, 1>;

Plus, please dont pass <0, 0, 0, 0> rotation to llSitTarget. Its not even valid. If you are talking about the zero-rotation, pass <0, 0, 0, 1> instead.

I know. That's why I said that the objects in question are all within less than 1m of each other, their offsets are set to the same amount, yet their destinations are innacurate by about 30m or so.

Objects x, y, and z, are all at the same location. They all have the same offset. They all sit-target at three COMPLETELY DIFFERENT locations.

And if <0,0,0,0> is not a valid rotation, they need error-checking on stuff like that, because it seems to work just fine. (I'll go in tomorrow and change them to ZERO_ROTATION, see if that might clear up the bug.)