Spam

[asdd1]

as

[Sir_Fz]

Try replacing the || with && at this line

Code: Select all

if {![isop $nick $pvchan2] || ![isvoice $nick $pvchan2]} {

and this line

Code: Select all

if {![ischanban $pvmask2 $pvchan2] || [botisop $pvchan2]} {

[asdd1]

No changes ;( It's same doesn't detect.

[nml375]

Think you could show a live example of when it did not detect the spam?

[speechles]

Code: Select all

if {[regexp -nocase "#" $text] || [regexp -nocase "join" $text] || [regexp -nocase "channel" $text] || [regexp -nocase "klik" $text] || [regexp -nocase "www" $text] || [regexp -nocase "pussy" $text] || [regexp -nocase "http" $text] || [regexp -nocase "server" $text] || [regexp -nocase "click" $text] > 0} {

Here is your problem, and it isn't those or's (||) this time. It's the fact you have that greater than sign and a 0 on the end. Matter of fact, why do you use regexp to do this? Why not a simple lsearch, it would save you time, and the bot wouldn't need to cycle through all those regexp's.

Code: Select all

#Antispam With cycle command

# -> bantime
set bantime 30

# -> banned words
set bannedwords "# join channel klik www pussy http"

# -> minutes bot should cycle channels
set timecycle 1



# SCRIPT BEGINS
bind msgm - "*" pv_kick2

# kick
proc pv_kick2 {nick uhost hand text} {
	foreach word [split $text] {
		if {[lsearch -exact [split [$::bannedwords]]  $word}{
			set banthisguy 1
		}
	}
	if {[info exists $banthisguy]} {
		foreach pvchan2 [channels] {
		if {![isop $nick $pvchan2] && ![isvoice $nick $pvchan2] && [onchan $nick $pvchan2]} { 
			set pvmask2 "*!*$uhost"
			if {![ischanban $pvmask2 $pvchan2] && [botisop $pvchan2]} {
				set pvkickmsg2 "\002Msg Spam 30min. Ban!" 
				putquick "kick $pvchan2 $nick :$pvkickmsg2"
				putquick "mode $pvchan2 +b $pvmask2 $::bantime"
               
			}
		}
	}
}

# cycle
timer $timecycle part_chan
proc part_chan {} {
	global timecycle
	foreach chancycle [channels] {
		putserv "PART $chancycle :\037Spam Check!\037"
	}
	timer $timecycle part_chan
}
# SCRIPT ENDS

This should work better for ya

[asdd1]

as

[nml375]

Code: Select all

if {[regexp -nocase "#" $text] || [regexp -nocase "join" $text] || [regexp -nocase "channel" $text] || [regexp -nocase "klik" $text] || [regexp -nocase "www" $text] || [regexp -nocase "pussy" $text] || [regexp -nocase "http" $text] || [regexp -nocase "server" $text] || [regexp -nocase "click" $text] > 0} {

Here is your problem, and it isn't those or's (||) this time. It's the fact you have that greater than sign and a 0 on the end. Matter of fact, why do you use regexp to do this? Why not a simple lsearch, it would save you time, and the bot wouldn't need to cycle through all those regexp's. ...

Although this would appear somewhat misleading, it is not causing the script to fail. The simple form of regexp returns 1 for a match, and 0 for no match. In tcl, 1 is true while 0 is false, hence "[regexp pattern string]" and "[regexp pattern string] > 0" has the same logics-table. Hence either works...

I do agree that regexp is overkill here, string match would make a far better replacement. I'm not so sure lsearch would be an option however...

Edit:
Oh, and how on earth do you expect "if {[lsearch -exact [split [$::bannedwords]] $text]}{" to work? Remember that $text would be the pattern here, and -exact implies there must be an exact match of $text and one of the words in $::bannedwords. Unless the spam is a single word, this test would miss it.

[speechles]

Although this would appear somewhat misleading, it is not causing the script to fail. The simple form of regexp returns 1 for a match, and 0 for no match. In tcl, 1 is true while 0 is false, hence "[regexp pattern string]" and "[regexp pattern string] > 0" has the same logics-table. Hence either works...

But if we compound those or's and then provide a single evaluation of greater than comparing to zero. Wont the interpreter instead, do as every other language would, and using a binary-OR operation on each of the results, which is basically an x0r... 1 to 0 to 1 to 0 to 1 to 0 to 1 to 0 and then is it greater than 0? no it equals it. This is how many programming languages behave without strict use of parenthesis to stop it.

* Parts: gather-lv (~gather@62.84.24.156) (Spam Check!)
* Joins: gather-lv (~gather@62.84.24.156)
* ChanServ sets mode: +o gather-lv

Here is your problem. The bot is not getting opped fast enough. It is spammed before it is opped. It will not do anything when spammed if not opped.

[asdd1]

asd

[speechles]

Code: Select all

#Antispam With cycle command

# -> bantime
set bantime 30

# -> banned words
set bannedwords "# join channel klik www pussy http"

# -> minutes bot should cycle channels
set timecycle 1



# SCRIPT BEGINS
bind msgm - "*" pv_kick2

# kick
proc pv_kick2 {nick uhost hand text} {
   foreach word [split $text] {
      if {[lsearch -nocase -exact [split [$::bannedwords]]  $word]}{
         set banthisguy 1
      }
   }
   if {[info exists $banthisguy]} {
      foreach pvchan2 [channels] {
      if {![isop $nick $pvchan2] && ![isvoice $nick $pvchan2] && [onchan $nick $pvchan2]} {
         set pvmask2 "*!*$uhost"
         #set pvmask "*!*@[lindex [split $uhost @] 1]"
         if {![ischanban $pvmask2 $pvchan2]} {
            set pvkickmsg2 "\002Msg Spam 30min. Ban!"
            newchanban $pvchan2 $pvmask2 "Anti-Spam" $::pvkickmsg2 "%0d0h30m"
               
         }
      }
   }
}

# cycle
timer $timecycle part_chan
proc part_chan {} {
   global timecycle
   foreach chancycle [channels] {
      putserv "PART $chancycle :\037Spam Check!\037"
   }
   timer $timecycle part_chan
}
# SCRIPT ENDS

Changed the part which checks bot is opped. If the ban isn't set in the channel, the bot will set it within its internal ban list, once chanserv ops the bot, bot will ban the spammer with your message. The ban will last 30 minutes per your message.

[nml375]

Although this would appear somewhat misleading, it is not causing the script to fail. The simple form of regexp returns 1 for a match, and 0 for no match. In tcl, 1 is true while 0 is false, hence "[regexp pattern string]" and "[regexp pattern string] > 0" has the same logics-table. Hence either works...

But if we compound those or's and then provide a single evaluation of greater than comparing to zero. Wont the interpreter instead, do as every other language would, and using a binary-OR operation on each of the results, which is basically an x0r... 1 to 0 to 1 to 0 to 1 to 0 to 1 to 0 and then is it greater than 0? no it equals it. This is how many programming languages behave without strict use of parenthesis to stop it.

Binary OR is not the same as XOR (exclusive or)... The fundamental difference is when both expr1 and expr2 is true, with OR, this evaluates to True, while for XOR this evaluates to False. No language I've ever used does any kind of "magic" switch to XOR from OR...

Also, remember that tcl uses "lazy evaluation" of ||, &&, and ?: operations, meaning that as soon as there is no use for further tests, it'll skip on (ie. if the first test is true, and we are using ||, there is no need to do the second test since this can't change the outcome of it all...). Finally, >, <, <=, and >= has a far higher priority than ||...

* Parts: gather-lv (~gather@62.84.24.156) (Spam Check!)
* Joins: gather-lv (~gather@62.84.24.156)
* ChanServ sets mode: +o gather-lv

Here is your problem. The bot is not getting opped fast enough. It is spammed before it is opped. It will not do anything when spammed if not opped.

How do you gather that from this limited output? (that the bot is opped too slow) All I see is the bot parting (stating the custom reason "Spam Check!", rejoining, and being opped by chanserv... I do agree that the bot will do nothing if not opped, but I can see other reasons for this happening aswell..

[asdd1]

asd

[nml375]

Same, no changes.

To check i'm using this mIRC Script:

Code: Select all

on 1:JOIN:#:/msg $nick join #test

<05.07 19:01:00> <gather-lv> [19:01] Tcl error [pv_kick2]: extra characters after close-brace
<05.07 19:01:00> <gather-lv> [19:01] [user01!test@84.237.152.149] join #test

Does your testing-client have ops or voice on the channels?
(seems speech' made a slight typo in his script, but I'm sure he'll post a fix shortly

[asdd1]

Nope.

[asdd1]

asd