This simple alias is intended for the quick creation of otherwise tedious regexes used primarily in badword filter snippets. What this alias does is take a simple English word and generate a regex that will match that word as well as ANY "l33t"-ified version of it. This is intended to counteract attempts by users to bypass badword filters. So if you want to censor the word "foobar", using this snippet..
Alright, well here it is. Something I've been wanting to do for quite some time but never had the energy or motivation to get through. This is the beginning of hopefully my full script for online mIRC poker (not for real money, of course). Supply this alias with a "board" and an infinite number of "hole" hands, and it will tell you which hand wins and with what. It will also tell you if there is..
The quickest and most reliable way to find all the numerics you need is to first turn on debug with /debug -p @debug, and then do a /whois on yourself with IRCop priveliges when you have an SWHOIS set. You can set an SWHOIS for yourself in your operblock; there may also be a way to temporarily set one using the OperServ RAW command (don\'t mess with that if you don\'t know what you\'re doing though, of course).
Also on large channels, it is likely to RecvQ you off. While a SendQ could be prevented by combining it into a /whois nick1,nick2,..,nickN command, this won\'t do anything for your RecvQ, since the server still has to send you the same amount of information. In order to prevent a RecvQ flood on larger channels, you should use timers... PM me if you want specific info on how.
A simple and straightforward snippet that will scan for IRCops and echo the nickname and address of any that it finds to the active window. The scanning will be automatically performed when you join a channel and on anyone who subsequently joins a channel you are on, as well as whenever you receive a new private message. It may also be performed with the /scan TARGET command, where TARGET is a nickname..
Should be noted that this snippet will only achieve full functionality on networks with Anope services.
If the network is running a similar variant (any that use ChanServ, NickServ, etc) it\'s likely that the more basic funtions like IDENTIFY and REGISTER will work, but functions such as XOP on/off and ACCESS lists are, I believe, unique to Anope.
I don\'t think it\'s possible for $network not to be filled...it is standard protocol to send a network name to a connecting client in raw 005, and I can\'t think of any reason for an IRCd not to follow this practice.
The maximum number of channels a person is allowed to simultaneously be in are also included in raw 005. At least, that information is sent on UnrealIRCd, and while I haven\'t tested it on others I would be that they would send it as well.
After connecting to DALnet, for instance, you receive a message like this, displayed before the MOTD:
<- :aeon.ix.us.dal.net 005 YOURNICK NETWORK=DALnet SAFELIST MAXBANS=200 MAXCHANNELS=20 CHANNELLEN=32 KICKLEN=307 NICKLEN=30 TOPICLEN=307 MODES=6 CHANTYPES=# CHANLIMIT=#:20 PREFIX=(ov)@+ STATUSMSG=@+ :are available on this server
And it says in this message that the maximum number of channels you are allowed to be in at one time is 20 (MAXCHANNELS=20)
Ugh. What happened to the bracket formatting?
Also, there is no effective way for closing the client. For instance, if you needed to restart your computer, you would have to ensure that everyone was logged out of the bot first, or else manually change the values in udata.ini. Otherwise, when you opened the client running the script again, anyone who was logged on at the time you closed it would still be considered logged on, even if they had changed nicks or quit or whatever.
Hash tables are probably the easiest way to solve this problem since the data in a hash table is automatically cleared on exit unless explicitly saved. Therefore, even if the client crashes and the on EXIT event is not triggered, nobody will be logged in the next time you start the client.
This snippet does what $duration should do and converts a string like 2w4d10h3m2s into seconds. Usage is $lduration(string) where string should be formatted as above. Accepted time measures are the same as for $duration and include w, d, h, m, and s. Poorly formatted strings, such as 5m2h4m, are okay (the previous example would be evaluated the same as 2h9m).
A big improvement, I think, would be maybe a timed query only ignore after denying a query...this way users couldn\'t spam you with popup windows by rapidly querying you; you just deny it once and there you go.
Another thing is I would try to use $input rather than a dialog in this case. You don\'t have to, but if you decide not to then consider a dynamic name for the dialog (so the dialog open command would look like /dialog $+(query.,%qnum) query) so that you can have multiple dialogs open at the same time. The problem with what you have now is that if Person A queries you and while you are deciding whether to accept or decline, Person B queries you, you\'ll get some errors since it tries to open up another dialog named query, but it can\'t since there\'s already one open.
I suppose you decide that for yourself, based on the overall, all-inclusive quality of the script.
I personally think it should be scored based solely on function. If it works well and is practical, it gets a good score. If the coding could be neater, that\'s something to talk about in a comment, but I don\'t think it should affect the snippet\'s score.
The only exception is if the code is really ugly and the snippet is made to be modified for a person\'s own purposes. Then it SHOULD be judged on neatness and efficiency of the code.
