A client/server resync call?

Hi, I had a question I been trying to find an answer to with no luck.

Using llTargetOmega(<0,0,1>,1,1) will set a target in rotation and then calling llTargetOmega(<0,0,0>,1,1) will stop the target. As far as the server is concerned though, the target has never moved, it is all client side. So using llGetRot or llSetRot is useless as the object has never moved as far as they are concerned, but to the client it has most certainly moved. Perhaps it is not possible but is there a call that will resync the client and server in this case so the target object is back where it started to both the client and server? Thanks.

You could stop the llTargetOmega then llSetRot at the start rotation? Or does that not work because the server doesn't bother updating the client as it thinks nothing has changed? If so you may have to SetRot to some other rotation and back to the start to reset.

I had been racking my brain all morning on this one trying to remember what all was different now. llTargetOmega behaviour changed last year. The best thing to do would be go back to the wiki and click on "Display Comments Form" on the bottom. The problem is discussed and a workaround or two are shown there.

I had this problem. I made a rezzer / derezzer... Sounds like a half arsed attempt to get around this huh?

So when the object is meant to stop It sends a message to a rezzer, it dies, rezzer makes a new object! It is a long and stupid way to get around this... but the only one I have found so far

Of course you can make it self replicate and die, but that is a tad more in depth

Just tested this in beta

default{
    state_entry(){
        llTargetOmega(<0,0,1>, 0.5, 0.5);
    }
    touch_start(integer n){
        state stop;
    }
}
state stop{
    state_entry(){
        llTargetOmega(<0,0,1>, 0.0, 0.0);
    }
    touch_start(integer n){
        state default;
    }
}
[\PHP]
Using that script then whenever I push stop, the prim will swing back to it's starting position & stop.

Ah so much fun. I had run through a couple of itinerations of scripts before I boiled it down to the one above. But I thought I was going out of my mind because I thought that was what I had originally started with and when it stopped it would stop in it's current rotation and then start from there also.

SO of course I had to go back into beta and try again. Starting with a fresh prim and that same script the prim will stop in it's tracks and then start from the stopped rotation and if you change the script to this:

default{
    state_entry(){
        llTargetOmega(<0,0,1>, 0.5, 0.5);
        llOwnerSay("wtf?");
    }
    touch_start(integer n){
        state stop;
    }
}
state stop{
    state_entry(){
        llTargetOmega(<0,0,1>, 0.0, 0.0);
        llOwnerSay("What is going on?");
    }
    touch_start(integer n){
        state default;
    }
}
[\PHP]
It will still do the same BUT................................................. If you now comment out the llOwnerSays or even completely remove them then when you stop the prim it will rotate back to it's starting location and start from there when touched again. WOOT so much fun!!!!!

Wow, thanks everyone, yes this was driving me nuts too and everytime I would get a script that would compile I would think I am home free only to have it do the exact same thing. The weird thing is the server never even see's it move and you are looking at it and see it where you see it only to walk into it where the server thinks it it. And you can edit it and see its not at 0,0,0. On a long arm you can be sitting on it and going around and around but on the mini map you are standing still

I will try those script changes Jesse, thanks.

Doh... still sunning smooth as silk starting and stopping where ever it happens to be.
Is it possible to have it keep updating the server as to its location I wonder...

llTargetOmega is really borked right now, and has been for many months. No workarounds to date work universally.

VOTE for this JIRA bugfix request: http://jira.secondlife.com/browse/SVC-54