venom_il
11-08-2003, 06:26 PM
updated - 21/12/03
Credit - Magnet0
Explanations that don't have to be read and can be skipped are in italic
Settings
----------
* Open mIRC
* In "DCC" choose "auto get file" and "if exists, resume" (this means that anyone who will send any file to you - you will auto accept it and start getting it - you will soon see why this is necessary, )
* In "IRC" -> check "rejoin channels on connect" and "rejoin channel when kicked"
* In "Connect" -> "Options", check "reconnect on disconnection"
Also, click on "Perform" -> in "All networks" (select from top list), paste:
/remote off
/pdcc on
/fsend on
/ctcps on
/raw on
/events on
"/Remote" makes sure you don't have problems with some chans, "/pdcc" and "/fsend" speed up sends and the 3 last ones allow the MAIN addition which will immediately be introduced (credit to the nice ppl at the mirc.com forum who wrote this code based on what i asked + stephen for his debugging :) ):
Exit the Options window, Press alt+r and paste this exact code in the window that pops up (it should be the mIRC Script Editor, Remote tab):
On *:GETFAIL:*: {
btrunc $+(",$filename,") $iif($calc($file($filename).size - 512000 ) > 0, $ifmatch, 0)
}
on *:FILERCVD:*: { .timers off }
The first command is an implementation of RESUME ROLLBACK. I can't stress enough how important this is. This means that whenever a send dies and we resume, the file is resumed some 500KB (or any other number you choose) before the last reception. This should ELIMINATE corruption problems which I for one have had a lot of - cases where I'd download a 2 GB tar file, only to find out quite a few rar files inside were corrupted. And if you think that doesn't happen often statistically, think again. There are whole (packed) channels dedicated for sending missing rar files to ppl whose tars were corrupted. The best one i know of, btw, is #incomplete on Efnet, they have explanations there, a list of other similar chans, a web site (http://www.incomplete.pwp.blueyonder.co.uk), the works. It's a mandatory channel (actually more like a network) to know of, regardless.
The second command halts all existing timers upon a dcc send completion (a "download" in mIRC). At this point you might ask "WTF ?!!?!? " or something along those lines, justifiably. But this command is actually just a complement to something we'll do later. Let's carry on...
As we all know, IRC bots, even on the best, most popular and most quality channels, are highly unreliable. FACT - at ANY point a bot could die in the middle of a send to you, at which point 2 things would happen:
a) You would lose the send, obviously
b ) The "dying bot" *might* send you corrupt data (this is the only source for corruptions that I know of, other than the bot itself having a corrupt file to begin with, which is quite rare, especially on quality channels). But that's why we have implemented our own little system of resume rollback. Actually, mIRC has a small rollback of 8 kb upon resume, but that's not enough. I don't really know, maybe 500KB isn't enough as well, and whoever downloads from mIRC probably has a connection that downloads ~100KB in a second anyway, so maybe even setting a resume roll back of 1 meg or even more when dealing with large files would be better. the alteration to the code i gave is obvious (switch 512000 to whatever size you want, in bytes). In any case, moving on
If we're on a queue to a bot (i.e. when we type the trigger we got from ircspy, the bot sends us a message in the form of "all send slots full, queued you in position x out of y", which means you'll get the file when a send slot is freed [someone who's getting the file now finishes getting it], although there are x-1 before you), and that bot dies (disconnects or gets f/cked up for any reason), we're out of the queue (even if that bot returns/is fixed a second later). Accordingly, if we're receiving a file and the bot dies, the bot isn't going to automatically resend us the file, even if it returns ok later. And if we're merely on queue, we won't even hear the "triple-alert beep" mIRC would play when an ongoing send fails. Actually, even when a send fails I wouldn't count on alert beeps too much, as they are highly unreliable in mIRC - sometimes they beep, sometimes they don't.
So, seeing as a bot can die in any given moment, the only way to make sure you're downloading what you want until it's finished is to sit in front of the computer and monitor the send, right? Wrong. That's why we have a wonderful little command called "/timer". You can find the full syntax in mirc help, we'll just use a basic configuration. Timers will help us both GET in the queue, and STAY in the queue (or even better - quickly resume what we are getting) automatically.
For simplicity, let us assume that we're following KrackHead2k's (excellent) guide and get into whatever channel / network with the trigger "/ctcp xdccbot1 xdcc send #1" in your clipboard. Let's also assume that the queue if full (10/10 on queue for example). Many times all the good bots (I actually sort the bots by transfer speed in ircspy) have full queues. This means that when we fire up the command IRCSPY has given us, the bot will give us a message in the likes of "bot queue is full, try again later". The only way to work around this is to continuously type the trigger ourselves until we get lucky and query the bot right after some user has finished getting his file and a queue spot has cleared up, and before someone else takes it. However, this must be done in sufficiently long intervals, as spamming the bot every 10 secs is bound to have you quickly banned. Sometimes minimum bot intervals are stated in the topic or rules, sometimes they aren't. In the latter case, I recommend using ~6 minutes. Here's a simple timer command that does just that, that is, types in the trigger for you every 6 minutes automatically. Type it in the same place you put the IRCSPY trigger before:
/timer6 -o 101 300 /ctcp xdccbot1 xdcc send #1 (this timer's name is "timer6")
The "101" means that this timer will only be executed 101 times, which should be quite sufficient when our goal is simply getting into the queue, and setting it to 0 (infinite) or any significantly higher number is prone to be detected by the mods as abuse which would lead to a quick ban. If you HAPPEN to be in the vicinity of the computer, it wouldn't hurt to check from time to time whether you've gotten in the queue so you could shut the unneeded timer (with the command "/timer6 off"), although not necessary - this guide is all about downloading things off IRC without being around the comp. If the queue isn't full, skip what we just did (i.e. don't create timer6).
Now, onto the second timer (even if you're not on queue, you don't need to wait until you get in, put the following timer right after you put the last one and let them work simultaneously):
/timer7 -o 0 3600 /ctcp xdccbot1 xdcc send #1
thus we have created a timer called "timer7"
This timer will simply request the file from the bot every hour (i.e. type in the trigger automatically for us every 60 minutes).
Regarding both timers - if you're on queue or already downloading it at the moment the timer kicks in and sends the trigger to the bot - no harm's done, the bot tells you "you're on queue" or "already requested pack #1" or some such and as long as you keep reasonable intervals you shouldn't get booted. Going lower than an hour in this timer (=changing 3600 to something lower) is risking ban, as this timer is infinite, i.e. it will run until you shut it down (well, actually no because of the script we put in the beginning, but that's for later). This timer will make sure, once every hour, that we are downloading, and if not - we'll be put back on queue or resume the download without user interference (that's why we needed auto get and resume). [You might ask, "but what if a bot dies, and then before the timer kicks in (this could easily be 50 minutes) the queue is filled?" the answer to that question is that it almost never happens :) all slots + all queues, especially after a bot unexpectedly dies, take some time to fill. come to think of it, though, if everyone used this guide, I'm not so sure that would be true anymore :lol: ]
Now the second command in the script we wrote in the beginning kicks in - as soon as the download (any download) SUCCESSFULLY finishes, all timers are halted (terminated) and therefore we don't spam the bots with no need, which is always a good thing (both for you and for the channel). It also prevents you from trying to download something you already have, thus wasting BW and queue position. And finally think about this - the send finishes successfully, but the timers (or timer, if the finite one has finished or you shut it down) keep on going. so one of the timers re-requests the file, the bot sends it to you, mIRC cuts 8 kb off the full file you have (remember mIRC's built in resume rollback?) and THEN the bot dies and never returns again, before it sends u those 8 kb's you just cut off :D
Now, if you're downloading more than one file thing at the time.. Simplest thing I can think of is use multiple instances of mIRC, one for each file. They are allowed by mIRC itself (but don't use multiple sessions for the same chat room !!! it is called cloning and you will get banned !!!) and take very little resources. I seldom download more than one file since IRC usually maxes out my connection anyway.
And if you have other timers you don't want to be halted for some reason, you can easily alter the script i gave for example use:
on *:FILERCVD:*: { .timers7 off }
instead, to shut down the infinite timer we've built rather then all of them (that's assuming timer6 is already shut down or finished, or never existed to begin with)
i think
on *:FILERCVD:*: { .timers6 off }
on *:FILERCVD:*: { .timers7 off }
would shut both of them, though i don't know mIRC scripting so i can't be sure (not sure if you can write "on FUBAR" twice). you can ask around on mirc.com's forums.
Comments:
**********
* The -o trigger on our timers means that they will keep working even if mIRC gets disconnected from the network, which could very well happen. That's why we have enabled "automatic reconnection" and "rejoining the channel" on that event. In other words - we have created a "leave and forget" system which makes IRC much like k-lite in that regard, albeit much less sophisticated, accurate and reliable (mostly due to the fact the network itself and the bots aren't)
* Obviously, this system can be improved. For example, one might write a script that rather than running a crude timer that makes sure we're downloading every hour, would retype the trigger as soon as it's notified that the bot is on the network (after it, or you, got disconnected) or that the download has failed for any reason, but the bot is still there. I think it would require the use of the "notify" system in mIRC (which is useful by itself) and shouldn't be too hard. I haven't had time to try it myself though - and you'd have to change the script for every download you do (to put in the bot name and trigger)
* I recommend everyone to verify resume rollback is functioning well (it will require a restart of mirc since part of the implementation is in the start up) - go to some xdcc channel, download a file, any file, and when it reaches say 500K hit cancel (don't press the X button as it won't count as a failed download and the script wouldn't be triggered!!!) and then check to see if the file is 400K in your hard drive as it should be. If this is not the case, double check everything and if it still doesn't work ask here :)
Also, another little tip is that some some channels may change the default xdcc send command so you'd have to msg their bots with "xdcc OPTIC send #1" or "xcdd gimme #1" or the likes to get a file, in stead of the usual "xdcc send #1". For whatever reason they're doing this, the command IRCSPY and the likes would put in the clipboard won't work. So its important always to check the chan's topic as well as !rules and !help etc triggers - keep an eye out for notices in the main chat, too. A good strategy would be to look at the commands for other bots in the chan when their ads pop up (not necessarily the one you want to download off), especially if they have the same "structure". For example, looking at XDCCBOT2's command would give us a good idea on how XDCCBOT1's command would look like (simply switch XDCCBOT2 with XDCCBOT1 in XDCCBOT2's cmd). However, [uber]bot1 may have an entirely different command syntax - but again, it's pretty rare. Actually, it's best to ALWAYS read the topic and use !help triggers etc, as they can provide very interesting information. For example, some channels allow "xdcc list" which lists all the bots and packs in the chan (while others ban you if you type it). Some chans will allow "!xfccfind searchstring" or "@find searchstring" while others will ban you for it, etc. In channels that allow either of these 2 or some similar commands, keep in mind that they usually support wildcards, for example "!xdccfind *sam*" will find both "samuel" and "osama" :D
Whoever goes exactly by this guide wouldn't need the services of an anti-virus program.. ever. It goes without saying that you don't download anything you haven't asked for explicitly from a bot, fserv or the likes. Yeah, i know auto get is on so simply delete whatever was sent to you that you didn't ask for (never happened to me yet, though). And bots serving proper releases just never have viruses, it's unheard of. However, users of k-lite (or should i say *KMD*), that's a whole different story :P
One last thing: taken from Winrar WinRAR 3.30 Beta 1 changelog (http://zonehd.net/downloads.php?op=voirfich&fid=127):
Now it is possible to decompress TAR, GZIP and ISO9660
archives of any size. Previous versions could not handle
files of these formats, if they exceeded 2 GB.
so make sure you use a later version of winrar if you unpack tar files larger than 2 GB, or just use winzip. I'm not sure how winace handles such files, so I wouldn't take any chances
PS - there exist scripts/programs meant for downloading off xdcc's that have similar features I believe - they go by names like "bottler", "xdcc catcher" "ork" and others. The problem with them is that all the chans HATE them and if they detect you're using such a script - perm ban, goodbye. And they have ways to know. However, following this guide shouldn't get you banned/kicked (it hasn't gotten me anyway) from anywhere. Especially if you happen to shut the first timer (the 6 mins interval one, that only exists to get you into the queue) after you got in, or there's a free queue slot and you don't have a need for it, or u use a number smaller than 100 repetitions if you happen to know that chan is not extremely packed and busy. Lastly, none of these scripts/progs have adjustable resume rollback as far as I know, which is something I wouldn't go without anyway (DC++ has it for ages, and for a good reason).
Credit - Magnet0
Explanations that don't have to be read and can be skipped are in italic
Settings
----------
* Open mIRC
* In "DCC" choose "auto get file" and "if exists, resume" (this means that anyone who will send any file to you - you will auto accept it and start getting it - you will soon see why this is necessary, )
* In "IRC" -> check "rejoin channels on connect" and "rejoin channel when kicked"
* In "Connect" -> "Options", check "reconnect on disconnection"
Also, click on "Perform" -> in "All networks" (select from top list), paste:
/remote off
/pdcc on
/fsend on
/ctcps on
/raw on
/events on
"/Remote" makes sure you don't have problems with some chans, "/pdcc" and "/fsend" speed up sends and the 3 last ones allow the MAIN addition which will immediately be introduced (credit to the nice ppl at the mirc.com forum who wrote this code based on what i asked + stephen for his debugging :) ):
Exit the Options window, Press alt+r and paste this exact code in the window that pops up (it should be the mIRC Script Editor, Remote tab):
On *:GETFAIL:*: {
btrunc $+(",$filename,") $iif($calc($file($filename).size - 512000 ) > 0, $ifmatch, 0)
}
on *:FILERCVD:*: { .timers off }
The first command is an implementation of RESUME ROLLBACK. I can't stress enough how important this is. This means that whenever a send dies and we resume, the file is resumed some 500KB (or any other number you choose) before the last reception. This should ELIMINATE corruption problems which I for one have had a lot of - cases where I'd download a 2 GB tar file, only to find out quite a few rar files inside were corrupted. And if you think that doesn't happen often statistically, think again. There are whole (packed) channels dedicated for sending missing rar files to ppl whose tars were corrupted. The best one i know of, btw, is #incomplete on Efnet, they have explanations there, a list of other similar chans, a web site (http://www.incomplete.pwp.blueyonder.co.uk), the works. It's a mandatory channel (actually more like a network) to know of, regardless.
The second command halts all existing timers upon a dcc send completion (a "download" in mIRC). At this point you might ask "WTF ?!!?!? " or something along those lines, justifiably. But this command is actually just a complement to something we'll do later. Let's carry on...
As we all know, IRC bots, even on the best, most popular and most quality channels, are highly unreliable. FACT - at ANY point a bot could die in the middle of a send to you, at which point 2 things would happen:
a) You would lose the send, obviously
b ) The "dying bot" *might* send you corrupt data (this is the only source for corruptions that I know of, other than the bot itself having a corrupt file to begin with, which is quite rare, especially on quality channels). But that's why we have implemented our own little system of resume rollback. Actually, mIRC has a small rollback of 8 kb upon resume, but that's not enough. I don't really know, maybe 500KB isn't enough as well, and whoever downloads from mIRC probably has a connection that downloads ~100KB in a second anyway, so maybe even setting a resume roll back of 1 meg or even more when dealing with large files would be better. the alteration to the code i gave is obvious (switch 512000 to whatever size you want, in bytes). In any case, moving on
If we're on a queue to a bot (i.e. when we type the trigger we got from ircspy, the bot sends us a message in the form of "all send slots full, queued you in position x out of y", which means you'll get the file when a send slot is freed [someone who's getting the file now finishes getting it], although there are x-1 before you), and that bot dies (disconnects or gets f/cked up for any reason), we're out of the queue (even if that bot returns/is fixed a second later). Accordingly, if we're receiving a file and the bot dies, the bot isn't going to automatically resend us the file, even if it returns ok later. And if we're merely on queue, we won't even hear the "triple-alert beep" mIRC would play when an ongoing send fails. Actually, even when a send fails I wouldn't count on alert beeps too much, as they are highly unreliable in mIRC - sometimes they beep, sometimes they don't.
So, seeing as a bot can die in any given moment, the only way to make sure you're downloading what you want until it's finished is to sit in front of the computer and monitor the send, right? Wrong. That's why we have a wonderful little command called "/timer". You can find the full syntax in mirc help, we'll just use a basic configuration. Timers will help us both GET in the queue, and STAY in the queue (or even better - quickly resume what we are getting) automatically.
For simplicity, let us assume that we're following KrackHead2k's (excellent) guide and get into whatever channel / network with the trigger "/ctcp xdccbot1 xdcc send #1" in your clipboard. Let's also assume that the queue if full (10/10 on queue for example). Many times all the good bots (I actually sort the bots by transfer speed in ircspy) have full queues. This means that when we fire up the command IRCSPY has given us, the bot will give us a message in the likes of "bot queue is full, try again later". The only way to work around this is to continuously type the trigger ourselves until we get lucky and query the bot right after some user has finished getting his file and a queue spot has cleared up, and before someone else takes it. However, this must be done in sufficiently long intervals, as spamming the bot every 10 secs is bound to have you quickly banned. Sometimes minimum bot intervals are stated in the topic or rules, sometimes they aren't. In the latter case, I recommend using ~6 minutes. Here's a simple timer command that does just that, that is, types in the trigger for you every 6 minutes automatically. Type it in the same place you put the IRCSPY trigger before:
/timer6 -o 101 300 /ctcp xdccbot1 xdcc send #1 (this timer's name is "timer6")
The "101" means that this timer will only be executed 101 times, which should be quite sufficient when our goal is simply getting into the queue, and setting it to 0 (infinite) or any significantly higher number is prone to be detected by the mods as abuse which would lead to a quick ban. If you HAPPEN to be in the vicinity of the computer, it wouldn't hurt to check from time to time whether you've gotten in the queue so you could shut the unneeded timer (with the command "/timer6 off"), although not necessary - this guide is all about downloading things off IRC without being around the comp. If the queue isn't full, skip what we just did (i.e. don't create timer6).
Now, onto the second timer (even if you're not on queue, you don't need to wait until you get in, put the following timer right after you put the last one and let them work simultaneously):
/timer7 -o 0 3600 /ctcp xdccbot1 xdcc send #1
thus we have created a timer called "timer7"
This timer will simply request the file from the bot every hour (i.e. type in the trigger automatically for us every 60 minutes).
Regarding both timers - if you're on queue or already downloading it at the moment the timer kicks in and sends the trigger to the bot - no harm's done, the bot tells you "you're on queue" or "already requested pack #1" or some such and as long as you keep reasonable intervals you shouldn't get booted. Going lower than an hour in this timer (=changing 3600 to something lower) is risking ban, as this timer is infinite, i.e. it will run until you shut it down (well, actually no because of the script we put in the beginning, but that's for later). This timer will make sure, once every hour, that we are downloading, and if not - we'll be put back on queue or resume the download without user interference (that's why we needed auto get and resume). [You might ask, "but what if a bot dies, and then before the timer kicks in (this could easily be 50 minutes) the queue is filled?" the answer to that question is that it almost never happens :) all slots + all queues, especially after a bot unexpectedly dies, take some time to fill. come to think of it, though, if everyone used this guide, I'm not so sure that would be true anymore :lol: ]
Now the second command in the script we wrote in the beginning kicks in - as soon as the download (any download) SUCCESSFULLY finishes, all timers are halted (terminated) and therefore we don't spam the bots with no need, which is always a good thing (both for you and for the channel). It also prevents you from trying to download something you already have, thus wasting BW and queue position. And finally think about this - the send finishes successfully, but the timers (or timer, if the finite one has finished or you shut it down) keep on going. so one of the timers re-requests the file, the bot sends it to you, mIRC cuts 8 kb off the full file you have (remember mIRC's built in resume rollback?) and THEN the bot dies and never returns again, before it sends u those 8 kb's you just cut off :D
Now, if you're downloading more than one file thing at the time.. Simplest thing I can think of is use multiple instances of mIRC, one for each file. They are allowed by mIRC itself (but don't use multiple sessions for the same chat room !!! it is called cloning and you will get banned !!!) and take very little resources. I seldom download more than one file since IRC usually maxes out my connection anyway.
And if you have other timers you don't want to be halted for some reason, you can easily alter the script i gave for example use:
on *:FILERCVD:*: { .timers7 off }
instead, to shut down the infinite timer we've built rather then all of them (that's assuming timer6 is already shut down or finished, or never existed to begin with)
i think
on *:FILERCVD:*: { .timers6 off }
on *:FILERCVD:*: { .timers7 off }
would shut both of them, though i don't know mIRC scripting so i can't be sure (not sure if you can write "on FUBAR" twice). you can ask around on mirc.com's forums.
Comments:
**********
* The -o trigger on our timers means that they will keep working even if mIRC gets disconnected from the network, which could very well happen. That's why we have enabled "automatic reconnection" and "rejoining the channel" on that event. In other words - we have created a "leave and forget" system which makes IRC much like k-lite in that regard, albeit much less sophisticated, accurate and reliable (mostly due to the fact the network itself and the bots aren't)
* Obviously, this system can be improved. For example, one might write a script that rather than running a crude timer that makes sure we're downloading every hour, would retype the trigger as soon as it's notified that the bot is on the network (after it, or you, got disconnected) or that the download has failed for any reason, but the bot is still there. I think it would require the use of the "notify" system in mIRC (which is useful by itself) and shouldn't be too hard. I haven't had time to try it myself though - and you'd have to change the script for every download you do (to put in the bot name and trigger)
* I recommend everyone to verify resume rollback is functioning well (it will require a restart of mirc since part of the implementation is in the start up) - go to some xdcc channel, download a file, any file, and when it reaches say 500K hit cancel (don't press the X button as it won't count as a failed download and the script wouldn't be triggered!!!) and then check to see if the file is 400K in your hard drive as it should be. If this is not the case, double check everything and if it still doesn't work ask here :)
Also, another little tip is that some some channels may change the default xdcc send command so you'd have to msg their bots with "xdcc OPTIC send #1" or "xcdd gimme #1" or the likes to get a file, in stead of the usual "xdcc send #1". For whatever reason they're doing this, the command IRCSPY and the likes would put in the clipboard won't work. So its important always to check the chan's topic as well as !rules and !help etc triggers - keep an eye out for notices in the main chat, too. A good strategy would be to look at the commands for other bots in the chan when their ads pop up (not necessarily the one you want to download off), especially if they have the same "structure". For example, looking at XDCCBOT2's command would give us a good idea on how XDCCBOT1's command would look like (simply switch XDCCBOT2 with XDCCBOT1 in XDCCBOT2's cmd). However, [uber]bot1 may have an entirely different command syntax - but again, it's pretty rare. Actually, it's best to ALWAYS read the topic and use !help triggers etc, as they can provide very interesting information. For example, some channels allow "xdcc list" which lists all the bots and packs in the chan (while others ban you if you type it). Some chans will allow "!xfccfind searchstring" or "@find searchstring" while others will ban you for it, etc. In channels that allow either of these 2 or some similar commands, keep in mind that they usually support wildcards, for example "!xdccfind *sam*" will find both "samuel" and "osama" :D
Whoever goes exactly by this guide wouldn't need the services of an anti-virus program.. ever. It goes without saying that you don't download anything you haven't asked for explicitly from a bot, fserv or the likes. Yeah, i know auto get is on so simply delete whatever was sent to you that you didn't ask for (never happened to me yet, though). And bots serving proper releases just never have viruses, it's unheard of. However, users of k-lite (or should i say *KMD*), that's a whole different story :P
One last thing: taken from Winrar WinRAR 3.30 Beta 1 changelog (http://zonehd.net/downloads.php?op=voirfich&fid=127):
Now it is possible to decompress TAR, GZIP and ISO9660
archives of any size. Previous versions could not handle
files of these formats, if they exceeded 2 GB.
so make sure you use a later version of winrar if you unpack tar files larger than 2 GB, or just use winzip. I'm not sure how winace handles such files, so I wouldn't take any chances
PS - there exist scripts/programs meant for downloading off xdcc's that have similar features I believe - they go by names like "bottler", "xdcc catcher" "ork" and others. The problem with them is that all the chans HATE them and if they detect you're using such a script - perm ban, goodbye. And they have ways to know. However, following this guide shouldn't get you banned/kicked (it hasn't gotten me anyway) from anywhere. Especially if you happen to shut the first timer (the 6 mins interval one, that only exists to get you into the queue) after you got in, or there's a free queue slot and you don't have a need for it, or u use a number smaller than 100 repetitions if you happen to know that chan is not extremely packed and busy. Lastly, none of these scripts/progs have adjustable resume rollback as far as I know, which is something I wouldn't go without anyway (DC++ has it for ages, and for a good reason).