script chat channel

I want to make my object capable of changing its script-chat channel.

I want the owners to specify a channel for the script to chat on, but I am not sure how to do this...

aka; The default CHANNEL is 45678, I want the owner to be able to say channel=23546 and it would use this channel from now on.

The reason is that I will have a few people using the same object near one another....

does anyone here know how I do this?

well - you're initially listening on 45678

you define the channel in the global scope

integer channel = 45678;
integer listen_handler;

default{

state entry{

listen_handler = llListen(channel, "", llGetOwner(), "");

}

listen(integer channel, string name, key ID, string message)
{
    integer split = llSubStringIndex(message, "=");
    
    // If we found an equal-sign and the left part of the message is 
    // channel, change the channel to the right part of the message

    if(split != -1 && llGetSubString(message, 0, split - 1) == "channel")
    {
        channel = (integer)llGetSubString(message, split + 1, -1);
        llListenRemove(listen_handler);
        listen_handler = llListen(channel, "", llGetOwner(), "");
    }
    else
    {
        // do some other stuff 
    }

}

on_rez(integer param)
{
    llResetScript();
}

}

Didn't test this though... but it should work...

The easiest solution would be for each object to only listen to its owner.

Then you need not worry about all of them using the same channel.

llListen(Channel,"",llGetOwner(),"";

should accomplish this. though you will have to cancel/restart the listen on owner change or on rez to make sure it listens for the proper person.

duh...
(I'm actually telling the listener to only listen to the Owner... all the rest is just a waste of time... maaaaan...

Haruki--
For the OP's issue, yes, the ability to change the channel, when only listening to the Owner, is a waste; however, in a different scenario, the ability to change the channel may be desired.

For instance:
Suppose we have multiple objects using the same communication Chat Channel. Should the AV be using another object that uses the same Chat Channel, there could be potential command conflicts. Having the ability to change the communication channel can alievate this type of conflict.

Note:
I recommend NOT to allow the Chat Channel being changed to Channel Zero in order to keep it out of open chat communication.

Now I got confused... So... I am to add what to my script? To let the owner change the channel... and no... anyone should be able to interact with it... only I want noone but the owner to be able to change the channel... *smile*

There are a number of solutions.

One is to have a chat command for the owner to set the channel. However, if he/she goofs, problem! I recommend against this.

Another way is to use notecard configuration. See the Wiki for examples! Note that it's not trivial, but if you script much, you'll want to learn how and have this as a normal tool in your kit.

Yet another way is to put the chat channel in the object's description, and use llGetObjectDesc() to get that and cast to integer. This is the easiest solution, and works fine when there's only one configurable item, and it's the kind of item where description isn't important for other reasons. The biggest problem with this approach is the object isn't notified that the description changed, so there needs to be SOME event where it checks it. E.g., on rez, or touch, or whatever.

Of course, after changing the channel variable, you need to cancel the old listen and start a new one. The easiest way to do this is to change state. (Changing state always cancels all listens.) For example:

integer CommandChannel = 2345;

...

state Reactivate
{
    state_entry() {
        state Active;
    }
}

state Active
{
    state_entry() {
        llListen(....)
    }
    listen(CommandChannel, ...) {
        ....
    }

    // on touch by owner, check for a new chat channel in the description
    touch(integer tot) {
        if (llDetectedKey() == llGetOwner()) {
            integer chan = llGetObjectDesc();
            if (chan == 0) {
                return; // probably no description, so let's not use the open channel!
            }
            if (chan != CommandChannel) {
                CommandChannel = chan;
                state Reactivate;
            }
        }
    }
}

BTW, to read the code while bbcode isn't working, just hit "Reply" to this message.

BTW, Haruki, I like to use the following simple code for picking out a command and arguments. Not ingame now, so beware typos.

// parse str into components separated by '='

    list terms = llParseStringKeepNulls(str, ["="], []);
    string command = llList2String(terms, 0);
    
    if (command == "foo") {
        integer fooval = llList2Integer(terms, 1);
        ...
    } else if (command == "bar") {
        ...
    }

Or a related thing: separating into blank-separated words:

// parse str into space-separated words; eat consecutive spaces

    list words = llParseString2List(str, [" "], []);
    string command = llList2String(words, 0);
    
    if (command == "foo") {
        integer fooval = llList2Integer(words, 1);
        ...
    } else if (command == "bar") {
        ...
    }

Cheers
Jeff

While there are times when this is convenient, my intuition says it should be faster to save the listener channel in a global and use llListenRemove to remove it. State changes commonly have a lot of overhead. It's also, in my opinion, easier to write and maintain than adding a state whose sole purpose is to close a listener.

Or is this not the case? I haven't actually tested it.

Have you tested this? The way I read the documentation, this won't work. If you pass it
"foo bar"
then the resulting list will be ["foo", " ", "bar"].

If there were two spaces between the two, you'd get ["foo", " ", " ", "bar"].

Ah, I think I goofed the words part. Will check and post correction later, sorry!

Good point that changing state might not be as efficient. However, how often do you expect the state change to happen? The key to writing scalable code is counting how many times something happens. In this case, it's so rare that optimization is insignificant, and the design/maintenance issues take precedence.

I use the state change a lot and find it very maintainable. But it all depends; there are a number of cases where I do NOT want a state change for changing listens because I'm using the states for other purposes.

Note that if you have state changes, you have to reissue the listens anyway. So, I find it's best to set up the listen in the state entry and do it once correctly and let that logic do its work. I find it unfortunate that saying "state foo" from within state foo is a no-op. I wish it would cause the exit and entry handlers to run again. Thus the re-entry state, which shouldn't be necessary.

Jeff,

G-R-E-A-T!!! It's much simpler than the code I use - and it's actually pretty logic.
Thanks for pointing that one out to me!

/me waves

Fixed the mistakes above. Thanks again, Kidd!

& YW, Haruki, waving back!

One other thing I should have mentioned in my previous post; when I allow changing the chat channel, I have the object llOwnerSay() the chat channel upon rez or attach, something like the following for an attachment:

Widget attached. Type '/5 cmd help' for help.

That way the owner can always find out the channel the object is expecting to receive commands.

I have an object whose chat channel is configured in the object name. "Chat Chat Revolution @ ch 0"

Good idea or bad idea?

Day...that depends on the security you want on it. I don't see any problem with setting the chat-channel in the name of an object, so long as you don't mind that a lot of people will know it. Additionally, since security should involve a lot more than just simple channeling...I wouldn't see any problem at all in revealing a chat-channel.

I forgot to mention, though, it doesn't check repeatedly whether the object's name has changed. Instead, you have to touch or reattach it for the change to take effect. That's one thing that makes me reconsider.