Issues with Rotation and Position on Linked Prims

[Mirajai Maven]

Okay I'm trying to make kind of like an orbiting sphere with objects orbiting in an alternate patterns. The sphere itself is going counter-clockwise and the orbiting objects are going clock wise. I haven't successful done this without making 2 seperate group sets. (Question #1 is it possible to do alternating rotations all sharing a center axis in 1 object?) 

Also I wrote this snippet of code and it's not working. Am I trying to do the impossible(or just doing it in the wrong way)?

timer()
   {
   integer linkNum = llGetNumberOfPrims();
   integer num = 2;
   llSetRot(llEuler2Rot(<0.0,0.0,-1>*DEG_TO_RAD)*llGetLocalRot());
    while(num <= linkNum){
        llSetLinkPrimitiveParamsFast(num,[PRIM_POS_LOCAL,llGetPos() + <0.0,0.0,0.2-llFrand(.5)>]);
        num++;
    }
   }

 Try as I might I can't get the orbiting objects to spin properly without spining the base with it. Since the linkparam version of set rotation is broken? So I resorted to this, but the code ignores my attempts to reposition specific children randomly. (Question #2 is it even possible to make children of a linked prim change position randomly without moving all of them together?)

[Rolig Loon]

You should be able to handle the orbits by making multiple calls to llSetLinkPrimitiveParamsFast and using the PRIM_OMEGA parameter.  Changing the arithmetic sign on the spinrate reverses the direction of rotation. 

As for your code snippet, you will need to determine each object's local position with llGetLinkPrimitiveParams(link_number,[PRIM_POS_LOCAL]) and then alter that result to set the object's new local position with llSetLinkPrimitiveParamsFast

[Mirajai Maven]

Oh yey! Thank you I'm getting the look I want now. One last question. I'm trying to put some fail safes for the random orbit so they don't just eventually float off into the distance on the z axis. Is there something more efficient than checking against the root position. I know I could store I guess default positions but there are 9 defaults to store. And also checking against the root position with hard numbers won't work quite so well if the object is resized correct?

[Rolig Loon]

There's no reason why they should float off in any direction.  Those Target Omega orbits are stable.  If you really worry about it, though, I suppose you could always save the local position of each child prim before you start and then periodically stop the orbiting, reset to those local positions, and start things spinning again.  Frankly, though, I don't think it's worth fretting over.

[Mirajai Maven]

Ah I want to change the position of the orbiting objects up and down just a bit. Not in a rotation just pushign them up and down a randomly generated amount (while they are in rotation). But I don't want them to pass out of a given range, or if when they do I can force them to switch position in the opposite direction. 

[Rolig Loon]

Oh, OK.  Then you ought to be able to do a small random position adjustment as I described earlier with SLPPF.  Just do a reality check each time you adjust Z to be sure that it's still within your permissable range.  If not, move the orbit in the opposite Z direction.