Spin round, wobble round...

[Domitan Redenblack]

Yes, Darkie, I read the Wiki, but must be missing something...

I have two spinning discs which rotate using llTargetOmega( )

One of them can be moved around and tilted, and it still rotates like a spinning disc.

My disc spins nicely, until you edit-rotate it, then it wobble-spins all over the place.

default
{
    state_entry()
    {
       llTargetOmega( <0.0,0.0,1.0> * llGetLocalRot( ), 2.0, 1.0);
    }
}

 I tried both llGetRot and llGetLocalRot - makes no diff.

Am I missing something?

 

[Dora Gustafson]

State entry is only called once, when the script is first entered.
To update the rotation axis you have to call your function at regular intervals

[Domitan Redenblack]

---

Dora Gustafson wrote: State entry is only called once, when the script is first entered.

To update the rotation axis you have to call your function at regular intervals

---

Ohhhh! I did not see anything about that in the Wiki, thanks!

Is there a reliable event to tell if the disc has been moved?

 

 

[Dora Gustafson]

There are two events: moving_start() and moving_end(), but none for rotation
(I wonder why I keep on looking up functions for other people) :smileyindifferent:
Here are all the available events listed.

[Domitan Redenblack]

---

Dora Gustafson wrote:

There are two events:

moving_start()

and

moving_end()

, but none for rotation

(I wonder why I keep on looking up functions for other people) :smileyindifferent:

Here

are all the available events listed.

---

I have found moving_start and moving_end to be very unreliable. Have you?

If I don't use those, should I use a timer to fix the llTargetOmega repeatedly? That seems kind of laggy-inducing.

 

[Void Singer]

you can cheat and set a rotation target of the current rotation, and the not_at_target event will catch rotation changes... at which point you would cancel the old target, set a new one, and run your target omega code again

[Domitan Redenblack]

---

Void Singer wrote: you can cheat and set a rotation target of the current rotation, and the not_at_target event will catch rotation changes... at which point you would cancel the old target, set a new one, and run your target omega code again

---

Clever! I assume you mean not_at_rot_target and does this work if you start at the rot_target then leave it? Is the test not turned off upon current_rot == target_rot ?

Is it possible to set a rot_target for only two axes?

[Domitan Redenblack]

Excellent! Works a treat!

Question though:
When I edit-tilt my disc, it stops spinning until edit done... If I edit the other disc I have, it continues to spin even while I edit-tilt etc. Why is that?

 

integer giRotationStart;default {    on_rez ( integer start_param ){        giRotationStart = llRotTarget( llGetRot(), 0.05);    }    not_at_rot_target( ) {        llRotTargetRemove( giRotationStart );        llTargetOmega( <0.0, 0.0,1.0> * llGetRot( ), 1.0, 1.0 );        giRotationStart = llRotTarget( llGetRot( ), 0.05);    }    }

 

[Dekka Raymaker]

to do with the script being in the root or child prim.

[Void Singer]

probably because the physics engine doesn't send it's trigger to the script engine until the edit is completed? just guessing there

[Innula Zenovka]

I've always been a worried about when to use no_at_target events because, presumably, they're firing constantly until I reach my target, so it's a bit like using a very fast timer -- not really a good idea over extended periods except when absolutely necessary.    Or am I being over-cautious because I've misunderstood?

[Domitan Redenblack]

---

Innula Zenovka wrote:

I've always been a worried about when to use no_at_target events because, presumably, they're firing constantly until I reach my target, so it's a bit like using a very fast timer -- not really a good idea over extended periods except when absolutely necessary.    Or am I being over-cautious because I've misunderstood?

---

Since we start out At The Target, presumably not_at_rot_target will not fire until the disc is tilted. Then it will only fire until the target stops moving, which I assume will be pretty quick.

Yes?

 

[Innula Zenovka]

That's a good point.   Is your spinning disk generally static, then (that is, it doesn't normally change its rotation)?    Since I don't know what it's in, but since you're so concerned about the rotation changing and having to reset llTargetOmega, I sort of assumed it was going to be in something that moves around a lot.

[Domitan Redenblack]

No, it is generally static, only tilted or moved during initial placement.

 

[Void Singer]

there probably is a bit more server overhead to this than the similar changed event flags.... but if you aren't including the event that would be constantly firing (in this case at_rot_target) then is should be nicer than a faster timer/event-loop.....

it is a concern, and I really wish there was a CHANGED_ROT flag, even if it only fired in the root.

[Rolig Loon]

If you're dreaming for a CHANGED_ROT flag, wish for a CHANGED_POS flag too. It's a nuisance to have to store position or rotation information in a non-volatile spot and then keep checking it to be sure nobody has moved your object.

[Domitan Redenblack]

I checked this and not_at_rot is not triggered at all until you tilt the object.

 

[Void Singer]

oh I have a list.....