Choosing A Channel

[Perrie Juran]

I love chat commands.

Any time that I can use them I prefer them over a touch event.

For example, I have fog generators I use on my land around Halloween.  They are set so all I need to do is type "fog on" or "fog off" rather than having to find the invisiprims I use for them and touching each one.

According to the LSL Wiki there 4,294,967,294 possible channels.  I do understand that half of these are only for scripts to "talk to" other scripts.  (Struck because I misunderstood something in the Wiki).

So my question is, is there a logic or reason for choosing the channels to use.

The most common channels I see being used for scripted objects are 1,2,7 & 99.  Is this simply a matter of convenience, that it is easy for people to remember?  Or are there other factors?  Can for instance a channel get overloaded?

Thanks. 

[LepreKhaun]

---

Perrie Juran wrote:

I love chat commands.

Any time that I can use them I prefer them over a touch event.

For example, I have fog generators I use on my land around Halloween.  They are set so all I need to do is type "fog on" or "fog off" rather than having to find the invisiprims I use for them and touching each one.

According to the 

LSL Wiki

there 4,294,967,294 possible channels.  I do understand that half of these are only for scripts to "talk to" other scripts.

So my question is, is there a logic or reason for choosing the channels to use.

The most common channels I see being used for scripted objects are 1,2,7 & 99.  Is this simply a matter of convenience, that it is easy for people to remember?  Or are there other factors?  Can for instance a channel get overloaded?

Thanks. 

---

Channels are one part of the subscription filter used for the listen event handler. When used for the purpose as you described, it is entirely a matter of convenience; you're wanting an easy to remember number of few key strokes.

 

Other factors may influence the filtering, usually to reduce the likelihood of having the handler triggered by chat not meant for them, as by subscribing only to anything said by the owner of the object on channel 1 ( integer listener = llListen(1, "", llGetOwner(), ""); ).

 

I have no idea what you mean by "overloaded" in this context so can't answer that.

[ETA a space between a semicolon and close paranthesis to get rid of a unwanted smiley face.)

[Helium Loon]

The biggest issue with using Listen()'s is that they consume a good bit of server resources, script-wise().  This can be limited with using proper filtering on the listen parameters, but they still consume a good bit of resources.

 

The channel is a 32-bit signed integer.  This gives about 2 billion positive (chat accessible) and 2 billion negative (script only) channels.

 

Use of a channel is pretty much a matter of taste.  Realize that the more 'common' a channel you use, the more likely something else may be using the same channel in the same area.  Which means more work for the server sending messages to scripts that don't really need to 'hear' the cross-talk.

 

The particular 'common' channels you list are easily typed and remembered.  A LOT of scripts use them.  I find 3 digit (non-repeating) numbers work very well and minimize the chance of crosstalk.  456, 789, 234....these are all easily used, and rarely will you experience any crosstalk.

 

Make sure you put good filters on your llListen() call.  If only you are ever supposed to use it, make sure you set the user filter to llGetOwner().  If it only gets one command, set the text filter to that command.  That will minimize the impact on the server from the Listen.

 

[steph Arnott]

I bit confused here "I do understand that half of these are only for scripts to "talk to" other scripts." PUBLIC_CHANNEL is the only one. No scripter would use those unless it needs to be manually inputted by a avatar,for ease of recall.

@ Helium Loon

" that they consume a good bit of server resources, script-wise()."  so old hat. "This can be limited with using proper filtering on the listen parameters" that makes it even worse.

"

[Madelaine McMasters]

---

Perrie Juran wrote:

So my question is, is there a logic or reason for choosing the channels to use.

The most common channels I see being used for scripted objects are 1,2,7 & 99.  Is this simply a matter of convenience, that it is easy for people to remember?  Or are there other factors?  Can for instance a channel get overloaded?

Thanks. 

---

Yes, 1,2,7 & 99 are matters of convenience... or inconvenience, and perhaps a matter of defacto standardization. I'd never script something other than a poseball to operate on channel 1 because so many poseballs show/hide/sync on that channel, and every time I chatted a command, they'd all have to parse it.

I suppose it's possible to have so many scripts listening on a channel that launching a command there would bog the server, but it's possible that servers limit script time, so the net effect would be a slowing of the scripts, not other things. For script to script communications, I always use large negative channel numbers (all negatives are for script-to-script only, hence half the channels). For avatar to script communications, I use easy to remember yet out of the way channel numbers like... 666.

;-)

[Perrie Juran]

---

steph Arnott wrote:

I bit confused here "

I do understand that half of these are only for scripts to "talk to" other scripts." PUBLIC_CHANNEL is the only one. No scripter would use those unless it needs to be manually inputted by a avatar,for ease of recall.

---

Oops.  I misread / misunderstood something in the Wiki.  Thanks.  Struck in my post.

[LepreKhaun]

---

Helium Loon wrote:

The biggest issue with using Listen()'s is that they consume a good bit of server resources, script-wise().  This can be limited with using proper filtering on the listen parameters, but they still consume a good bit of resources.

...

---

A minor clarification is needed here: Listen() is just an event handler, the code you've written in your script to respond to a chat message. The listener handle is what you're refering to.

[steph Arnott]

Positive channels can only be inputted by an avatar. E.g. /10. Negative tend to be used as communication channels, but can still use positive channels. Me I tend to  use negative on script say and positive on link messages.

[LepreKhaun]

---

steph Arnott wrote:

Positive channels can only be inputted by an avatar. E.g. /10. Negative tend to be used as communication channels, but can still use positive channels. Me I tend to  use negative on script say and positive on link messages.

---

Some TPVes can chat on negative channels, the standard SL Viewer cannot however.

 

Link messages do not use channels in any sense of the word.

[steph Arnott]

I was not aware of this "Some TPVes can chat on negative channels, the standard SL Viewer cannot however."

and i was just saying how i do things, but yes it not a channel. "Link messages do not use channels in any sense of the word." thanks for the update.

[LepreKhaun]

Firestorm can, for one. Open Avatar=>Preferences=>Chat=>Firestorm and enable Show Channel Selection In Chatbar.

 

You don't even have to type the channel number that way, negative or not. But one can still only "hear" PUBLIC_CHANNEL, as always. That just controls what you "speak".

[Qie Niangao]

---

steph Arnott wrote:

@ Helium Loon

"

 that they consume a good bit of server resources, script-wise()."  so old hat. "

This can be limited with using proper filtering on the listen parameters" that makes it even worse.

"

---

I believe the truth is to be found somewhere between these extremes.

Back before Mono, anything that caused a script to be eligible to run was really to be avoided. It was crucial, then, to use llListen filters that were as restrictive as possible, so the sim's event dispatching would only wake up scripts when there really was something for them to process.

Since Mono, it shouldn't matter quite so much whether irrelevant messages are filtered out in event dispatching or in a script's listen() handler. It's undoubtedly still less expensive to do it outside the script, but the difference should be several-fold now, rather than orders of magnitude as before. (Of course, if all messages actually present on the channel will end up being processed by the script anyway -- it's an obscure channel containing only relevant messages -- then any potential benefit of a filter is never realized.)

The general observation that listeners consume resources can't be disputed, but all scripts consume resources by their very nature. There's some additional overhead to a listener-triggered script compared to one triggered by touch or link message, etc., but if the listener is on some non-zero channel, that overhead is a tiny price to pay for even a bit of user convenience.

[Perrie Juran]

Thanks everyone for your replies.

I was repairing some things I had made to get rid of llListen(1,"",NULL_KEY,"") where it wasn't needed when the question crossed my mind.

I know that sometimes one person's convenience can be another person's nightmare, like my neighbor running his snow blower at 5AM this morning.

I happen to like chat commands.  But if I'm going to use them I want to do it in the manner that least impacts everyone.  So your answers have been very appreciated.

[Nova Convair]

I made a simple test. 1000 scripts in 100 prims all listening on the same channel.

A sender sent 500 messages. The 1000 scripts tell me the number of messages they received when they get the end message.

What happened? The scripts can receive 12 messages per second so the script events went up by 12000 for a while. Then i got reports about received messages until the output gets capped, so 100 reports make it through, all 100% success.

No visible efffects on the sim/stats/chat/other running scripts.

Of course 1000 listeners use up resources, even if they are not working so I suggest to only listen when needed. By my calculations I think I need at least 10000 to have a "visible" impact.

 

[Xiija]

a quickie script to make a channel based on someone's avatar key ( good for multi touch listeners?)

 make sure & use a timer to clean them up!

string CHkey; string tmp;integer check;string convert;integer chan;integer len ;integer listener;
key ID;

Key2Channel( key input){        CHkey = (string)input;         len = llStringLength(CHkey);         integer n;         for(; n <len; ++n)         {            tmp = llGetSubString(CHkey, n, n) ;            check = llAbs( (integer)tmp );                 // numbers are numbers, letters are 0          if(check == 0){}          else            convert += (string)check;         }         convert =  llGetSubString(convert, 0, 5) ;  // channel has 5 numbers in it         chan = (integer)convert; chan = -chan;    // make it negative        listener = llListen(chan, "", input, "");       // listen only to this obj/avatar}default{    state_entry()    {    }    touch_start(integer total_number)    {  ID = llDetectedKey(0);       Key2Channel(ID);       llDialog(ID, "\nChoose a button: ", ["Yes", "No" ] , chan);    }     listen(integer chan, string name, key id, string msg)    {  if (msg == "Yes")       { // do something       }   }}

 

[LepreKhaun]

---

Xiija wrote:

a quickie script to make a channel based on someone's avatar key ( good for multi touch listeners?)

 make sure & use a timer to clean them up!

---

Errr, is that as in "Do as I say, not as I do"?

 

Seriously, your approach is way off, you can't handle multiple listeners in an integer variable, a list is required.

[Rolig Loon]

Wouldn't it just be easier to write

integer Chan = (integer)("0xF" + llGetSubString(llDetectedKey(0),0,6));

?

[Xiija]

@ LepreKhaun..... truetrue...i was trying to be all scripty at getting a unique channel

and not posting the list part

@ Rolig ....that is way easier, but i have no clue how it works  

(integer)"0xF" by itself is giving me 15 .. adding that to the first 7 digits in my key

does not give the same answer as whatever happens in that snippet ...?

 

[Rolig Loon]

"0xF", added to that substring, will make it a hex number with a negative sign.  Convert that to an integer and you have your negative channel.

[Perrie Juran]

Ummmmmmm,  I'm lost here.

For a touch event what advantage does this have over my randomly choosing a number?

[steph Arnott]

Not a lot, It just an over complicated way of getting a channel, which can be hacked by copying the owners uuid, which is a big bonus if that ones intention. I simply do this.

menu_chan	=(integer)llFrand(-10000)-100;

 

[Perrie Juran]

---

steph Arnott wrote:

Not a lot, It just an over complicated way of getting a channel, which can be hacked by copying the owners uuid, which is a big bonus if that ones intention. I simply do this.

menu_chan	=(integer)llFrand(-10000)-100;

 

---

But if I've set the script to listen only to me, knowing the channel should be of no real value?

[Rolig Loon]

---

Perrie Juran wrote:

Ummmmmmm,  I'm lost here.

For a touch event what advantage does this have over my randomly choosing a number?

---

It all depends on who's touching and why.  There are many situations in which you want to open a comm channel that is not random but it somehow unique to either the person using the device or to the device itself.  For example, if I want to be able to rez demo items one at a time for a customer to see, I will need to write a script that

• Gives the customer a dialog menu for selecting which item to rez
• Deletes any demo item that was rezzed previously
• Rezzes the selected item

To do that, I need to have some way to communicate with each newly rezzed item, to tell it when to die. So, I create a unique comm channel based on my rezzer's own UUID:

integer My_channel = (integer) ("0xF" + llGetSubString(llGetKey(),0,6));

and I tell the new object what that channel is by passing it as a parameter in the llRezAtRoot command:

llRezAtRoot("New_Demo_Item_1", llGetPos() + <0.0,0.0,1.0>*llGetRot(),ZERO_VECTOR,ZERO_ROTATION,My_channel);

A script in my New_Demo_Item_1 receives that information as it is rezzed and immediately opens a llListen handler on that channel.  When it hears the rezzer issue a later a command to die, it's toast.

Using that unique but non-random channel lets me run several identical rezzers in the same shop, secure in the knowledge that they will be able to manage their own products but won't interfere with each other .

[Perrie Juran]

So this would explain why I've seen an 'error' message to the effect of, "So and So is using the Vendor or Rezzer...."

I did have a slight concern that this could be used to 'hack' into one of my scripts with out my granting permission but I didn't think LL would leave something like that so wide open.

[LepreKhaun]

---

Xiija wrote:

...

@ Rolig ....that is way easier, but i have no clue how it works

 

(integer)"0xF" by itself is giving me 15 ...

 

---

One way to look at this to realize how a signed 32-bit integer is written, the most significant bit determines if it's positive or negative.

"0xF" is "15" in decimal and "1111" in binary. That first bit, being a "1", sets the resulting integer to a negative value. She could also have used any hex value down to "0x8" (which is "1000" in binary) for this but not "0x7" (which is "0111").