revenge-mode 2

[willyw]

It is hard for me to moderate this topic as I'm involved myself, but I believe it is time for all to chill down a little.

I was quite cool, and quite done.
Until somebody came in with foul language and name calling directed at me.
Scroll to the top and read down again, and notice where the name calling and foul language were introduced. Notice it wasn't by me?

The first time I read the post, I overlooked that language, and had decided to just not reply at all.
But when I saw the name calling and foul language, I was not about to let that go un-answered.

I did a very good job of not replying in kind, which would be perfectly acceptable.

I hardly believe anyone is here with the sole intent of arguing. There have been a few misunderstandings along the thread, but I'm sure we're all adults enough to look beyond that.

I now believe you look at the issue of revengebot and revenge-mode solely for the bot itself, whereas I look at any known bot amongst the channel members. Given my point of view and experience using eggdrops, I do not see that behaviour as a bug, but just normal behaviour and according to the documentations.

It is not according to the docs. ... sigh....
I simply did a .help chaninfo, and read what it said.

With your point of view, I can admit the documentation may be ambiguos or misdirecting, as it makes no explicit exception in the special case of bot itself being the victim.

Exception when the bot is the victim?? hehehe... the bot being the victim is the very topic, and what IS described in the docs.

Thinking back, I believe there was a documentation bug on this back in 1.6.10 or so, where the helptext for revengebot actually specified "the bot" rather than "a bot", later on fixed. Unfortunately, some helpsites still use these old docs adding to the confusion.

As for your initial query, which got lost in the thread, "Does anyone have any solutions?", I would have to say this would have to be solved using scripting.
I can't think of any specific one at the moment,

Thanks for addressing that question though.

but the basics would be to track all deops and kicks, and see if the bot itself was the target.

The bot being the target is the ONLY consideration, for this thread, and has been all along.

It would then have to store the channel name and nickname of the event in some variable, to be used once your eggdrop regains op (thus your eggdrop would also have to track itself being opped).

This is what I was thinking too.

A rough skeleton code would look something like this:

Code: Select all

bind kick - * checkKickRevenge
bind mode "% -o" checkDeopRevenge
bind mode "% +o" exertRevenge

proc checkKickRevenge {nick host handle channel target reason} {
 if {[isbotnick $target]} {
  lappend $::revengeList([string tolower $channel]) $nick
 }
}
proc checkDeopRevenge {nick host handle channel mode target} {
 if {[isbotnick $target]} {
  lappend $::revengeList([string tolower $channel]) $nick
 }
}
proc exertRevenge {nick host handle channel mode target} {
 if {[isbotnick $target] && [info exists ::revengeList([string tolower $channel])]} {
  putkick $channel [join $::revengeList([string tolower $channel]) ","]
  unset ::revengeList([string tolower $channel])
 }
}

You'd probably like to add some code to restrict whom your bot will revenge though.

Thank you for your time with the above code. However it is probably beyond me. I've only just begun... total beginner with tcl.

[speechles]

Code: Select all

bind kick - * checkKickRevenge
bind mode "% -o" checkDeopRevenge
bind mode "% +o" exertRevenge 

variable demoteLevel 1
variable dontDemoteFlags "f|f"
variable demoteReason "Don't kick or deop the bot!"

proc checkKickRevenge {nick host handle channel target reason} {
  checkDeopRevenge $nick $host $handle $channel "kicked" $target
}
proc checkDeopRevenge {nick host handle channel mode target} {
 if {[isbotnick $target] && ![matchattr $handle $::dontDemoteFlags $channel} {
  putquick "privmsg chanserv :ACCESS ADD $nick $::demoteLevel" -next
  putquick "privmsg chanserv :DEOP $channel $nick" -next
  lappend $::revengeList([string tolower $channel]) $nick
  if {![string equal "kicked" $mode]} {
    putquick "privmsg chanserv :OP $channel"
  }
 }
}
proc exertRevenge {nick host handle channel mode target} {
 if {[isbotnick $target] && [info exists ::revengeList([string tolower $channel])]} {
  putkick $channel [join $::revengeList([string tolower $channel]) ","] $::demoteReason
  unset ::revengeList([string tolower $channel])
 }
} 

edit: Changed the code above to better fit a network with services. When your bot is deopped (by someone who isn't set a friend either in that channel or globally (+f)), chanserv access lists will be changed and that user will be in effect "demoted". After which chanserv will deop them, then with access changed and deop upon them. There isn't a need except to kick them, so the exertRevenge procedure is changed simply to add demoteReason.

[nml375]

I was quite cool, and quite done.
Until somebody came in with foul language and name calling directed at me.
Scroll to the top and read down again, and notice where the name calling and foul language were introduced. Notice it wasn't by me?

I'm not saying you started it, nor am I trying to imply it. And with all, I of course include myself.

Exception when the bot is the victim?? hehehe... the bot being the victim if the very topic, and what IS described in the docs.

Well, looking from my perspective, that's the only case where the behaviour of the bot regarding revenge-mode is.. perhaps not well described. Since we're talking 'bout the docs, we have to keep in mind that revenge-mode applies to any and all revenge-actions within the channel, bot or not. Though I think we've sorted our views on this by now :p

but the basics would be to track all deops and kicks, and see if the bot itself was the target.

The bot being the target is the ONLY consideration, for this thread, and has been all along.

Here, I'm talking from a coder's context. That is, I must tell the script to ignore all other cases. If I were to simply ignore that, the script would revenge any deop'ing or kicking in the channel.
Basically, I'm outlining what tasks have to be done within the script (I don't like posting a huge block of code without any kind of explanation of the concept of the code).

The posted code should do the trick, but it will avenge anyone kicking the bot, including owners. Also, it will remember a kick until it gets opped again, regardless of how long time has passed or whether the nick is still around in the channel. To address these "issues", some kind of policy to how the bot should treat those cases would be needed. I suppose eggdrop's default behaviour would do, where we would ignore any +f (friend users). As for "old" records, eggdrop has no such feature (hence this thread), and thus no policy on the matter, so I'll leave that one be. I'll edit my previous post to implement this once I get this one submitted..

[TCL_no_TK]

Thanks nml375, speechles. i dont know if its been mentioned or not but i remenber there being a question asked about it. And since there's too much for me to read. I wanted to say *that*
When eggdrop dose take any sort of "revenge", the action is logged and also if the eggdrop has been given a option to give the person a +d flag or something. IT will also set the "comment" entry in that person's userfile with the information it logs as well. This is the same for any "ban" reason that would also contain the same log message. This usually includes the following: nickname, address, active, bot that was "deop'd" ..etc, what channel it took place on and the date of the "deopping".

P.S sorry if this has been mentioned or not.

[nml375]

@TCL_no_TK:
I don't think that have been covered in the thread, but that is good to keep in mind. In this code example, I'm taking a shortcut since the revenge-action would be triggered anyway upon kick/deop, I'm just filling in the spot where the kick goes missing.

Now that I think of it, that script of mine actually doesn't care for the value of revenge-mode; I guess that's one for the Fix-list. Also, I'm lazy kicking all offenders in one, so using individual kick-reasons go busted here.
I guess there's a lot other checks that could be added as well, but being suffering from migraine for the last two days, I'm opting for the easy way for now :p

[willyw]

...
I'm not saying you started it,

Thank you.

nor am I trying to imply it.

Understood.

And with all, I of course include myself.

np.

Exception when the bot is the victim?? hehehe... the bot being the victim if the very topic, and what IS described in the docs.

Well, looking from my perspective, that's the only case where the behaviour of the bot regarding revenge-mode is.. perhaps not well described. Since we're talking 'bout the docs, we have to keep in mind that revenge-mode applies to any and all revenge-actions within the channel, bot or not. Though I think we've sorted our views on this by now :p

Maybe not. To be clear: the bot is set -revenge , and +revengebot
Therefore revenge-mode does not to ANY and ALL revenge-actions.
Not if I understood correctly when I read the descriptions of both revenge and revengebot.
With -revenge, it would not apply to other users being de-op'd, for example.

but the basics would be to track all deops and kicks, and see if the bot itself was the target.

The bot being the target is the ONLY consideration, for this thread, and has been all along.

Here, I'm talking from a coder's context. That is, I must tell the script to ignore all other cases. If I were to simply ignore that, the script would revenge any deop'ing or kicking in the channel.

Ok

Basically, I'm outlining what tasks have to be done within the script (I don't like posting a huge block of code without any kind of explanation of the concept of the code).

The posted code should do the trick, but it will avenge anyone kicking the bot, including owners. Also, it will remember a kick until it gets opped again, regardless of how long time has passed or whether the nick is still around in the channel. To address these "issues", some kind of policy to how the bot should treat those cases would be needed. I suppose eggdrop's default behaviour would do, where we would ignore any +f (friend users). As for "old" records, eggdrop has no such feature (hence this thread), and thus no policy on the matter, so I'll leave that one be. I'll edit my previous post to implement this once I get this one submitted..

I haven't much time right now. Sorry.
I want to visit this thread again tomorrow, when I do have a bit more time, and re-read.
Just wanted to ack this last post of yours, and be sure to clear that up about not using "revenge" in my situation and testing.

I see speechles has joined in.
Perhaps we have all turned 180, and will all pursue this as an interesting project.
That would be quite interesting, and much more than I originally asked for. I just wanted to know if what I was seeing was the way it is, and not that I'd missed some switch somewhere.

I'll be back tomorrow, I hope.

Thanks

[willyw]

...
but being suffering from migraine for the last two days, I'm opting for the easy way for now :p

I'm not in any hurry on this. Don't worry about it. I'll check back in a few days or next week then, for further comments, etc.

[willyw]

Haven't forgotten.

Hardware problems.
Part ordered.



Thanks

[nml375]

Took me a little while, but here's the added checks for revengebot, revenge-mode, and "exempt friends". Also added a timeout, that will remove any unhandled revenges after 60 minutes.

Code: Select all

bind kick - * checkKickRevenge
bind mode "% -o" checkDeopRevenge
bind mode "% +o" exertRevenge

proc checkKickRevenge {nick host handle channel target reason} {
 if {[isbotnick $target] && [channel get $channel revengebot] && [channel get $channel revenge-mode] >= 2 && ![matchattr $handle f|f $channel]} {
  lappend ::revengeList([string tolower $channel]) $nick
  set unset [list unset ::revengeList([string tolower $channel])]
  foreach timer [utimers] {
   if {[string equal [lindex $timer 1] $unset]} {return}
  }
  timer 60 $unset
 }
}

proc checkDeopRevenge {nick host handle channel mode target} {
 if {[isbotnick $target] && [channel get $channel revengebot] && [channel get $channel revenge-mode] >= 2 && ![matchattr $handle f|f $channel]} {
  lappend ::revengeList([string tolower $channel]) $nick
  set unset [list unset ::revengeList([string tolower $channel])]
  foreach timer [utimers] {
   if {[string equal [lindex $timer 1] $unset]} {return}
  }
  timer 60 $unset
 }
}

proc exertRevenge {nick host handle channel mode target} {
 if {[isbotnick $target] && [info exists ::revengeList([string tolower $channel])]} {
  putkick $channel [join $::revengeList([string tolower $channel]) ","]
  unset ::revengeList([string tolower $channel])
  set unset [list unset ::revengeList([string tolower $channel])]
  foreach timer [utimers] {
   if {[string equal [lindex $timer 1] $unset]} {
    killtimer [lindex $timer 2]
    break
   }
  }
 }
}

Edit: Fixed typo

[willyw]

Took me a little while, but here's the added....

Many thanks.

Am still awaiting hardware.

But I did play with your original code above, briefly. On a 'test' bot.

(please bear in mind that I am a rank tcl beginner) , And encountered
an error that the variable was not found. var was revengeList .

I looked up lappend, and the way I understand it, if the variable does not already exist, lappend will create it.
That stumped me... it would seem that it should not error.

I haven't had time to get back to it yet... but since you remembered, and posted here, I thought I'd go ahead and mention it.


Also - question: is that variable an array? why? is it necessary that it be an array?

Thanks

[nml375]

Ah yes, you're quite right about lappend creating the variable..
Unfortunately I've been coding a lot of php lately, and they use variables in quite different ways.

In tcl, whenever you prefix a variable name with $, it's substituted with the content of the variable before passing it as a parameter to the command.
Basically, the command should read "lappend ::revengeList...." instead of "lappend $::revengeList..." (otherwize lappend will never see the variable at all).

[nml375]

Ohh, forgot your last question:
That variable is indeed an array, having the channel name as index. The reason for this is to avoid using one variable for each channel your eggdrop is monitoring.

[willyw]

Ohh, forgot your last question:
That variable is indeed an array, having the channel name as index. The reason for this is to avoid using one variable for each channel your eggdrop is monitoring.

Thanks for both replies above.


Have played around with it some more, as time permits.

It is not working, and I'd wanted to be able to tell you that I'd found a solution, but since I'm not good at this, it takes a tremendous amount of time as I fumble around.

What I believe is the problem, is:

Code: Select all

bind mode "% +o" exertRevenge 

that line.
What seems to be happening, is that when the bot re-enters the channel, it is op'd by Chanserv so quickly, that the bot is yet 'watching' and misses it.

I wanted to try something like an If statement, or perhaps a While loop.. just thinking of things that might get around it... and ran into a heck of a time waster. I kept getting error messages that 'else' was not a valid command... finally, I found that it must all be on one line, or very carefully entered, if put on more than one line.
You can laugh now.
But it really is time consuming....

I also thought of possibly using utimer to simply have the script wait.
Heck... 5 seconds ought to do it. That is time enough for the bot, after being kicked, to re-enter the channel and get ops from ChanServ.
But, I don't know about how that might interfere with the timer you are setting.

Anyway, time was going by, and even though I've not succeeded, I thought I should go ahead and reply here.

Thanks.

[nml375]

Well, if you're accustomed to C/C++ or Php, or the likes, it's easy to forget that tcl is a linefeed terminated language, contrary to ";" -terminated.

A workaround for that "sync"-situation, I suppose, would be to add yet another event - when the bot joins the channel:

Code: Select all

bind join - * checkJoin

This should then start a timer, calling yet another proc (ugh) that'll test for ops and revenge.

Code: Select all

proc checkJoin {nick host handle channel} {
 if {[isbotnick $nick]} {
  utimer 10 [list delayRevenge $channel]
 }
}

proc delayRevenge {channel} {
 if {[botisop $channel]} {
#Call the exertRevenge proc, faking a +o botnick mode on channel...
  exertRevenge "" "" "" $channel "" $::botnick
 }
}

This is not ideal, as we're just guessing that 10 seconds is enough to sync the channel data. Pref. we'd use some raw bindings, to catch the moment eggdrop has recieved all sync. info, but in most cases this should do. Besides, if it takes more than 10 secs to sync the channel, we've got issues enough as is.

[Sir_Fz]

Would a raw bind for mode catch the +o mode event?