).and yes, then symbolic character is ! for admin and * owner, like a modechange example below.
in a strange kind of fakt, eggdrop isnt puzzled by "ChanServ sets mode: +qo Stadler Stadler"
This is the new home of the egghelp.org community forum.
All data has been migrated (including user logins/passwords) to a new phpBB version.
For more information, see this announcement post. Click the X in the top right-corner of this box to dismiss this message.
All data has been migrated (including user logins/passwords) to a new phpBB version.
For more information, see this announcement post. Click the X in the top right-corner of this box to dismiss this message.
euirc - +a admin/protection not recognizing as userflag
euirc - +a admin/protection not recognizing as userflag
eggdrop recognizes the modechange +a for admin as channelflag, so it sees a channelflag line like "Ctrna" instead of "Ctrn" after a modechange like "ChanServ sets mode: +ao emp|De_Kus emp|De_Kus". so far i know +a is a rare usermode, but its really cool. i dunno if it qould be possible for further version to support. cause +a can only be set via chanserv or als owner its not neccesary that its able to set it or have a userflag for admin and autoadmin (admin is nothing more or less than the present master flag +m already existing ).
and yes, then symbolic character is ! for admin and * owner, like a modechange example below.
in a strange kind of fakt, eggdrop isnt puzzled by "ChanServ sets mode: +qo Stadler Stadler"
).and yes, then symbolic character is ! for admin and * owner, like a modechange example below.
in a strange kind of fakt, eggdrop isnt puzzled by "ChanServ sets mode: +qo Stadler Stadler"
Doubtful. This is not defined in the RFC, and is not supported by the Big 4 (undernet, ircnet, efnet and dalnet).
Unless these networks start to adopt it, it wont be added.
If they did, they would start having to support every single feature a IRC server support, by every network.
This is just not possible, as some fo these features clash with other networks.
Unless these networks start to adopt it, it wont be added.
If they did, they would start having to support every single feature a IRC server support, by every network.
This is just not possible, as some fo these features clash with other networks.
Photon, I guess it's time to read the eggheads, and eggdev archives.
This has been argued about time and time again. Not so much as regards exactly this, but how eggdrop will handle networks in the future.
net-type actualy does very little. Most of it's work, is to pre-set default values. All of these values can be changed manualy, by setting net-type to other.
There are likely to be some other bots as well, but they are likely non-RFC related.
It should not be up to us to fix the fault of the IRCD programmers.
If every client decides to jump to more strict parsing, which they may well do, due to DDOS, and other vulnerablities that may be lurking with a loose parser, the the IRC networks are stumped.
People may well say "lets stick with client V1.2.3.4 instead of upgrading tot he more strict version". However, if you look at mirc, if this was changed, and knowing the features that are introduced, people would want to jump to it, for all these cool new features.
This has been argued about time and time again. Not so much as regards exactly this, but how eggdrop will handle networks in the future.
net-type actualy does very little. Most of it's work, is to pre-set default values. All of these values can be changed manualy, by setting net-type to other.
There are likely to be some other bots as well, but they are likely non-RFC related.
It should not be up to us to fix the fault of the IRCD programmers.
If every client decides to jump to more strict parsing, which they may well do, due to DDOS, and other vulnerablities that may be lurking with a loose parser, the the IRC networks are stumped.
People may well say "lets stick with client V1.2.3.4 instead of upgrading tot he more strict version". However, if you look at mirc, if this was changed, and knowing the features that are introduced, people would want to jump to it, for all these cool new features.
hihi
yeah, sure, its not a standard of any big network, but it is standard enogh so mirc supports it... more or less, it knows +a is user stat !, but thats all.
i dunno if its mirc global or noname script (which supports primary quakenet with Q and L integration), but with +a and -o and -h mirc doesnt want to use +o oder any other op commands. so i only wanted to point on it. up to know it seems the bot hasn't been troubled by it, but you never know.
but i should perhaps pay more attention to why my bot dies without an error trieing to defeat takeovers on quakenet...
.
PS: normal for this board to get off topic? ^-^
quakenet is sure... diffrent, and L is really... light, but Q rulez. A bot must only know how to be helped by Q & L., but thats easy done with some tcl scripting 
.
i dunno if its mirc global or noname script (which supports primary quakenet with Q and L integration), but with +a and -o and -h mirc doesnt want to use +o oder any other op commands. so i only wanted to point on it. up to know it seems the bot hasn't been troubled by it, but you never know.
but i should perhaps pay more attention to why my bot dies without an error trieing to defeat takeovers on quakenet...
.PS: normal for this board to get off topic? ^-^
quakenet is sure... diffrent, and L is really... light, but Q rulez
. A bot must only know how to be helped by Q & L., but thats easy done with some tcl scripting .It's not up to the bot to understand and interface directly with Q, L, nickserv, chanserver or any other service.
Before we touch on why, look at mIRC, it doesn't have any direct support for it.
Eggdrop and mIRC are basicaly the same thing. They are both clients, to a server, in your average Internet basec client-server relationship.
The differance between eggdrop and mIRC, is that mIRC is a human based, visual interactive interface to this tapology. Where eggdrop is a robot (bot), automated in all it's tasks.
I have 5 eggdrops, that I havn't seen in 5 months. I have made payment for them within this time, and have read 2 e-mails, asking for adjustments to 3 on-join messages it delivers. Every aspect, ranging from starting it, connecting it, sendings it's messages, replying to commands, messages and events, updates to informational messages, all the way to reporting it's errors, is automatied, and requires no user intervention, other than to add new users and bots.
Hell, my bots have probably lost there user-record for me by now, with all the self managment I have created for them.
Yes, eggdrop can be used interactivly to IRC, but using third party tools to do so. IRC Client directly connect and managment message sending 100% within 1 application.
This is all done, following an RFC, whcih dictates how messages are sent, when messages are sent, how messages are received and interpreted, when messages are not allowed to be sent, and what must be sent.
This RFC is based for the connection between IRC CLIENT and IRC SERVER.
Services are a whole new ballgame, and have nothing to do with the RFC, other than, messages between client and service, are sent and received using the IRC RFC. There is no other reason for this, other than because they are being routed through the IRC servers.
Services are funny little things, non of them are named the same (essantialy, because the commands between each one, are different, and it's the only way to tell them apart), non of them operate int he same manner and non of them have the same set of features.
This makes it impossible to make a standard script for all of them, without essntialy making however many, and placing them in one file, which is stupid.
The same applied both for eggdrop and mIRC, as neither has direct support.
The reason mIRC is able to understand the differances in flags?
Becuase the developer of mIRC/strong followers of mIRC and the IRC developers, came to a compromise, while forgetting about the rest of the population of software and there views.
When connecting to IRC servers, a META string is sent to the client. Most clients ditch this string, as it's non-essantial, and more informational.
It comains information about whatt he server supports. IE, des it support the watch command, instead of the ISON command.
It also sends a list of channel META characters. These are the valid characters, that can be used at the start of a channel name, IE, &, #, !.
On top, it sends a list of mode characters, grouped by a , (comma).
These represent usermodes (ops, voice halfops ETC), argument less channel modes (+m, +s) and finaly arguemtned channles modes (eg +k password, +l limit).
This would be excelent for eggdrop to follow, but it's pathetic. It would be adding support into eggdrop, to understand what to interpret things as.
It would make codes segments twice as long, and actiona can vary from server to server.
The RFC 1459 (IRC) is a sloppy protocol. Adding this stuff only makes ti worse.
There where plans for a new version of the protocol, based on the original, but one to base any new feature added, and such. But unless these plan allow all IRCD programers to participate, and artivly allow them to get here idea in, and they then wish to actualy impliment them, then it's doubtful eggdrop will follow.
From what I understand, and have read abotu today, there are 3 new RFC (newer than 1459). These relate to more detail within specific areas, and should all be followed at the same time. SOme fo these new IRCD's may well be following these.
If they are, then this is the issue. Eggdrop is RFC 1459 complient, and is not intended for IRCD's following the newer RFCs.
Before we touch on why, look at mIRC, it doesn't have any direct support for it.
Eggdrop and mIRC are basicaly the same thing. They are both clients, to a server, in your average Internet basec client-server relationship.
The differance between eggdrop and mIRC, is that mIRC is a human based, visual interactive interface to this tapology. Where eggdrop is a robot (bot), automated in all it's tasks.
I have 5 eggdrops, that I havn't seen in 5 months. I have made payment for them within this time, and have read 2 e-mails, asking for adjustments to 3 on-join messages it delivers. Every aspect, ranging from starting it, connecting it, sendings it's messages, replying to commands, messages and events, updates to informational messages, all the way to reporting it's errors, is automatied, and requires no user intervention, other than to add new users and bots.
Hell, my bots have probably lost there user-record for me by now, with all the self managment I have created for them.
Yes, eggdrop can be used interactivly to IRC, but using third party tools to do so. IRC Client directly connect and managment message sending 100% within 1 application.
This is all done, following an RFC, whcih dictates how messages are sent, when messages are sent, how messages are received and interpreted, when messages are not allowed to be sent, and what must be sent.
This RFC is based for the connection between IRC CLIENT and IRC SERVER.
Services are a whole new ballgame, and have nothing to do with the RFC, other than, messages between client and service, are sent and received using the IRC RFC. There is no other reason for this, other than because they are being routed through the IRC servers.
Services are funny little things, non of them are named the same (essantialy, because the commands between each one, are different, and it's the only way to tell them apart), non of them operate int he same manner and non of them have the same set of features.
This makes it impossible to make a standard script for all of them, without essntialy making however many, and placing them in one file, which is stupid.
The same applied both for eggdrop and mIRC, as neither has direct support.
The reason mIRC is able to understand the differances in flags?
Becuase the developer of mIRC/strong followers of mIRC and the IRC developers, came to a compromise, while forgetting about the rest of the population of software and there views.
When connecting to IRC servers, a META string is sent to the client. Most clients ditch this string, as it's non-essantial, and more informational.
It comains information about whatt he server supports. IE, des it support the watch command, instead of the ISON command.
It also sends a list of channel META characters. These are the valid characters, that can be used at the start of a channel name, IE, &, #, !.
On top, it sends a list of mode characters, grouped by a , (comma).
These represent usermodes (ops, voice halfops ETC), argument less channel modes (+m, +s) and finaly arguemtned channles modes (eg +k password, +l limit).
This would be excelent for eggdrop to follow, but it's pathetic. It would be adding support into eggdrop, to understand what to interpret things as.
It would make codes segments twice as long, and actiona can vary from server to server.
The RFC 1459 (IRC) is a sloppy protocol. Adding this stuff only makes ti worse.
There where plans for a new version of the protocol, based on the original, but one to base any new feature added, and such. But unless these plan allow all IRCD programers to participate, and artivly allow them to get here idea in, and they then wish to actualy impliment them, then it's doubtful eggdrop will follow.
From what I understand, and have read abotu today, there are 3 new RFC (newer than 1459). These relate to more detail within specific areas, and should all be followed at the same time. SOme fo these new IRCD's may well be following these.
If they are, then this is the issue. Eggdrop is RFC 1459 complient, and is not intended for IRCD's following the newer RFCs.