Multiple level Base objects for built objects...

I am suggesting that a hierarchy of "Base" prims be set, so that the highest Base(set by a dropdown menu, of 3rd level base, 2nd level base, and 1st level base), 1st level Base Prim, would be the "center" of the object when calculating object location, et cetera. However, this would allow the Second level prims to set up various scripts that are only connected to that specific 2nd level base prim. For instance.

I build, say, a Vulcan Cannon, a small 3-barrel rotating minigun, that, when I push a button, begins spinning and "firing". As the system stands right now, the whole object would begin rotating if I told it to, not just the barrels. With the hierarchy, I could set the barrels to rotate under the "2nd level" prim channel, which would cause only that set of prims to rotate instead of everything.

The setup would be based on Channels, with a limitation of about 16 channels per object, that would allow you to set up scripts that only work on the individual channels, based on which base script they are set upon. This would allow, say, a builder to build a helicopter with realistic counterspin in the rotors, as well as a more realistic spinning tail rotor as well.

I am aware of the texture anim function, but I think it's time we stopped using shortcuts and started using better Prim work. We're on a high end system set, and most of our users are capable of rendering a decent prim setup, I think it's time we put that to use. You will see other suggestions along the lines of making more prim-intensive setups possible in the future.

Having nested linksets would solve these problems too.

Agreed. Some type of hierarchy would be great. Right now I have a model of the SL AV in SL used to creat poses/animation from within Secondlife. As it stands there is a script in every prim to figure out the hierarchy of the skeletal system. Althought how to define the center of each sub set is also something that need to be defined. So something like a property of the prim could be set. llHierachy(integer group); where you use the 32 bit integer. Then use a bit field to determine which prims move, which it what I' using now. not sure how an event system would be handled for somthing like this... Right now i use link message where the integer is "link group" and pass all value thru the string. Again the first set is 1, second 2, third 4 , forth 8 and so on which allow you to define branches in the heirarchy. any more ideas? expand on this. walking pets, walking vehicles, all sorts of stuff.

This is an incredibly important feature request. Proposition 1547 states the request for a hierarchy perhaps a bit more specifically, so I've thrown a few of my votes there.

At its simplest, a large complex object like a house should not "disintegrate" into 250 individual prims when you unlink it. This is complete madness- it wasn't assembled that way, and it matches no practical construction system from the real world. A house consists of a dozen or so main objects, each of which consist of dozens of sub-objects, some of which have their own children. This is how we think of things, and practically I'd suggest this is the best way to model objects.

More importantly, even a relatively simple compound object would be made richer if its sub-objects remained "discrete" within the larger whole. Case in point- a porch swing. We've all seen them in SL- they consist of two unlinked objects, one with the frame and one with all the moving parts. If the "swinging" part of the swing remained aware of its existence as a seperately linked sub-object, it's scripts could continue to act on it as such.

I was flabbergasted when I went to add a scripted rotating three prim door handle to a door...and found that my handle suddenly "forgot" that it was a discrete linked object. A moving object (handle) within a moving object (door) becomes non-intuitively complex to create in the absence of an object hierarchy.

I don't doubt that there are some significant complexities in making linked object hierarchies work- however, I'd suggest that it is crucial to permitting the effective creation of more sophisticated builds.