There is currently a lot of debate on how to improve driving, sailing, and flying experiences through mainland where those individuals may have to either deliberately or inadvertently find their way onto a privacy focused parcel during their recreational vehicular activities. The argument is currently focused around the preservation of privacy vs. the desire to not be sent home via teleport for a momentary and potentially unavoidable encroachment onto a private parcel.
A solution that could serve both sides of this argument was proposed by
omoMMomo Resident
as a comment and expanded upon by me.
Due to how this may actually solve both sides of the problem without causing either side to "lose" anything, I felt the proposal deserved it's own canny post to discuss and upvote as needed
. Here is the original pitch within the comments:
Original Proposal (with edits/updates)
The ability to place a static volume (box, cylinder, sphere) tied to a list that separates the residents living there (listed) from the residents passing through (unlisted), as though two dimensions occupy the same space; similar to how private parcels do it except access will not be denied. It might be worth exploring if this is possible without having to modify the clients (viewers).
  • Listed residents will not be disturbed because they cannot see/hear unlisted (and vise-versa) (including media).
  • Unlisted residents can navigate through the property without hassle.
  • hide objects (like cars, planes, boats) of residents that are unlisted from the listed ones.*
  • disallow unlisted residents from interacting (touch, sit) with any prims within the volume.*
  • prevent unlisted residents (on the same parcel) from IMing listed residents while inside the privacy area.*
Like this, everyone can be happy. Those that want privacy get their privacy. Those that want to explore get to explore. Such a system could replace and obsolete existing systems for privacy (parcel rules, ban lines,
llEjectAgent()
, etc.),
modernizing and simplifying the whole concept going forward
.
* - Edits to the original proposal.
Expanded Proposal
As was mentioned, I liked the idea of this proposal and added to it with my own thoughts on how an implementation might work:
To expand on the original proposal, in the spirit of what the 'volume' or "prim" bordering suggests, perhaps we can utilize something similar to the EEP system that allows for different environments at different levels. Instead it would allow for different privacy permissions at different altitudes.
Starting from 4096m, as that is the highest one can rez anything, every 'entry' that is added encompasses the space from the next highest entry down to the present entry, at which the new policy/privacy preference takes precedence (the reverse of the environment system). It could incentivize folks to use their land and space in new ways. Say someone wants to have a portion of their parcel be public, but wants a private space for just their friends. They set everything below 3000m public and then everything from 4096m - 3001m is private, subject to the limitations you suggested. I think that would be a win, and based upon the other logic within the original proposal, it would make the space from 4096-3001m still passable, but they couldn't interact with the individuals or objects inside of that space and vice versa.
I did a small mock up of what that could look like. I also like this idea for the other fact that you could essentially do a 'block and derender' of someone through the land without listing them. They still get to pass through, but unless you've got radar or your mini-map up, you'd be none the wiser.
Assumptions
I want to make note that this change if made would have some assumptions around it:
  • This would apply solely to mainland regions.
  • Parcel Bans would still be effective for those that need them (for public parts of their space, for instance).
  • Modifications may need to be made to parcel access lists to work more like estate access lists where they can accept both groups and people.
  • This implementation would also go in line with changes to how
    llTeleportAgentHome()
    works within mainland, to help solve the original problem stated above.
Thank you for taking the time to read this proposal.