Circles within circles... a rot problem

I know I know - ugh! Another rot question.

Here's the idea:

Part A: a seat, that rotates.
Part B: a vertical ring, that rotates.
Part C: a horizontal ring, that rotates

Part A is affixed at the top of the outer edge of part B (so basically a spinning chair that travels around the outside edge of the vertical ring - yes, getting inverted at the bottom of the ring). Part B's centerpoint is linked to the outer edge of part C (so the combined A & B are swept in a wide arc around part C's centerpoint...)

You're looking at this and saying (aside from "Eww, motion sickness" "well there's your problem: you can't do xyz"... and I'm saying, yes, there's my problem - the issue is, is there a solution? (preferably something simple - I'm a builder/texturer, making baby steps towards scripting...). Is it completely unworkable with the current state of SL's rot mechanics (including the issues of avatar motion)?

Or... if there's a scripter who likes challenges and has nothing to do (yeeah reeeight) who would be interested in helping set up a themed sim we've been kicking around, let us know. Feel free to contact me, Solivar Scarborough or Daequix Scarborough inWorld.

Blessings of the Spanner be with you.
Gadget

It's possible to implement this, but the movement will be "choppy" or "warpy".

There are two limitations working against this scheme.

1) There's no hierarchy in objects. That is, I can't set up two objects, attach them to each other, and set them up with independent rotations relative to each other. The way I interpret your example, you want to have a platform C that rotates. That's no problem. You want to have platform B attached to C, and rotating with C's rotation as well as its own. That works too. But where it breaks down is when I attach seat "A" on to "B" and want to use A as a seat-- it fails here. What you want to have happen is for A to move with both the rotations of B and C put together, complete with the ensuing motion sickness. But what actually happens is that A moves relative to C. What you want is C is the parent of B is the parent of A. What you get is that C is the parent, and everybody else is his child. What that means is that you can't do the motion that you want.*

2) *Technically you can produce the movement that you want by calculating it in a script and setting the position. The downside here is that the motion won't be smooth. It'll be updated about 2-3 times per second. If "warpy" "jumpy" movement is acceptable to you, then it can work splendidly. I created a neato script that lets a giant juggle multple avatars using this technique. But the movement looks more like the way a hummingbird moves than the way a ball moves through the air. But once you set the avatars on fire and play screaming noises the effect still works

If you had two seperate objects it would work mb? Basically you have B as the root and A as the child of one, and using llTargetOmega you set it to spinning on say the X and Z axis (so it goes round and round while inverting). You add this script to B to get the whole thing spinning.
You then set C to rotate seperately, again using target omega, but in your case (if I've interpreted it right) you'd only spin on the Z axis.

My mention of axis is most likely utter rubbish, but I know that with only two rings you can get them to rotate using target omega in such a way that it looks as if they are logically joined at a point. It's tricky but by trial and error on which axis to use not too difficult I think.

Haravikk is right that you can set B and C spinning in different ways. But that's only 1 level of child, and the original poster asked for 2 levels of parent-child (a scene hierarchy).

C is the parent, and it's spinning. C could be the platform that the whole thing sits on.

B is a child, this could be a teacup attached to the surface of the platform towards the edge. B is spinning its own way on its own axis, plus spinning with the rotation of the parent.

All works great up to this point.

But you can't put another prim (A) on B, let's say a seat in the cup, and have it work the way you want. Instead, A would rotate only with the the platform (C) rotation, ignoring the spin/omega of B.

Try it out. If I'm wrong about this, I'd love to know how to do it.

Juuust great ... got me thinking again ... and I have too much on my plate already to think about.

You got me curious as to whether it's actually possible to do smoothly.

It might be possible to do it smoothly like this:

Calculate the positions of "waypoints" that (A) would take, let's say 20 or so of them. Next, use llMoveToTarget to move through those waypoints in succession.

The downside on this approach is that (A) needs to be physical. I try to avoid making things physical, because that mean's they're breakable. In particular, they're prone to dropping their physical flag and locking up if something comes to intersect with them. This means more work if you want this object to always work without human intervention and maintenance.

I'd still say two objects is your only real option, you could have the part with the seat (B & A combined) rez C as needed, if you're concerned about packaging it up for other users?
Linking hierarchy is an idea I seem to seeing more and more uses for now that I think about it, hehe

Sounds a little more than my limited understanding of scripting can handle. If it helps, it doesn't need packaging - it'll be a static attraction.

Thanks anyway though - I appreciate the thought you all put into it. It'll have to wait till I'm smarter I guess.

Ta
Gadget