Does anyone have a problem with their eggdrop thinking a channel is moderated if mode +f [m] is set using Unreal 3.2.3?
The actual channel modes are:
[+CfnrtT]
My eggdrop is interpreting the channel modes as:
[+mCRtMrn]
The problem only occurs when mode +f [m] is set BEFORE the eggdrop joins the channel. The eggdrop then thinks that the channel is moderated (channel mode +m), and, as a result, commands such as ".act #chan test" cannot be executed.
As far as I can see, this code works when the eggdrop is in a channel, then a user joins, and a user mode is set (by the eggdrop, services, or someone else).
The problem I have occurs when an eggdrop joins a channel where mode f[m] is already set. The eggdrop joins and detects the channel modes, incorrectly interpreting mode +f[m] as modes +fm.
Maybe I can put on my Christmas 2006 wishlist a new release of eggdrop that has Unreal as a separate net type
I think I have already said this before but anyway:
eggdrop shouldn't have chan- and usermodes hardcoded; it should interpret numeric 005 (ISUPPORT) server reply, just as mIRC does, and thus learn about non-standard modes (Unreal, as lame as it is, supports 005 - or so I think)
hopefully eggheads will eventually implement such flexibility, nowadays mandatory for any IRC client (eggdrop is, after all, a special kind of IRC client), ot at least follow-up on this
connection, sharing, dcc problems? click <here>
before asking for scripting help, read <this>
use
A good suggestion for 1.6.19 . I personally think eggdrop should really use the 005 and fallback to channel mode if still unkown. There is no reason to believe the IRC server wants to send the bot a fake mode that doesnt reall exist . Threating it as an unknown channel mode should be safe, so no harm can be done anyway.