MSG Commands?

[CharlesZink]

Not sure if this should be in help or scripting help. My bot won't respond to messages. Here is what I have,

Code: Select all

bind msg - test test_msg

proc test_msg {nick host handle channel testes  } {
putserv "PRIVMSG $nick :It works!"
return 0
} 

[nml375]

Your proc's argument list does not match the parameters provided by the msg binding (reading from doc/tcl-commands.doc):

(1) MSG
bind msg <flags> <command> <proc>
procname <nick> <user@host> <handle> <text>

Description: used for /msg commands. The first word of the user's
msg is the command, and everything else becomes the text argument.
Module: server

Or, even more obviously, msg's don't come through a channel; drop the "channel" argument from the list.

[CharlesZink]

Ok Thanks. What is the <user@host> for? What am I suppose to put in there?

[nml375]

You're not supposed to put something there...
The first line explains the bind command - or how to create the trigger.
The second line explains what will be executed when the binding triggers.. That is, assuming we've got this:

Code: Select all

bind msg - Hi do_hi

This creates a "/msg" binding for the word "Hi", and when it triggers it will call the proc "do_hi" with for parameters: the nickname of the user, the user@host of the user, the handle (as your bot sees it) of the user - or * if unknown, and whatever the user wrote after "Hi".

As such, your proc (do_hi) would have to accept 4 arguments (one for each parameter). The first argument will hold the first parameter (the nickname), the second argument the second parameter, etc... Each argument will then be available as a local variable with the same name within the proc.

What you call these arguments is pretty much up to you (as long as you don't use "args", as this is a special argument name for tcl), although using descriptive names usually helps writing good code. A common practice is "nick host hand text", but you could just as easily use "nick userhost handle text", or simply "n u h t". It doesn't matter, as long as you keep track of the names of the arguments/variables in your code...

In your first example, you don't make use of any of the arguments, so the names are really not important, only that you have one for each parameter (total of 4).

[raider2k]

/<- CODE

bind pub - !test test_pub
proc test_pub {nick uhost handle chan text } {

->/ CODE

when bind PUB has been specified put channel in there as an arguement being passed on ("chan" in my case). why? because a PUBlic event can be triggered in a CHANNEL, therefore channel is needed

/<- CODE

bind msg - !test test_msg
proc test_msg {nick uhost handle text } {

->/ CODE

when bind MSG has been specified do NOT put the channel arguement in there, as the bind type already says -> its a MSG type which can ONLY be triggered in a msg/query-window, theres NO channel, so NO channel arguement being passed on either.