Local rotation in llSetPrimitiveParams?

Why isn't there a possibility of local rotation in the llSetPrimitiveParams? Is this a sensible feature request or am I missing a simple way to achieve this?

from wiki llSetLocalRot:
Q: How do I perform this with llSetPrimitiveParams on a child of an attached prim?
A: You need to know the local rotation of the root prim of the the attachment and divide your target rotation by the root's local rotation.

I believe there is a pretty severe defect in this operation, that makes it so you have to do a very strange, incorrect calculation to get the results you want. Maybe someone knows the JIRA issue offhand...?

SVC-93 --> https://jira.secondlife.com/browse/SVC-93

world relative workaround:
llSetPrimtiiveParams([PRIM_ROTATION, (rot / llGetRootRotation) / llGetRootRotation);

local relative workaround:
llSetPrimitiveParams([PRIM_ROTATION, rot/llGetRootRotation]);

Thanks Void!

it's one of those issue that got me right between the eyes, kinda hard to forget.

Note that this does not work in an attachement

I believe it USED to, where llGetRootRotation /actually/ returned something that would be "llGetRootLocalRotation()" (if such a command existed) but unfortunately it only returns <0,0,1,0> now ALWAYS. THis makes sens on one level but is actually totally USELESS.

When an object is unattached, using the above equations work great using the global rotation of the root prim that is returned, when attached, that functions SHOULD return the local rotation of the root prim becuase it would /functionally/ be the same thing. I.e. an object would behave identically whether attached or not.

Unfortuantely that is not the case now... And with the absense of an llGetRootLocalRotation function, you are left with having to have the root prim get it's own local rotation and link message it to any child prims that need to use that info

the workaround would be to get the rotation of the root, from the root, an use a link msg to inform the child prims...

another workaround would be to do the calls from the root, and use get local rot and set link prim params....

there are situations in which it doesn't matter, and you can just add the local degrees onto what is being set (I used this for wings), but it takes a little trial an error.

tnx for the response guys; these rotations still freak me out

I think this might be the thing I was looking for, but I'm such a scripting newbie that you all appear to be speaking a completely alien language

I've been scouring the forums looking for a rotation (or llTARGETOMEGA) script that will allow for repositioning... for instance... I have a windmill, with sails... that go around and around (yes this is the limit of my scripting abilities) which is all very lovely, but when I move/turn my windmill... the sails do not reposition themselves and they continue to rotate in relation to their original position (which looks very odd).

Please does anyone know of a fairly simple rotational script that will reposition the rotate when moved?

Many thanks

for Set Rot type rotations, it'd be
llSetRot( arc2traverse * llGetRot() );

for target omega type rotations (non physical)
llTargetOmega( axis * llGetRot(), spinrate, gain ); //-- I believe

This really does look exactly like the kind of thing I'm looking for! You're a genius Void!
Now.. how can I get this translated from martian into english? (how does that fit into a script?)
spinrate and gain = numbers? definition for axis?? aarrghh!

confused... and blonde...

~ Kittie

assuming that's the right formula, spin rate is a float that detrmines how many times times the axis rotation happens in radians per second (TWO_PI = 1/sec), and gain should be a float of how quicklly it gets up to that full speed (I'm not sure how this works, it could be in fractions of force, or seconds till full speed, or whatever, but it appears not to matter for non-physics enabled objects, unless it's 0 so just use 1)

for spinrate to be exactly the number of rotations per seceond at full speed, axis (a vector describing the axis to rotate on) should be either (-)1 in one axis and zero in all others, or should be normalized using llVecNorm...

as an example of an object that spins around it's y-axis 2 times per second
llTargetOmega( <0.0, 1.0, 0.0> * llGetRot(), 2.0 * TWO_PI, 1.0 );

if some other more complex vector is being used then you should use
llTargetOmega( llVecNorm( <0.0, 1.0, 0.0> ) * llGetRot(), 2.0 * TWO_PI, 1.0 );
to get the same effect.

presumably called from the root of your sails (which should be both their center and not connected to the larger structure)

references:
https://wiki.secondlife.com/wiki/llTargetOmega


now the first link says all root usage results in global rotation frame, while the second says it becomes local for physical objects...

void, you're my rotation hero!!!!

at last, a LOCAL AXIS target omega function!

so um... what other good secrets do you know? lol!

vector gPosOffset = <1.0, 0.0, 0.0>;
vector gDegArc = <0.0, 0.0, 6.0>;
rotation gRotArc;

gRotArc = llEuler2Rot( gDegArc * DEG_TO_RAD );
llSetPrimitiveParams( [PRIM_POSITION, llGetPos() + (gPosOffset - gPosOffset * gRotArc) * llGetRot,
                       PRIM_ROTATION, gRotArc * llGetRot()] );

the formula for rotating a prim around an offset point (which is wrong on both top wikis last I checked, really must correct at least one of them) with no anchor prim. can be adapted (and probably has) for multi-move type non-phys vehicles to smooth turns without large jumps in pos (depending on object width).

I used a similar formula to make oval particle effects (it traces the oval instead of being a burst though)... ok off to edit the LSL portal now that I'm reminded.

the same principle (used in the previous posts) is used for anything that uses an offset point that need to be relative to the facing of an object (doors, rezzors, bullets, holo vendors, lids, trunks, etc ad nauseam) just multiply your local vector offset times the objects rot to get a point (or in OP's case a spin) relative to the objects facing regardless of region facing. (I didn't come up with it)

EDIT: I updated LSL Portal, trying to keep as much of the original formatting as possible, but it's ugly (rotations page, section on rotating vectors), if anyone knows french or japanese the change should be made to those languages too, I'd do it but translating via alta-vista or similar is bound to just make it incomprehesible.