Moving-attachment - Feature extension

http://secondlife.com/vote/index.php?get_id=607

1.7's feature to have moving attachments would be a whole lot better if we could move a bunch of them at once.

1. Heirarchical Linking (Tree-based linking)

a. Essentially, organize primitives in a tree / heirarchical set.
b. Branches could be trimmed off or added, removed, or re-ordered.
c. Individual prims could be edited, or entire branches.
d. Scripting linking could be altered to allow scripts to affect entire branches with sub-branches, or a list of branches. (Along with 1.7's movable attachment prims, would greatly improve ease-of-use and functionality of this new feature!)

2. Move sitting AV on script-moved prim

- Currently, Avatars sitting on prims are not moved if the prim is moved by a script.
- Since moving them by hand will move the AV, it makes sense that the script method should work the same way.
- This would allow new features for vehicles, seating, carnival rides, and combat games.

This is the first time I'm voting, and I'm putting all my available votes into this Couldn't agree with you more. Though I was wondering if there might be an easier way for LL to implement this. I'm thinking out loud here, so tell me if this works and achieves the same thing.

Add the ability to set a 'target prim' as the reference/origin for local position and rotation changes. This target would be a different prim in the linked object. The key implementation detail here would be that this target could move (change position/rotation), and all the prims that have that prim as a target would update their positions and rotations automatically. I think this would achieve the same effect of hierarchical links, but the scripter/builder would have to do it by setting up the targets correctly. And of course, prim X could have prim Y as a target, which in turn could have prim Z as its target, and so on, so you get the multi-depth capability too.

From the point of view of implementing it in SL, it would probably be a similar amount of work. What this would save is the complexity of branch/tree management in the UI. In fact, the UI might not need to change at all. That complexity gets pushed out to the builder/scripter, i.e. they'd need to build the link tree by setting up these targets correctly. In fact, it would make the building a lot more complex if we couldn't just link up a sub-tree and then link that to a bigger object like you described. I'd prefer to have it your way, but if it's easier to implement the way I described it and makes the difference between getting it and not geting it, I'll settle for that too.

Does that make sense?

And if A points at B which points at C which points at ... which points at Z, which points at A... then the world explodes.

I'm guessing any kind of implementation would have to check for loops, which basically means building the tree anyway. It might be better as a way for the scripter to control things, but I doubt it would make much difference on the business end.

With 1.7, basically the scripter will have to keep track of each and every prim they want to move and calculate the movement for all of them relative to the primary prim. Imagine something like a transformer with 100 prims, and you get a concept of how tedious that would be.

With the suggestion of tree-linking, the user just needs to know the start of the branch and how that will move relative to the prim it's attached to. Way simpler.

Good point. That would completely break it.



True. I was trying to save them UI development work. The back-end logic development would be about the same either way.

I was thinking about the UI needs for this, and it might not be that bad. Today, you can link together objects that are themselves linked objects. So that interface could stay the same, with the change that all the prims in the subset remember what their branch-root prim was. Hmm... and along with 'edit linked prims', maybe an 'edit linked prim branches' checkbox, where clicking on a prim selects the branch at its level and everything below that. And a 'flatten link branches' or something for when a builder actually wants everything to be relative to the main root? Though an unlink-relink would probably achieve that too.



Which is the same as 1.6 with unattached objects, right? I think your idea has merit beyond just moving attachments. Having this feature would allow for much more complex moving objects, both attachments and otherwise.