egghelp/eggheads community

Strange 'Control $idx ' behaviour

2002-09-02T17:24:17-04:00

Heh, thats exactly what I did in the end, thanks anyway

Statistics: Posted by Guest — Mon Sep 02, 2002 5:24 pm

Strange 'Control $idx ' behaviour

2002-09-02T16:19:05-04:00

Yes it is an unfortunate feature of the way eggdrop does the control command. When you set a new handler, it saves the previous handler in a linked list instead of overwriting it. I had the same problem when I was writing a game with a menu interface. When users quit, it would spit out like 50 "connection lost" messages. I changed my code to use a single handler for all idx's, which would then branch to the correct handler based on a global array idx_state. Something like this:

proc idx_handler {idx data} {
global idx_state
if {[info exists idx_state($idx)]} {
if {[catch {eval $idx_state($idx) [list $idx $data]} err]} {
putlog "error in handler: $err"
}
} else {
putlog "no handler for $idx"
}
return 0
}

Then in all the places you normally say "control $idx blah" just say "set idx_state($idx) blah"

Statistics: Posted by stdragon — Mon Sep 02, 2002 4:19 pm

Strange 'Control $idx ' behaviour

2002-09-01T10:32:00-04:00

If you return 1, the control proc isn't used any more, but..

if I do

Code:

control $idx myrealinterfacereturn 1

it kills the myrealinterface control

and I can't do

Code:

return 1control $idx myrealinterface

because that will kill the current procedure before it gets to the new control.

Statistics: Posted by Guest — Sun Sep 01, 2002 10:32 am

Try return value

2002-09-01T10:23:56-04:00

Hi,
I'am a newbe so please correct me if I'm wrong but I think I can help you.
I've read something about a return value of the control proc. Maybe you have to return 0 if a control isn't used anymore.

Paul Bottin a/k/a FrEsC

Statistics: Posted by Guest — Sun Sep 01, 2002 10:23 am

Strange 'Control $idx ' behaviour

2002-08-28T06:58:02-04:00

I'm trying to write a dcc interface for one of my bots, what I do is the user connects, they are 'controled' by the 'user' proc. If they enter a valid user control moves onto the 'password' proc. If they pass that they are kicked into the 'real interface' proc.

example:

Code:

proc dccaccept {idx data} {  # blah blah  set idx [connect $ip $port]  control $idx myuser}proc myuser {idx data} {  global theusername  if {$data == ""} { putlog "$idx closed connection" }  if {[validuser $data]} {    set username $data    control $idx mypassword  }}proc mypassword {idx data} {  global theusername  if {$data == ""} { putlog "$idx closed connection" }  if {[passwdok $theusername $data]} {    control $idx myrealinterface  }}proc myrealinterface {idx data} {  if {$data == ""} { putlog "$idx closed connection" }  # blah blah}

Now, everything works fine and if I enter everything correctly, I reach myrealinterface and it does what it is supposed to.. BUT

Why is it that when I close the connection, I see the putlog three times? if I put a number with each different putlog, I see each different putlog. If there is an error in myrealinterface, instead of the connection terminating I get kicked back to the password proc. Basically, if the connection gets closed in myrealinterface, it gets kicked back to the previous control procedure. This is not what I want

I have tried 'control $idx ""' and 'control $idx' but that means that it just seems to try and call the idx number as a proc (calling ' ' instead of ' '

This is very strange. It would be useful if someone could explain this or tell me how I can perhaps 'clear' the procs behind it. I have tried looking through some of the tcldcc.c and some of the other source, but to no avail

Thanks for your time, and thanks in advance.

Statistics: Posted by Guest — Wed Aug 28, 2002 6:58 am