Multiple Link Levels

Before I propose this I'd like to just run this by someone to see if (a) it's possible or (b) there's already a feature like this.

You know how when you link two items together, they become the same item and from then on it seems you can only unlink them prim by prim? It'd be nice if you could link two items, then have the option of unlinking the two original linked items. For example, if I add something onto a paw (such as bracelets or a ring) I'd like to be able to take just that off if I want to make changes to it or something. Just a suggestion.

It's called a hierarchy. Each object has a parent, which may or may not be the "root prim."

Would cause possible memory issues as the current link limit is ~250, if you give it a hierarchy, either a) limit how many childeren each prim can have: breaks existing content if below the current max. b) limit it to the currnet max and have memory overflow as someone tries to link a 250 prim object to a 250 prim object to a 250 prim object to a 250 prim object to a 250 prim object, ad nausium. c) limit the depth of the "tree" so that B is possible. d) limit the entire object to 250 prims, forcing a rewite of the link list, which would probably be slower as currently it just checks how many prims are in the selection set (assuming we want a true hierarchy and not a link history).

And this has been suggested at least once before, and once by yours truely.

Actually, you can unlink multiple prims off of a link set. Do this:

1. Go into edit mode.
2. Choose Edit Linked Parts.
3. Select the prims you want to unlink off together by holding shift and clicking each one (or drag-select).
4. Hit control-shift-L.
5. Sometimes when you do this, it'll leave those unlinked prims selected along with the main object, so whole holding shift, click the main object to deselect it.
6. Optional: hit control-L to relink the prims you unlinked off, if you so desire.

I hope that helps :)

Oh, yeah, I know how to do that, but like sometimes I have something complex (like hair) and I work another rather complex thing into it. I'm all for the 255 prim limit still standing - I'm simply saying, if you like a 100 prim item and a 100 prim item, remember which was which.

Considering my current method of getting around this is creating a copy of every "body part" with an attachment (in areas other than, say, the head where I have a bunch of static points to choose from), I think this would be much more memory efficent. At least for raw HD space on the servers.

Or that, allow more than one attachment to a point. Obviously not many, avatars bring my computer to it's knees and I play HL Source-based games at full options at about 50 fps.

I dunno about "multiple" link or "hierarchy" but what about 2nd "generation" linkset?

Having linkset in linkset in linkset in linkset in linkset and goes on and on, could be memory issue with data problem.

Instead... why not more than one linksets in only one linkset?

hierarchy is like a tree that can go many branches on branches.

but 2nd generation will only limit to one level, the main linkset or call it the parent link and that other linkset is the child.

Of course it would limited you from having hierarchy's form, but I'm sure 2nd level is enough for a lot of possibities that can be done with this method.

Think about it... a 4-prim door linkset in a house linkset able to open by only the root of the door's prim in its own linkset. Even better, a tank with a turret that rotate by its own linkset root!

Yes, and "640 KB RAM should be enough for everyone".

Why setting an arbitrary limit *again* instead of properly implementing a hierachy structure in the first place?

Quoted for truth.

the infamous "640kb Ram" quote isn't something to use in this statement... because back when he said it, all the softwares didn't need more than that. Well duh, of course we need more than that because softwares changed. That statement was about not going over the board when it's hardly used for anything during that market timeline. For Example... You brought a "Blue Gene/L" Computer system for what? To play Half Life 2? I'd just point at you and laugh while you file a bankruptcy and tell your parents that you gotta go play the REAL Half Life game in Iraq.

Now, you asked a really good question about limiting arbitary. Let's just say, it's unlimited, we have the hierachy in SL. Can Havok 1 and few Non-Class-5 servers handle all the madness of crazy-over-excited scripters building a walking mechs that has more than 8 legs and snake-like robot arms? I'm putting my bet down, no. Not when SL has more than 10,000 Active Online users.

Maybe after the Mono? Can't tell, cause we have yet to see this new "Mono" system to support SL.

Seriously, haven't you ever wonder why some FPS games has a limit of players in one server network game? Everything need a limit, there's no such thing can be unlimited except outer space.

Best to say, let's start with 1 more link level (2nd generation linkset/groupset). If that flies well enough, add another. One step at a time. There's no harm in that.

It is an example of a limitation that bites you later when you try to expand. The 640 KB limit has been a problem for every memory expansion that had to be made when 640 KB were *not* enough for everyone anymore.


We don't know if the servers will be capable of handling this, so this is a theoretical point that can't be discussed.


Of course there is a limit to everything technology-related. But that doesn't mean we should limit our software arbitrarily. The system should be aware of how much load it can handle and offer as much resources as possible. When more computing power is available the software can adapt and offer more resources.


Nothing wrong with that, but the interface and inner workings of this system should already be capable of using unlimited hierachy, so there will be no need for new development work when it proves to be working.

I guess? But can you ask all the people not to abuse that "resources"?

Those hackers that attacked the grid abused it by using bunch of party hats that Linden created in the library folder.

But meh, I guess we could take a risk to see how bad it could affect from using unlimited hierachy.

Although... that's another thing to think about. Should use 255 prims in each hierachy line or in the total of the whole unlimited hierachy line to keep the whole thing under the same limit as one link-set?

For compatibility it would probably be best to keep the 255 prim limit per linkset. I wouldn't mind seeing this limit go away, too, but as stated before, the limit should correspond to the available processing power and not be set arbitrary.

Not true. When he said that there were already personal computers available with a meg or more of RAM, and operating systems that could use it effectively. The quote is particularly appropriate because Like Microsoft, Linden Labs backed themselves into a corner with their system (the joints system that previously provided a hierarchy). Unlike Microsoft, though, they're working on digging themselves out of it and are willing to temporarily remove features to make it possible. They used to have a one-level hierarchy called "joints". The code was implemented on top of Havok 1, and was distributed all through the system. When they tried to upgrade to havok 2 they couldn't do it *and* retain the joints.
Mono has nothingto do with the physics engine.

They had to remove the ability to create joints as a first step to removing joints from the system, which is why you can't create them now. Once that is done, and all the code that involves joints is cleaned out, THEN they can upgrade to Havok 3 and put joints back in using the new code.

Dude, we're not even talking about Mono affecting the difference with the physical engine at all.

In Fact, it's more likely that Linden is going for ODE instead of havok 2.

Geez.

Then why bring Mono up at all? There's not a lot of interaction between "going to mono" and "upgrading the physics engine". The physics API in LSL will have to remain the same after either of these updates, to avoid breaking content, so there's no dependancy either way. Which is a good thing... I've written real-time control languages and getting an off-the-shelf engine tuned for performance to work well in a real-time environment is damn hard. Don't plan on Mono happening soon.

Back to the physics:

LL has already said that they're going to Havok 3. They've explained why they couldn't go to Havok 2. They've explained what they're doing about it. Bringing back joints (which will give you multiple link levels) is on hold until they've completed that, because that's what kept them from going to Havok 2 in the first place.

Do you have recent information suggesting they're going to use something other than Havok 3?