reducing lag? - stop scripts listening on channel 0

Here's an idea (just floating it, not endorsing it) - why not make it impossible for LSL scripts to listen to channel 0 (public chat)?

This would force all scripts to use a numbered channel (which has, of course, much less traffic).

Advantages :
1) reduces lag
2) eliminates some worries about the privacy of public chat in SL (becuase scripts can't listen in)

Whether this is a good idea or not depends on :
1) How much this would reduce lag
2) If we value the reduction in lag and privacy gains above the freedom that scripts listening to chat offers (basically, the ability to command scripts with voice commands that others can hear)

Do we think this is a good idea, or not?

Personally, I'd only go for this if it did a *lot* to reduce lag, and we couldn't reduce lag any other way. I thought I'd float it anyway though, in case of the unlikely event it gets a lot of support.

The key to creating better anti-lag proposals really requires residents to actually know what's causing lag... and currently, many of us don't....

maybe if we knew we could propose better ideas to help combat lag (other then the obvious ones like educating people to turn off listening scripts, don't use llSensorRepeat more then needed, try to avoid having timers on 0.1s, etc).

Er, disadvantages: no script could ever tell what any avatar was saying publicly. Which is fairly important.

Why is that important? Seriously. What scripts require the ability to do that?
I'm sure there are some, I'd just like to know what they are

Collars typically work on 2 channels, one public and one private - useful for the collared one to see any owner issued commands.

Microphones / repeaters that listen to one AV and then respeak the text - doing it on public channel means the speaker can be seen typing. Private channel you see nothing.

Bingo (the game).

Huggers (see collars).

Magic 8 Balls.

Just a few off the top of my head

Chatloggers - these have a bad rep but they can be extremely useful for taking minutes. I'm sure there are lots of cutesy little attachments which work by listening as well, say producing a load of heart particles when someone says "I love you". (I have a typewriter typing script which goes "ding!" when you press Enter, which works by listening on channel 0 for you to say something.)

Unfortunately there are too many implementations using channel 0 to just chuck it =(

In the majority of cases channel 0 listens are completely uneccessary, maybe for chat-logging, but for things like collars there's no reason to not listen to a private channel, owners can easily type /2 to speak on channel two, just so long as it's standard, it's easy.
Channel 0 listens are bad-scripting, and bad-scripts are always going to cause lag

Fundamentally, it's a problem of the LSL implementation if a listener causes the system to lag.

I agree: most scripts do not have to listen on channel 0, but for other reasons. The commands are spam to everybody else, so take them to the private channels. Likewise for debugging or status output. use llOwnerSay() or DEBUG_CHANNEL instead of llSay(0,...)

Stand in at the shore and protect a square meter of sand with a glass bowl.
Ignore the other 99.9999% of beaches.

Or, less snarkily, if open listens on 0 were in the top ten causes of lag, this would be a great idea. Scripters should still not use them, but their removal really wouldn't help SL generally or noticably.

Possibly.

Agreed, though I don't believe we should remove features because they annoy people (mute always exists, after all).

Yes, and there are other very useful applications beyond simply the comic ones like the typewriter script.

That objection will probably be fatal to the whole idea of stopping scripts listening on channel 0. It'd cause too much economic disruption as large numbers of scripted objects suddenly stop working, customers demand refunds, etc.

Yeah, it does seem clear that stopping scripts listening on channel 0 is a bad idea, because :
1) nobody's posted arguing that it definately does reduce lag significantly
2) while stopping spam, it's possible to do that anyway using the mute command
3) removing the feature now would cause problems as objects would stop working

So yeah, I now know why this is a bad idea

Each listener running in an object regardless of what channel its listening to creates a minor resource hit. This is because it schedules a 'speech handler' in the various events tracked in the server. Generically this means that anything said at all will require some ammount of processing for anything listening in the sim.

The advantage of using something OTHER than channel zero is that the fastest evaluation you can do in computers is checking if two numbers are equal or not. So if the spoken command does not match the channel a given listener is on, then it can immediately move on skipping further processing.

If the channel matches the next optimal operation to check would be distance. Reason you check channel prior to distance is to compute distance you have to take

sqrt( (X1-x2)*(X1-x2) + (Y1-y2)*(Y1-y2) + (Z1-z2)*(Z1-z2) )

to get the distances between two 3d points. Lot more processing than a simple integer check. After that you have to see IF the listener has a name filter or not and to then compare names . After that you have to first check IF the listener even has a UUID filter or not and then compare. And after that you have to just look IF the listener is filtered further by checking message content or not.

All this has to be done BEFORE the listen() event in the script is even executed. So changing a single listener being changed from channel zero to ANY other channel, removes all that processing. And it reduces that processing for EVERY SINGLE thing said by any avatar in the sim. Or even those in nearby sims where their speech range forces the spoken message to cross a sim boundary.

So its all that baggage of processing TIMES the number of spoken messages, TIMES the number of listeners running. It adds up. Quickly. And this is assuming that Linden Labs is doing the most effecient order of processing on it. If the processing method is less effecient you will have even worse performance per channel zero listener. Its not a weakness of the LSL system that makes it cause lag. Its the fact that to process messages you have to have some MINIMUM ammount of work performed in order to allow features like filtering to exist.

So, for all those people running around with an AO or two that listens to an /AO ON or /AO OFF message, if the scripter was smart and ONLY filtered that by owner and just parsed the message in the script for which action then you just have one listener ineffeciently doing all that wasteful pre-filter processing due to chan zero ignorance. If the scripter thought they were being smart (mistake) and uses two listereners, each filtered by message to reduce the number of times the script will be called (not very important) while doubling th enumber of listeners you get even more wasteful processing.

now add in all the 'safe' 'unsafe' weapon commands. all the 'shield on/off' commands. all the follower bots that listen for targets in common chat. all the stupid dragons that react to you saying 'kewl' in chat. Hell that stupid dragon is fully parsing everything said completely. Its almost the worst of them all.

Now there might be some legitimate uses for channel zero listeners. You can use them to automatically record the ongoing speech in a class. Actually you can use your chat history and copy/paste. Ok you can use it to record a conversation that you want to save for later while you and a friend are discussing design issues in-world. Oh wait chat history covers that too. How about those dragons or parrots? Ugh that was covered above.

OK. There are -THEORHETICALLY- some legitimate uses for channel zero listeners. Someone somewhere might have had a drug induced 'vision quest' where they discovered the secret. Its beyond me.

I dont think channel zero listeners should be outright disabled as a whole. They have limited uses somewhere. But to filter typed commands is NOT a valid reason. /1command is only TWO MORE LETTERS to type than just 'command'.


Har: "Unfortunately there are too many implementations using channel 0 to just chuck it =("

sorry thats the reason TO chuck it out the window. It would be an immediate improvement because all those scripts would crash and burn and no longer be able to cause undo processing requirements

Ninja: "useful for the collared one to see any owner issued commands."

That is why the collared avatar should have their color use llOwnerSay() to echo PRIVATELY the typed command. No need for a chan zero command to be heard at all. That also covers huggers and anything else. Those objects can listen on channel 1 and echo even via a llWhisper the typed command if audience participation is needed. It would still reduce the overall processing. And the same goes for chat repeaters over large areas. The speaker can type on an offchannel and have the repeaters be the ones to echo the chat.

There you go with the technicalities of why channel zero listeners have NO LEGITIMATE USE. If you want to come up with another reason they should be used i'll give you an alternative to it to. But feel free to come up with them all you want. The more alternatives we make public the more SOMEONE will get smart and start using them.

Assuming your present at the conversation you want to record for its duration. If your having stability problems you cant copy and paste a conversation that's just been replaced with your desktop.



And when every AO wearing hugger enabled resident asks "why does all this stuff i paid money for not work anymore?" we should just direct them to an explanation of why channel 0 had to go, sorry. I don't think your wish to see a lot of peoples utility attachments crash and burn included a desire to replace, retool or compensate.

Thinking about it, lets ban the torus while were at it. Its twisted form pushes polygon counts through the roof, I am quite sure everyone will experience better performance.

Sorry, but dispite a very good exmplanation of messages and channels, its still my opinion that there are lots of other more legitimate targets to improve performance. Listening on channel 0 isn't one of them, which as you manage to point out very clearly yourself - Everthing does it and the world keeps on turning - peechy.

And despite what you say, a parrot is a legitimate use, you don't have to like it or even see the point.

I point out that lots of things use them and that its a cause of increased SIM lag. You can control polygon counts with client options and there are many things that use a torus in the shape that couldnt be done in other methods without using enough combined other pieces to throw the prim count thru the roof and thus likely use more polygons than a the tori would have done on their own. Another deficite of using multiple prims in replacement of a single torus would be that when the sim decides to send you a 'full stats update' of an object sending that info for multiple prims would increase bandwidth, a resource effecting performance on both sim and client side. Where a single torus for the shape reduces the complexity of the object to be handled via the various physics engine tests and other occlusion based tests (among other things). Thus having tori available to build with improves overall performances because of fewer operations being required. Another issue is that there are not many places in SL where polygons of themselves are an issue. Its normally the sheer number of objects with its textures and data manipulations and calculations that does it rather than the draw. There is lots of room for effeciency in the logical tests the client uses.

My pure issue is with channel zero effeciencies. Recording a speech can be the ONLY legitimate use for a channel zero listener. Thats it. And if one person is having stability issues you can ask for the chat log from someone else in attendance. Cut / paste into a notecard and you're golden. As far as breaking all those AOs. Yes i would truely love to see that happen. Didnt claim otherwise. If the people using them gets their money back i dont care at all. I dont condone people implimenting things that cause more harm than help and i dont pity people who purchase those objects at all. I dont use -any- objects that /require/ a chan zero listener outside of testing them. No commercial product has an excuse for using them.

That is why I dont think the feature should be removed. But I do think that if its used in a manner that could be better implimented it should break. And there just isnt enough legitimate uses (none) to make up for all the bad uses that create problems (many).

So yes direct every complainer to this thread. They will either 'see the light' and demand fixed versions of the products without the lag inducing mis-feature, or they will blow up emotionally, hunt me down in world and scream their heads off while I nod and snicker and move on about my business without pity because the game was just improved.

Oh.. and i agree there are LOTS of other issues that can improve performance. Some of which would be a lot higher improvement than this. Thing is this is LITERALLY a 10 minute code fix as far as rewriting anything on the developement side. In the function that recieves the llListen() call it can do an integer check and if channel == 0 it can just not set a listener. Sure it can optionally send the wearer of the object an error message but thats a very small code change. So implimenting this particular idea would be a quick job with immediate results.

Sorry, but im going to say it again. A parrot is a legitimate use, and one you can't just write off because you don't see the point. I don't see the point of a lot of things in SL, don't think they should be prohibited.

Simple AI that can verbally interact with a nearby group of people (without people being told they need to talk directly to the script) is very exciting. At its most pointless thats a parrot or a dragon or a magic 8 ball. Its not really been feasable to put more into AI's until recently - its not as if any sane person would want to try and implement anything more than a simple ALICE in LSL, with httprequest however, you can have a parrot backed by a whole server full of magic.

mole hill -> mountain

Thats still only 1 use that isnt easily done in another manner vs the 100's that are currently used that contribute to lag. Lessor of Evils issue in my POV. =-) But at least an ALICE or ELIZA would be a semi legitimate use. If only functional without being much useful.

I use channel 0 in a renter script to temporarily listen to a user so they can input a title for their room, or someone to add to their allowed list. It contributes very little to lag because it only listens for 60 seconds, and filters on the user in question.

It's a less specialised and still legitimate use because it's easier to say "Speak (in chat) the name to add to the allowed list" than it is to say "Speak (in chat prefixed by /2) the name to add to the allowed list", not to mention much easier for casual users who don't use scripts much to understand.
It's also not exactly wasteful, it only listens for 30 to 60 seconds (depending what option was chosen) and is much easier for people to use. Or closes the moment a response is received.

That's how all listens should behave unless they are needed permanently and is good scripting. In that case it's also a good example of a properly used listen on channel zero.
Even the AI things or whatever, so long as they are actually using the chat and need to respond to it, it's still a proper listen. It's the listens that don't close when they're finished, or which do superfluous work on channel zero (e.g checking each message to see if it's from their owner instead of filtering on that to begin with.

Channel zero listens are just as valid as any other, lag is only caused by poorly scripted ones. Even then I don't think channel zero listens have all that much of an effect, if they cause too much lag then the script slows down, and as such it's events get executed more slowly, if at all (as I think it only has a limited queue for events?)

For the most part the extra processing im referring to is all the execution performed PRIOR to your scripts listen() event triggering. Just the fact of a chan 0 listener existing causes resource use beyond what is needed.

I consider the code written in the listen event itself to be a moot point on the lag issue. A script writer is gonna do an effecient job or not and the script side of the processing will be the same ammount no matter what channel. When its processed the whole block executes after all. But no matter how effecient you are just having the listener EXIST on chan zero causes more processing than is needed.

Telling someone to 'To add a name to your allow list please say the avatars name on channel 2." i consider a very straight forward explination. If a user doesnt understand what channels are they NEED to know. Its a basic feature of SL and thats what Live Help is for. I'm part of LH and i have no problems giving these explinations as its required knowledge to function in this world.

That aside I admire the work you put into making your listeners effecient. I dont have a single llDialog call in any of my scripts that use a permanant channel. They've all been upgraded months ago that the channel only opens up for the duration its needed and closes out automatically after a given time or a proper response. But I still think that those habits should be one used on ANY listener regardless of channel and that the chan zero listener itself could be offset to another.

Personally my dream would be that functions such as llGiveInventory() llRezObject() llSensorRepeat() and llListen() should be access limited. I would like those features to not be able to compile for a user unless that users avatar had attended some once a month "responsibility with scripts" class in order to get certified. Now I think that should only limit compilation. As long as the script designer compiled the script it would be usable by anyone it was sold / given to. Just if they changed it it would not compile for them due to access restrictions. Oh well only in my dream world.

BTW i know what i -want- to happen can prevent legitimate uses. I think channel zero listeners should be something that is restricted use only to people have proven themselve responsible. That type of certification is also beyond LL's means to accomplish and outright banning THOUGH FULLY MERITED is a bit harsh on the FEW people who use it responsibly.

I would like this to happen but admit it never will. A more reasonable discussion along a similar though not as extreme line is here:

/13/00/113247/1.html

The proposal im putting forth on its own merits is a bit of a compromise on what i think should happen (kill chan zero listeners) so might fit your preferences better. I created a seperate thread so that this one could maintain its topic of outright banning without being diluted.

You're not serious surely.

Yes quite serious. My history with online gaming started with MUDs. They were strictly text based interfaces but you had to be approved to get access to the building tools. It wasnt a given right for anyone. You could do that by attending in-game meetings and learning about how things work, by providing proof of work accomplished in other games or in some other manners in a case by case method.

It meant idiots without a sense of responsibility didnt have power to do harm. Im not saying all of SL should be restricted. And im not saying the class should be difficult. Limiting it strictly to being attendance at the pre written lecture and not going AFK or IDLE at all for the duration of the lecture could be enough. At least at this point you've not only agreed to the TOS but you SHOULD have listened to what the consequences of your actions could do.

I did NOT intend for it to mean that only a hand selected few get the rights to use those features. Also if the preview grid was left running continuously people could always go THERE and not have the limits. That way they could practice with the features and learn how they work in a safe environment that doesnt effect the grid as a whole.

Other than that im dead serious. I also know it will never happen.

You might want to add the push functions to your seminar list as well.

As for chan 0 listens, I've never used them for anything that could possibly be deemed important and I HATE above all else chat messages from objects that I'm not using on chan 0 (either listen or say. GODS ABOVE I hate baby attachments).

But thats exactly what would happen in effect. You would cap the number of scripters to those you could / would teach and I am quite sure some people would be excluded for personal or political reasons.



You do know the preview grid has very limited resources and is not intended as a sandbox for the masses. Especially as your wishing to send all the irresponsible scripters there, we would need a second preview grid in order to get any actual bug testing done!

Instead of banning channel 0 listeners, just reduce the script time available to scripts with an open listener on zero. Maybe all 0 listener scripts on a sim get capped to 1% of the total available sim time, put together.

That won't break anything, and it won't directly solve the problem, but it'll make people want to switch to other channels.

Not really. As i said it could be a completely automated feature to get the 'certification' for these features. Simply by showing up at a scheduled lecture. The lecture itself could even be a prescripted speech given by an object. You could be checked to ensure you dont go idle. Possibly there could be a set of boxes that required you to click one every 3 or 4 minutes to ensure you're not using an anti idler.

Anyone showing up before the lecture starts and remaining until completion, having proven they were not AFKing would be given a notecard containing the class lecture and automatically certified for that feature. Nothing elitist about it.



I like !! you get a brownie point. Actually have a full brownie. =-)

Id still rather just break the feature in half and kill the bloody '0' listeners. Im a lot more reasonable in the other topic.

Seronis, you're trying to solve a social problem by technical means. This has never worked in any environment I know of, and it will not help here

I truly agree, channel 0 should be used carefully and only if there's no better way to do it. But most people have no deeper understanding in how sims and LSL work, and those people probably will not read any documentation you give them, forced or not. They will attend your class, click on the boxes, because they have to, and otherwise forget about the lecture altogether. The few who actually do grasp the concept would have learned it without this lecture anyway.

What I miss personally is a "llListListeners()" function, where I can check upon open listener channels and see, if my script behaves badly. As it is now, we can only play the code in our mind line-by-line and hope we interpret every case correctly to know, how many listeners there will be in the end.

Give the users / scripters more tools instead of restricting them. LSL is a nightmare, as we all know, so you can't expect from the majority of people to learn all it's quirks and shortcomings. We need better debugging and code monitoring / profiling tools to iron out those cases on our own.

Oh, about "muting" channel 0 spamming objects: Not a good idea, if the object in question is named: "Object" This prevented me from collecting Linden Cards at Waterhead, because the object giver was also an unnamed object. Took me some time and a Linden to find that out. I still need to IM Nicole Linden to fix that, but this describes, why muting can be a problem, since it's done on a per-name basis.

Beautiful post Zi. Agree its a technical fix to a social problem. =-) But that was my intention all along hehe.