Crise

well it's not our fault the same user is in all of (or at least 4 of them) the hubs you are in You can only take one slot per user, but same user on different hub is considered as different user by (Apex)DC++ because of the pesudo CID's used in non-ADC environment to put it short you can only take one slot per user per hub, because of the CID's used in NMDC-environment

Nope leave the filename out And to Toast, will this URL be persistent?

There won't be a solution as the are just not able to be converted/imported... You have 2 possible solutions: 1. Download all your old filws with PWDC, and then upgrade (i recommend this, always the safest) 2. Search alternates for all queued files (the auto searching will do this for you, but it will take time)

the sources are not compatible between ApexDC and PWDC, so you need to search for alternates most likely...

what do you mean exactly, screenshot?

Only he can answer those questions... and as the last info I have is somewhat old I am not even willing to make any detailed statements regarding this subject, to avoid giving out false or inaccurate information.

You hit the nail on the head (though even before i wrote that post/footnote i knew that the changes him reading it would be close to non-existent)

any more details such as how has he set up his client etc...

That's not all of them but many are listed there though.

Read f.ex. Here and Here. As for not having to set segments to 200, that is true but there are many many users that will always set segments to the max they can, even though in reality with most connections and correctly configured slow downloads disconnecting you only need 5-8 segments or even less... if you are on well sourced file. And the mod has other "questionable" features as well, which have been covered in the two topics I linked above

ADC is a protocol. not a client Anyways you can see if the tranfer is encrypted from the progress bars

ADC is a "next generation of DC" (well really it's pretty much completely new protocol that has some similarities to the old one, an improved version of it you could say) But for the time being it's still work in progress :)

find an adcs hub (they are probably bit hard to come by though)

And using patched wtl and stlport (stlport must be compiled), as well as have wmp.h and ddraw.h?

You are compiling with visual studio 2005 (8.0) right?

You don't see force connection option there because it could be used for manual hammering of users :whistling: (I only checked what options that dropdown actually had after writing that post)

Sorry can't forget ot quite yet... had to comment on this I thought it's commonly known that bugs are in fact just features waiting for removal :stuart:

well some parts of the guide have not been updated in a long time (read: Someone is too lazy to do it :whistling:) In regards to the errors sure you followed the later version posted by ifmn...

If it's something he has said or something that he shares, reporting to hub operators should be enough :whistling:

Settings > Advanced > Experts Only

TYRRAM, you can download and upload on DC without being a "thief" as P2P is just as legal as f.ex. knifes are. You see, one may use a knife to cut slices of bread while the other may use knife for killing or stabbing people... same item but the way of use is what may or may not be illegal. So if someone chooses/has chosen to make P2P technologies illegal they should also make many everyday items illegal as well... as P2P (and in our example knife) is just as legal or illegal as the user of it is. This is just to show that you should never go with stereotypes, when making statements against or for some previous statement... you should stay with facts. What developers have rights to do and what they don't is not that simple... so I am not even going into that here. But what i do say is that it indeed is developers responsibility to ensure that his software does not harm nor abuse (or have means to do so) what it's living from. If we do think of SMT's mod alone it does not harm DC as a whole, but it sure has means of abusing it (to some extent every multisource client abuses DC in a way... because multisourcing is not something that this network was originally designed for, you can this from the fact that DC doesn't have such things as upload queue f.ex.) So after this you may say that every multisource client is as bad as the other regardless of how it limits (or doesn't limit) the maximum amount of segments or what other limitations it may have. But there is also other things that developer tries to achieve and one of them is making his software as efficient as possible. And here is where, in DC's case, developers have to make more than a few tough decision, because we have no magic tricks we can do to improve download speeds, so we have to "take" that speed somewhere in some cases it's compression but in many cases that has little or no impact so we need to do something else... we would f.ex. have to multisource. Here we however face the limitations of the technology we are using and we should realize that excessive multisourcing does more harm than good, in an environment that's not particularly designed for it. Here is where our goals and responsibilities don't go hand in hand with each other and here is also where opinions differ. There are three choices which each is represented in the wide variety of DC clients out there: 1. Developer decides that since the network is not designed for it it should not be done at all (this is also unfortunately the choice most hub/network owners prefer as well) 2. Developer decides that since it's not right to discard the fact that careless multisourcing may harm the network he has to make a compromise because he still sees the advantages of multisourcing and he sees not only those that affect the downloader but also those that affect the spreading of content in general. (I see the limitations that exist as this very compromise that has been made). Before anyone says that 200 segments is also a limitation it's not solely about the fact that the limitation is there it needs to be sensible also, regards to this there was a good post done by BM on these forums somewhere but I was unable to find it for the time being. This second choice is also the choice which I personally would like to see becoming more accepted amongst people. 3. Developer discards the limitations of the technology and thrives only for his goal with the expense of the other users. In this case also the advantages of faster spreading of content no longer even out with the resources (in our case slots) consumed from the network. Edit: Darn you Zlobomir you were faster than me :whistling: Edit 2: Also comparing P2P and knifes was not my idea originally, I read similar comparison waay back on one DC relatted forum, but can't remember the original poster anymore. Edit 3: And the post i was referring in this post can be found here (the whole topic actually is pretty good discussion about the segment matter)

:stuart: Though why to copy paste it from some list of symbols when it's on your keyboard? (at least in keyboards with the fin/swe layout/positioning)

Thanks for refreshing my memory (it is good just way too short) As for this topic the missing of "fav.xml" can't ApexDC's installer bug (as i have said that the installer should not install any settings/data files, because the client generates them on it's own, and it does this just fine) The most likely culprit is vista (not saying if it's a bug or not... just that the root of the "problem" has something to do with how vista handles it's read/write permissions etc.)

If dollar sign isn't allowed that's most likely because it's a protocol char in NMDC protocol :whistling:

UPnP should work just fine with 0.4.0 (read: same way that it works in StrongDC as we have not modified the implantation in any way)