Clouds: Try restarting mIRC to make sure the on START event has executed. Or, if you added this script with the /load command, be sure you answer "Yes" to the dialog that should appear.
Lindrian- The . just makes you not see the OUTGOING message; you\'ll see the incoming notice to yourself. Although it still could be done more professionally with echo, it works fine.
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.
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.
So...it just tells you when a person changes nicknames?
Since you have to have at least 1 common channel with someone for the on NICK event to trigger, I really see absolutely no use for this...
Sorry lol I made this thing a loooong time ago when i wasn\'t the greatest scripter...since there seems to be continuing demand for it i do plan to completely rebuild it with more useful functions.
That is basically what I use...i think you got mixed up or something though cause $calc($1 ^ $2) would return $1 to the $2 power, which is the opposite purpose of this snippet, thus i reciprocate $2 by doing $calc($1 ^ (1/ $2))
Try using more local variables...
There\'s no need for any globals in there.
Basically, replace any /set %var commands in there with var %var or /set -l
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.
Good script...I would like to see it make use of hash tables as inis are really a little excessive here and are slower. Code could be cleaned up a bit as well, but functionality is pretty good.
Good work :)
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.
