Skip to content
This repository has been archived by the owner on Mar 28, 2024. It is now read-only.

[BUG-6736] Content Creation: "Link failed pieces are too far apart" #14554

Closed
1 task
sl-service-account opened this issue Jul 17, 2014 · 9 comments
Closed
1 task

Comments

@sl-service-account
Copy link

sl-service-account commented Jul 17, 2014

As a Content Creator what would you like changed in the building features?

The prim linking limitation issue, as I can see from the short time I have been in SL as a content creator (4 yrs.) this limitation has dated back many years. Some of the reasons for this limitation were due to the carelessness and or those that did not care when building and dumping prim across borders of regions and parcels of others. I can understand why this was done years ago. Now it is 2014, and there are changes for preventing large builds and prim from encroaching someone else's land.
This limitation could probably be changed or removed completely now since it is not required anymore due to the protection offered to Parcel and Sim owners.

Estate Manager/Estate Owner access:
allow_return_encroaching_object
Allow land owners to return a regular object that overlaps their land. Read/Write
Can set it in region via the debug console.

Estate Manager access:
allow_return_encroaching_estate_object
Allow land owners to return an Estate Manager's object that overlaps their land. Read/Write

Why would this link limitation removal be important to Content Creators? How would it benefit them and the community?

As a content creator in Second Life I have been hearing many others discuss this issue and wonder why it has not been removed with the expansion to 64m limit on prim size. 64m prim was the first great step for us, but as for "Link failed pieces are too far apart" this hampers us from using less scripts and at times less prim for our builds. This is not a script issue, but using a rez-box to place a build into requires more scripts. Each group of prim has to be linked then a script dropped into that linkset then another script as the main hud to access the rezzing of that build. All these steps slow down the process of creation.

So lets say you have a building of 256 prim but it is quite large, roughly 100m-W x 64m-D x 64m-H, this build would have to be broken down to 2-4 linksets possibly more due to the size and the limits on distance of linking the prim. The size of this build with the limitation would need a rezz-box to package the build. With the limitation removed it could be one large linkset of 256 prim. One prim linkset, no scripts for packaging thus no rezz-box. Much easier for content creators to work with.
I could go on with many more examples, but I am sure that this one example should be enough.

As for the community benefit; if the limitation is removed there is less need for packaging a build into a rezz-box. All that would be needed is to just rezz the full build right where you want and move where needed.
In some cases a rez-box will build around the box not in back of it, during the build it is hard at times to move that box while things are flying all over the place preventing you from targeting the box. If you rezz a complete linkset too close to a property boundary, it will now push it back or auto return it to the inventory intact as a full build.
Please look into request for the removal of this limit.

Thank you

Links

Related

Original Jira Fields
Field Value
Issue BUG-6736
Summary Content Creation: "Link failed pieces are too far apart"
Type New Feature Request
Priority Unset
Status Closed
Resolution Unactionable
Reporter GEE McAuley (gee.mcauley)
Created at 2014-07-17T21:44:31Z
Updated at 2020-10-25T00:48:22Z
{
  'Business Unit': ['Platform'],
  'Date of First Response': '2014-07-21T17:15:56.879-0500',
  'How would you like the feature to work?': "The limitation issue, as I can see from the short time I have been in SL as a content creator (4 yrs.)  has dated back many years.  Some of the reasons for this limitation were due to the carelessness and or those that did not care when building and dumping prim across borders of regions and parcels of others.  I can understand why this was done years ago.  Now it is 2014, and there are changes for preventing large builds and prim from encroaching someone else's land.\r\nThis limitation could probably be changed or removed completely now since it is not required anymore due to the protection offered to Parcel and Sim owners.\r\n\r\nEstate Manager/Estate Owner access:\r\nallow_return_encroaching_object\r\nAllow land owners to return a regular object that overlaps their land. Read/Write\r\nCan set it in region via the debug console.\r\n\r\nEstate Manager access:\r\nallow_return_encroaching_estate_object\r\nAllow land owners to return an Estate Manager's object that overlaps their land. Read/Write\r\n\r\n",
  'Target Viewer Version': 'viewer-development',
  'Why is this feature important to you? How would it benefit the community?': 'As a content creator in Second Life I have been hearing many others discuss this issue and wonder why it has not been removed with the expansion to 64m limit on prim size.  64m prim was the first great step for us, but as for "Link failed pieces are too far apart"  this hampers us from using less scripts and at times less prim for our builds.  Less scripts, using a rez-box to place a build into. Each group of prim has to be linked then a script dropped into that linkset then another script as the main hud to access the rezzing of that build.\r\n\r\nSo lets say you have a building of 256 prim but it is quite large, roughly 100m-W x 64m-D x 64m-H, this build would have to be broken down to 2-4 linksets possibly more due to the size and the limits of distance of linking the prim. This sized build at this time need a rezz-box to package the build.  Now with the limitation removed it could be one large linkset of 256 prim.  One prim linkset, no scripts for packaging thus no rezz-box.  Much easier for content creators to work with.\r\nI could go on with many more examples, but I am sure that my thought has been conveyed by the above example. \r\nPlease look into request for the removal of this limit.\r\n\r\nThanks you',
}
@sl-service-account
Copy link
Author

Rand Blinker commented at 2014-07-21T22:15:57Z

I agree, as a creator I prefer fewer scripts in use as well as builds that are totally linked. I have even done sim wide builds that required even more scripts which cause even more lag and slow rezz-ing. If we were allowed linking at over the current distance limit, and linking more prims in one linkset than the current limit then I believe it would reduce sim lag as well as the amount of time and effort required for larger builds. It would also likely help with inventory size and organization, since to package a large build in a rezzer the builder must put in the scripts, have the rezzer locate the items then take a copy of the items to inventory to add to the rezzer contents, Having to take those scripted items into inventory only adds to invenory size and the potential confusion as to which copy of the item is which that sometimes follows.

@sl-service-account
Copy link
Author

DarkWulf Chun commented at 2014-07-31T21:15:50Z

As a creator, i specialize in housing and other structures. A lot of my builds have exceeded the link limit and not only does it cause problems for me as i'm trying to work on a project and move things around, but it also can cause a lot of frustration for the consumer because they have to use a package rezzer which can use quite a few scripts and not everyone understands how to use the rezzer in the first place. I get IM's from people asking for redeliveries and if i can fix part of my build for them because it didn't rez right or they simply don't understand how to use the rezzer. Personally i have to make copies of each piece after the scripts in each piece have recorded the position, which causes confusion and makes things a hassle when im trying to keep track of things i have and havnt put the script into, if the scripts have recorded everything right and so on.

@sl-service-account
Copy link
Author

dragonslord commented at 2014-07-31T21:25:38Z

I believe is time for Sl to have a better or more extensive limit of linking prims, me as hundreds of other creators have this common problem when creating buildings, the idea on this project I believe would benefit everyone, as it would have less scripts thus better performance for sims, regions and SL in general!
As I see it there would me more pros than cons on this chnage!
Thanks

@sl-service-account
Copy link
Author

GEE McAuley commented at 2014-08-09T10:55:10Z, updated at 2014-08-09T23:47:40Z

h1.Linkability Rules

By what I read and number crunched, changing the Link Limitation should not be an issue.
h3.

OLD Rules: http://wiki.secondlife.com/wiki/Linkability_Rules/Havok_4 (Written 04-02-2004 by Andrew Linden)
Original Post: http://forums-archive.secondlife.com/111/62/11883/1.html

If a linkable set is tested by the linkability algorithm then the final subset of linkable parts is NOT affected by the order in which the candidates were submitted. That is, if just the linkable subsets of the failure modes above are tested for all permutations of sequence they will always link. The proof of this is left as an exercise for the reader.
Formulas

Radius of the Bounding Sphere: SQRT(x^2 + y^2 + z^2)/2
Maximum link span (two prims): Minimum of (3 * (radius_A + radius_B) + LINK_BONUS) and 54
Distance between the centers (two prims): Minimum of ((3 * (radius_A + radius_B) + LINK_BONUS) - (radius_A + radius_B)) and 54 - (radius_A + radius_B). If the 54 meters maximum is not reached the distance between centers formula can be condensed to:
SQRT(Xa^2 + Ya^2 + Za^2) + SQRT(Xb^2 + Yb^2 + Zb^2) + LINK_BONUS

h4.Examples
2 Very small prims
radius_A = ~0.01
radius_B = ~0.01
LINK_BONUS = 2.0 meters
LARGEST_MAX = 54.0 meters
3 * (radius_A + radius_B) + LINK_BONUS = 2.06 meters
2.06 is less than 54
Thus max_link_span = 2.06m

One large prim and one small prim
radius_A = 8.66m (This is a 10x10x10m prim of any shape type)
radius_B = ~0.01
LINK_BONUS = 2.0 meters
LARGEST_MAX = 54.0 meters
3 * (radius_A + radius_B) + LINK_BONUS = 28.01 meters
28.01 is smaller than 54.0
Thus max_link_span = 28.01m
Note this is NOT the maximum distance between the two centers. This is the maximum distance between the farthest edges of A and B.

2 Very large prims
The diameter of a bounding sphere is the square root of x^2 + y^2 + z^2 thus, the diameter of a 10m x 10m x 10m prim is the square root of (100+100+100) = ~17.3m and the diameter of a 10m x 1m x 1m prim is square root (100+1+1) = ~10.1m (The type of prim doesn't matter for this calculation. We only care about the dimensions.) Let's take the case of two 10m x 10m x 10m prims.
radius_A = 8.66m
radius_B = 8.66m
LINK_BONUS = 2.0 meters
LARGEST_MAX = 54.0 meters
3 * (radius_A + radius_B) + LINK_BONUS = 53.96m
53.96 is smaller than 54
Thus max_link_span = 53.96m
Note this is NOT the maximum distance between the two centers. The center of each prim is actually 8.66m meters inside the bounding sphere, so the max distance between the centers is approximately 36.64m.
Distance between centers: SQRT(Xa^2 + Ya^2 + Za^2) + SQRT(Xb^2 + Yb^2 + Zb^2) + LINK_BONUS
SQRT(10^2+10^2+10^2) + SQRT(10^2+10^2+10^2) + 2
SQRT(300) + SQRT(300) + 2
17.32 + 17.32 + 2 = 36.64m

h3.

NEW Shortened Rules: http://wiki.secondlife.com/wiki/Linkability_Rules (Updated 2011-08-27 by Andrew Linden)

LINKABLE = D < 54 AND N ≤ 256
where D = diameter of the smallest bounding sphere of the collection of prim centers and N = number of prims in the collection

h3.

You can do some of the number crunching here if needed. http://www.wolframalpha.com/

@sl-service-account
Copy link
Author

GEE McAuley commented at 2014-08-09T23:24:16Z, updated at 2014-08-14T20:26:12Z

My Numbers using very large prims example:

radius of a 64m prim = 15.6 [ 64m cube = Calculated Cube Root of 3.9999999999999996^2 = 15.6 ]
radius_A = 15.6m
radius_B = 15.6m
LINK_BONUS = 2.0 meters
LARGEST_MAX = 96 meters
3 * (radius_A + radius_B) + LINK_BONUS = 95.6m
95.6m is smaller than 96m
Thus max_link_span = 95.6m

Distance between centers: SQRT(Xa^2 + Ya^2 + Za^2) + SQRT(Xb^2 + Yb^2 + Zb^2) + LINK_BONUS
SQRT(64^2+64^2+64^2) + SQRT(64^2+64^2+64^2) + 2
SQRT(110.85) + SQRT(110.85) + 2
10.528 + 10.528 + 2 = 23.056m
Hopefully my calculations are correct

h3.

This mambo jumbo of math may make some people's heads explode, and I'm still cleaning up since this morning. These numbers are needed to make things work in SL.
One of the issues is quite minor in my opinion with removing or changing the Link Limit is DD (Draw Distance). Those of you that have low end computers and or low end graphics may be automatically set to 64m DD (graphics Low setting) after you install any viewer thus not seeing prim past 64m.
So lets say you have two 64mx2m prim and link lets say as the letter L, if you are set at 64m for DD and the linked point is 66m. That is 64m + the 2m thickness of the second prim linked, you may not see that linked point looking down the long end.

How many times have you been to a huge building such as a castle, were you were not able to see the top from ground level or from one end to the building to the other without seeing a good part of it not rezzed? Remember when you looked at that huge build, what did you first do? You probably at first flew around it to see the whole thing and then finally you realized that all you had to do is to bump up your DD. Even with the DD set to automatic; if I remember correctly, it usually starts at 128m.

Not many users have the DD <96m and if they do I think their computer would have a bit of wiggle room for 128m.
Even with the link limits as they are now, I would think this would still pose an issue at 66m with a DD of 64.
With all the older computers I have worked with, some as slow as molasses in January, if I bumped the DD above 64 I was still able to function.

So as I said earlier on, this should not be an issue. Easily said for someone not doing the programming. It would be nice if we could test this change in the Link Limit setting on the Beta Grid.

@sl-service-account
Copy link
Author

Marissa Linden commented at 2014-08-20T18:10:24Z

Thank you for your suggestion. The link limit is not something we will be modifying at this time.

@sl-service-account
Copy link
Author

GEE McAuley commented at 2014-08-24T23:15:14Z, updated at 2014-09-05T11:23:18Z

Hello Marissa,

Thank you for looking at this issue.

It is not that I do not understand the complexities and the order of things to be done within a company such as Linden Labs. I also do understand that there are many other issues that are more important then this issue.

Closing this issue with one line and without any real explanation I feel was not proper, especially with the votes and followers not only with this JIRA but other JIRAs that are related to this one. This is one of the many reasons for the lack of enthusiasm with Second Life from the content creators, thus causing these creators to eventually leave Second Life to other Virtual Worlds that show more interest in what the creators are doing for them to enhance their simulators. Talking with the owners of two of these worlds; there are no limitations and they have not encountered any issues with the size of builds and the old issues with builders placing items over other simulators or parcels. Mostly, they are just automatically moved or sent back to the owner if there is any encroachment.

I had been given an explanation at a recent meeting on this subject. The issue can only be explained as a visible 64m issue and has been mentioned within my comments on the 64m DD.

I have been a content creator for a little over 4 years. I am a Manager at what was once called Hobo Island, now Hobos. This was once one of the largest known creator sandboxes in Second Life. I have been a member of Builders Brewery, also a well known and probably the largest content creators group in Second Life.
Many of the content creators in Second Life that I have spoken with over the past few years have been very disillusioned with Second Life due to the lack of attention and or the minor attention to our suggestions and issues within our content creation community. Many have stated; why bother placing a JIRA, it will go ignored or just be closed with little to no input from the Labs. Many already have left Second Life and I have already seen them on other simulators doing what they do best, building. Can we afford to lose creative people in Second Life? We should be trying to retain these content creators, artists, graphics designers etc., not be sending them away disillusioned.

At a recent meeting I attend we were honored with the presence of Linden Lab CEO Ebbe Altberg. I will paraphrase in short a comment he made about Builders / Content Creators in general.
The content creators are one of the main reasons Second Life is such a pleasant place to explore and enjoy...

I am not really here for a debate on the subject. This issue has been around since 2007 and possibly before.
Remember this. It is the Content Creators of Second Life that make Second Life more enjoyable for everyone. I do not think there would have even been a small following of Second Life if things were just a flat plain and a barren world.
Always show your appreciation and nurture the imagination of others to create, create the many lands that add to the beauty and wonderment of Second Life.

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2014-08-24T23:24:09Z

GEE - you should not reopen a feature request issue once a Linden has traiged and closed it - just sayin' ;)

@sl-service-account
Copy link
Author

Marissa Linden commented at 2014-08-25T18:11:07Z

Hi GEE,

Thank you for your response. Please understand that we recognize how important your feature request is to you. We took it under serious consideration among a group of our internal developers, and came to the conclusion that implementing a change like this would be too great a technological re-design to undertake at this time.

As you stated, we need to weigh many different considerations, like cost/benefit analysis, technical difficulty, potential for abuse, etc. in order to make decisions on which features we can accept, and which we can't. This request is one that we cannot commit to at this time.

Thank you for your understanding.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant