Rotation Making My Head Spin - Help

Hi.

I've been making a prim spin in my script. That part was was easy to do. I can start and stop the prim spinning using:


// Start spinning

llTargetOmega(<0,0,1>,0.3,1.0);

// Stop spinning

llTargetOmega(<0,0,0>,0,0.0);

I can even sit my av on the prim and have it rotate with it.


2 problems that have my head spinning trying to figure out are:

~

1. I'd like to have the prim return to its start position after the spin stops.

So I figured that I could get the start position and return the prim to it using this code:

------------------

rotation start_position;

// Get original position
start_position = llGetRot();

// Start spinning
llTargetOmega(<0,0,1>,spin_speed_direction,1.0);
// Stop spinning
llTargetOmega(<0,0,0>,0,0.0);

// Return to original position.
llSetRot(start_position);

-------------------

Only the prim doesn't return to the start position. It just stops wherever its at and stays there.

I'm finding the commands, script help and wiki so confusing. Can anyone please suggest what command I should be using?

~

And 2.

When my av sits on the rotating prim, usually the camera stays still and just the prim and av spin together. Sometimes the camera spins with them. Does anyone have any idea what cases the camera to spin with prim and av and and how to stop it?


Thanks - Dina

I'll take a stab at this, other better scripters may be able to help more.

1. Your pseudo code loooks good, I would suspect there is something wrong with the flow in the script not calling the llSetRot, but that would be hard to dertemine without the real code.

2. An avatar that has alt-cammed to focus on an object (or avatar or patch of ground) will always stay focused on that place regardless of if that object moves or thier avatar does. Next time it happens hit ESC twice and see if your camera return to default and spins with the avvie.

Thanks Dnel.

ESC 2x does nothing.

I can't seem to find any information on "alt-cammed". Is that the right word I should be searching on?

I realized that my original description of what was happening isn't very clear. Maybe this will help.

What I want is the camera to stay focused on the av all the time as its spinning, with the room standing still. Most of the time this happens correctly.

Sometimes when I sit, or if I click on the av while its spinning, the focus stays on just the back of the av, and the room starts spinning too.

If I click on the camera control box (from the View Menu) the focus is still on the av, but now only the av is spinning and the room stops.

Is there a way to force the focus on the spinning av, from within a script, and the room stays still?

- D

It is a current known bug in SL. It's even worse for child prims, as they do not even stop spinning, no matter what you do. Until they fix it, it won't work. Please log in to JIRA and cast your vote to get this bug fixed.



Depends on what your focus is on when you sit. If you are focusing on your av or the object, it will follow your av or the object; if you are focused on some other object or non-moving spot, it won't. If you are in Mouselook, well, I hope you stocked up on pepto bismol.

You won't be able to reset the rotation of your prim using llSetRot() in conjunction with llTargetOmega(). The problem lies in the way the code is split up.

llTargetOmega is run client-side, and sends one rotation to the server: the initial starting rotation. As a client side process, it does not send information to the server regarding the current rotation of the prim. This was done to ease server lag issues.

You can use llSetRot() and a timer event to make a prim rotate. It will look choppy however, and use quite a bit of server cycles to implement something fairly smooth.You will be able to set the prim back to it's original rotation, however. This method is not really suggested, as it can cause lag issues on various servers.

Actually, the way it is supposed to work (and did work before) is, if you turn llTargetOmega off, llSetRot() would then rotate it again normally. As you can see in the OP's code, llTargetOmega is turned off, and the llSetRot() afterwards doesn't work. This is part of the buggy operation. It used to work fine.

More silliness I've discovered. And think I understand a bit thanks to everyone's feedback.

My original code was:

------------------

rotation start_position;

// Get original position
start_position = llGetRot();

// Start spinning
llTargetOmega(<0,0,1>,spin_speed_direction,1.0);
// Stop spinning
llTargetOmega(<0,0,0>,0,0.0);

// Return to original position.
llSetRot(start_position);

-------------------

Doesn't perform the Return to original position.

So added this test

------------------

rotation start_position;

// Get original position
start_position = llGetRot();

llOwnerSay((string)start_position); // testing

// Start spinning
llTargetOmega(<0,0,1>,spin_speed_direction,1.0);
// Stop spinning
llTargetOmega(<0,0,0>,0,0.0);

iiOwnerSay(llGetRot()): // Testing

// Return to original position.
llSetRot(start_position);

-------------------

I found that the llGetRot values are the same before and after the llTargetOmega.

However, now when I right click on the prim it snaps back to its original rotation.

My theory is that the 2nd llGetRot is somehow causing the viewer and the server to get back into sync which is being triggered by the right click.

Now my silly question.

How do I get the script to force the prim to resync with the server and redisplay like the right click is doing?

- D

Yeah this is a really, really annoying bug.

One workaround I've used with some success is to use SetRot to return to the original rotation *while also introducing a small rotation (like 1 degree) on an unrelated axis*, then immediately "correct" it to just the actual desired rotation. This can create a visible wiggle, but it was ok for my purposes.

Sorry, but I don't see where the problem is. There is a fundamental difference: llTargetOmega is computed and displayed client-side, while llSetRot is server-side and updates and displays the same way for everyone in-world.
This means that even though it _looks like_ it's spinning, it really is still; the rotation is just "emulated", and everyone will see it at different rotation positions.

http://rpgstats.com/wiki/index.php?title=LlTargetOmega

If you want it to stop and reset back to rotation zero, it's no problem: it already is at that rotation. You just have to cancel the emulated rotation with llTargetRemove.

Got all excited for a minute. However the

llTarget
llTargetRemove

idea doesn't seem to work any better than the

llGetRot();
llSetRot(start_position);

I still have to right click on the object to get it to revert to the server version position.

- D

Got all excited for a minute. However the

llTarget
llTargetRemove

idea doesn't seem to work any better than the

llGetRot
llSetRot

I still have to right click on the object to get it to revert to the server version position.

- D

You mean that when you use TargeRemove, the object stays with the apparent rotation it has, instead of reverting to zero rotation? That's weird.


I see... I thought so. One of my first scripted objects was a cube that rotated on a different axis every time you clicked it, and I remember every time it changed the targetOmega rotation it quickly contorted to return to the original "real" rotation and start rotating from there. That's why your problem seemed weird to me, I didn't remember it acting different... since when is this bug been around?

However. I was thinking of some trick, like setting a color or someting to force an unnoticeable update on the object... then I read in the jira comments they suggest to use a SetText with an empty string. You could try that.

I've tried the SetText and it doesn't make any difference. However, with all the new bugs in sl right now, I can't tell what is working and what isn't.

- D

You're right, it's me that's stupid... llTargetRemove is for llTarget, that has nothing to do with llTargetOmega. However I've made some experiments... it's getting scary. After my box was made spin with llTargetOmega and stopped, not one of the solid-changing update command I used did anything to force him to obey to llSetRot(ZERO_ROTATION); I changed hover text, color, rotation, size, and even resetting the script at every cycle and THEN ordering a ZERO_ROTATION, but nothing worked. Only rotating the box slightly with the handles allowed the SetRot to have effect, but once targetOmega had been used, nothing worked anymore. Must be a quite grave bug. And unfortunately, I don't see remedies or workarounds right now.

The wiki states:
" Physics
* If the object is not physical then the effect is entirely client side.
* If the object is physical then the physical representation is updated regularly. "

Since the rotation fields where changed from 0.0 to something else no matter if phantom, physical or nothing at all were checked, it seems that the "update regularly"part happens anyway, and then "lock" the rotation from being changed via script.

Uhm... how does that "voting bugs" thing on the jira work..?