Parcel Basements

Parcel basements are an idea that evolved in several long discussion threads on the SL Forums, as a mechanism for implementing private areas in SL that is efficient for LL to implement and effective at providing privacy.

Proposal

A landowner can request the creation of a "basement" zone for a parcel. The "basement" zone would be in the boundaries of the parcel, but isolated from anything else in the sim. The proposed implementation is a region between -1024 to -768 meters altitude, limited to the borders of the parcel, sharing the parcel's prim quota. Objects in this zone would not interact with anything outside the zone: the zone border would be a solid wall (like the edge of the void), agents in the zone would not receive any object data or chat from outside the parcel boundary, and so on.

For physical objects, each zone would be a separate collision group.
Non-physical objects would be blocked at the wall. Physical objects would bounce off it.
Object data in the zone would only be transmitted to clients inside that zone.
Chat in the zone would only be transmitted to listeners inside the parcel.
For the proposed implementation:
- LSL script calls like llGetPos() would return <x,y,z+1024>.
- llgetRegionCorner() would return <region_x,region_y,-1024>.

Access

Access to the zone could be granted in a number of ways.

The owner and members of the parcel group might see a button when they are in the parcel. Clicking that button would flick them into the zone when they entered the parcel.
The owner might grant access to access the zone using a scripted object.
The owner might transfer agents into the zone using a script call.
The owner might flag a prim as a "portal", and an agent passing through that prim would be transferred to the zone.

The preferred implementation would depend on the goals.

Scripted access would be the most versatile: access could be made through a volume-detect prim for a portal, a listener for a magic word, a click for a "teleport" style access.
Access based on membership in a group would be easiest to understand, but would prevent the owner from creating the illusion that the zone was a continuous part of the build.

Other considerations

Linden Labs could use a tier surcharge to pay for a basement. This would not provide additional prims, it would simply make the parcel (say) 10% more expensive.

The surcharge should probably not be greater than the group tier bonus.

Should adjacent parcels with the same owner be part of the same zone?
- Principle of Least Astonishment says "yes".
- But it might be more useful to allow a landowner to create multiple basements, or smaller basements.

Particularly if there's a surcharge.

Should non-contiguous parcels be one or many zones?

This is probably an implementation issue.

History

Original design

The original idea was to simply allow a landowner to request a private region for a parcel. The private region would be located beneath the sim, the same shape as the original parcel, and vertically separated by at least 512 meters (maximum draw distance) from any other parcel's private region. The number of private regions in a sim would be determined by the limitations in the physics engine (for example, physical resolution of coordinates). Since this would be a limited resource, it would involve paying some fee for it, perhaps as a tier surcharge of 10% or so, or even via some kind of per-sim bidding system. The parcel basement would not come with any extra prim quota, nor would it be any larger than the existing land... it would simply be a "skybox" underground. This implementation would not require a huge change to the simulator code.

Access to the basement would be controlled by the landowner, through a script. My original idea was to use llTeleportAgent (this was back when Linden Labs was actively developing that), but a specific call to transition to the region, or to allow transition, or a call to turn a prim into a portal to the region, would all be possible.

Some issues that came up:

What happens if you try and pass through the walls of the basement?

Hitting the wall of the basement should be like hitting the edge of the void. Hitting the roof might simply "bounce" you to <x,y,llGround(ZERO_VECTOR)>.

What should the ground of the basement look like?

Possibly a plain white room (like the Matrix "construct"), or a duplicate of the parcel ground above.

What about scripts that might crash or misbehave if Z was negative?

Apply a transform: in a basement at offset meters below zero, script calls like llGetPos() would return <x,y,z+offset> and llRegionCorner() would return <x,y,z-offset>.

This is an argument for using the parcel ground, since you want llGround() to make sense.

What about non-contiguous parcels?

Parcel basements may be non-contiguous, or it may require that the parcel be contiguous.

What about adjacent parcels with the same owner?

There are good arguments for both combining them and leaving them separate. It would probably come down to the Linden's implementation.

Later discussion

Later the idea of having some kind of parcel-based privacy came up, and this would allow the parcel basements to be all at the same level, with the sim simply not passing information outside your parcel to you when you were in a basement. The sim is already tracking parcels and objects for entry restrictions, so it could use the same mechanism here, or it could put separate basements in separate collision groups.

This later design is what is proposed here.