Channel zero listens in attachments

Simple issue, nasty result. One of the big problems with lag in clubs comes from the use of animation overriders, gestures and so-on that listen on channel zero (in-world chat).

Now, simply removing channel zero listens unfortunately will break a lot of badly scripted and annoyingly popular products. Better products are available such as the ZHAO as an animation overrider, but people just don't use them, most users don't see why their current AOs are evil and so-on.

I'm very much still for just removing channel zero listens, preferably on a parcel basis so clubs can disable them to reduce the lag they cause.

But I'd just throught I'd throw out an alternative:
Treat channel zero listens in attachments differently. Namely; don't let them listen to anyone but their avatar.

In essence, they wouldn't be a part of the usual table listens, and each avatar would instead have their own little list of attachment listeners. If someone speaks on channel zero, they don't get a consideration, if an avatar speaks who has a table of attachment listeners, then these listeners are also consulted.
As a result, only when I speak, would my attachments be considered if they're listening on channel zero.

I'd still like rid of them entirely, but perhaps this way they can phased out instead.

I think that'd end up being a hard coded version of llListen(0, "" llGetOwner(), "" [I get that right?]
Such that it doesn't exactly reduce the table, but causes one more check to be performed before the script gets ahold of it. Which reduces the lag a bit, but not by that much (is faster for the sim to check the keys than it is for the script to).

Personally I'm all in favor of killing channel 0 listens and having it break scripts left and right. I'd clue in the users who don't know why it's bad, forcing them to get a new product or get the old one fixed and it'd clue in content creators making them fix their products.

Now if I only knew a way to break scripts that use llSay() [or llWhisper()] instead of llOwnerSay()....failing that, a way to identify when an object uses llSay/Whisper and doesn't need to so I can yell at the creator for being an idiot.

Channel 0 listens are important for role-playing objects, broadcasters, and so on. They're also needed for existing vehicles where they used a single-character channel-0 command because it was the quickest way to enter a command in mouselook flight.

Even with out that, killing channel 0 listens would break far too much content for it to ever happen. Much as I might like to break some of it.

I didn't say that there weren'y legitimate uses--most of which aren't attachments as that's the discussion--just that I'd like to break them.

Not exactly, but similar in idea.

Imagine the current listen system as a great big list of listens, now if LL have done it right this will be broken down by channel, since the channel something was spoken on will be very easy to filter.
Anyways, now imagine only channel zero listens, right now we have one big list for all channel zero listens in a simulator, every single one has to be checked every time someone (or something) says something in audible chat. This isn't very nice at all

However, when this is happening for an attachment, 99% of the time it's only interested in the owner, yet by all appearances at the moment, these will still be checked EVERY time someone or something speaks.

So the idea is, for ordinary listens on channel zero, will still have our list, this sadly is unavoidable. However, we basically remove all channel zero listens for an attachment from this list, and put them into separate lists depending on the avatar they are attached to.
So we could have a main list, then a list for Haravikk Mistral, a list for Draco18s Majestic, a list for Argent Stonecutter etc.

Now, if I speak, it will perform a range check on all listens in the main list, then it will look through all listens in my list. But it won't bother looking at the lists for anyone else, because their attachments now can't hear me. And it obviously doesn't need to check range for these, as I was the one speaking, if my attachments are out of range then I would have to had some kind of very unfortunate accident.

This way, on average when someone speaks, there are signifcantly fewer listens to consult, say four or five poorly scripted items that have channel zero commands to configure them. Plus anything the person in question may have attached.
Rather than as it seems to be now where at a club or other event you could be looking at every message being passed through upwards of easily 20 listens. I mean, 40 people to a typical full simulator, as if that isn't bad enough, half of these people may have AOs, and/or multi-tools and similar devices. 20 could become a very conservative estimate in busy simulators.

As far as I've been able to tell, splitting off into separate lists is not done, as it seems that attachments are not treated as a special case, when they could be (since they are associated with a single avatar only by virtue of being an attachment). Ordinary listens with an avatar filter couldn't really have this behaviour as the avatar may not be around (though if 'attaching' these listens when avatars join/leave is feasible it could be an option).
This idea wouldn't affect listens on other channels, as these are used much less frequently, even common ones like /1 are not as commonly checked as channel zero.

I understand that. I'd like to break them, too, as well as 90% of the channel zero chat.

The problem is that there are is so much content that depends on it that there's no way it's going to happen.

Which was why this might be nice ^^

Ultimately I'd maybe like this first, followed by (or maybe just going straight to) requiring a / before a message for a channel zero listen to work.

ie: "Hey Argent I'm Haravikk" wouldn't be picked up by a script but would appear in chat.
However: "/Hey Argent I'm Haravikk" would be picked up by a script and would not be visible in chat. Why I'd want a script to hear that I don't know, maybe for a megaphone or something.

Possibly even with optional characters on the client side which are then converted, so if you need quick commands you could make it just a space, or something (since space at the start of chat is redundant too).

This also happens to coincide nicely with hugs, pounces, ao's etc which already suggest that people type /ao on, or /hug Argent.

Actually, this idea is genius, ignore my original one.

Hmmm... I think I see what you're getting at after sleeping on it re-reading the message.

This might be a worthwhile optimization, let me try restating what I think you're proposing and extend it modestly:

WHEN an object is attached to an avatar,
AND it has a listen on channel 0,
THEN that listen is treated specially:
* It is taken out of the sim-wide channel zero Listen list.
* It is added to a list JUST for that avatar.

To deal with objects broken by this, you can have a flag you can set (on the attachment, or on all attachments) that would disable it, and there should be some kind of visual indication when there are objects on your personal listen list.

As an implementation technique, how about this? The client application picks an initially random high channel number for personal communication, and copies all the avatar's channel 0 chat to that channel as well. Attachments with listens on 0 get them remapped to that channel. There would have a preference setting to select the "attachment chat" channel. To disable it, the user would set their channel to zero.

This would be easier for LL to implement, since they already have the filters by channel. It would also allow the user to set their attachment chat channel to something low and talk to their attachments silently on that channel without having to be able to mod their scripts to do it.

Yep that's it exactly, my explanation can't have been total balls then
Hmmm, I do like that as a possible implementation actually, removes any extra checking on the channel zero listens to look for these specials lists in the first place, and offloads some of it to the client.

For broken content, I'm still unsure how much it is likely to break, 99% of channel zero listens on attachments are for animation over-riders, and emote/emote style scripts, maybe attachment vehicles as well if they need commands.
The only things I can really think of that would break are things that are of a dubious nature in the first place, such as chat loggers/repeaters. The only legitimate use for those was really to log meetings, but you can now log chat on the client-side and just copy/paste it instead.

How's about the alternative idea in my last post? I like it even better personally, implementation wise your suggestion would still work in a way whereby text beginning with a / (not /me) would automatically transmit to some new channel that zero listens would be remapped to. ALL zero listens in this case rather than just attachments, would be remapped to one of the high-end channels like DEBUG_CHANNEL, but not the same one, INT_MIN perhaps?
Basically in this way, if you WANT your chat to be seen by objects/scripts listening on 'channel zero' then you are giving that permission by typing a / at the start. I'm undecided whether chat beginning with a / would be removed, ie only scripts would see it as with current non-zero communications, or if it would still appear.

The most innocent examples that come to mind: dance chimeras that take commands, and role-play objects and pets. I have a shoulder pet that responds when someone around me says his name, for one example.

It wouldn't effect me, but a *lot* of people would go totally ballistic because they use "/" to prevent the typing animation and sounds when chatting at performances, so you don't get that "takka takka takka" going on over the stream.

Hrm, that's a very unusual little feature I was unaware of.
In that event then I would allow / chat to remain 'audible' to avatars so messages aren't lost, space could be an additional key to remove the keyboard sound (since starting a message with a space is redundant), but would not be audible to scripts.
A message beginning with a / would still be the only way to communite with a channel 'zero' listener.

Therefore current / typers would be unaffected, ordinary chat wouldn't be heard by objects, and there is a better alternative for / typers who don't want objects to hear them either. The disadvantage to allowing / typers unbroken functionality would be that people typing /ao on would still be audible to other avatars, which I could do without, but I've lived with thus far.

No matter how you do that you'll break some chat controls. The "/ is a command" convention is really only a convention, some scripted objects use it, some don't, so whether you strip the leading "/" or not some object won't get the right commands.

You're trying to solve two problems here: lag from listeners, and annoying chat. I don't think it's necessary or really possible to solve both at once.

I'm not really, I said it would be better to remove the commands (thus solving annoying chat), but the main idea really is the part whereby the scripts only hear messages beginning with a /.
If I've confused the issue then please ignore annoying messages and just assume messages are transmitted as normal, but only ones with a / are heard by channel zero listens.

The disadvantage is of course that people would have to learn that to communicate with an object they need to start their message with a slash, thus qualifying the message as script audible. It will cause confusion, but things like the tips messages at log-in and other avenues for making users aware of the change ought to help.
Users who still don't find out can fairly easily be told 'You just need to start the message with a / now'. It's just like learning to use the /me for descriptions really.

Yes, and that's also a problem:
That would break a lot of existing objects that use commands that don't start with a slash, or if you strip the slash it will break existing objects that use commands that do start with a slash. It would also break vehicles that use single-character commands.

And since the vast majority of the scripts still in use that have promiscuous listens on 0 are on attachments, if you just solve the problem for attachments you've solved the majority of the problem. And that's what I had come to think your main idea was... not this slash business.

Problem with using / to communicate with scripts:

How do you transmit a number?

/14

sends "" to channel 14.

/ 14

sends..." 14"? to channel "0 with scripts" or would it send "14" ignoring the leading space?

By the way... IF this had been done in the original design of SL this would probably be a good idea. In fact it would be a great idea. Nobody would have written any of the code that would be broken by any possible variant of this.

But there's too many scripts that depend on "/" or "no /" for it to be retrofitted now.