Problems linking a rotating prim to a stationary one.

I've created a dance floor comprised of several layers. One of these layers has four disks each with a rotating texture. They in turn are linked to a parent rotating prim. They have the properties of being a phantom. They are located in the middle gap of the floor assembly. It all works fine until I try to link to rotating parts to the main body of the dance floor, which is needed if I want to sell it as a single item. When I link the moving parts to the non-moving parts, (parents), the rotating prims stop moving. (And it's not because I'm still in edit mode.) What is going wrong here? The following is a rough cut-away view of how it is assembled.

Is the non-phantom part of the floor physical?

I heard somewhere that you cannot link phantom and physical objects together...

One possible solution would be to make two separate objects, but make one of them a follower of the other... Then, when the one moves, it tells the other what it's own orientation is and the other can move to the correct orientation and location...

It would involve some scripting, but it's do-able if you cannot find another way...

You can't currently have a portion of a link set be phantom/physical while the rest of it is nonphantom/nonphysical. The way to do this is to line it all up, select everything and "Take a copy"

You'll get one object in your inventory that when rezzed should keep its alignment without requiring linking.

Allen: from the fact that your top layer is solid, I am guessing that you don't need the texture layers to be phantom at all - but making them solid will not solve your problem.

You are probably using llTargetOmega to rotate the tex layers, and it was never really designed with linked items in mind. It tends to work until you rez from inventory, when either the tex layers won't rotate, or the whole floor starts rotating (usually around the wrong axis!)

Take a look at llSetTextureAnim, to rotate the texture on a stationary disk, rather than trying to rotate the disk.
Shout if you need more info.

Three things you need to know:

1. As others have stated, you can't link phantom and non-phantom prims together.

2. You can't link rotating objects to stationary ones. Either the object will rotate as a whole or not at all. The solution is to rotate the texture, not the actual prim.

3. You do NOT need to link the whole thing together in order to sell it as a single item. Just select the whole thing by drawing a selection box with the mouse, and then take it into inventory. It will appear in your inventory "packaged" as one object. Give that object a name, and then put it into the contents of your sale box. When the customer extracts it and rezzes it, all the parts will be in place.


Edit: After taking a more careful look at your diagram, Like Ben, I'm wondering what is the purpose of the phantom prims. An object only needs to be phantom if you actully need it to be intangible. Good examples would be maybe a layer of fog above the floor, the surface of water in a hot tub, or a waterfall that you need to be able to walk through. Since your phantom prims are encased by solid ones, they're never gonna be touched. So why have them phantom?

I would like to point out that phantom prims and non-phantom can be linked but the added prim(s) gets changed to the state that the root prim is in. If the root is Phantom then the linkset becomes phantom and vise-versa. You can link a rotating prim to a linkset under a few situations:
The prim that is rotating is using llTargetOmega or using llSetLocalRot (This only works on a specific child prim in the linkset, with how your setup is, it will not work unless there is some fancy updates made to the desgn) with some advanced timing/calculating to get a good rotational feel to it. But llTargetOmega is a weird one to use so be careful with it and how it is set in the linkchain. llSetLocalRot is also a strange one to use due to how it sleeps the script for .2 seconds. So I agree that rotating the texture is the best idea.

If it is absolutly necessary to sell as is with rotations and phantom then the method of selecting all then taking is the best. But if you want to keep it as 1 object till it gets "installed" then some fancy scripting could be added to where the objects gets placed where it will be, the owner issues a command and the object performs an unlink function on specific parts then converts them to phantom.

I hope this helps any

I Edited to add that if the rotating texture needs to look "fast" then perhaps creating a new txture in Phootshop or Gimp using a Radial Blur, couple that with a texture rotate and it looks pretty real as far as high-speed motion goes.

If I provide enough clearance between the layers it all can be non-phantom. The moving layer's child parts already are using the llSetTextureAnim to rotate the child textures as the parent rotates, via llTargetOmega. See the rough diagram below. These are very slow moving. The reason for the top layer was when the moving layer was exposed and solid you whould have the problem of the avatars being carried around with it. I made it a phantom so it would pass through the solid layers should I not have it alined right. (I have not tried saving it to my Inv. and retreving it to see if the animations startup correctly.)

From what I gather their is no easy way, or none at all, to group this as one piece permanently and still work. It will have to be two separate groups and when it comes time to move it both groups will have to be selected at the same time.

Here is another thought to the object in question, instead of having to select each part separatly, possibly configure it in a way that the center part is in the one parts contents, drop in an llDialog script or a simple non-channel 0 listener for the owner in an object rezzer script. So when the owner of the dance floor is staisfied with it's position, they can command the inner workings to be placed in the spot they were made for with no muss no fuss and no nasty selection process on either party to move it. Move the shell or stationary component, delete the rotation part and command another rotating unit in to the new location. I would really love to see this item in production as it looks to be cool from the diagrams you have provided

Where there is a will, there is a hack