LlGetChannel

From Second Life Wiki
Revision as of 10:54, 19 April 2007 by Xoren Raymaker (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

This article is a feature request

Freedom of speech is a very important thing, both in real life and in second life. In second life, objects can speak. They can speak only to their owner, speak over instant message to any object or they can even llWhisper, llSay or llShout to a channel of choice. This is where the problem starts to form: With a constantly growing number of objects containing scripts, the number of used channels is climbing fast. The chance that two objects (perhaps two copies of the same thing) use the same channel to communicate is getting bigger and bigger. If such a thing would happen, the chance of undefined behavior of objects would be very realistic. I would consider such undefined behavior to be a bug and i personally see any bug as a way for certain people to bring the grid to it's knees or do other bad things..

A way to prevent these problems is to limit the choice of channel to use, by enforcing a rule. We could allow every object free use of channels 0-9999. Channels above 9999 would then not be free to choose, but would have to be requested, so the server may ensure that the channel is not used by any other objects in the grid. The way to request such a channel for usage is to use the function llGetChannel() which returns an integer, identifying the channel.

The object that requested a channel, becomes owner of this channel and must decide which objects may or may not communicate on it. Therefor a few other functions would need to be added. Other objects could use a new function like llRequestChannelUsage(integer channel), upon which an event would be fired in the script of the channel owner. This could be perhaps a channel_request(integer channel, key id) event and the owner could then llAllowChannelUsage(integer channel, key id) or llDenyChannelUsage(integer channel, key id). The requesting object would then receive this answer through a new channel_permission(integer channel, bool allowed) event.

This is just an idea and it might still need some thinking over, but i think the idea is clear enough.


See also: