Kitely Forums

So I made the Multi-Die Random Roller that is on sale on the KMP. Other than its scripted rolling of multiple dice chosen by dialog by the user, the mesh object the script resides in, which looks like a d6, is scripted to roll in x y and z axes with PRIM_OMEGA during a roll, then the PRIM_OMEGA is set to <0,0,0>,0,0 in order to nullify the Omega entirely, at which point the mesh die is oriented some random direction. So I have put two functions in (one didn't work either), such as llSetPrimitiveParamsFast([PRIM_OMEGA,<0,0,0>0,0,PRIM_ROTATION,ZERO_ROTATIONS]); followed by llSetRot(ZERO_ROTATIONS);. These functions work fine on other grids to force the mesh to reorient itself to a rotation of <0,0,0,1>. However on Kitely this function does not work, and the die just comes to a stop in a random orientation. This has happened in Naboo, Space Force, Kitely Merchant Sandbox, and a few other regions in Kitely, while it works fine in Alternate Metaverse Grid and Discovery grid.
Would appreciate someone looking into this. According to the opensimulator.org, both functions are fully implemented, which is evidenced by them working properly on other grids.

https://www.kitely.com/market/product/6 ... dom-Roller

Hi Mike,

Physics behavior is highly dependant on which physics engine is being used, what objects/land are colliding with the object and how object physics is configured in all these objects.

Have you tried changing the physics engine in your world and seeing how this effects these objects?

Ilan Tochner wrote: ↑

Fri Jan 27, 2023 8:38 pm

Hi Mike,

Physics behavior is highly dependant on which physics engine is being used, what objects/land are colliding with the object and how object physics is configured in all these objects.

Have you tried changing the physics engine in your world and seeing how this effects these objects?

This is not a physical object, so it does not rely on the physics engine. Neither PRIM_OMEGA nor llSetRot() are physics functions.
I am using ubODE in my regions. Same as is used in the grids I referred to where the script is functioning properly

Please read: viewtopic.php?f=26&t=3610

Ilan Tochner wrote: ↑

Fri Jan 27, 2023 10:44 pm

Please read: viewtopic.php?f=26&t=3610

a) timers in opensim are now 0.11s minimum
b) ok distinction: PRIM_OMEGA is spinning. llSetRot() or PRIM_ROTATION is not spinning, it is setting an object to a specific quaternion rotational orientation. I had assumed you undestood these distinctions. Neither is relevant to timers or physics. PRIM_OMEGA is a parameter in llSetLinkPrimitiveParams and llSetLinkPrimParamsFast that is equivalent to llTargetOmega but can be applied as part of a list of prim parameter changes as well as to child prims from a script in another iink in the linkset. So the PRIM_OMEGA I originally set to <1,0,0>,1,1 on the x axis, then on the y axis, then on the z axis, then I set PRIM_OMEGA to <0,0,0>,0,0 which makes it stop spinning entirely. PRIM_ROTATION is the same as llSetRot() but, like PRIM_OMEGA, part of the llSLPPF and llSPP functions parameters. It sets the quaternion orientation of the object. Neither requires a timer. Setting an object to zero on PRIM_OMEGA should halt all viewer side spinning and PRIM_ROTATION with ZERO_ROTATIONS as the value of that parameter, should return the object to a standard rotation orientation of 0,0,0 degrees on all three axes, which it does on other grids just fine.
Demanding that people use Key Framed Motion to do this is a whole lot more laggy script wise than what I am doing. How about you just fix your script engine to comply with the opensim standard?

MIke, you asked a technical question and I gave you a technical solution that was written by other Kitely scripters and improves what you're trying to do more than making timer events more frequent. If you use it then you'll get the same technical benefits that are discussed in that fourms thread. You can use it, or not, that's up to you.

FYI, part of the reason timer frequency is kept low in grids that understand how OpenSim and common LSL and OSSL scripts work is that many scripts are badly written and overuse timer events thus causing high CPU usage which leads to lag. There are functions, like the ones discussed in the aforementioned thread, that are designed to work better and not cause high CPU usage. As stated previously, you can use them, or not, that's up to you.

Ilan Tochner wrote: ↑

Fri Jan 27, 2023 11:47 pm

MIke, you asked a technical question and I gave you a technical solution that was written by other Kitely scripters and improves what you're trying to do more than making timer events more frequent. If you use it then you'll get the same technical benefits that are discussed in that fourms thread. You can use it, or not, that's up to you.

FYI, part of the reason timer frequency is kept low in grids that understand how OpenSim and common LSL and OSSL scripts work is that many scripts are badly written and overuse timer events thus causing high CPU usage which leads to lag. There are functions, like the ones discussed in the aforementioned thread, that are designed to work better and not cause high CPU usage. As stated previously, you can use them, or not, that's up to you.

A technical solution is for you to fix the script engine on kitely servers to work properly like the rest of opensim does. There is no valid reason to not allow llSetRot() to function properly. Your response is absurd

Mike, we use the same code for this as the one from OpenSim 0.9.1.1 post fixes release.

I may be missing something but this works for me.

Graham Mills wrote: ↑

Sat Jan 28, 2023 1:45 pm

I may be missing something but this works for me.

Code: Select all

default
{
    touch_start(integer n)
    {
        llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_OMEGA,<1,3,0.5>,TWO_PI,1]); 
        llSetTimerEvent(5.0);
    }
    
    timer()
    {
        llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_OMEGA,<0,0,0>,0,0]);
        llSetTimerEvent(0.0);
        state zero;
    }
}

state zero
{
    state_entry()
    {
        llSetRot(ZERO_ROTATION);
        state default;
    }
}

When you say it "works for you" what exactly do you mean? That it stops spinning, sure that is what happens on my script as well. Does it return to a zero rotations orientation with the z+ axis up etc? No, it doesnt. You need to do either PRIM_ROTATION,ZERO_ROTATIONS in the llSPPF function, or llSetRot(ZERO_ROTATIONS); to get it to return an upright orientation. It is the SetRot and PRIM_ROTATION that are not functioning