Just curious :)

[Tattooshop]

Hello!

There is a physical linkset of two objects, one of which, a child primitive, rotates.
Seems to work fine, but sometimes ( when I log in ) I see that the child prim is not spinning.
However, if I grab the object with the right mouse button and hit Edit, it starts rotating again.
Why could this happen?
I am using this line for rotation:

llSetLinkPrimitiveParamsFast( 2, [PRIM_OMEGA, < -1.0, 0.0, 0.0 >, 10, 1]);

And also when an object crosses the parsel boundary, a message pops up, well, you know "Your object is not allowed...", and so on. And the object itself hangs in the air and seems to cease to be physical. Can I somehow detect this moment and reset the script?

Thanks for any help! 👍

[Profaitchikenz Haiku]

Omega is client-side, so you are having to refresh your viewer because the server has no idea what the amount of actual rotation is.

 

The simplest way to constrain to a parcel is to keep checking llGetPos() and testing X and Y against the parcel bounds.

[Tattooshop]

44 minutes ago, Profaitchikenz Haiku said:

Omega is client-side, so you are having to refresh your viewer because the server has no idea what the amount of actual rotation is.

Hi, thanks for the reply!

Is there any other way to make the child prim rotate, but without this effect? 🙂

[Tattooshop]

I'll explain a little. This wanderer script is used and the object is constantly being rezzed in-world. And part of the object rotates.
And it's just that when I login this part doesn't rotate until I do this "Edit manipulation".
If I just use the targetmega script in the child prim, this will not happen.
But I need to put everything in one script in the root prim.

Wanderer script from wiki

 

Edited June 6, 2021 by Tattooshop

[Bugs Larnia]

Like @Profaitchikenz Haiku said, this is because it is a client-side effect. I have the same issue during the Twisted hunt (which has rotating cubes).  Sometimes they rotate, sometimes they don't until I right-click/edit them.  Offhand, I don't know of a different way to fix this, unless you can fix it with a texture rotation instead of a prim rotation.

[Tattooshop]

4 hours ago, Bugs Larnia said:

Like @Profaitchikenz Haiku said, this is because it is a client-side effect. I have the same issue during the Twisted hunt (which has rotating cubes).  Sometimes they rotate, sometimes they don't until I right-click/edit them.  Offhand, I don't know of a different way to fix this, unless you can fix it with a texture rotation instead of a prim rotation.

Thank you!

 

I got the idea to add a timer that will start the spin again, say every second. But I'm not sure if this is advisable ... I wonder if there are other ways.

( I can also add a sensor that, if it detects an avatar in the vicinity, will also restart the rotation, but this is too much. )

Edited June 6, 2021 by Tattooshop

[Quistess Alpha]

4 hours ago, Tattooshop said:

will start the spin again, say every second

it's counter-intuitive, but from my limited experiences, you sometimes have to /stop/ the rotation before you start it again to get the change to take effect. I wouldn't do that too often though. Once per minute or two would probably be fine, as long as nobody's looking at it constantly they probably won't notice the hiccup.

[Profaitchikenz Haiku]

21 hours ago, Tattooshop said:

Is there any other way to make the child prim rotate, but without this effect? 🙂

You can use llSetLinkPrimitiveParamsFast(linkNum, [PRIM_ROT_LOCAL, newRotation]);

Calculate newRotation by getting the current link local rotation and multiplying it by a small amount on the particular axis you want to spin around. Repeat this on a timer, probably in whatever timer loop your wanderer script already has.

To speed things up you can bypass the getting current local rot and simply have a rotation variable that gets turned and applied to the child, when the script resets, reset this variable to the initial rotation and apply it to the child as part of the reset procedure.

Slow rotation is very hard to achieve in this manner without a certain amount of jerkiness, Omega often gives a better result.

[Tattooshop]

10 hours ago, Quistessa said:

it's counter-intuitive, but from my limited experiences, you sometimes have to /stop/ the rotation before you start it again to get the change to take effect. I wouldn't do that too often though. Once per minute or two would probably be fine, as long as nobody's looking at it constantly they probably won't notice the hiccup.

 

6 hours ago, Profaitchikenz Haiku said:

You can use llSetLinkPrimitiveParamsFast(linkNum, [PRIM_ROT_LOCAL, newRotation]);

Calculate newRotation by getting the current link local rotation and multiplying it by a small amount on the particular axis you want to spin around. Repeat this on a timer, probably in whatever timer loop your wanderer script already has.

To speed things up you can bypass the getting current local rot and simply have a rotation variable that gets turned and applied to the child, when the script resets, reset this variable to the initial rotation and apply it to the child as part of the reset procedure.

Slow rotation is very hard to achieve in this manner without a certain amount of jerkiness, Omega often gives a better result.

Many thanks!

It's just that at the moment there is no timer in the script at all. There are only state_entry and at_target events.

Also do I still need to add a timer to use PRIM_ROT_LOCAL?

Is there some way to cram this into the at_target event instead of the state_entry like it is now? Does this make sense?

 

[Wulfie Reanimator]

1 hour ago, Tattooshop said:

Many thanks!

It's just that at the moment there is no timer in the script at all. There are only state_entry and at_target events.

Also do I still need to add a timer to use PRIM_ROT_LOCAL?

Is there some way to cram this into the at_target event instead of the state_entry like it is now? Does this make sense?

You don't need a timer to use llSLPPF with PRIM_ROT_LOCAL (or any other parameter), but Prof is suggesting that instead of using PRIM_OMEGA, you would explicitly change the object's rotation in increments. This could of course be done in a loop within at_target, but that would probably leave your object unable to do anything else because new events cannot be processed while a loop is keeping the current event busy.

There are also significantly more things happening if you used the loop method. It would increase your script-time (because it's constantly doing calculations) and it would increase the network traffic for all observers (because the script keeps sending updates about the object's new rotation). I would personally avoid this and use a slow 5-30+ second timer to stop-and-start PRIM_OMEGA, depending on how important/prominent the effect actually is. (Faster timer if it's an object people are meant to directly interact with, slower if it's more of a "background decoration.")

[Tattooshop]

Thanks a lot to everyone for your help. Here's what I finally got.

...
default
{
    on_rez(integer start_param)
    {
        llResetScript(); 
    }
    
    state_entry() 
    {
        llSetTimerEvent(30);
        
        iPos = llGetPos();
        llSetStatus(STATUS_PHYSICS|STATUS_BLOCK_GRAB_OBJECT, TRUE);
        llSetForce(<0,0,9.81> * llGetMass(), 0);
        moveTo(nextCoordinates(MOVEMENT_TYPE));
    }
 
    at_target(integer tnum, vector targetpos, vector ourpos) 
    {
        if(tnum != targetID) return;
        moveTo(nextCoordinates(MOVEMENT_TYPE));
    }
    
    timer()
    {
        llSetLinkPrimitiveParamsFast( 2, [PRIM_OMEGA, ZERO_VECTOR, 0, 0]);
        llSetLinkPrimitiveParamsFast( 2, [PRIM_OMEGA, < 1.0, 0.0, 0.0 >, 10, 1]);
    }
}