Linking objects and limits

Eh everyone, just wondering if there is currently a limit as to size/amount of objects you can link together etc?
I am trying to put together something and being the object size restriction of 10m, I am forced to link several objects together to make it work. My problem is that when I do the click/edit and <ctrl> click to select a bunch of objects to link together, it doesn't always work. I will click Link and they are still not linked together. So curious if it's a bug or if there is a limit on the amount/size of the objects to link. (ie. a lot of them are 10x10 wall slabs and I am linking about 10 pieces etc. <edit: possibly upwards of 20 pieces>

Yes, there are limits. The logic for success is a function of the size and placement of the objects. Its exact expression is too complicated to describe in words here, however for just two objects it is approximately as follows:

IF the distance between the center of masses of two objects is less than 32 meters

AND

IF the distance between the same center of masses is less than the sum of the lengths of the diagonals of the bounding boxes (plus 1 meter)

THEN

yes, you can link them.


Another way to say this is:

You can link a very small object to a very big object up to approximately the radius of the big objects bounding box (plus 1 meter) from the big object's center of mass (which you can only eyeball, but the server knows where it is). Two large objects can link twice as far (plus 1 meter) as long as it is less than 32 meters.


Unfortunately there are many good technical reasons for limiting the size of objects so the limits here are not likely to increase soon, sorry.

What if you made a sim where these constraints were taken off, but the objects created could not be put in the inventory, and died when they left the sim.

bad dave! *wammos dave*

Three years have passed.... why has this important issue not been corrected?

Lewis

Larger prims depend on collisions across region boundaries.

Collisions across region boundaries depends on an overhaul of the physics engine.

The ovehaul of the physics engine has been broken up into smaller pieces and continues to happen in the background, although more slowly than I had hoped as I and others get sidetracked on non-related, but important projects.

I guess if it's "still being worked on" theres not much we can do, but I would guess there was perhaps a lot more use for this kind of thing than you realise.

If there is a limit of 30m, why can't it be increased to 40m or 50m? Sure, a 200m build would be a problem but thats not really too big - and its not just for moving things, being able to build a roof as a complete object on a large building would be helpful for those times when moving is necessary.

Lewis

There is also the problem of clamping down on 50 m cubes on small parcels that aren't big enough to fit them. The vast majority of the prim would then cover nighboring parcels. Sure, we already have that problem now since you can put a 10 m cube on a 4x4 parcel, but I don't want to make that problem worse without solving it first.

So, bumping 10 to 50 depends on solving the placement problem.

Solving the placement problem depends on being able to do asynchronous collision detection quickly and cheaply.

Asynchronous collision detection depends on an overhaul of the physics engine. (Havok-1 can do it, but it is unsafe (dunno if you'll deep-think when you try), and it is too slow/expensive when the object count in the simulation is high.)

The ovehaul of the physics engine has been broken up into smaller pieces and continues to happen in the background, although more slowly than I had hoped as I and others get sidetracked on non-related, but important projects.

...

There are a lot of cool features that follow this path of dependencies, which is why internally to LL I've always been a strong supporter of prioritizing work on the physics engine, and why it was originally the #1 voted item on the resident's feature request page.

You might ask, "If it is so important why isn't LL working on it?"

Did I mention the non-related but important projects? Well, some of them were ranked as Very Important (TM).

And after that you might ask, "What about all of the unimporant stuff LL is works on?"

There are many developers at LL and coordinating the schedules of all the projects leaves little windows in the schedule where small less important stuff can get done, but big important stuff wouldn't fit. Also, some of the unimportant stuff can be good early projects for new developers, or can just be a fun way to wrap up a heavy week or a busy day.

Just thought I'd chime in and back Andrew up a little when it comes to developement.

Developers tend to specialize on particular areas. So let's say Physics, Database/backend, graphics ending, UI.

Now if all the important issues are in Physics and Graphics (which is actually close to the truth in SL ) do you want the UI and DB guys ( who are useless when it comes to helping on the important issues - it's not their area of expertese ) to be sitting on their hands? Of course not so you see apparantly low priority stuff like the Inventory upgrade come in when other bigger issues are still unresolved.

You also can't have too many people working on one area of code. Each file ( and there are admitadly probably 100 or more ) of code can only, at any one be worked on by a single engineer. In fact a single engineer may need to edit more than one file to resolve an issue. This is called code control and stops the confusion that happens when two people edit the code at once.

If two people edit the same file, then when they return it to the central code store the changes need merging. This merging of course, especially if both files have been heavily modified can in it's self cause problems. For example Developer 1 completely re-writes a function, Developer 2 at the same time uses the origonal version of their function to accomplish something. when the two files merge Developer 2's changes break and Developer 2 now has to do it's work again.

Fixing bugs or doing complex updates is NOT as simple as throwing every developer you have at the problem. Code development is definatly a case of 'Too many cooks spoil the broth'.

Don't get me wrong btw I'm not saying LL is doing things perfectly, however I hope this gives an insight into why fixing a lot of bugs in a particular area can take an apparantly long time. If there is a lot of bugs in a small area they have to be fixed sequentially pretty much not all at once.

I know this because I've worked on a large multi million line project myself with a team of developers. Sadly dont' develop code any more tho .

Question: Wouldn't enabling phantom and nonphantom prims in the same object help drastically by reducing the amount of prims for which collisions to be calculated? How much of a performance drain would it be to calculate the collisions for a 64 prim vehicle with 20 or more phantom prims? That seems to me like a good course of action to help with the physics engine on SL. Or maybe I'm just noob and someone mentioned it before. You decide.