v1.16.0 - The Channel-Aware Release

• Fixed (security, Windows): a list archive from another bot could make DCCore write to a device instead of a file. A file inside a fetched zip or RAR list named like a Windows device (NUL, COM1, con.txt) was opened as that device, which could stall fetching lists. Such names are now unpacked with an underscore (NUL_.txt), as DCCore already does for names it is sent elsewhere.
• Fixed: a large download queue drew more slowly and dlcancel all could take tens of seconds. The Download queues window's snapshot is now capped per message like the Downloads window's already was (the full count still shows), and cancelling several requests - or dlcancel all - lets them all go in one pass instead of one at a time. dlcancel all followed by extra words is refused instead of cancelling everything. Update dccore.mrc to 1.17.1 and reload it with /reload -rs dccore.mrc.
• Fixed (mIRC): "Clear the queue of ... and ignore for..." no longer clears the queue when the ignore is refused. The two steps used to run unconditionally; the queue is now only cleared once the ignore has actually taken.
• Fixed: a search reply's From: line could start with ! under a custom theme. A border, separator or text-box colour set to certain text could put it, unescaped, at the very start of the line. The line now always starts with the literal text From: , under any theme or custom colour.
• Fixed: the settings preview now shows an unsaved change to "Answer @find searches" too, the same as it already does for the theme colours.
• Fixed: -help no longer mentions searching when it is turned off.
• Fixed: a bot or an album folder named like a Windows device name (AUX, NUL, COM1 ...) could collide with one already named with the usual safety suffix. Each now gets a short, stable tag instead, so the two can never be mistaken for one another.
• New: a bot's other channel-bound list is discovered and held automatically. A bot bound to a different list per channel (the same feature DCCore itself has) used to only ever give up its first list, and a wrong second fetch could even wipe it out. Discover a bot's other channel-bound lists (Settings → Grabbing lists, off by default) watches for a genuinely different, stable list in another shared channel and holds it alongside the first - never instead of it - with no manual step, and keeps it fresh from then on.
• Fixed: a request to another bot goes to the right channel. A bot that serves a different list per channel could silently get a file/folder request that landed where it answers nothing. Requests now remember which channel a bot's list came from and reuse it automatically - including a retry of one, from either the dashboard's "Try again" button or dlagain in mIRC.
• Fixed: a late folder archive from a slow bot could be filed under the wrong queued row. When several folders were requested from one bot at once and one took too long, its archive could end up attributed to the NEXT folder in line instead - shifting every label after it and losing the true last one. A folder's late answer is now matched to the request it actually belongs to. A file request held back for retry could also, rarely, have its answer taken by an unrelated folder request to the same bot; this is fixed the same way.
• Fixed: a rare timing issue could reconnect the bot when an ignore from the dashboard landed at the wrong moment. An ignore or "stop ignoring" set from the dashboard or console could, very rarely, collide with the bot's own once-a-minute flood check and force an unplanned reconnect. It is now properly synchronised and cannot happen.
• Changed: a file asked for by private message is handled as part of the channel its sender shares with the bot. Its notices follow that channel's mode, the console and the @dccore window name that channel (before, they named your first channel, where the person might never have been), and nothing is announced in any channel for it. Someone who shares none of your channels is no longer served by private message - before, they were when a slot happened to be free and dropped when they had to wait. File requests by private message no longer show on the dashboard's Messages page.
• New: search can be turned off. Answer @find searches in Settings → Sharing & queue (on by default). Off, @find and @locator get no reply and the channel advert says Search: OFF instead of the Search: ON it always showed.
• New: search replies can say which folder each result is in. Turn on "Name the folder in search replies" (SEARCH_SHOW_FOLDER) and an @find reply puts a From: <folder> line above each folder's results - once per folder, not per file - so a studio, a live and a tribute version of the same song can be told apart. The result lines are exactly as before, so they can still be copied as requests, and the From: line can never be mistaken for one. A long folder is shortened from the left (From: ...allica\1988 - ...And Justice for All); "Longest folder shown" (SEARCH_FOLDER_MAX_CHARS, 80) sets how long. Off by default.
• Fixed: Download selected in a RAR list fetches folders, and many can be queued. Ticked rows of another bot's RAR list were asked for as files that never arrive, so the request repeated every minute and failed. They now go as folder requests, any number can be queued at once, and DCCore asks for one folder per bot at a time, starting the next when the one ahead has finished or failed. The same folder asked for twice is one request.
• New: a channel can be Quiet or Request only. In Settings → Served lists each channel a list serves has a mode next to its tick box. Quiet sends no advert in the channel but answers requests and sends its usual notices; Request only sends no advert and no notices either, and serves silently. The "Sent:" line posted in the channel after a transfer is dropped in both. A private-message request takes the mode of the first list-bound channel the user shares with the bot. Every channel is Normal until you change it, so an update changes nothing by itself.
• Fixed: a search word is matched against the file name only. @find info or nfo used to match every file, and the bot's own nick matched the whole list, because the words were also looked for in the !nick at the start of each row and the ::INFO:: size tail at the end. Now only the file name counts, as in the filter bar across lists. A size or bitrate (320, 10MB) is no longer something you can search for.
• New: the Stats page shows how transfers ended, and a success rate. Failed and cancelled sends, folder packs that failed, and downloads that broke off are now recorded beside the completed ones. A new "How transfers ended" table shows, for the chosen period, how many files, albums and lists were attempted, completed, failed and cancelled, and the success rate - completed out of completed and failed, so a stop or a cancel of yours does not count against it. Export CSV has a status column. Counting starts when you update; transfers before that all read as completed.
• New: a bot that keeps failing is paused for a while instead of being asked again and again. After 3 of your download requests to the same bot fail in a row (no answer, an offer that cannot be reached, or a transfer that breaks off), DCCore stops asking it for 15 minutes; its requests wait, and go out in order when the pause ends, even across a restart. The Downloads page says "Paused until 14:32 after 3 failures" with a Resume now button. A bot that answers "not found" or "busy" is not counted. Both numbers are in Settings (FETCH_BOT_MAX_FAILS, FETCH_BOT_COOLDOWN_MINUTES; 0 turns it off).
• New: users are told when the next slot is likely to free up. @nick-que and @nick-stats now say "Next free slot: ~4 min" (or "now", or "not known yet" before the sends have a speed), worked out from how much the current sends have left and how fast they are going; the dashboard's Live Transfers page shows it too. It is when a slot frees, not when it is your turn.
• Changed: asking a bot for its list (@nick) no longer waits behind everyone's files. The list takes the next free slot ahead of queued files (and goes at once if a slot is free), so a newcomer sees what the bot has straight away; the notice says "Your list is next". Only one list at a time can jump ahead, so a flood of list requests cannot hold up file sends, and asking for the list does not cost anyone their place for the files they already queued.
• New: ignore a nick for a while. ignore <nick> <minutes> in the console, or Ignore on the dashboard's Queue page: the nick's requests are dropped without a word until the time is up, even across a restart. unignore <nick> (or Lift) ends it early, and bans shows the time left.
• New (mIRC): ignore a nick and change the queue from the menus. Right-click a nick in a channel → DCCore → Ignore for... (asks for the minutes), Clear the queue of ... and ignore for... or Stop ignoring. The @dccore window's right-click menu has the same for the selected queue row, Move earlier / later in line, and prompts for ignore, unignore, move and remove under User control. Update dccore.mrc to 1.16 and reload it with /reload -rs dccore.mrc; an older script just does not have the items, and an older bot answers "unknown command" to ignore and queuemove.
• New: move, remove and clear in the queue. On the dashboard's Queue page each nick has arrows to go earlier or later in the line for a free slot, and Clear (it asks first); each of its files can be moved up or down or removed - the nick gets the same "Removed ... from your queue" notice as when they use @<bot>-remove <file> themselves. The console has queuemove and queueremove, and queue <nick> numbers the files. A file being sent, or a folder being packed, is never moved, moved past or removed. A nick whose list is waiting stays first, as it is served first. A move changes only the two nicks it swaps. The order is kept until the bot restarts.
• Fixed: a file is no longer requested twice from the same bot. Pasting the same line twice, repeating a search, or double-clicking Download made a second request, and the other bot saw the same !bot file several times. A file that is already waiting, asked for, queued there or coming in is now asked for once; the dashboard says it is already requested. Asking again after it finished or failed still works.
• New: DCCore can fetch from bots running mxrarserver. They now appear in the List Browser and are grabbed like other bots; requests go to their trigger word even when it is not their nick; their replies (queued and at what position, already queued, not found, compression failed) are understood; a list that takes a while to arrive is still taken; and their folders can be fetched with "Get folder as RAR", the packed folder being accepted under the name such a bot gives it.
• Fixed: a bot saying its list was "temporarily disabled" failed every folder download waiting on it. Only a real refusal of folder requests does now.
• New (mIRC): a Download queues window. Info → Download queues... (also in a channel's right-click menu under DCCore) shows every request your bot has made to other bots that has not started yet - files, !rar folders and lists - and lets you remove the selected ones or all of them, so you do not have to hunt for them one by one. A download that has started is never touched. Update dccore.mrc to 1.15 and reload it with /reload -rs dccore.mrc. The admin console has dlqueue, and dlcancel now takes several ids or all. (This is not Info → Queue, which is what other users have queued on your bot.)
• New: you can see a folder pack running, and cancel it. While rar packs a folder for someone, their row on the dashboard's Queue page reads "packing" with the folder, how big the archive is so far against the folder, and the time, with a Cancel pack button. The admin console has packing and packcancel, and the @dccore panel shows a Packing section with Cancel the running pack at the top of the right-click menu (update dccore.mrc to 1.14 and reload it with /reload -rs dccore.mrc). A cancel stops that rar, deletes the partial archive, tells the user it was cancelled, and lets the next waiting request start. Before, nothing short of the pack time limit ended a pack that was holding everyone else up.
• Fixed (Windows): a list or a folder named like a Windows device name no longer fails. Windows will not create CON, PRN, AUX, NUL, COM1-COM9 or LPT1-LPT9 (with any extension), so a list called NUL, a !rar of a folder called AUX, a file offered as NUL.txt or a bot nicked Con failed at the last step. They are given a name Windows can create (a folder AUX is stored as AUX_.rar on the bot's disk; the name offered to the user stays AUX.rar, so AutoQ still matches it). Naming a list like that in the list editor is refused with a message saying why; a list that already has such a name still loads.
• New (mIRC): the DCCore windows open by themselves when mIRC starts. @DCCore opens minimised, its button at the end of the switchbar, and its title says what it is waiting for (not connected to the network yet, the bot not answering yet, or no bot paired) until the console connects. Chat and Downloads can open at start too: tick them under "Open when mIRC starts" in /dccore options. Update dccore.mrc (1.13) and reload it with /reload -rs dccore.mrc.
• Fixed: a list another bot sends as a .rar replaced the list you already held with nothing. It was taken as a text list, came out with no files (or a few garbage ones), was reported as fetched, and the good list you had for that bot was thrown away. A .rar list is now opened with your rar program (the one !rar packing uses), with the same safety checks as a .zip list; without rar it is refused and your old list is kept. Any other file that is not a list - a .7z, or anything binary - is refused the same way.