reducing lag? - stop scripts listening on channel 0

How about just giving land owners the ability to limit channel 0 listens to objects they own, or objects set to the land's group?

Channel 0 listens don't seem to lag that badly - though the above option might make sense, for, say, clubs with lots of people and chat.

Or my post here describes a script you can write to discourage people using them.

Hmmmm ....

I am writing a script designed to work off a script someone else wrote. Their script has ways to talk to things on private channels, but this information will not be divulged to me. I am a Hacker, not a Cracker, so finding those channels is not something I can do, and what's more, the data is probably encrypted. And it gets better. Even if I *could* find those channels, setting up something that could broadcast on those channels using his script to call my script would probably be next to impossible.

Lucky for me, his scripts like dumping stuff I can tell it to dump on Channel 0.

Is this a case of bad scripting on my part, to tell another person's script to dump something on the only channel I have available to me so my script can pick it up? Or is this a clever solution to a rather infuriating problem?

Both. he should never have written a dump feature that used anything but llOwnerSay or llEmail. You using the 'dump to chan' zero is safe lag wise, if annoyingly spammy. That only addes the equivilant of a spoken message in chat. But if you then create script to LISTEN to those channel zero messages you are again violating the rule of DONT LISTEN on channel zero.

I disagree with your statement.
As for RPer it's much easier to have a collar that reacts immediately
when the Owner (not owner, scriptwise: llListen(0,"",theOwner,"") is able to say in channel 0:
* come here
* follow me
* stand / halt
* kneel
* etc.
and it reacts.
This is more immersive to both Owner and property (so to speak).
Takes _less_ typing (twice!) as well as no need for a clicky interface.

Having said that, my personaly opinion is like some things that do not interact directly should be listening on private channels.
Example:
- doorscript: saying lock/unlock over channel 0 is a bit unrealistic
- advertisement scripts blurting out and waiting for channel 0 input.. If you blurt out, you can name the channel too
- etc.

You missed llInstantMessage...

If you're issing commands like 'follow me' in public chat in a crowed place, it would probably cause a lot of confusion.
If you instead issued them as 'NAME: follow me', in the standard chat convention when talking to just one person... then there is no advantage in doing that over doing "/7 follow me" or something similar.
So, if non addressed to a person, it may cause confusion for other people in the area. If addressed to a person as it should be, then there is really no reason not to use a private channel given that other people don't need to see it anyway. It's not a big problem, but if you're in a big room where lots of people are giving commands in public chat it can get quite annoying.

So what you are saying is that we should never have scripts that do any of this, and, not only should they never do this stuff, but that it is never a good idea to write a script such that another person's script can interact with your script.

Well, there goes all multi-tasking operating environs, I think.

Ooops. Better stick to Disk Operating System.

Ooops. Who wants Disk Operating System when you have Windows XP? But Windows XP Pro has lots of programs that talk to each other that weren't all written by one person or even one corporation.

But having code from different people talking to each other is insane. It causes lag and incompatibility and stuff. Better to not allow it.

So it's back to Disk Operating System.

But it can't be, because who wants Disk Operating System, nowadays?

I can go on forever.

It is my humble opinion that using channel 0 is poor practice for other reasons. The primary reason for it being poor practice is any place a script can recieve commands from the outside is a weak place. Crackers and Griefers can take advantage.

The weakness in the other person's script was that they never set up a way for their scripts to talk to scripts that were outside theirs. What they did was set them up to listen to outside scripts {through a translator script I do not have} but never to talk to them.

Since I am attempting to design an enhancement on their product, I need their product to talk to mine. Obviously, it would be pointless to try to make this conversation work through their translator {they've made it pretty clear they don't want this} so I am using an ad hoc method to accomplish it.

Not the ideal solution, not even the best solution, but it's all I have until I can find something better.

Of course, if they don't provide the translator scripts, my scripts will be useless in this capacity, in which case, I guess I will just have to forgo interacting with their scripts at all. In which case, they will be very unhappy, because I seem to have unique ideas all my own for writing scripts, and nobody else seems to impliment.

Hmmm .... I think it's because most geeky scripters live in a crazy little bubble and don't see anything else in the outside world.

How many of you would happen to know the horsepower of a typical SD90MAC?

How many of you would happen to know where to find a soup kitchen in Jacksonville, Florida?

How many of you would know how to remove the protruding points of nails and screws that you can not remove from the work because they're still needed to hold the work together?

How many would even have tools to find out the last one?

How about finding me a propane range cooker for less than $75.00? Is this beyond you, too?

I think exclusively across the board. I do not put ideas in boxes, like most people do. I do not buy "Pasta Bake Sauce" because there's nothing special about it. I *could* sell "incredible gravy cubes," complete with directions on how to use them to make "incredible gravy," for a buck apiece, and nobody would be the wiser as to what they actually were.

And all this goes in to my scripting, as well. I don't do things the "normal" way. I do them efficiently, and I do them to suit the task I have at hand, and I do them to make them work very well, and at the same time, I make them safe and stable. It's more than I can say for most "conventional" scripters.

One other thing: When I write programs, I write them "for the masses." This means anyone can use them, even if they're running a lowly 8088. Incidently, how many of you even *know* what an 8088 is?

Yes, bondage / master/slave equipment is better with Channel 0, however, that isn't a large enough reason to get rid of it. It's easy enough to code the collar (or some other script) to repeat the command on the general chat so it only needs to be typed once. Viola, a hack.

However, if it is a landswitch "Disable outside Ch 0 listens" then there's no issue. You want it to work on you rland--it works. If you wander around with your pet it'd be just as if you hit a no-script parcel, you just have to deal with it.

actually if you're an RPer just set up a gesture that detects your channel zero message and then rebroadcasts the COLLARS command on the off channel at the same time. You still get visual effects and you still reduce lag by not listening on channel zero. All the tools already exist to do this. Just be responsible in using them.

Re-read the entire thing. All i said is that channel zero is not an acceptible interface for this EVER. Use any other. They dont cause extra processing for every spoken command. If you are not capable of understanding the technicalities go re-read them as they were posted very well already. Use channe 1 - 2.14billion. use channel -1 through -2.14billion. Use ANY OTHER CHANNEL but zero.

Use a method that isnt inherantly lag causing. Use socket() and recv() / send(). I've done years of programming with windows sockets 1.1 and 2.0. They work well as long as you run your polling properly.

Most people in the world can come up with off topic rants having nothing to do with the factual information thats presented. Its just playing the numbers. There are always infinately more pointless rants than valid arguments. You may use as many of them as you wish.

That is where you use check digits, encryption and various forms of public / private key authentication. I can write a system that has two objects talk to each other to exchange information, TELL YOU the channel the communicate on and you would never be able to get either of them listen to a message you spoof from another source. Just because YOU dont protect YOUR script communications doesnt mean no one else does.

So im assuming that you've aquired a lisence from this original content creator to design derivitive works of their product? If not what you are doing is illegal and i have no pity for your frustrations. If you need the products to interact so well WRITE THE ENTIRE THING yourself. Dont rely on their product at all

Then please feel free to quit attempting to illegally profit off another persons work and do your own product line on your own. No matter what your choice is USING CHANNEL ZERO is bad practice and I would gladly petition people to avoid buying your product on the merits its INTENTIONALLY lag inducing and infringing on others proprietary rights.


You've already openly shown that you write crappy software by utilizing lag inducing methods and using others unique products without consent. And your method you've openly stated for doing an ugly hack job to get the products to work together involve channel zero speech which spams the masses and forces your hack job scripts to ...

screw it. The point has been made. Channel zero in all regards is wrong. In your specific example its not just technically wrong but morally wrong.

Has anyone actually run performance testing on the effect of channel 0 listens?

I don't think they're good either but I think there's a lot of hyperbole about the performance effects. As chat is user input it happens extremely slowly from a computers viewpoint, so long as there aren't dozens of listeners per av and not too much abuse of functions like llSubStringIndex it shouldn't be that bad.

I see your point, but in a well played environment, RPG and good formed commands (!) there is no confusion.

But I see that, with a lot of people, it might cause a problem. That's why I said in the first place for RP-ing environment. And there, people *know* who/what is going on and know how to react.

You describe a social hub with many people, strangers even which is a complete other situation.

In the latter situation, the channel number should be higher then 0, in the situation described by me, channel 0 is preferable.

That alone should be sufficient to allow scripts to use channel 0.

That I never thought of... Would be a good point, were it not that you would have to setup MULTIPLE gestures if you'd have more then 1 sub... (differnt subs, different channels, different gestures)
Hell of a lot of work... Using channel 0 with personalised commands (which would need some collar scripting tweaking) is much better:
* come here, my <fill in your thing>
* kneel for me, my <etc>

Added: now if they would allow some sort of REGULAR Expressions in gestures and use those RE's withing the gestures to be defined (and or even programmable rewrites), then it would be much more usefull..

Just saying in channel 0, gestures get triggered and take over.

As I read or misunderstood for collars to rebroadcast (as mentioned by someone), 2 major issues:

- the best collars out there (amethyst, or collars with the xcite script package) afaik, do not allow to repeat on channel 0 (say only).

- altering those scripts yourself isnt possible (no mod, no copy)

So I'd have to write a complete new set of the same stuff invented already just to make it happen that channel 0 for script listeners can be removed?

But at least copy/pasting and doing a minor name tweak for each sub is only a ONE TIME setup required on the part of the master for each submissive. That one-time setup means that every command you use afterwards will be just as convienent for you to type while still more friendly on the server.

But some regex processing on gestures would be GREAT. Especially since gestures are one of the few things processed client side (or should be logically) so regex would not be a system hit. I've argued for regex before.

Without regex i still say setting up multiple gestures is a trivial chore for the benifits gained.

Any scripted bot that attempts basic chat AI would be rendered useless, and there are lots of these.

Also, any device that operates as a public facility or utility that does not have clickable controls would break.

While you have good software engineering reasons for not wanting channel 0 listening for scripts, there are lots of social engineering reasons why it's essential that it stay the way it is.

Don't forget that the reason it happens at all is to allow scripted objects to easily interact with the human occupants of Second Life. It's not about what's best for the machines - it's about what's best for the people who have to use them.

Umm.. that is a valid reason TO block them. You argueing for or against banning chan zero? We dont want basic chat AI. We want object commands to be on off channels so that it doesnt spam people in the area and doesnt cause unneeded processing.

Then they need to add a clickable button that when clicked will open up a listener on some off channel keyed to the clicker. That automatically closes after a small timeout period if no message is recieved. There is still NO EXCUSE for a channel zero listener.

I've also supplied social reasons to stop all chan zero listeners. Namely and most importantly SPAM.

And using the method that is best for the machine allows a mroe enjoyable experience to ALL users. Banning channel zero listeners would not remove ANY functionality. You can still use messages on an off channel. As far as 'easier for humans' using channels is an integral part of SL. EVERY user needs to understand how to talk on an off channel. Have to learn it eventually.

That quote tells me, no offense tho, that you have no idea what it is in D/s lifestyle...It's not just a minor name tweak. Nor is it a ONE TIME setup. Thats why I brought up the RE stuff. Not to mention the number of gestures, commands that could be given.

Some calculations (without RE):
- Assume 1 sub, about 10 commands on necklace, 10+ animations/poses (= a few!) = grand total of 20 gestures/say/steering
- 2 subs, same assumptions = 40 gestures
- 3 subs, same assumptions = 60 gestures
That is NOT fun and way more work than it's worth when one can use channel 0 (sorry)

Looking at my own situation, 1 sub only (number from head, estimate, so may be off a few):
- necklace: about 15 commands, 20 build in (and with next collar probably around 30) poses
- I have some pose/anims to to use with others: bout 6 so far
That is a grand total of 41 gestures for 1 sub (and 51 with next collar)

And, as with D/s grows, it will become even more.

Now, I do understand your idea about limiting channel 0 (that's why i deliver my scripts with a notecard/voicecommand change of channel configuration), but do you understand USER FRIENDLYNESS?

Making 40+ gestures for steering 1 sub is definately not UF.

What you mean, "we", kemosabe?

What's fun in a secluded area can be grossly antisocial in a crowd. So what?

You don't need one. It's not against the law to reverse-engineer a device to build a compatible component, even under the DMCA, unless the device is using encryption to protect copyrighted materials that you're attempting to make a copy of. There was a recent decision where someone who was abusing the DMCA to keep people from reverse-engineering their toner cartridges got shot down.

Actually I meant a minor name tweak PER ITEM. And onetime setup Per Item. Which it is. I was also assuming that you had closer to 100 possible items per sub. But setting up a set of 100 items per sub is still a 1-Time setup for that sub. Its no different if you have 5 commands or 500 per sub. You set up the gestures once for that sub and after that point in time ALL 500 commands you use will always be more effecient.

To be honest the more commands you have the MORE important it is you do this as there are even more opportunities for that channel zero listener to cause needless resource use. I have a lot of understanding of what is required because earlier on in my SL career i was commisioned by a player to write a collar that supported a set of commands and way back then i still refused to use channel zero. Its still quite easy to use the commands on an off channel.

For what its worth one method i was considering using was having the Doms leash rename itself to its current owner and echo the commands. So you would still see your Doms command vocally displayed in chat (albeit in green) with the Doms name with no gesture setup required.

Problem: not all items use the same commands... Hence it wouldnt work... Problems is exponential use of gestures. No way in hell I'd start that.

We're just at totally opppisute POVs here. Lets just accept that.



For the second part: yes.

For the first part: I disagree...

Not sure how the llListener stuff is implemented at client/server

But, what would cause more lag:
llListen(0,"",NULL_KEY,"" and do handling
or
llListen(233208,"",llGetOwner(),"" // for sub
llListen(0,"",Owner,"" // Owner set by sub

I think the latter one would cast less resources for channel 0 anyway.

Anyway, as said before, we're on opposite side of the fence. Scripts SHOULD be able to listen to channel 0. But Scripters would be wise only to use it when necesary and allow it to be changed by the owner _AND_ the users should be aware of changing the channel if they dont need/want it on channel 0.

Which is IMHO the current situation. No changes needed.