Chat space pollution

Hi all,

I'd like to make some suggestions to my fellow LSL developers about respecting channel zero as a public chat channel, and suggest that it ought not be used for the types of communications described below. There are two areas where this could be greatly improved:

1) Object to owner communication

2) Owner to object communication

Go hang out near a busy telehub and you can barely have a conversation due to everyone's attachments letting everyone know that they are there and that they arrived in one piece. There is no need for this. It is trivial to instead use private instant messages to the owner of the object.

Just a couple simple suggestions:

1) Use instant messages to communicate status/initialization messages to the object's owner. Nobody cares except the owner that their dance braclet or cellphone or wings rezzed & initialized ok. Also, if you develop casino games or other types of single-player games, then talk to your player in instant messages! You receive their key when you receive their money! Use it! I don't care if someone won or lost. I mean, sure, shout it out when someone wins a huge jackpot, but there's no reason for 3 chat messages every time someone pulls the handle on a slot machine or plunks down L$10 on a hand of blackjack. And yes, of course there are situations where a script should say something on the public chat channel. A money ball? Sure. Anything that is adressing more than one person in the general vicinity of the object, yes.

2) Make your device accept commands on any chat channel except 0. Again, the chat space gets polluted with people trying to set an animation or change their shoes' color or whatever else. This is admittedly a less widespread/annoying thing, but could be handled much better. Ok its pretty annoying to me.

The long and short of it is that channel 0 should be reserved for PEOPLE talking to PEOPLE with few exceptions. I'm just asking you to think twice before using llSay(0, ) or even llWhisper(0, ) -- consider who needs to hear what you are about to say, and if it is only one person, then send them an IM.

Arright, thats all I have to say about that. Any better ideas or refinements of these ideas are welcome. I'm also happy to help if you need it, just IM me in-world.

Thanks for listening.

Bestest,
Jimmy

I agree totally.

One other thing too, make IM's in another color.
It can be hard to know if an object you have is giving you IM or regular channel message.

/ Max

I totally totally agree with this! Also ~ give us the option for not having IM chat show up in the regular chat space. I have had to quit many clubs only because of the flood of chat that pops up once an hour and really would have prefered remaining a member of most of them. Guess this is more of a feature request ..

I develop a lot of attachment and casino products. And, I agree with you 100%. I have a couple comments.

IM communication is slightly hampered in the fact that there is a 2 second delay of the script for every message sent. For those of you who find that too long in your main script, send a link message to another script (in the same object)and have that script send the actual message.

Give the option to send commands via 0 or another channel. Just put in your startup help that commands may be prefaced with '/3' where 3 is your command channel.

Never llSay() when you can llWhisper().

As far as attachments being chatty at telehubs goes, that is bit harder. You usually need to at least state a help prompt on_rez. And, well, attachments rez when teleporting in. I guess you could send these IM. I just never thought of telehubs as conversation spots.

Al,

I'll take your argument the next step further:

Never llWhisper() when you can llInstantMessage()

I suspect that instant messaging is less used due to the 2 second penalty. If one is developing several apps for distribution, it would be wise to create shared components that can be dropped into any object or project. One of those libraries should be an instant message app that just listens for a link message and sends out instant messages. Using multi-threading in this manner will save your main script from incurring the 2 second wait. If you are sending several instant messages, the IM object will be delayed 2 seconds between messages, but your main script will not be delayed because it is just sending link messages, which will queue nicely.

Also, I'll say that it should not be optional to use a non-zero channel for user input to an object, it should be designed that way. If it is optional, the user will choose the path of least resistance, and save a few keystrokes by using public chat. Also no reason to have 2 listens in your object unneccesarily. If your object is only listening on channel 3, then the users must use channel 3, then nobody else has to listen to them configuring their hair or whatever. Simple. Just put in your startup help that commands must be prefaced with '/3'

inre: telehubs as conversation spots.. true, but this very much applies to anywhere that people are teleporting in frequently (i.e. nightclub or any event right around its starting time). The signal to noise ratio gets pretty lousy in situations like that.

Another benefit of llInstantMessage() is that delivery to the intended recipient is much more likely. Say someone walks away from your casino machine in the middle of a game and you time them out after 3 or 4 minutes; if you llSay() something to them, they probably won't hear it because they walked away or teleported somewhere else! If you IM them, they will get the message, even if they already went offline!

I would be happy to share code with anyone who wants to make their product more in line with these principles.

Best,
JL

YEah, I'm curently working on a new version of something I sell, and it will be using only IM communication. I feel kinda bad that my previous version says everything outloud.

I do try to keep chatter to a minimum. I hate nothing more than chatty items (ever danced and suddenly had your screen scrolled up by a chatty dancebracelet announcing its content?).

However each item I do will announce its presence with ONE (and only one) line when rezzed/attached/tepeorted. Why? Well, to be honest, advertisement ... Simple and easy! Most other communication is done through private channels and or IM, when practicable.

Till Stirling

Till,

I know. *sigh*

Well go easy on the all caps if that is what you are doing. LOL.

Best,
JL

I have found, in practice at least, that my scripts run just fine using a combination of llSetText and arbitrary channels (Channel 1 being quite handy). I primarily use channel 0 for announcements others need to be keen to (eg. waiting queues). Some thoughts:

1) llSetText is a pretty flexible interface if treated properly. As is the particle system for Second Life. It does only take a second or two of your time to come up with a creative interface utilizing these features, whereas it takes a second or two of everyone else's time if you don't.

2) Channel 0 for debug features is commonly okay. llWhisper is the polite way to do this. Just remember to shut off/delete your debug scripts once you're done with them.

3) llDialog with null fields also makes for a good, quick fix as far as owner messages and errors are concerned. Besides, they're good for making sure the user sees the message a la "Ignore" or "Okay."

4) Listeners set to owner on channel 1 are easy enough to use for item commands. However, try not to abuse them. When you can, link messages are also more sim-friendly.

All in all, I've yet to require the email feature for inter-script commands (partially why I don't even know the syntax of the command), and there's really no excuse for people to spam local chat other than their own inability to invest time or effort into being polite.

My advice: Make liberal use of the Ignore feature as needed. And bug the Lindens for an "Ignore Other's Objects on Channel 0" feature, if one doesn't already exist.

And, by means of edit: I reserve the right to ignore you and/or your scripts if you spam for sake of advertisement. You're welcome to do so, but please - don't ruin others' experiences for your sake.

Besides.

Why not just have your script rez a big ol' advertisement particle instead?

right on veva la restonce !

Jeffrey,

I love the particle idea. That had occurred to me too. Just belch out one particle on_rez with your ad on it. Could be a much nicer ad than a single line of text gets you too. You hear that Till?

One other benefit of using nonzero channels for device commands is that listening on channel 0 causes lag; listening on channel 1 causes lag too, but significantly less, if what I am to believe is true.

A "mute others' attachments" setting would be great, but I can see that if everyone had one of those filters it could really increase server load and lag.

I'll suggest that a per-object setting such as "Only owner hears script chat" that only the owner sets would do the deal. That way you could silence your dance braclet to the outside world, but still hear it yourself. This would also not require any code changes in any scripts, and would be fully backward-compatible (of course it would only apply to channel 0). It would save a lot of people from having to endure these "initvertisements", and of course it should be enabled by default.

Best,
JL

I feel like bringing this topic back to the top.. and I'll add:
llOwnerSay()

.....which is useless, because I bet 99.95% of all casino gamers are not also the owners

but for all those attachments that spam .... it's useful.

and to advertising, just click that little box that lists you in "Places" for $30/week. if you can't afford that, then your products aren't good enough to be spamming, so get them out of my face. (kidding.. but really, that's annoying, cut it out)

Spam advertisements often serve to warn potential customers of products to AVOID.

I would be ashamed to wear an attachment that made an announcement every time someone tp'd me into an event, and I hope your customers are ashamed, as well.

The core discussion may be an old one but I agree, I use llOwnerSay in all my attatchment scripts now and so far no one has complained.

On the note of what to avoid, lately I have been thinking of being lazy and getting a dance ball instead of spending the time to make one, but all the ones I see spam channel 0 like its candy land and its calling for the care bears to make sweet love to it!

I just wish more people follow the nice nice of keeping announcements for WHO they are ment to be sent to.

IM through link messages are wonderful if you have no other option and dont want the queue (casinos) so lets start trying to clean stuff up and make it a bit easier to be in a club and not see a billion "ao off" "title blue click my butt!" etc...

hmm, I'm wondering how to handle this for group enabled objects.

llOwnerSay fails quietly on groups owned objects so does llInstantMessage(beside who wants an IM from an object that you aren't interacting with atm?)

llwhisper is nice, but for some things it just isn't going to go far enough.

guess I'm stuck with llSay

EDIT: ok so I didn't realize how object IM's worked... which is why I never used them... thought they'd show up as an ACTUAL IM... not so... rather they seem to work just like llOwnerSay only targeted... color me ignorant. in which case it makes perfect sense to use for group enabled objects... and only the person interacting with it need hear it.... I suppose I could use a temp sensor and nail all group members in the local area too.....
/edit

....

to play devils advocate, the users frequently don't want to HAVE to talk to their objects on a separate channel... and remember not only what commands to use, but what channel they're on.... (ASIDE: would having a filtered listen on 0, that instructs the user and opens a separate temp channeled listen be any less laggy than an unfiltered one? it'd certainly cut down on command spam in chat)

....

now I'm like you, and open listens Especially on channel 0 really suck especially for things like configuration... when it's going to used infrequently it's plain silly.

for non-attached items (and I suppose you could use it for attachments too) I use a filtered touch=on system on a timer... this opens a listen and then gives it's instructions.

I mention it because it would reduce the need for some objects to spam help messages on rez.

Take that one step further and use llDialog() menu system on touch.
And there is no reason you can't touch your attachment either.

Words to live by.

LOL. /me touches my attachment

Its good to see this old thread being resurrected, it is still very relevant, and more so now -- llOwnerSay wasn't around when I started this thread, that is a great option for many situations. One deficiency of it is the particle swirl when the attachment talks -- it can be confusing to people when you are standing there looking like you are talking but they don't hear anything, not a big deal, but I would use it in more situations if it didn't have the particle swirl.

Also, I have converted pretty much all of my casino games to llDialog menu-driven configuration; its so much easier than command line driven config -- no need for help or remembering commands, and no open listens unless you are actively configuring the thing.

j

============================
NEW Klub Kaili - World class casino gaming
Moneyball AND Free Slots 24/7
Unique games you won't find anywhere else
Refugio(68, 190)

Only an object's owner sees the chat swirl from llOwnerSay().