Having prims collide with each other without submitting to gravity

As the title of the topic says: what I'm trying to do is find a way that two prims can be physical of one another but not be physical in the sense that they're affected by gravity. For example: rear-view mirror fuzzy dice that are hanging by the string. However, I don't want the pieces to be dependent upon the string, I'd like for them to hover in the air but still collide with one another. This would be my first obstacle to overcome. After this, I would need to know how to anchor two pieces together but still allow them to turn. For example: a wheel and axle. The axle needs to be stationary, but allow the wheel to turn without letting the wheel come off of the axle. THEN after I get that figured out, I would need to know how to script turns for different pieces of the combination of prims. For example: one wheel on each side of an axle. I would need the left wheel to rotate one direction, stop, then the right wheel to rotate the opposite direction. All of this will allow me to complete my first build project that I want to keep a secret because if this hasn't been done yet, I don't want to have someone steal the idea. >:0 So yeah, I'll be trying to research a way to do all of this while generous people like you all could give some insight as to how I would make this magic happen.

Thanks,
Ross Penucca

EDIT: I'm guessing that for the "axle and two wheels" set, I would need to link them together in order to anchor them all together, but then that wouldn't allow them to move freely from one another, would it? If so, then how would they be able to be anchored to each other while still being able to move freely?

EDIT #2: Here is a list of all of the prims that are to be included (in case this helps):

1) 1x 3-prim group of cylinders (very similar to an XYZ trio of axes)
2) 6x 2-prim groups of 1 cylinder and 1 rectangle each (similar to a thumb tack)
3) 12x 2-prim groups of 1 square and 1 rectangle each (similar to a "T"
4) 8x 2-prim groups of 1 square and 1 eighth-sphere each (similar to a cube stuck in part of a rock?)

The 1x would be the aforementioned "axle" and the 6x's would be the aforementioned "wheels". So the 6x's would need to be anchored to the 1x (one on each positive and negative of all x, y, and z axes, in other words) so they don't fall off of the 1x, but the 6x's all need to be able to rotate freely from one another, affecting none of the other five 6x's or the 1x. If this is too confusing to you, PLEASE PM me and if you seem willing to help and not take my idea (which I should just go ahead and copyright the idea to me now...for SL purposes anyways), then I'll tell you what I'm trying to make so that could help clear up confusion.

EDIT #3: I've also noticed that that's a total of 55 BASIC prims, but since there are groups of prim groups, would it technically be going over the 31 prim limit or no? I would think not since each group of prims would act as one prim toward the main group, which would be the 1x XYZ axis.

On reading this my first thought is that it can't be done, I don't belive the physics engine is up to it.

My second thought is that if it can be done it is going to require a lot of heavy duty scripting.

I would suggest cross posting this to the scripting forum and see if they can come up with anything (I don't normally approve of cross posting but in this case i think it is valid).

Sorry I can't be of more help.

Ok...well...would it be possible if I could somehow make a stand for my object that it could then be affected by gravity but still be elevated?

There used to be "joint" connections (pivot, hinge, etc.) in SL which allowed the sort of attachment you desire. They were removed because they didn't work properly and/or caused the old Havok2 physics engine to go wonky.

for the dice, i would put them inside a transparent hollowed sphere.

the wheels require a more complex explaination than i can give here. I'll pop inworld and gift you a couple of working wheel systems.

I do not think this can be done using physical objects. There are a number issues in building mechanics using the physics engine. The smallest reasonable safe (as in not blowing up) bearing I have build is at around 1.5 meters in diameter. So I think that part is out.

Now, your original title question: physical objects unaffected by gravity is easy, but requires a simple script: "llSetBuoyancy( 1.0 );" to be put in the state_entry method of a script inside the prim, and it will float where ever you put it, and it can be physical.

Anchoring things together make them one object seen from the physics side. Using scripting you can still make them turn and rotate compared to each other though. As you start to let the axis turn, and want the wheels to move along, and still rotate around the axis, it starts to become heavy in rotation scripts. It does not sound outright impossible, but is is surely no longer a "build" exercise, but a scripting exercise.

Finally, there is not such thing as "prim groups". It is all linked into one massive chunk, so you will hit the limit of 32.

Sorry for being so pessimistic about your idea.

XD; Thanks for the support everyone, and don't be sorry about critiquing. The idea I had was making a sort of sculpture kinda..thing? That scrambled its pieces up then solved itself using a specific set of rotations and such: a Rubik's Cube to be more specific. I would REALLY love to try to make one, but if it just can't be done through the current physics engine, then I shall make something else that I've been thinking about. XD

EDIT: I believe one of my problems is that I'm trying to make it too complicated with all of the trinkets and doohickies on the inside when I could just make 27 boxes and stack them to make a 3x3x3 cube. Now, with that being said, is there a way that a prim can be affected by two different root prims and their scripts? I suppose this question should probably be posted in the scripting section, huh?

EDIT #2: Ah, I see now. What I wanted to do at first was essentially hierarchical root prims, which aren't available (yet).

Ahh now we know the problem, we can give some answers.

Physical movement is not needed for this.
27 Cubes stacked as 3x3 is the way to go.

Physics are not needed.
you can rotate a non-physical prim

see
http://wiki.secondlife.com/wiki/LlSetRot
http://wiki.secondlife.com/wiki/LlSetLocalRot

still really a scripting problem (and assumes you know how to solve the problem) but definately possible.

link all 27 with the centre as the root prim, and put the script in there.

Edit a quick google found this
http://www.wrongway.org/?rubiksource

Yes, this much is true, but you do know how a Rubik's Cube works, right? For instance, if I had a White-Red-Green corner piece (called a corner cubie) in the, for example White-Red-Green intersection, you could turn two faces 180 degrees each and end up with the White-Red-Green corner piece in the Blue-Orange-Yellow intersection, so all of the cubies are not necessarily anchored to the core of the Rubik's Cube, only the centers of each face are because they don't move their locations. With this being said, the only pieces that would be allowed to be linked to the core of the Rubik's Cube would be the central core, so only the 6 adjacent cubes would be linked to the root/parent cube core. So basically the other 20 cubies (the pieces that can change their position throughout the Rubik's Cube) must not be linked to the central core, but at the same time be anchored into the Rubik's Cube so they don't fall out. This is what my original design did, and seemed that if I had a larger prim limit and a hierarchical linking system at my disposal, I could do this, but I can't.

I don't think you even need to actually rotate the prims. You can achieve the necessary effects by changing the textures on the affected surfaces. This should be easy, as there are only six fundamental operations (90 degree clockwise rotation about each of the six faces) and these are the same except for axis and sign. All more complex operations are sequences of these. Definately a scripting problem.

....Oh wow....I did NOT even think about simply changing the colors of the faces. However, that would require a LOT of llSetColor's to perform, and I would have to note down what each pieces's colors are at each step of the scrambling and solving steps. Thanks a bunch, I believe I can do this easily now. The only problem with that is that I won't be able to see the turning animations....but that's ok~ This shall be version 1.0, lol.

The animation part can be done by coloring the third that is to be rotated in transparent, and then rotating a non-transparent slice in its place. This should give the right visual effect.

Alternative: a script to unlink the 9 that need to rotate from the cube, link the 9 into a slice, rotate them, and re-link back onto the cube.

Yeahh...I think I know what you're getting at, but for my first official attempt, I'm just going to load my scripts up with llMessageLinked's and llSetColor's. But once I get this working for a while, I'll take a look at the animating.