revenge-mode 2

[willyw]

Hello,


Using revenge-mode 2 .

2 Deop the user, give them the +d flag for the channel, and kick them.

and the bot does not kick when deop'd. It does deop, and set the +d flag.

I think the problem is that the bot issues the kick command while it is still deop'd itself, therefore the command is ignored by Chanserv.

When deop'd, the bot WILL get its ops back from Chanserv, but it takes a second, and I suspect the kick is issued during that time.

Has anyone else experienced this?

Does anyone have any solutions?

Thanks



Edit:
On second thought, maybe that is all wrong, because instead of deop'ing the bot, I just tested by kicking the bot.
It returned to the channel with no problem, and deop'd the offender - - but still did not kick the offender.

Need advice.
Thanks

[TCL_no_TK]

I doubt the bot would be able to kick someone when its been deop'd or kicked from a channel, sadly. But if it helps, you can try using

Code: Select all

3   	Deop the user, give them the +d flag for the channel, kick, and ban them.

This *should* set a channel ban on the bot, so the bot would kick the user. If you need the "revenge" improving i'd looking into the 3rd party scripts available for this.

[nml375]

As I recall, eggies won't kick if they're the victim, as they would lack op anyway.
It will always add the +d flag to the offender, which will cause it to deop the offender whenever it sees him/her opped, hence the deop once opped.
It will not, however, add the +k flag, and thus it will not kick the offender whenever it sees him/her in the channel.

[willyw]

I doubt the bot would be able to kick someone when its been deop'd or kicked from a channel, sadly. But if it helps, you can try using

Code: Select all

3   	Deop the user, give them the +d flag for the channel, kick, and ban them.

This *should* set a channel ban on the bot, so the bot would kick the user.

And ban the user, which is what I don't want to do.

If you need the "revenge" improving i'd looking into the 3rd party scripts available for this.

Ok. I was afraid that might be the solution.

If it is a 'bug' in Eggdrop though, I'm surprised it is not mentioned more often. I tried searching for it, and didn't find it here.

Thanks

[willyw]

As I recall, eggies won't kick if they're the victim, as they would lack op anyway.
It will always add the +d flag to the offender, which will cause it to deop the offender whenever it sees him/her opped, hence the deop once opped.
It will not, however, add the +k flag, and thus it will not kick the offender whenever it sees him/her in the channel.

+k ?
In .help whois, +k is described as:

k - autokick (user is kicked and banned automatically)

which would also include a ban.

[willyw]

... If you need the "revenge" improving i'd looking into the 3rd party scripts available for this.

Maybe someone reading this already experimented and found a script that does what revenge-mode 2 does.

Does anyone have any suggestions of scripts to try?


Thanks

[nml375]

Precisely, so it is not a matter of a bug, but rather a limitation of eggdrop/irc. Eggdrop only "remembers" things added to user records and ban/invites/ignores added to their respective lists. When eggdrop itself is the victim of a hostile action, it cannot take immediate actions, and thus the only options are to alter user records and/or add ban masks. As the description rules out +k for "mode2", eggdrop has no other means of kicking, but simply adds the +d flag to the user record.

[willyw]

Precisely, so it is not a matter of a bug,

The description of revenge-mode 2 reads:

2 Deop the user, give them the +d flag for the channel, and kick them.

yet it seems that the bot cannot do this.

The 'help' info is therefore creating a 'bug' situation.

but rather a limitation of eggdrop/irc.

The thing to do then, is not claim that it can do it. Then the 'bug' is gone.

OR:
Perhaps have a way to make it wait x seconds, then issue the kick command.
That way, it would have time to both return to the channel, and regain its own ops, so that it COULD kick the offender.
.... just an idea.....

[nml375]

...yet it seems that the bot cannot do this.

Sure it can. Just not in the cases where the eggdrop itself isn't opped.

The thing to do then, is not claim that it can do it. Then the 'bug' is gone.

No, that would actually introduce a bug. Namely eggdrop having an undocumented "feature" of kicking offenders.

What I believe you need to realize, is that the revenge-behaviour of eggdrop is not restricted to the case where your eggdrop is itself the victim. It will in fact revenge any protected channel member.

Perhaps have a way to make it wait x seconds, then issue the kick command.
That way, it would have time to both return to the channel, and regain its own ops, so that it COULD kick the offender.

Problem here is, what if your eggdrop does not regain op in 2 secs, 5 secs, 10 secs, 10 minutes, etc... how long should it remember that it should kick the offender?
Especially in the case of being kicked itself - how can we even be sure it's even the same offender?

Besides, if we simply wait an arbitrary number of seconds with issuing the kick, we'd might miss the opportunity to kick the offender (when we see him kicking someone we're protecting) before he kicks us as well..

Once again, eggdrop's only memory is its user records and ban/invite/ignore-lists. Adding +k to the offenders handle means we'll kick/ban him/her every time we see him/her... Being option 3...
The reason for banning as well as kicking upon +k-mode, is that evil irc clients feature auto-rejoin functions which result in extensive flooding. And +k remains until someone manually removes it (just like +d).

[willyw]

...yet it seems that the bot cannot do this.

Sure it can. Just not in the cases where the eggdrop itself isn't opped.

umm.. ... That's exactly what we're talking about - in cases where the bot has been deop'd.
As described here:

revengebot This is similar to to the 'revenge' option, but it only triggers if a bot gets deopped, kicked or banned.

The thing to do then, is not claim that it can do it. Then the 'bug' is gone.

No, that would actually introduce a bug. Namely eggdrop having an undocumented "feature" of kicking offenders.

Somehow, you've gotten yourself very confused.
I thought I had explained it, and showed where the information was coming from, so that what I was talking about could be followed.

What I believe you need to realize, is that the revenge-behaviour of eggdrop is not restricted to the case where your eggdrop is itself the victim. It will in fact revenge any protected channel member.

Not unless it is told to... at least that is how I read it.
You seem to think that we are talking about +revenge.
We are not.
Just +revengebot.

Perhaps have a way to make it wait x seconds, then issue the kick command.
That way, it would have time to both return to the channel, and regain its own ops, so that it COULD kick the offender.

Problem here is, what if your eggdrop does not regain op in 2 secs, 5 secs, 10 secs, 10 minutes, etc... how long should it remember that it should kick the offender?

Obviously, that would be for the bot's owner to determine what works in his situation, and set it accordingly.

Especially in the case of being kicked itself - how can we even be sure it's even the same offender?

"its" ?
What are you talking about?
We certainly know who kicked the bot.

Besides, if we simply wait an arbitrary number of seconds with issuing the kick, we'd might miss the opportunity to kick the offender (when we see him kicking someone we're protecting) before he kicks us as well..

Once again, eggdrop's only memory is its user records and ban/invite/ignore-lists. Adding +k to the offenders handle means we'll kick/ban him/her every time we see him/her... Being option 3...
The reason for banning as well as kicking upon +k-mode, is that evil irc clients feature auto-rejoin functions which result in extensive flooding. And +k remains until someone manually removes it (just like +d).

I'm quite aware of auto-rejoins, etc. And it is not relevant at all.
Because banning is not what I wanted.

I read the description of what was available, and found one the I did want.
And found that it does not work as described.
Very simple.

[nml375]

revenge-mode applies to both +revenge aswell as +revengebot.
Oh, and read the text for revengebot a bit more throughout, and you'll see it says "a bot", not "the bot". Hence it applies to any known bot being kicked/deop'd/etc.

Remove the claim, and it would still kick when another bot (for revengebot) or user (for revenge) would be the victim. Hence it would be an undocumented feature.

Both revenge and revengebot applies to other channel members as well as the bot itself.

Obviously, that would be for the bot's owner to determine what works in his situation, and set it accordingly.

Just as it is up to the bot's owner to implement additional features not included in the vanilla eggdrop.

We certainly know who kicked the bot.

For how long do we know this? 10 secs, 1 minute, 10 minutes, 1 day?
Kick the bot, change nickname before the bot manages to rejoin, and your bot has no clues as to whom kicked it.


I'm pointing out the issue with +k specifically since you did not want banning, and why that would not be an option to "remember" to kick the offender.

Eggdrop does what it says, to its best abilities. If it lacks operator privileges, it is unable to kick an offender - plain and simple. In such cases, it'll add the +d (as documented), and add a ban to the internal banlist depending on how you set revenge-mode.

I read the description of what was available, and found one the I did want.
And found that it does not work as described.

I'd say the flaw here is your misconception with "a bot" being "the bot".

[willyw]

.........

I read the description of what was available, and found one the I did want.
And found that it does not work as described.

I'd say the flaw here is your misconception with "a bot" being "the bot".

My, my... aren't you something?

Look, I don't know what is wrong with you, but I'm not interested in arguing with you.
It is was becoming clear that is all you wanted.
You've clarified that even more.

[speechles]

Woah, willyw, slow down a bit and stop attacking the people trying to help you. It's like so simple to understand...

revenge-mode defines how the bot should punish bad users when revenging
2 for deop, +d and kick

Now, in the case of the bot itself being deopped, well... exactly as nml375 said, it simply cannot kick because it no longer has operator privileges. It will still add the +d because this can be done regardless of what mode the bot presently has. This is not a bug within eggdrop. This is called common sense and one must use it when setting this option. If you want to protect your bot, and revenge against it's deop, well round up a botnet. In this way, the other bot will punish when another bot is deopped.

And most of all, stay happy, the help you get here is 100% free and offered by volunteers so try to be friendly and not ask for the moon and be an a55hole...

[willyw]

Woah, willyw, slow down a bit and stop attacking the people trying to help you.

Whoa yourself. I wasn't even going to respond anymore in this thread, until I read this silly post.

Note that *I'm* not attacking anybody that is helping me.
I even said "Thanks" to the person that did have a nice, sensible reply - TCL_no_TK. Scroll up. It there.

As far as the other foolishness, once it was beyond a doubt that he was just looking to argue - that's what it is when one introduces non-relevant things repeatedly, and makes assumptions without asking first - I didn't attack that poster. I merely acknowledged it, and was moving on.

Your post here to me is out of line.

It's like so simple to understand...

revenge-mode defines how the bot should punish bad users when revenging
2 for deop, +d and kick

Now, in the case of the bot itself being deopped, well... exactly as nml375 said, it simply cannot kick because it no longer has operator privileges. It will still add the +d because this can be done regardless of what mode the bot presently has. This is not a bug within eggdrop. This is called common sense and one must use it when setting this option.

Exactly. Common sense.
That's how I arrived at my conclusion, when I first discovered that it did not do what was described in the docs.
But, since it was in the docs, and there is always a possibility that I've overlooked something, I thought I'd come here and inquire.

As far as I am concerned, a "bug" is when software does not perform as expected.
Expectations come from the descriptions in the docs.
Eggdrop does not do what is described, in this case. Period.

Yes, your repeating the series of events as to why it cannot perform makes good sense. I've already affirmed that.
Thus, the problem is with the docs. If the docs didn't say what they do, then there would be no "bug".

If you want to protect your bot, and revenge against it's deop, well round up a botnet. In this way, the other bot will punish when another bot is deopped.

And most of all, stay happy, the help you get here is 100% free and offered by volunteers so try to be friendly and not ask for the moon and be an a55hole...

That's rich... now who is it doing the 'attacking'??

I was very happy, and quite done with this, until I read this stupid post of yours for the second time. I overlooked your uncalled for smart azz remark the first time.

Nobody asked for the moon. You're making that up. Read what I originally asked.

If there is an a55hole in this conversation, it surely is not I. I can see a couple that qualify though.

Remember - I was quite done, and you wouldn't be reading this, if YOU had not posted.

[nml375]

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 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. 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.
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, but the basics would be to track all deops and kicks, and see if the bot itself was the target. 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).
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] && ![matchattr $handle "+f|+f" $channel]} {
  lappend ::revengeList([string tolower $channel]) $nick
 }
}
proc checkDeopRevenge {nick host handle channel mode target} {
 if {[isbotnick $target] && ![matchattr $handle "+f|+f" $channel]} {
  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.