A note about the returnable encroachment feature...

It introduces a new definition I'm calling "Estate Content".
Estate content is stuff owned by the Estate Owner, or an Estate Manager.
It is treated differently by the "returnable encroachment" feature,
namely in order for Estate Content to be returned there is a special
per-region setting that mus be enabled.

That is, each region will have two independent settings:

allow_return_encroaching_object = true/false
allow_return_encroaching_estate_object = true/false

The reason for this split is that some estates already use encroachment
as a feature, where there are some encroaching content that is considered
"public content" such as roads and communal buildings.

As to encroaching objects on the mainland...

We'll eventually enable return of encroaching objects on the mainland
after some private estates have been using it for a while.  I expect we'll
enable it on a few mainland regions and see how things go, then expand.

Some mainland regions use encroachment as a feature and I think we should
move a little slowly there until we have a good understanding of how things
should be configured for the least damage.  After that I suspect we'll
enable encroachment return across all of mainland.

As to cross-region encroachment, where an object is on one region but sticks
into the parcel of another region...

Return of cross-region encroaching objects is not supported yet, but we plan
to implement it before mesh ships (early 2011).  This means "simscape"
megaprims will be at risk for encroachment return via neighboring regions.

Estate owners can always disable encroachment return if they prefer to protect
their simscapes, or they can just make sure their simscapes fall into the
Estate Content category.  Meanwhile on the mainland I think the returnable
encroachment outweighs the simscape megaprim hack so I will push to make the
demise of this hack a non-blocker.

Eventually I'm sure we can come up with a solution and I hope it is a "real"
simscape feature that doesn't rely on really really big megaprims.

- Andrew


On 12/22/2010 10:57 AM, Liny Odell wrote:
> Another key point is "simscapes" that use megaprims that obviously covers all 
> parcels but is only visible along the outside of the region along the void. 
> Also, what about prims that are centered in a neiboring region? Are thous 
> detected as encroaching?
>
> On Wed, Dec 22, 2010 at 10:45 AM, Aleric Inglewood 
> <aleric.inglew...@gmail.com <mailto:aleric.inglew...@gmail.com>> wrote:
>
>     This is an automatically generated e-mail. To reply, visit: 
> http://codereview.secondlife.com/r/56/
>
>
>     I have the feeling that this notion of'encroachesOwned'  is going to 
> cause a lot of trouble in the case of sculptures.
>     At the very least you should use use an aligned bb that is the minimal bb 
> for anything *visible* of a prim. In the case
>     of the sculptures this requires a special function to find the min/max 
> coordinates of all the points used. The same
>     story holds for path cut-off (mega) prims. Ie, if I resize a megaprim 
> (the ONLY way to resize a mega prim is
>     by using one of those prim torture tricks) then it's very possible one 
> ends up with a prim that is just 1/3 of it's"size".
>     It wouldn't be fair when a house that clearly ends on ones own parcel 
> is"detected"  to encroach another parcel, just
>     because the viewer code is too lame to take path cutting and sphere 
> dimples etc into account.
>
>
>     - Aleric
>
>
>     On December 22nd, 2010, 9:37 a.m., Merov Linden wrote:
>
>     Review request for Viewer and Andrew Meadows.
>     By Merov Linden.
>
>     /Updated 2010-12-22 09:37:08/
>
>
>       Description
>
>     The object-vs-parcel overlap test is done by building axis-aligned 
> bounding boxes (AABB) about each prim of the selected objects and then 
> checking for overlap between those boxes and self- and group-owned parcels.
>
>     *Bugs: * STORM-807 <http://jira.secondlife.com/browse/STORM-807>
>
>
>       Diffs
>
>         * indra/llcommon/llversionserver.h (fc82190a3f0c)
>         * indra/llcommon/llversionviewer.h (fc82190a3f0c)
>         * indra/llmath/llbbox.h (fc82190a3f0c)
>         * indra/llmath/llbbox.cpp (fc82190a3f0c)
>         * indra/llmessage/llregionflags.h (fc82190a3f0c)
>         * indra/newview/English.lproj/InfoPlist.strings (fc82190a3f0c)
>         * indra/newview/Info-SecondLife.plist (fc82190a3f0c)
>         * indra/newview/llviewermenu.cpp (fc82190a3f0c)
>         * indra/newview/llviewerobject.h (fc82190a3f0c)
>         * indra/newview/llviewerobject.cpp (fc82190a3f0c)
>         * indra/newview/llviewerparceloverlay.h (fc82190a3f0c)
>         * indra/newview/llviewerparceloverlay.cpp (fc82190a3f0c)
>         * indra/newview/llviewerregion.h (fc82190a3f0c)
>         * indra/newview/llviewerregion.cpp (fc82190a3f0c)
>         * indra/newview/res/viewerRes.rc (fc82190a3f0c)
>         * indra/newview/skins/default/xui/en/menu_viewer.xml (fc82190a3f0c)
>
>     View Diff <http://codereview.secondlife.com/r/56/diff/>
>
>
>     _______________________________________________
>     Policies and (un)subscribe information available here:
>     http://wiki.secondlife.com/wiki/OpenSource-Dev
>     Please read the policies before posting to keep unmoderated posting 
> privileges
>
>
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Reply via email to