How to make a script selectable multi-channel

[willyw]

Hello,

Not sure how to classify myself.... I can do basic scripts, and have fun figuring out how to get them to work.
Beginner?


I'd like to learn a good method of making scripts multi-channel. NOT all channels that the bot is on though - but be able to have the script operate in some channels that I select.

An example of a script that I'd like to modify to become multi-channel, is:
http://www.egghelp.org/cgi-bin/tcl_arch ... oad&id=821
It is named count.tcl by caesar. v.0.1 11/04/2003

No doubt there are other scripts out there, that do what this one does, and are already multi-channel. But I want to learn a good method, and this script is not too complicated. And, I would like a nice multi-channel counter script (maintain seperate join counts on a per channel basis) anyway.
I thought it might be a good place to start.

I found one method, somewhere, that set channels by name, in an array.
It just didn't feel right.

But elsewhere, - - in this script: http://www.egghelp.org/cgi-bin/tcl_arch ... oad&id=259
peak.tcl 1.8 25/07/2004 FireEgl
I found that he does it with setudef and uses:
if {[lsearch -exact [channel info $chan] {+peak}] != -1}

When I also found that method in the google script by incith ( That is a GREAT script! ) , I was encouraged.

First question: Before I waste a lot of time studying it, and trying to learn to implement this method - is this a good method to learn?

Next question: Using the search engine here in the forum, I didn't find any posts that addressed this. If you have anything, anywhere to direct me to, for more reading on this, please post a link.

Last: Any other comments to get me going in the right direction will be appreciated.

Thanks

[willyw]

No replies?

[arfer]

Code: Select all

setudef flag uflag

bind PUB - !test1 pTestProc1

proc pTestProc1 {nick uhost hand chan text} {
    if {[channel get $chan uflag]} {
        # code here
    }
    return 0
}

OR

Code: Select all

set vTestChans "#chan1 #chan2 #chan3"

bind PUB - !test2 pTestProc2

proc pTestProc2 {nick uhost hand chan text} {
    global vTestChans
    if {[lsearch -exact [split [string tolower $vTestChans]] [string tolower $chan]] != -1} {
        # code here
    }
    return 0
}

The first example requires '.chanset #channelname +uflag' in the bot's partyline for each channel you require the script to function on.

The second example could be made a little simpler by using the -nocase option for the lsearch command, but this option was only made available on Tcl 8.5 therefore would not work for older installations.

The most likely reason for the lack of response is that you pretty much answered your own question. It is always a good idea to study other scripts.

[willyw]

Thanks for the reply, and examples.

Code: Select all

...
    if {[channel get $chan uflag]} {
        # code here
    }
    return 0
}

OR

Code: Select all

...
    if {[lsearch -exact [split [string tolower $vTestChans]] [string tolower $chan]] != -1}
 {
        # code here
    }
    return 0
}

The first example requires '.chanset #channelname +uflag' in the bot's partyline for each channel you require the script to function on.

The second example could be made a little simpler by using the -nocase option for the lsearch command, but this option was only made available on Tcl 8.5 therefore would not work for older installations.

If one style is just as good and acceptable as the other, I'm going with the first one then. Where the flag is set via .chanset, etc. For no other reason than personal preference.

You did cause me to go looking in tcl-commands.doc though.
I found the command you are using to check for the flag - channel get.
Interesting.

The command I'd found used in other scripts, was like this:
if {([lsearch -exact [channel info $chan] {+theflag}] != -1)} {

The channel info command.

Is there a reason to choose one method (command) vs. the other? or just personal preference?

Also, and again in the interest of learning good practice:
I return 0 in there.
What is the reasoning behind that? ... thanks

The most likely reason for the lack of response is that you pretty much answered your own question. It is always a good idea to study other scripts.

But it is reassuring to get feedback and an opinion from someone 'live', that didn't write the script that I was examining.
Thank you, ... I appreciate your time.

By the way, the I believe I got my multi-channel (selectable chans) join counter script working!
Of course, now I've thought of something I want to modify in it......

[arfer]

My preference is also to set a user defined channel flag. It permits you you to switch a script on/off in any channel without changing a script's configuration and rehashing.

As for different methods/syntax/commands achieving the same result. I would say such things are commonplace in most if not all languages. I would tend to choose the simplest, though sometimes I might have a favourite without there necessarily being an obvious reason. I suppose 'elegance' also creeps into it somewhere. The most important issue is that when you look at a piece of code you previously wrote, you can instantly recognise what it is doing.

It is good practice for a proc to return a value when the code has finished execution, even if the return value is unused. I generally use 'return 0' though on many occasions you will see simply 'return' or even 'return 1'. There is one important factor to consider. For some bind procs, the return value may be crucial. These can be found in tcl-commands.html under the heading 11 Bind b Return values. ALWAYS take account of these as not doing so can lead to unexpected results.

[willyw]

My preference is also to set a user defined channel flag. It permits you you to switch a script on/off in any channel without changing a script's configuration and rehashing.

Good.
Thanks.

As for different methods/syntax/commands achieving the same result. I would say such things are commonplace in most if not all languages. I would tend to choose the simplest, though sometimes I might have a favourite without there necessarily being an obvious reason. I suppose 'elegance' also creeps into it somewhere. The most important issue is that when you look at a piece of code you previously wrote, you can instantly recognise what it is doing.

oh. ok.
I guess I was more thinking of the "unknown"... that if I do it this way instead of that way, and both seem to work now.... then later on down the road it returns to bite me in the butt because I didn't know any better, as to which way to do it. If and when it happens, I'll just have to deal with it then.

Thanks for your explanation and advice.

It is good practice for a proc to return a value when the code has finished execution, even if the return value is unused.

ok.

I generally use 'return 0' though on many occasions you will see simply 'return' or even 'return 1'. There is one important factor to consider. For some bind procs, the return value may be crucial. These can be found in tcl-commands.html under the heading 11 Bind b Return values. ALWAYS take account of these as not doing so can lead to unexpected results.

I've run afoul of this, I believe. Logging ceased. As I recall, return 1 did it.
I was wondering if this was what you were going to say, as the reason, when I asked.
I was thinking you might say that return 0 is a general good idea, when possible.
Thanks for your comments.


Duly armed with this info, and some ideas to see if I can work out - I shall return to the drawing board.