| View previous topic :: View next topic |
| Author |
Message |
willyw
Revered One
Joined: 15 Jan 2009
Posts: 1175
|
 Posted: Sat Oct 17, 2009 12:46 pm Post subject: How to make a script selectable multi-channel |
 |
|
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_archive.tcl?mode=download&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_archive.tcl?mode=download&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 |
|
| Back to top |
|
 |
willyw
Revered One
Joined: 15 Jan 2009
Posts: 1175
|
| Posted: Mon Oct 19, 2009 10:58 am Post subject: |
|
|
| No replies? |
|
| Back to top |
|
|
arfer
Master
Joined: 26 Nov 2004
Posts: 436
Location: Manchester, UK
|
| Posted: Mon Oct 19, 2009 3:45 pm Post subject: |
|
|
| Code: |
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: |
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.
_________________
I must have had nothing to do |
|
| Back to top |
|
|
willyw
Revered One
Joined: 15 Jan 2009
Posts: 1175
|
| Posted: Tue Oct 20, 2009 11:59 am Post subject: |
|
|
Thanks for the reply, and examples.
| arfer wrote: |
| Code: |
...
if {[channel get $chan uflag]} {
# code here
}
return 0
}
|
OR
| Code: |
...
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
| Quote: |
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...... |
|
| Back to top |
|
|
arfer
Master
Joined: 26 Nov 2004
Posts: 436
Location: Manchester, UK
|
| Posted: Tue Oct 20, 2009 12:51 pm Post subject: |
|
|
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.
_________________
I must have had nothing to do |
|
| Back to top |
|
|
willyw
Revered One
Joined: 15 Jan 2009
Posts: 1175
|
| Posted: Tue Oct 20, 2009 7:44 pm Post subject: |
|
|
| arfer wrote: | 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.
| Quote: |
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.
| Quote: |
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.
| Quote: |
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. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
