Privacy quick wins - llDetectedCameraPos() and llDetectedEyePos()

... and maybe the angles too.

Comments ensue...

Well, I'm not sure how feasible this is, to be honest. First remember that the camera position only exists on your client -- the SL window isn't a "portal" into a 3d world; rather, it contains a representation of data transmitted from the server, assembled and extrapolated on the client.

The client does send "looking at" and "editing" target data, but this doesn't reflect the camera, it merely tells the server, "I am looking at this avatar" or "I am editing this object".

So for this to work, either a second constantly updated position would have to be sent to the server, representing the camera, or the client would have to respond to polls requested by LSL -- I assume you'd see something like llGetCameraPos(key agent) or llGetCameraTarget(key agent).

I'm not totally clear on what you would use this data for, though.

Indeed, they would be quick wins *IF* the coordinates are already known.

A question, Timeless: you've named them llDetected.... Does this imply that they would be available only within a touch event? (I'd be able to use them within my two proposed mouse_touch_* events too then.)

Both camera pos and eye pos are actually independent of touches so they could return new coordinates continuously on each call, rather than the coordinates at time of touch detection. I'd try to call them something else than llDetected... in that case.

Specifically called "detected" because I was implying that they be used in any of the event types that normally support the other detected functions, eg. sense, touch. See the wiki for the others, I don't remember off-hand.

And yes, there are many uses for this data. But I was aiming at helping solve some of the current SL objectives - privacy. Trust me, I'd also make games with this data.

I disagree and am betting that you are speculating.

Remember the avatar is visually affected by where the camera moves to and where you are looking whilst in mouselook. I think the data does get sent to the server.

I think the purpose is given in those three words of Timeless's, "Privacy quick wins".

I'm not sure what could be done with this either. After all, you can't eject the intruder, as he's not there, only his camera is. Maybe it's to stop doing something dodgy on detecting a camera ... but that doesn't seem too convincing.

This may be tackling a symptom rather than the root cause of any privacy issues, which is that opaque walls belonging to someone else are no barrier to camera penetration.

How would this help privacy?

Sorry, I should have been more forthcoming. I am quite open and have nothing to hide.

Basically, if you don't want a snooper you can detect their camera presence and then have your script either warn them, or actually do a Push to move them out of camera range as a subtle hint.

Note that "opaque walls belonging to someone else [being] no barrier to camera penetration" is a feature that will have to be made a land option before SL can be used for games that require uncertainty of knowledge of one's surroundings.

And that's pretty much every MMOG or FPS-style game.

So, firewall could drop packets that report cam position data before it's sent. If you want privacy, get a private island. We need 2d UI control for privacy, not cam control.

I'm coming from the approach of "give the tools to the users to solve the problems" rather than SL spending a lot more time solving our problems badly (potentially).

You have my full attention, please explain this to me.

For things like health meters, passwords, we need the ability to send them directly to the 2d screen. To add a 2d overlay to our client.

To control the camera, we'd need to "turn off" user cam control all together, and let the server lock and/or reposition the camera.

Erk, that would be a 10-ton sledgehammer to crack a peanut.

There's no need to turn off camera modes nor camera flexibility --- the biggest MMOG around retains all 5 camera modes at all times. Camera locking would be exasperatingly horrid to everyone except those people who use that particular locked-in camera mode by preference.

All that's needed is to allow the plot owner to specify that walls are camera-opaque on this plot. Then he can easily restrict forward camera navigation using phantom walls.

Hell, I thought you wanted it to handle people what fly their cameras up girl's skirts.

now that would sell

Haven't you heard? Bush+Ashcroft are in.

50 years prison sentences coming up real soon now for flying cameras up skirts.

Killing and mutilating thousands is fine though, so you'll have to make your money off MMOG and FPS-type violence.

And on that topic of killing and violence ...

What's the nearest thing to death and destruction in SL currently?

The extent of my involvement with death here was Tiger Crossing's exhibit at Burning Man, although I don't actually recall whether a ball killed me once or not. A very nice piece, that.

This thread has "hijack me" written all over it. Well it's more interesting than the word "bump", I'll take what I can get.


Keep on keeping on!

Yep, that's how Feature Suggestions currently works, Timeless.

It would be much nicer if there were an official list of those features accepted for eventual consideration or not, with tick boxes showing the state of play (even if it's negative), ie. considered, approved, resourced, implemented, tested, or rejected.

Then we could even point new posters who repeat old requests at it, and there would be less wasted posting all 'round.

That wouldn't be too hard to do. There would be no point in a 3rd-party making such a page though --- without direct official dev buy-in and input it would be worthless.

That's the trouble with a forum that's only a token route for customer input.