Crise

You know, this is a free world and the source code is there for anyone to take... as for Source being what 1.2.1 is all about I wonder what do you wish imply with this? Sounds like a misunderstanding, I have cleaned the useless posts out . So now as BigMuscle stated let's stick to the topic... also to anyone reading this do remember that StrongDC++ 2.30 is the client where DHT debuted in, so it should be pretty obvious it is not in ApexDC yet but it certainly will be at some point just to make it clear.

Well it's possible but I don't see a need for such feature (mainly because my mouse has "next" and "previous" buttons that work with Apex). What you ask might or might not be added don't know yet for sure but in any case it won't exactly have a high priority.

Regarding windows 7 (and vista for that matter as well) check that you are either, explicitly, running ApexDC as administrator or have given it full permissions in it's own directory.

I suppose it can be done... though in that case decorated names come to play, although I suppose def file can resolve that easily enough for us.

Maybe, but it would clutter the code... This is not something that you can do without, quite a bit of, extra work...

Remove the shared folders from dcplusplus.xml manually and then do it...

Try to disable fast hashing, it's an option in settings under advanced :D

None, because there is no need for such feature as there is no limits to the amount of hubs you can connect to at one time. Not in clients but hubs may impose such limits on their users if they so wish (which is what horus22 is experiencing). In such cases the only viable solution is to search for hubs which have loose limits or no limits at all.

Find hubs that don't kick you for being in that many hubs Client such as ApexDC++ can not implement this kind of feature.

But you have to understand that if you always run for older version and just say "New version does not work" it in fact will never work. Because if I knew what caused your crashes I would have worked on fixing them by now. In other words I need info from those who experience issues with the latest version in order to do something about them... because I do not personally get the "luxury" of experiencing every problem in ApexDC personally so that I could look into it. Edit: also note that error messages or exceptioninfo's are not the only thing you can add to your bug report... Be creative about it, the more information the better (but too much of it isn't good either). F.ex. When we ask of user having a problem with ApexDC++ "What were you doing?" Of course if he was not watching the app when the problem occurred he can't answer that but then the creativity comes in (because it is of no use for us if he states that ApexDC++ was running on the background), so then maybe he should tell us as much as he can about what could have been the "prerequisites" for the problem. I could write a lot about how to report bugs here but please also take a look at this: http://forums.apexdc.net/index.php?showannouncement=4

Oh but not having an official spec doesn't mean it's not available, just look at NMDC :stuart: Thus is the case with ADCS also, it is very much available and used from what I can see...

Will consider doing this in next major version, won't make it in the minor and/or maintenance updates though.

There are plenty of support topics about this on the forums, the solution is to ensure than ApexDC++ can write to it's own directory.

Well /winamp is always there... any adittional ones can be found from Media Players plugin. + commands are hub side commands you should prefix your command with the slash (/) to get the client side version. ie. /me f.ex.

I'll add all the missing country codes reported, provided they are standard, assuming RadoX here or someone else is willing to add them flags. No hurry though, but it would be nice to get it done for next minor version (which should have been out some time ago imo, lucky that we do not give release dates tho).

I have cleaned the topic up, you can continue what it was you were doing at the place where I moved those posts if you like. But in here act as is appropriate. I will only say that ADC needs to be made more user approachable (read: easy to use and feature rich hubs, with a GUI) then and only then can ADC be actively promoted and results be expected out of it. Note that (G)UI's are not necessarily restricted to actually being part of the physical hub software (although many users might prefer such approach for simplicity on their end). But atm. no hubsoft makes it possible to build external UI's even, excluding adchpp and Sulans GUI which is on hiatus atm, and there aren't any plans (aside aforementioned) for desktop GUI either (wxWidgets FTW). We'll have to see what happens when Offset is done with his Web Interface for uHub (though he has to start making it before he can be done with it).

Actually now that you mentioned Montenegro... there should actually actually be flag for the Serbia + Montenegro combo in the flags image I think (should be between the flags of costa rica and cuba if I read the source code correctly). Looks like no-one just bothered to make the change when GeoIP separated those two. Anyways... better to have both , and also leave the old (combo) flag and CC there in case someone uses an old version of geoip. Edit: not wanting to sound picky but the last one of the two new flags (montenegro, I assume), seems to look bit different from the rest (ie. the 3d'ish effect seems to be different/missing).

Most likely it is your â

Default is 2 slots :)

I never once said something is inferior (or superior) to to Apex nor vice versa. I didn't even raise a real argument... I just asked a simple question. I'm not so cheap as to neglect valid reasons, like you seem to think... but I have yet to see any other reason, from you, besides "just because". I never change the DC++ version we send while "emulating" it stays as it comes from StrongDC++ (and is thus only updated when merges happen). First, RSX++ a cheating client? How so? Now here we have reasons, real ones, and here is what should be noted, for future: 1. DC++ 0.75 already does segmented downloading (some form of multi source too these days, unless I am badly mistaken). 2. Bandwidth Limiter is already in DC++ svn trunk (albeit it has a bug or two to work out) and that trunk version still identifies itself as 0.75 (for now) I think, but this I need to check.

You know, Apex can be spotted even when emulating... and it will even more so when we merge some changes from SDC. If the hub owners are too lazy to figure out how, then sorry no cookie for them You say emulating is cheating if that is the case then do something about it, don't expect us do it for you. Because we obviously do not think that emulation is cheating (since if we did that option would have been removed ages ago). Anyways, could you perhaps give me a list of reasons why DC++ 0.75 (since that is the version we "emulate") should be allowed in a hub and Apex shouldn't... I am more than interested in hearing these reasons. If you are unable to do this then the whole discussion about emulation going on in here is pointless (since I don't even consider changing anything if the reasoning behind it is "just because"). Taking the RSX case when YnHub uses the "<RSX++ 1.00>" as description, it is doing the right thing... because that *is* the description (whether it is automatically added or manually typed is irrelevant).

To be more precise it was StrongDC++, but all the same really, "upstream" anyways.

Then that means there is no hub running on that port/machine or that the firewall on the hub machine is blocking incoming connections.

You might, in that case want to try a shorter nick, as that message is coming from the hub... so it is possible that it is just sending the wrong message.

Well at least you know what's causing it, so avoid the problem for now and don't loose connection to any hub you connect to :)