[sldev] New Feature: Mute Visibility

[Able Whitman]

I've given this feature some thought, and I think that without additional
support for muting objects on the server side, this feature could wind up
making things worse instead of better.

The goal of "visibility muting" is to allow users to select objects in-world
that they don't wish to see, or at least that they wish to see in a less
instrusive or annoying manner. This muting will overwhelmingly be applied to
ad prims. The goal of ad prims (or rather, the goal of their owners) is for
the ad prims to be seen, since this is what makes them useful and valuable
(from the perspective of the advertiser). If you mute an ad, the owner will
obviously want to modify their ad prims so that they circumvent the muting
mechanism. Without additional support from the server, this is an arms race
that the client cannot win.

There are several properties that would be useful as filters for which
objects to mute:
* object id or object name
* owner id or owner name
* creator id or creator name
* texture id

Creator id or name is out, because (as far as I have been able to find) the
only way the client can get the creator id of an object is to make that
object the currently selected object. Getting the creator name then requires
the name cache to make an asynchronous request from the server. This makes
creator information too cumbersome to use as a mute filter.

Object name and object id are the most promising properties to use.
Unfortunately, both of these properties are easily mutable. The object name
can easily be scripted to change randomly with llSetObjectName(). The object
id will change every time the object is rezzed. If the client implements
object-id-based filtering, I think in a very short order ad prims will be
supplanted by ad prim rezzers, which could periodically re-rez the ad prims,
effectively randomizing their ids. Muting the ad rezzer wouldn't help,
because the client can't prevent it from rezzing objects, and (again, as far
as I know) the client has no way of knowing that a given object was rezzed
by another given object.

Filtering muted objects based on owner name or id could work, but this
paints with a pretty wide brush, and I think it's probably too much of an
all-or-nothing approach to be really useful. And with the ready availability
of SL bots, it wouldn't be long before advertisers were regularly creating
new bots to be able to vary the owner of their ad prims. (Having a bot place
ad prims isn't appreciably different in complexity than having a bot sit in
a camping chair, in any event.)

Perhaps filtering by texture id is the most promising approach, but with so
many ad prims driven by a client-server advertising network, it wouldn't be
much additional work on the part of the advertiser to regularly upload
multiple copies of the same texture, each with a new texture id.

Further complicating things is the fact that being seen isn't the only way
an ad prim can convey its content. It can play audio, speak in public chat,
give notecards or textures, or raise a script dialog on someone's client.
Texture filtering doesn't address any of those techniques.

Certainly, implementing an object muting feature would be useful, at least
for static prims. It would initially be useful for ad prims as well, but the
availability of client-side visibility muting would motivate ad prim owners
to modify their techniques in such a way that the muting feature would be
rendered ineffective. Worse still, the circumvention techniques that are
available to ad prim owners are those which the client cannot practically
overcome, without additional server support. (And I am not even certain what
kind of server-side mechanisms would be helpful in dealing with randomly
changing object and owner ids.)

--Able

On 6/1/07, Alvargi <alvargi at hotmail.com> wrote:
>
>  Rob Linden has talked about clients on low-end and mobile client devices,
> where reducing bandwidth or tuning what information is sent to the client
> based on device or network capabilities is a key consideration. A 100%
> client-side mute feature would also concern those aligned with the more
> commercial aspects of SL. (like the ability to mute commercials on
> television). I can also see where muting content based on its rating or
> other privacy flags could be a valuable tool in resolving some of those
> issues.  You can easily make an "invisible" prim today and place it in the
> middle of the road (so to speak).
>
>
>
> My point is that this particular feature has much broader implications and
> really should involve the sim/server side.
>
>
>
> Best,
>
> Alvargi
>
>
>
>
>  ------------------------------
>
> *From:* sldev-bounces at lists.secondlife.com [mailto:
> sldev-bounces at lists.secondlife.com] *On Behalf Of *Able Whitman
> *Sent:* Friday, June 01, 2007 7:25 AM
> *To:* Nicholaz Beresford
> *Cc:* sldev at lists.secondlife.com
> *Subject:* Re: [sldev] New Feature: Mute Visibility
>
>
>
> The only problem I see with that is that you wouldn't be able to see them
> coming. My personal feeling is that having random objects appear in front of
> me after I run into them is almost as bad as seeing spinning ad prims in the
> first place. Plus, not all such objects are small enough to fit on a 16sqm
> parcel; some ad prims are actually quite large.
>
> --Able
>
> On 6/1/07, *Nicholaz Beresford* <nicholaz at blueflash.cc> wrote:
>
>
> Another idea could be to just light them up fully rendered for a few
> seconds on a bump.
>
> Regarding the performance, we'll have to see if that can be done right
> with object
> creation as a flag and then subsequently just check that flag in the
> rendering process).
>
>
> Nick
>
>
>
>  Second Life from the inside out:
> http://nicholaz-beresford.blogspot.com/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070601/ded7c5f8/attachment.htm