On Join Auto Voice

[UnderDC]

on 1:join:#wwwarez:{
if ([WWW]* iswm $nick) {
mode $chan +v $nick
}
}

How would i write that Mirc Script into TCL Windrop language?
Thanks for any help!

[caesar]

what means "iswm"?

[ppslim]

"iswm" is for "is wild match"

Code: Select all

bind join - "*" join:warez
proc join:warez {nick uh hand chan} {
  if {($chan == "#wwwarez") && ([string match "WWW*" $nick])} {
    putserv "MODE $chan +v $nick"
  }
}

[caesar]

Oh. Thanks for the fill in.

[UnderDC]

bind join - "*" join:#wwwarez
proc join:#wwwarez {nick uh hand chan} {
if {($chan == "#wwwarez") && ([string match "[WWW]*" $nick])} {
putserv "MODE $chan +v $nick"
}
}

I gues it would be something like that, the bots are called [WWW]-XDCC***

I tryed that one and didn´t worked
any clue of whats wrong?

[Papillon]

Code: Select all

bind join - "*" join:#wwwarez 
proc join:#wwwarez {nick uh hand chan} { 
if {([string tolower $chan] == "#wwwarez") && ([string match "\[WWW\]*" $nick])} { 
putserv "MODE $chan +v $nick" 
} 
}

try this....
when using string match you have to escape special characters, [] are some of those characters, by adding the \ infront yoy tell the scrpit that the following character is to be considered as any other character...
hope this make sence... I'm t tired to rewrite it :p

[De Kus]

why always a * bind? isnt a modular check not faster than a tcl if? by the way this way its only one if... i know, it doesnt matter at all, but teoretically it saves CPU time . and i would recommed using pushmode to make the bot aviable to put multible modes into one line.

Code: Select all

bind join - "#wwwarez \[WWW\]*" warezjoinvoice

proc warezjoinvoice {nick host hand chan} {
  pushmode $chan +v $nick
}

btw. tcl-commds.doc is a nice thing to read... not to say RTFM

[ppslim]

It saves so little processing time, it's not worth it. Unless you are designing a bot, capable of running allmost every script under the sun.

On top, the reason my all my script code designed with the if?

It's far simpler to understand IF logic within a Tcl script, than it is to understand how to wrote the bind. more so for a new user.

[Papillon]

why always a * bind? isnt a modular check not faster than a tcl if? by the way this way its only one if... i know, it doesnt matter at all, but teoretically it saves CPU time . and i would recommed using pushmode to make the bot aviable to put multible modes into one line.
Code:
bind join - "#wwwarez \[WWW\]*" warezjoinvoice

proc warezjoinvoice {nick host hand chan} {
pushmode $chan +v $nick
}


btw. tcl-commds.doc is a nice thing to read... not to say RTFM

regarding the pushmode...

pushmode <channel> <mode> [arg]
sends out a channel mode change (ex: pushmode #lame +o goober) through
the bot's queueing system; all the mode changes will be sent out at
once (combined into one line as much as possible) after the script
finishes, or when 'flushmode' is called

this is really not needed in this script as it will handle each join seperatly, meaning it will alwyas be just one mode per line ... it is ofc not wrong to use it

[ppslim]

Not allways true.

During high queue load periods, modes will be stacked, which is beneficial.

However, this again, is simply a performance issue.

[strikelight]

Not allways true.

During high queue load periods, modes will be stacked, which is beneficial.

However, this again, is simply a performance issue.

In THIS case it IS true, since as Papillion was stating, the script WILL finish, since the "script" (procedure called) is just one single pushmode
, meaning there are no other modes to be stacked in the queue from within that "script" (procedure), and thus the queue will be emptied immediately.

If there were multiple modes being sent in that "script" (procedure), THEN the pushmode would be effective.

Read the definition Papillion posted from tcl-commands.doc again, and you will understand if this didn't clear things up.

[ppslim]

Not all modes will be flushed from the queue on return from a proc.

It all depends how full the queue is before the proc is enetered.

Remember, items in the queue are delayed, to prevent the bot from flooding off. If, as you are saying, they are all sent, before another proc is called, then the bot would rather likely lagg even more, during high queue usage.

[strikelight]

Not all modes will be flushed from the queue on return from a proc.

It all depends how full the queue is before the proc is enetered.

Remember, items in the queue are delayed, to prevent the bot from flooding off. If, as you are saying, they are all sent, before another proc is called, then the bot would rather likely lagg even more, during high queue usage.

When a bound procedure is returned (a bound procedure is considered to be a "script" regardless of whether there are more procedures + binds in a file), it is the same as a flushmode being sent. pushmode is not puthelp.

[ppslim]

Quite correct, pushmode is not puthelp.

These are two seperate queues, but queue nether the less. The server queue just has higher priority over the help queue.

After a good search of the source code, it's pretty complex. However, the code shows that deq_msg is called, by queue_server, to send important messages in the MODE queue.

On top, it's also called once per second.

Within the deq_msg function, there is code, that will limit the amount of items sent.

The conditions on sending informatiopn from the mode queue, are as follows

1: There must be content in the mode queue.
2: The values of burst must not be above 4.
3: The alapsed time since the last message was sent, must not be below the MAXPENALITY value.

So, if the burst value has been reached, just before some1 joins, the mode can't be sent once the proc has been complete.

The mode will have to wait, until either the "once per second" clear queue has reached the modes position in the queue.

It is quite true, that a equivilant call to flushmodes is called after the proc, but again, the queue needs to be empty enough, for the mode in question to be sent.;

[strikelight]

Quite correct, pushmode is not puthelp.

These are two seperate queues, but queue nether the less. The server queue just has higher priority over the help queue.

After a good search of the source code, it's pretty complex. However, the code shows that deq_msg is called, by queue_server, to send important messages in the MODE queue.

On top, it's also called once per second.

Within the deq_msg function, there is code, that will limit the amount of items sent.

The conditions on sending informatiopn from the mode queue, are as follows

1: There must be content in the mode queue.
2: The values of burst must not be above 4.
3: The alapsed time since the last message was sent, must not be below the MAXPENALITY value.

So, if the burst value has been reached, just before some1 joins, the mode can't be sent once the proc has been complete.

The mode will have to wait, until either the "once per second" clear queue has reached the modes position in the queue.

It is quite true, that a equivilant call to flushmodes is called after the proc, but again, the queue needs to be empty enough, for the mode in question to be sent.;

Hmm.. A quick check asserts that you are correct

Code: Select all

.tcl proc mytest {} {pushmode #chan v nick}; mytest; pushmode #chan +m

Result (as predicted by ppslim):
*** BOT sets mode: +mv nick

My apologies...

Looks as though however the documentation in tcl-commands.doc needs to be updated to reflect this, instead of providing false details.