Stop the Peeping Toms / Camera Limitation

And that's "griefing"? I wish that's all that griefers did.

I think you need to find slightly stronger reasons for rejecting designs for privacy.

Morg.

Alright.
Privacy enabled cage gun. With a privacy enabled cage.
And you thought llPush() was bad enough. That replicates it.

that's the best idea i've ever heard!! i want one of those guns now

You might as well go out and do this right now then, since similar griefing methods and camouflage/hiding/invisibility techniques already exist.

None of the suggested privacy methods offers anything particularly new for griefers, and they might well reduce griefing since the griefers wouldn't get the satisfaction of watching their victims' reactions.

Although it's not related to privacy per se, perhaps we should propose that an additional control be added to land, to allow the owner to disallow people not in the privacy group from enabling privacy for themselves. While some might object to this restriction, the major goal was always to provide privacy on one's own land, so it's probably a reasonable compromise.

Morg.

Then we might as well just toggle everything on the parcel based on the flag, ah la "every other privacy suggestion ever."

and while we're at it we might as well tie it in with the normal parcel access controls and replace ban lines with private prims and solve the "ban lines are killing flying" problem as well.

edit: this is a joke

LOL, sorry Haravikk, it took me a while to realize, but I've finally cottoned on ...

Draco18s and leliel aren't posting here to constructively criticize your proposal or mine in order that they can be improved, but merely to sabotage them. Ie. forum griefers.

In other words, the designs look good for now, one full-coverage but requiring heavy dev resources, the other providing only visual privacy but requiring only minimal dev time. Perhaps other people will offer some more useful criticisms to improve them further.

Morg.

it's nice that you think of me as such but anyway, i'm not helping to improve your proposal because i think its flawed to the core. i can just imagine what the sim would be thinking

"can this avatar see this prim, what about this prim. how about this avatar, can it see that prim over there? oh shit! 10 avatars just tp'd in, can they see this prim, and what about that prim over there, and there, and there..."

i am also against it because i belive it will turn the main land in to a giant empty field of grass with everyone sectioned off in their own little worlds destroying what little sens of community we have

No, that merely indicates your complete misunderstanding of the proposal.

Morg.

It's all too easy to swing the camera into other peoples' property accidentally in closely confined areas. I never intentionally peoples' privacy and my own property is open to the public anyway, but I think it's best to assume that there is no such thing as privacy in SL!!! If you really need privacy then a skypad or skybox is the best bet as there's less chance of being found.

how am i misunderstanding it? the server _will_ have to figure out whitch avatar can see which prims and i think it will eat up a lot of cpu cycles doing so.

That's a good point, Conifer.

What's you're describing is the use of isolation rather than privacy, and that is a perfectly useful suggestion in many situations. Indeed, that's the method used by huge numbers of people who own tiny PG plots when they work on their clothing, in order to respect the "PG" rule of their sim.

However, note that "isolation is not privacy".

Isolation is merely a method of avoiding the majority of unintentional invasions of privacy (as you described), and therefore does not tackle in any way the issue of intentional invasions of privacy.

And it's the latter that these proposals seek to address.

But yes, isolation is a very useful separate facility, and as we have huge vertical plot spaces available to us, this can compensate to some degree for the tight packing of living space on the ground. It may not be very decorative up there, but it's invaluable.

Morg.

I find it funny that you think as such, but I am pro-something-that-is-your-proposal, you just have everything wrong.

First off:
True privacy means that the sim has to decide what each avatar can see
Implies:
If it is per-object that means up to 15,000 checks per avatar.

Second:
Privacy of this kind needs to be by land, that is, each parcel has it's own on/off setting (however, there will also be a sim level check as well).
This is a maximum of 4096 checks per avatar.

Third:
You can't implement "something quick and easy" only to take it away again later to implement "something better." Look at joints.

I'm trying to be constructive by showing flaws in the design, providing an example that if your idea is implemented as written people will be up in arms about on the forum.

The kind of privacy I would like to see is the Parcel Basement idea (Argent Stonecutter's I believe). It avoids every single issue ever brought up against simpler privacy ideas:
one avatar in, another (banned) avatar out seeing different things, parcel basements are so far apart this can't happen
instanced: any laggy opperations only effect the single parcel
griefing: impossible, there isn't an "outside" that is ocupyable and visible.

Determining what to send each client from the sim is not the difficult part. You would just have a linked list for each privacy group/av on the sim and another linked list for everyone else on the sim. When your stuff is streamed it will be from the appropriate linked list. (My bet is that LL have implemented this with an array, hence the 15,000 limit).

The real programming problem is how to present all this to the physics engine. So you could be interacting with prims that are not viewable and that could lead to grieving or at the very least detract from the immersive experience. I just don't see that as acceptable to the Lindens or the residents. At this time everything on the sim can be seen by every client, though for some items you do need to turn on the infrared invisibility viewer.

But the real problem is the social one and I don't believe we have to a consensus yet.

First off, a linked list is not small memory wise, even compaired to an array. A linked list at the very least has the data of a same size array, and because it's a linked list, it also has data indicating the next list element (a one to two byte memory address).
Second, the 15k prim limit is based on 16535 prims minus the overhead for temp-on-rez. 117 prims per 512 sq.m. land.
Third, an array for every avatar in the sim of 15,000 UUIDs (a UUID is about 55 bytes) is a lot. That's 29296 MB of information for 40 avatars (max on a mainland sim). Even at one bit per object, that's 585 MB of information, or more RAM than most sims (I think only a class 5 has more RAM than that). Sounds like a good idea to me.

a linked list would work fine to start with as you could have one master list of all privacy prims on the sim and every time an avatar enters the sim it would just have to walk down the list and for every prim that the avatar can see it would and it to the avatar's personnel list. adding a new privacy prim would be easy as you just have to append it to the end of the master list and run one check per avatar. the real problem would be when someone changes the permissions on some prims (i.e. you invite someone over for some "private time" as now you have to walk down the master list and find all 200 or so prims for the persons bedroom to update their permissions and then propagate the changes out to all the avatar's personnel lists. so in this case i think a b-tree would be better for the master list keyed off of the owners name. but that still would leave the grid open to a DOS attack where a griefer could make 40 alt's and run through the the grid rezzing one privacy prim per alt in each sim with a script that randomly changes permissions every 30 seconds bogging the sim down in a never ending race to update all the privacy lists.

You would only need one privacy list for each privacy area and that would be applied to serve any client whose av is part of that privacy area. Each av would need a field to indicate which list they are to be served from. Any prim would only be on one list, so the total space required would not materially change. Alternatively, each list could be a dynamically sized array.

If pointers are 8 bytes each, we are talking here about an extra 8 * 15K = 120 KBytes in a 256 MB space. (I believe 4 sims occupy a 1 GByte mem space in a linux system).

That still does not address the physics or social aspects.

In view of the open letter and all the other features being introduced I do not see LL spending any time on this proposal anytime soon.

Fun dreaming about this. The best time to evaluate things is when the shops are closed. We should keep talking about what we really want so that all the considerations are out in the open by the time LL takes a look at this. One year, two years, three maybe?????

which would effectively limit everyones draw distance to the parcel there in as the sim doesn't bother figuring out if an avatar can enter a parcel untill it gets close to the parcel, as an added bonus this would greatly reduce the load on the sims. i would almost say this is a good thing as it would stop people with a draw distance of 512m from loading (lagging) 9 full sims.

Excellent, the discussion has become technical again. Let's keep it so.

These are the maximum numbers of objects that are ALREADY being handled and downloaded, and the privacy checking is aimed at *decreasing* the number that makes it to a client's download list. Consequently, even if only 1 single object is marked as private when someone else is around, it's a win.

You have to remember that checking these 3 fields is a trivial operation, basically just integer comparison. It simply doesn't get any faster than this. Even the group field checking is done by a single integer comparison of the pointers to the objects holding the internalized group names. The "overhead" of this kind of operation is not even on the radar.

What's more, there is no object scanning/finding/access overhead either, because the checking is done at the point of download. You've already obtained access to the object in order to put it into the client's download queue, all nice and ready to check.

The privacy bits scheme was designed that way on purpose, to make overheads virtually non-existent.

Excellent, the more privacy-oriented ideas the better, one might actually get implemented!

Indeed Argent's "Parcel basements" idea addresses many issues all in one go: for example as he mentioned, the isolation of basements actually works by not downloading objects to other clients, so in addition to privacy this could greatly reduce server loading as well as client lag. That's very valuable.

It may have some privacy problems if basements are at depth but still in the same world, given that an adjacent plot holder can have a basement at the same depth adjacent to yours. If it turns out that cameras can still navigate to adjacent basements at such depth then a very simple basement ID check on the server can prevent objects from basements that aren't yours from being downloaded to you. In effect, an object download restriction similar to mine.

The best thing I like about "Parcel basements" is that this is not a development-heavy proposal, since the basement could be exactly the same size and shape as your land above, but simply at depth and of limited vertical extent, hence there would be no new shaping issues or other structural work.

What's more, it would need no new UI changes in its first incarnation -- a simple LSL command could get you to your basement, and then you could TP other people in, by invite only. Of course, additional enhancements would be nice, but the basic scheme is simple structurally, and has low dev costs.

And of course, simplicity is of overriding importance. A great scheme that doesn't get implemented because of dev resource limits is utterly worthless.

Morg.

It's a game, who cares if your av is seen naked.
Solution: Keep your clothes on.

I don't know how true it is anymore, but LL was hesitant to add data to prims because they were running out of unused bits in the current prim data type.
Even if not, it's one more bit (or byte, or more) that the sim needs to keep stored in RAM.



I think Argent's idea addressed that. I don't remember what it was, but IMO it'd check on new parcel creation (splitting or joining a parcel) and on purchase to move all of one owner's land to the same z-level, and every owner has a unique depth (in that sim), each owner being 1000 m away from each other.
Objects wouldn't be left behind if a parcel moved vertically either, as you could simply move all objects the same relative distance.

Interestingly, "every owner has a unique depth (in that sim)" is functionally equivalent to each basement having a unique ID while all being at the same depth, plus a trivial ID check to prevent basement objects from being downloaded to the wrong client.

That's what I love about Argent's idea ... extreme simplicity of development and of use, yet providing very powerful privacy.

WTG Argent. "Parcel Basements" needs to be an official proposal!

Morg.

Addendum: Argent's post was here, btw.

And yes, I think that he was implying that the isolation was guaranteed regardless of adjacency of plot basements, but that remains to be seen. In any event, it's trivial to guarantee with basement IDs, as above. I vote for basements!

He's still around, even if he isn't posting.

Last Activity: 05-29-2007 05:51 AM
From:
/invalid_link.html

I hope LL Devs read these forums.

The basement does sound like a good idea.

I thought the instanced zone containing whatever you save into it and gets saved in the database is good idea too, since they poof after being vacated for a certain amount of time. Would free up a lot of space where all the data is stored.

Glad to see this thread is still drawing interest.

What looks simple may not be so. Watching a duck glide effortlessly across a pond ignores the webbed feet madly paddling beneath.

I still say that the major problems are the physics engine and the social aspects.

Argent's proposal of parcels at negative heights sounds simple, but I bet that the physics engine cannot handle negative heights. That would spoil the immersive experience.

Someone else, not sure who, has already proposed privacy at certain heights, say 650 to 700 (my guess), where you'd be able to specify a parcel to be private. Perhaps you should be able to specify your own heights within those limits. All that would mean is that anything in that parcel, both prims and av's, would only be served to clients whose av's are inside that parcel. Then it would be up to the parcel owner to limit general access to that parcel, maybe with a security orb, maybe with walls, or maybe both, but access should be managed by the parcel owner using current resources.

Technically, LL would only need to add one parcel flag to indicate privacy and manage the prim list to serve sim occupiers. Prims in the privacy volume would be on a separate list or array and only served to those clients with av's occupying that private volume.

However, there would not need to be any change to the physics engine as long as parcel owners properly protect access to their privacy volume.

Socially, this would have little effect on the ground level. Landscaping and dwellings would exist as before, and perhaps ban lines could be eliminated.

A landowner could carve out an inner parcel 10 M high and build a house around it with access controls. As he and his visitors walk through the front door they become invisible. They themselves will now see the interior and be able to live normally inside that house, knowing that nothing they do is visible to anyone outside the parcel. Any camera panned inside the house by an outsider would see nothing.

I would consider this to be a minimalistic approach requiring the least amount of program changing of sim software.