soundproof wall

Does anyone know if it's possible to make a soundproof wall?

I have many of Apotheus Silverman's bulletin boards together in the same area, but need to surround them with some sort of booth so that speaking to one doesn't activate them all.

There is nothing you can do to attentuate the effective radius of chat speech, apart from testing the range from the speaker within the script of the device itself, or physically altering the distance between speaker and listener. Other than that, if you're working with something somebody else made that you don't have modify rights on for the scripts, you're pretty much out of luck.

Thanks Kalel.

I do have modify rights on the script - any ideas?

Rez one, configure. Take it. Rez another, configure. Take. Repeat as necesary.

look for instance of the llListen command and configure the channels so they don't clash:

integer llListen(integer channel, string name, key id, string msg)

then preface each command with /channel no, eg /3 for channel 3, etc

Modify each so that when they Rez they set up their own channel.

integer channel;
integer listening = 0;


SetChannel()
{
       // Clear Current Channel (if any)
       if(listening != 0)llListenRemove(listening);
       listening = 0;
       
       channel = (integer)llFrand(100);
       listening = llListen(channel,"","","");

       llSay(0,"Listening on " + (string)channel);
}

if its menu driven then add a SetChannel option

You could also alter the listens to listen for a prefix. 1.list, 2.list etc... (or whatever the commands are, and the place I've used numbers could easily be, say, the object's name).

.. you could use llSensor() to determine the distance of the speaker, and only process the command if the speaker was within, say, 8 meters, or however far apart these boards need to be. You could feed llSensor() the key of the agent you were trying to detect, so it would be very low lag that way as well.

This method covers all the bases:
* You wouldn't have to have a unique script for each bulletin board.
* You wouldn't have to be continually picking them up and placing them again each time you wanted to change a message.
* You wouldn't have to mess around with secret chat channels, especially if you filter the listen for just the group ownership, or just the owner.
* Filtering listens by distance and owner/group cuts the lag you'd normally get with channel 0 chat listens to an insignificant level.

If you're going to resort to a sensor you may want to use llVolumeDetect instead.

Oh, I hadn't thought of that - you're right, much lower lag than llSensor().

Just generally less resource intensive. But does require an additional prim etc...

Another Idea.

You could also check the distance of the player from the object using a scan if the object is too far away, Ignore there speach, if they are within range then don't ignore it.

Another thought: have a central mediator that keeps track of the receiving objects and has a main listen. Centralize the distribution logic into this object's script(s) and multiplex it to an appropriate channel for one of the receiving objects. The position of the objects can be kept track of by announcements on another channel. At least, I assume several objects announcing their own positions every once in a while is going to be less work than a sensor. That would probably be a worthwhile thing to test out though.

This way, if commands are on channel zero, at least only ONE object needs listen on that channel and process each chat.

Wouldn't the central mediator still need a sensor, Too keep track of where the person speaking was and what object they are speaking to ?

Yes. It doesn't change that, except to reduce the number of sensors and channel zero listeners (or same-channel listeners if you will) to one.

A number of my web browsers are in the same room in a library on info island. I have the first line of the configuration notecard
specify the chat channel for the specific browser. That way two AV's can interact with the ones in front of them (do searches, pick a web site), without stepping on each other.

I suppose another thing you could do is "click on one of them, to associate yourself with that object" (and then the others ignore you). That gets into wierd UI and network problems though. Seems easiest to just clue in the user as to which channel will work with the object in front of them.