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

Design Goal

A landowner can request the creation of a "basement" zone for a parcel. The "basement" zone would be no larger in area than the parcel, and isolated from anything else in the sim. It would not interact with the rest of the sim in any way, it would not be visible from outside the zone, it would not create a barrier in the contiguous sim, it would not be enterable in any way except with the permission of the landowner.

Implementation

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 come up when they are in the parcel. Clicking that button would flick them into the zone.
• 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 most versatile implementation would allow scripted access and, if the landowner checked the appropriate box, simple group-membership-based access as well.

Scripted Access

Access to the zone should be through a script call "llZoneTransfer(key agent,vector position,integer zone)". If the zone value is TRUE, the agent would be transported to that location in the zone. If the zone value is FALSE, the agent would be transported to that location outside the zone. This call would fail if:

• zone == TRUE, and the script owner is not the parcel owner.
• zone == FALSE, and the script owner is not the parcel owner or the agent.

This would allow for zones that are apparently contiguous with the rest of the build by creating a portal using a volume-detect prim, zones that are entered using a magic word, zones that are "caves" in an open area, zones accessed by clicking on a switch, and so on.

A landowner could place a house entirely in the privacy zone, with a simple single-prim model on the surface using llVolumeDetect... walking through the door would transfer you to the "inside" of the house.

A landowner could place a single prim volume-detect door against a wall inside their house. Walking through it would transfer you to a "private room".

Allowing the agent to transfer himself *out* of the zone seems to be a useful safety feature that does not create security issues otherwise.

Group-based 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 Lab 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. This is not desirable from our point of view, but might serve as motivation for Linden Lab. :)

• For the proposed implementation the surcharge should probably not be greater than the group tier bonus.
• For the alternate implementation, the basement would be its own parcel with its own prim quota and tier.

• 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.

• For the proposed implementation, probably multiple zones, or contiguous parcels could be a requirement.
• For the alternate implementation, the boundaries of the zone do not have to match the boundaries of the parcel.

• What about the ground?

• For the proposed implementation, the ground in the zone should be the same as the ground outside the zone.
• For the alternate implementation, the ground could be separately edited.

Alternate Implementations

The parcel could also potentially be run on a "lightweight" sim instance on the same server as the sim. This would probably have significantly greater overhead (and would almost certainly require tier, since it would have its own prim quota), but may be simpler to implement.

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 Lab 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.