Big Muscle

it's not possible without increasing exe size and memory/cpu usage and it's main reason why it has been removed. The feature is obsolete and unuseful.

no, it's not possible and there's no reason why it should be done.

the last version of DC++ is emulated and DC++ doesn't have upload limiter, so you can emulate DC++ with disabled limiter only.

yeah it would be nice, so I could limit users to minimum value and give the maximum speed to OPs, so i can't be banned due to low speed :)

hub can't detect whether you use segmented downloading so there's no reason to disable it just enable Emulation :)

I don't see any point why to include $MyInfo spam using switching away mode.

then you have an option to completely disable multisource in Settings :fear: that superseeding can mess it up, but i can't say it does, because i have no experiences with its code, so I don't know how it selects chunk size - if it selects chunk size where it can't ensure that other chunk will begin out of that chunk then it can causes trouble with losing a slot. Chunk size/start position must be selected to ensure that the whole chunk will be really downloaded from that user without interruption.

yes, implementation is same (at least I expect that according to the client which PeerWeb/ApexDC are based on) If you have emulation enabled and downloading from 1 source then it's exactly the same way of downloading as in vanilla DC++ with one exception - our TTH leaves verification is still enabled. 2Zlobomir: You can't disable segmented downloading per hub. Just imagine you are downloading one file with many users and some are from "segmented" hub and some are from "non-segmented" hub. What to do then? Download the file using segmenting or not?

emulation is per-hub based, but segmented downloading isn't. And user shouldn't enable emulation if it's not really needed. But most of users always enabled, but it's their problem.

but there's no reconnect :)

the implementation is still same, only the settings page has been moved to Queue page and some of these settings have been removed because they have no meaning - 99% of users manually set maximum segments. if you got disconnected then user disconnected you or the connection failed but it has nothing to do with segmented downloading.

firstly, learn how segmented downloads work and then start talking bull ****

i should only remind that if you modify exe file, than you have to provide also modified source else ou violate GNU/GPL. it is all the same to me, but someone could complain.

yes, for about 5 - 10 second but I've never lost my settings/favorites/queue, neither if I interrupt the process manually. there's one thing - when you terminate the process, it can delete your queue.xml. Yes, actual queue is in memory, so it won't be saved, but there exists old queue.xml on your harddisk. If someone write some nice patch which avoid happening this situation, I will, of course, integrate it into StrongDC++. But I don't respect any post-checking whether current file is correct There must exist solution to have this file always correct and avoid damaging.

i've already removed auto-saving queue on startup.

I always shutdown my PC immediately after closing StrongDC++ and it has never happened to me :D

it's interesting to see how reliable your system is.

yes and StrongDC++ is prepared for the worst situtation which it can occur by its own activity. (What about making ready for situtation "if hacker attack my downloaded files, StrongDC++ should recognize it" )

if you do it during saving system registry then it won't start it happened to me in the past :blink:

just try to change path of your system registry and your windows won't simply boot without any try to fix the problem.

if you don't have any hardware problem (as me or many other people) than you will never have some problem with corrupted downloads. I downloaded tens of GB in last weeks) and nothing of it was corrupted (I always manually check whether TTH matches).

no it's not important, because when information is in queue.xml, it means that it exists (that's the purpose of queue.xml)

if uploader sends corrupted data then you will see message "TTH inconsistency", source will be removed from queue and block will be redownloaded. Current TTH checking method catches every corrupted incoming block, because each incoming byte is checked against TTH tree before saving to your HDD.

btw I found a workaround for this problem. It's flushing data using FlushFileBuffers before information about verified block is stored to queue.xml. But this can be too time consuming and can decrease overall download speed.

no, it only checks first X kB when resuming whether the file is same. It can't detect faulty blocks because they already has been verified and marked as ok, but your computer corrupted this information.