llSetPos for attachments not always working

Hi, can anyone confirm my suspicion of this bug? Here is what I did.
I have a script which takes position vector and rotation quat snapshots of objects attached to an avatar. I set these but using llGetLocalRot and llGetLocalPos (which when in root should defalt to getpos) Then I try to reset these old values back into the object that the script is in with llSetPos (there is no setlocalpos) and llSetLocalRot...

Get values and store them:
if (index == 1)
{
rot_1 = llGetLocalRot();
vec_1 = llGetLocalPos();
}

Set values out to prim:
if (message == "1"
{
llSetLocalRot(rot_1);
llSetPos(vec_1);
}

What ends up happening if you try to do this with a number of storoed position-rotations is that sometimes ONLY the rotation happens and the position stays the same.
This only seems to happen on attached objects.
I've confirmed that the data was the same despite the 'fake' lagged positioning with a click and a printout of the current position. Its actually where it should be.. but it doesnt look it.

Also... when you have an object of this type.. in its fake positioning and you go and delete the script... it sometimes causes the object to complete the repositioning.
Anybody else have this experiance? Workarounds?
Thanks,
Jadaira

Try to make sure if the stored value is loaded correctly like below.

Set values out to prim:
if (message == "1")
{
    llSetLocalRot(rot_1);
    llOwnerSay((string)vec_1);
    llSetPos(vec_1);
}

I've played llSetPos & attachment by the following script

default
{
    state_entry()
    {
        llListen(0, "", "", "");
    }
    listen(integer channel, string name, key id, string message)
    {
        llSetPos(<(float)message,0,0>);
        llOwnerSay((string)llGetLocalPos());
    }
}

And I had known the limit was 3.5m.

I've been playing with an attached object today that rotates and setposes itself and yeah, I've been seeing the odd random error with the setpos. (The rotate always seems to work.) Which is strange - it was working fine a week ago. A little irritating, since it's supposed to be for sale soon and the setpos element is pretty much essential to the concept. I can see a workaround using prims with setalpha in them but that's not at all ideal.

I've not been able to pin down exactly when it happens, but if I do, I'll try to remember to post about it....

Yeah.. the positions and the data itself (botht eh vector and the quat) are always correct.. its jus the object never MOVES properly.. it just rotates and leaves a sortof.. ghost of itself rotated at the position. I am pondering whether to submit it as a bug or not.

If the distance between the pos are too small it will not send the update; try setting the position before the local rot.

I use llSetPos extensively in my av and i have not had problems with this.
In my av the tail is pose-able, the positions are stored in notecards and read by the child prims on demand (this script set is a predecessor to TLML, the same functionality can be found in TLML-L).

I've tested things out in my builds using multi clients running at the same time. One screen shows the position correctly. The other computer sometimes does not. Or the other way around. Sometimes both are not right. But it's obvious to me that it's client side.
What looks right to one may not to another.
I hate that.
We need a refresh of some sort to make sure it's position is right.
Maybe call it's position twice after a sleep or timer event?
I have not had time to test any fixes myself just yet but I would assume it to be something along those lines.
It would only reduce the chances of a mistake. It's certainly not a fix. And would add to lag I'm sure. Hurray

I am considering trying multiple solutions to this problem, now that I know it isnt JUST me or something wrong with my code.

possible fixes:
use the setprimdata functions to set both rotation and position simultaniously
cons... lists are slow as heck.

using setpos twice with a delay in the middle...
cons.. still slow as heck and possibly slower than lists >.<

having the data written in notecards is unnaceeptable because it is too white box for normal users. Noone should have to type [1.234242,2.3453535,1.2342423,0.657567] kinds of stuff. Anyways thanks for all the verification and suggestions everyone.
Jadaira