[sldev] Re: More on Mute Visibility

[Able Whitman]

>
> I suggest using "smoke", which is the old "loading texture", instead.


That's a good idea; I just chose the white texture rather arbitrarily.

Not really. There's nothing this lets you do that "disable camera
> constraints" doesn't let you do already.


You're right, but how well-known is the "disable camera constraints"
feature, versus the Mute feature?  It's an unavoidable consequence of
visibility muting, but I'm sure some people will complain about it, so I
figured I would at least mention it.

"Mute selected"
> "Mute all objects in selected land"


Is it possible to group select objects which aren't yours and which you
don't have permission to edit? I thought the last time I tried (with "select
only my objects" unchecked) it it didn't work, but I could be wrong.

> Getting the border geometry of a parcel also requires a request and
> > reply message from and two the viewer.
>
> If you have an area selected, you have that. If you haven't swept an
> area out, or are just looking at the land info rather than the
> editor, that will be the whole parcel. That will also significantly
> reduce the complexity of the process.
>
> I think that for a first pass, mute by object ID and having
> "selected" and "selected land" as methods of grabbing a lot of object
> IDs at once is plenty.


Yes, if there is a parcel selected, the viewer has its geometry, but I'm
talking about determining the geometry after the parcel has been muted. I
think you and I are just talking about different approaches to
mute-by-parcel.

You're suggesting that when the user mutes a parcel, the viewer mutes all
the object IDs for objects it knows about that are in that parcel. The code
I've written so far could be adapted to do just this without too much
trouble, I think.

I was thinking that when a user mutes a parcel, that parcel ID is added to
the mute list, and then each time an object is updated, the viewer checks to
see if it falls inside of a muted parcel and if it does, the object is
muted. This is much more complicated than your approach, but it has a couple
of advantages:

1. It's not dependent on object ID, which is easily mutable.
2. It will also mute objects in the parcel that are outside of the viewer's
draw distance.
3. If new objects are placed in the parcel later, they will automatically be
muted.

Aside from being more complicated to implement, the by-parcel-ID approach
raises the question of how to handle objects (liek vehicles) that are only
transiently inside of a muted parcel.

I'm not sure yet how to implement my version of mute-by-parcel, but I will
take a shot at implementing yours, so at least we can get feedback about how
it works in principle.

It would also be interesting to have "listen to mute requests on
> 'channel'", with appropriate checks (eg, fetch the owner of the
> object sending the message and ignore it if it's not owned by you or
> by the owner of the land you're on) so you could have an in-world
> object doing something like this:


That's a really interesting idea, but I'm not really keen about reserving a
"special" chanel for only the viewer to listen on. Plus, which channel do
you choose? It doesn't seem possible to guarantee that that the channel you
pick won't already be used by some existing script somewhere. In practice
this probably isn't an issue, but I'd much rather implement a scriptable
muting mechanism in cooperation with server support for the feature. Then
there can be a special message from the sim that tells the viewer "mute this
object, please."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070621/69fae9ec/attachment-0001.htm