Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[1.8.3] syncing channel does not trigger event handlers #599

Open
wilkowy opened this issue Sep 1, 2018 · 2 comments · May be fixed by #1773
Open

[1.8.3] syncing channel does not trigger event handlers #599

wilkowy opened this issue Sep 1, 2018 · 2 comments · May be fixed by #1773

Comments

@wilkowy
Copy link
Contributor

wilkowy commented Sep 1, 2018

Eggdrop 1.8.3. This is a tweaked cut from my other script:

proc wilktest:user_kick {nick uhost hand chan whom why} {
	putlog "#DEBUG# user_kick $nick $uhost $hand $chan $whom $why"
	if {[isbotnick $whom]} {
		putlog "#DEBUG# user_kick - me"
		return
	}
	return
}

proc wilktest:chan_mode {nick uhost hand chan mode whom} {
	putlog "#DEBUG# chan_mode $nick $uhost $hand $chan $mode $whom / [isbotnick $whom] [botisop $chan] [wasop $whom $chan] [isop $whom $chan]"
	return
}

bind kick - * wilktest:user_kick
bind mode - *+o* wilktest:chan_mode

The problem is that bot until it goes in sync with channel (get users, +beIR lists) does not trigger events (at least mode events). The test was:

  1. kick bot
  2. wait until it rejoins channel
  3. quickly op it
  4. op it again after awhile

Here is the log (most syncing parts removed):

[01/18:07:31] [@] wilk!wilk@somehost KICK #*** somebot :no reason
[01/18:07:31] #DEBUG# user_kick wilk wi wilk #*** somebot no reason
[01/18:07:31] #DEBUG# user_kick - me
[01/18:07:31] [!s] JOIN #***
[01/18:07:31] [s->] JOIN #***
[01/18:07:31] Adding penalty: 3
[01/18:07:31] [@] somebot!~someident@somehost JOIN :#***
[...]
[01/18:07:33] [@] wilk!wilk@somehost MODE #*** +o somebot
[...]
[01/18:07:45] [@] otherbot!otherident@somehost MODE #*** +v somebot
[01/18:07:53] [@] wilk!wilk@somehost MODE #*** +o somebot
[01/18:07:53] #DEBUG# chan_mode wilk wilk@somehost wilk #*** +o somebot / 1 1 1 1

The first +o while bot was syncing with channel was totally ignored.

I've put the same code on 1.6.21 and there is no such behaviour. Every mode is triggered:

[01/18:30:54] [@] wilk!wilk@somehost KICK #*** otherbot :no reason
[01/18:30:54] #DEBUG# user_kick wilk wilk@somehost wilk #*** otherbot no reason
[01/18:30:54] #DEBUG# user_kick - me
[01/18:30:54] [!s] JOIN #***
[01/18:30:55] [s->] JOIN #***
[01/18:30:55] Adding penalty: 3
[01/18:30:56] [@] otherbot!otherident@somehost JOIN :#***
[...]
[01/18:30:58] [@] wilk!wilk@somehost MODE #*** +o otherbot
[01/18:30:58] #DEBUG# chan_mode wilk wilk@somehost wilk #*** +o otherbot / 1 1 0 1
[...]
[01/18:31:22] [@] wilk!wilk@somehost MODE #*** +o otherbot
[01/18:31:22] #DEBUG# chan_mode wilk wilk@somehost wilk #*** +o otherbot / 1 1 1 1

@michaelortmann
Copy link
Member

michaelortmann commented Sep 2, 2018

df4b71d#diff-320089252eeafc41d820752967364dce

"broke" it, when it changed init_channel

1.6.21 code:

if (!reset) {
[...]
clear channel member info
[...]

is not triggered, because reset flags are set

but 1.8.21 code:

if (flags & CHAN_RESETWHO) {
[...]
clear channel member info
[...]

is triggered, because CHAN_RESETWHO flag is set

when chaninfo is cleared, ismember() will return 0 then for a while, and that caused the following mode change (and probably not only those) to not call tcl binds. the bot goes blind here.

i tried to unset CHAN_RESETWHO flag in chan.c:gotjoin() like:
reset_chan_info(chan, (CHAN_RESETALL & ~CHAN_RESETTOPIC & ~CHAN_RESETWHO));
but it didnt work out as expected.

then i tried to let it clear, and set nick again afterwards:

      reset_chan_info(chan, (CHAN_RESETALL & ~CHAN_RESETTOPIC));             
      if (chan->channel.member)                                              
          strncpyz(chan->channel.member->nick, nick, sizeof(chan->channel.member->nick));

it seems to fix the problem,
but i have little idea of what i am doing here.
please someone else take it from here...

@wilkowy
Copy link
Contributor Author

wilkowy commented Jan 15, 2019

Bug still observed in 1.8.4.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants