Alternate channel chat

There's a thread in scripting about this and there have been a few here but here's my take.

Add the ability to use / and a channel number to chat without animation on that channel rather than 0.

With no channel indicated / would act as it does now just to stop the typing animation.

Examples:

/100 open sesame!
sends "open sesame!" on channel 100 without typing anim

/clap
chats "/clap" on channel 0 and if your gesture is setup claps for you

Now one other that would be super special nice would be to have
/IM Upshaw Underhill Hiya Upshaw!
which of course would instant message me "Hiya Upshaw!"


UU

Oobity Oobity Oobity!

I can't think of a THING this would break. If anyone out there has 'gestures' (a stupid thing to call /commands) that are EXCLUSIVELY numbers, they just should have to change to fit the new code. Evil people, using NUMBERS in /commands.

(Whomever thought up /commands as being exclusively emotes should be shot too.)

I support this feature.

I like the idea, but I don't want the hassle of typing:

/1 calc 2 + 2

I want to just type:

/calc 2 + 2

However, a configurable default channel would make this idea perfect.

It's intuitively expected that command line commands should start with /<command>

The extra keystroke or two is well worth the:
- Extended functionality
- Extended Security
- Backwards compatibility

Eh, now that I've thought about it, it's going to be a PITA to type

/999998 !return

in order to avoid the commonly used 1-9 channels.

Can't we just have a configureable checkbox that says / == channel X?

I've wanted this since practically my first day! I vote yes!

And though it would be a bit more work I would dearly love llWhisperTo (key avater, text)

or something like it so I can have scripts communicate information back to me privately.

kk

llInstantMessage(llGetOwner(),"Heya there kyle, this is your script talkin to ya";

It has a semi significant delay built into it ... maybe. It used to show up as text, now it gets its own box I think.

Here's something that will do just that.

key owner;
integer channel=0;
string msg;
default
{
    state_entry()
    {
        owner=llGetOwner();
        llListen(0, "", owner, "");
    }

    listen(integer channel, string name, key id, string message)
    {
        if(llGetSubString(message, 0, 2) == "/s ")
        {
            msg = llGetSubString(message, 3, llStringLength(message) - 1);
            llSay(channel, msg);
        }
        if(llGetSubString(message, 0, 3) == "/sh ")
        {
            msg = llGetSubString(message, 4, llStringLength(message) - 1);
            llShout(channel, msg);
        }
        if(llGetSubString(message, 0, 3) == "/wh ")
        {
            msg = llGetSubString(message, 4, llStringLength(message) - 1);
            llWhisper(channel, msg);
        }
        if(llGetSubString(message, 0, 5) == "/chan ")
        {
            msg = llGetSubString(message, 6, llStringLength(message) - 1);            
            channel=(integer)msg;
            llSay(0, "Channel: " + msg);
        }
        if(llGetSubString(message, 0, 5) == "/name ")
        {
            msg = llGetSubString(message, 6, llStringLength(message) - 1); 
            llSetObjectName(msg);
            llSay(0, "Name: " + msg);
        }        
    }
}

/s - says the message
/sh - shouts it
/wh - whispers it
/chan - change the channel
/name - changes the name of the object




What about a channel that only sends to the owner. Like -1 or something. So those who are scripting don't have to flood channel 0 and disrupting everyone.

With "/#" you not only have to remember the script command but what channel it listens on. While I think arbitrary channel speaking would be nice, there should be a default for just "/text". As for backwards compatability, process gestures first, which is what most people arguing against this bring up.

From a previous thread, my suggested processing order to minimize headaches.
1. If line doesn't begin with /, process as current method.
2. If line begins with a mapped gesture, process as current method.
3. If line begins with //, process as current "no typing" method.
4. Otherwise, output text to channel 1.

I seem to remember having a 5th step in there, but I can't remember what it was. Doing /# could easily be added into that parse order. Basically it doesn't change the current behavior except to change the fall-through case from "output on 0" to "output on 1".

As many scripted items do already to avoid confusion and extra manual filtering, rather than caring what you chat you could make your interface do different things from any message on a particular channel. ie. chatting '/2 open' will make your locked door open and so would '/2 close'

The channel number would do the work rather than the message. Not the way I'd normally program it but just one of many possibilities.

Considering the number of items people will want to have make use of this and again considering the security issue of having listeners know where to listen I have to argue for for ease of configuration and as near infinite choice as possible.

/ not just can but *should* still act as it does currently. You could even chain gesture commands to alternate channel chats but havin the gesture issue something different than what you initially typed.

UU

This was talked about in the chat with Cory a couple nights ago. He mentioned they are talking about it. I wonder what kind of implementation is being considered.

I like Cienna's logic best.

I'd also like to set in preferences what our "private" chat channel is so that we could execute commands without people "sniffing" them.

But we'd probably also want an llGetPrivateChannel() command in our scripts, so that they are easy to trade.

But if all of that is too complicated, I'd still be more than happy to suffice with one fixed channel for everyone (ie the example given so far, channel 1)

I've always maintained that I think just making all chat starting with a slash (/) automatically go to channel 1 and leaving it at that would be the cleanest and most logical solution. Yes, it breaks a lot of things, but it's not a lot of work to fix them. Moreover, it puts things the way they should have been from the beginning: simple, clean and consistent.

Establishing a standard "talking to scripts" channel is a good idea. Who wants to hear that they have to communicate with their new boat or gun on channel 839217154 only?

If you're really into customization, you could specify additional escape characters to correspond to different channels in Preferences. Say, chat starting with the character '!' goes to channel 151381518 or whatever the user specifies.

For the rest of us, however, I think the slash character and channel 1 are the best choices here.

I don't really have an opinion on whether or not /chat goes to channel 1, but I strongly support chatting to arbitrary channels. Personally I have no problem remembering what chat channels my different scripts use, and I certainly don't place them all on chat channel 1, that would result in too much cross talk and congestion (I don't want all my objects to llDie when I say 'die' on channel 1, phht!).

The moral of the story is that I want
/# text
to chat text on the specified channel #

I hope you lindens are seeing this thread! There is obviously sufficient demand.

Since most of us here speak "programming logic", here's pseudocode to explain how I'd do it:

event_chat_begin(){
  ch = get_first_character();
  if(ch == "/"){
    text = gather_text_to_EOL();
    if(text[0] == "/"){ // double-slash override
      send_to_channel(0,text);
      if(check_for_gestures(ch + text)){
        process_gestures(ch + text);
      }
    }else{
      first_word = get_first_word(text);
      if(is_number(first_word)){
        num = string_to_integer(first_word);
        new_text = delete_first_word_and_space(text);
        send_to_channel(num, new_text);
      }else{
        if(check_for_gestures(ch + first_word)){
          process_gestures(ch + first_word);
        }
        num = get_preferences(SCRIPT_CHANNEL);      
        send_to_channel(num,ch + text);
      }
    }
  }else{ // normal chat
    do_typing_animation();
    play_typing_sound();
    text = gather_text_to_EOL();
    if(check_for_gestures(ch + text)){
      process_gestures(ch + text);
    }
    send_to_channel(0,ch + text);
  }
}

Now, what this allows:

- You can issue script commands silenty or publically:

/calc 2+2 (shows as "calc 2+2" on my SCRIPT_CHANNEL)
//calc 2+2 (show as "/calc 2+2" on channel 0)

- You can issue gestures silently or publically:

/clap (performs gesture, and shows "/clap" on my SCRIPT_CHANNEL)
//clap (performs gesture and shows "/clap" in channel 0)
I dunno. (performs gesture and displays "I dunno." in channel 0)

- You can send your text to any channel:
/789 /calc 2+2 (shows as "/calc 2+2" on channel 789)
/789 calc 2+2 (show as "calc 2+2" on channel 789)

- You can still avoid the keyboard animation and sound

//Boo! (show as "/Boo!" on channel 0)

Please feel free to copy and modify the above pseudocode to express your opinion on how it should be done.

[
Edit: changed so first-token gestures also get passed to script channel (in case you want to do something with them)

- Say I wanted a script in background that maintains a backflip-counter for silly reasons

/flip (performs backflip, shows as "/flip" on my SCRIPT_CHANNEL)
]