Talk:LlGetChannel

Reasons why this feature request shouldn't be implemented.

1. Would break existing content.
2. Would require hundreds if not thousands of developer hours to code, debug and maintain.
3. Easily griefable. Just open a channel and lock it.
4. Collsions are rare.
   • If two objects are communicating on random channels, the probability of a collision is 2^-32
   • Sims lag horribly when you have several thousand listens open, being that there are 2³² channels, stumbling upon a used channel is rare.

Ways to mitigate collisions

• Your script can do owner and object name checks to validate who is speaking, allowing for the filtering of collisions.
• Your script can add a header to the message that gives the listener added information that it can use to filter out collisions.
• A protocol can be designed to move the channel it's communicating on when collisions occur.

Since this feature-request would break content and there are already methods for mitigating collisions, I cannot support this feature suggestion. --Strife Onizuka 18:36, 19 April 2007 (PDT)

---

I agree. If it breaks a little existing content, then we might think about implementing it, but if a lot of content would become broken, then it would need to be a very important update. Also the point about griefing you name, is a very good argument.

With this article i was merely trying to put the current method to discussion, as i think it isn't very intuitive how to use this in a secure way. Of cause one would need to use a header and one could even implement encryption and/or compression. But computers are dumb things that only do what we tell them to. If we know all facets of a computer program, we can predict it's entire flow. Unless (and here is where i am getting near my point) something unpredictable, or at least hard to predict, comes along. Because these situations would not (or at least should not) be hard to be made predictable, i do not like depending on something that *might* break because some people found a small chance of collision enough to depend on.

I am a professional computer programmer. If i tell my boss something i made *could* break if another copy is being run on a nearby computer, then i would have something to explain. It might be very well tolerated if we were in a hurry to produce something that would work (mostly), but we on second life are in no hurry, i believe, to make things the way they should be. To think about it and make things right and stable, in stead of something that *might* break, is hard to debug if it breaks and is difficult to maintain in the future.

Also, your solutions do not entirely satisfy me. The two objects in the given example would both have prims of the same name, owner and creator. Indeed, they would have a different key, but how would you tell each one which key to listen to? Of cause there are ways around this as well, and even simple ways by asking the user during initialization phase which key to listen to, but this would make it more difficult to set up, more sensitive to wrong user input and the script would need to have quite some extra code to get this setup done.

So, concluding: yes, you are right in saying it's not as easy as i perhaps pictured it in the article, but i do think it still deserves (and needs) some thinking over. Although, i admit, it is not a very high priority request. -- Xoren Raymaker 26 april, 2007

(use -- ~~~~ to sign your name with the date)

This would break a lot of content.

In your example of having two identical objects, you would still need to configure it, the configuration point would be at the channel authentication phase instead. It's the same problem in both situations just shifted to a different end of the communications. In RL there is software that only allows for a single instance, also there is software with networked licenses that only allow for so many copies to run on a network.

The requirement for scripters to make their communications robust I would have to say is one of the pills of LSL that can be hard for programmers to swallow. There are a number of aspects of LSL that make transitioning to LSL from programming difficult.

It's always good to examine current structures. -- Strife Onizuka 14:57, 26 April 2007 (PDT)