Kulmegil

I'm not much of a programmer but judging from ClientManager::getSharingHub I think Apex will only check whenever first hub where user is connected has hide share enabled. Shouldn't it check all and if even one has hide share disabled then download should proceed normally?

"Polacy nie gęsi..." jak mawiał Rej. Idąc w duchu z tym mottem pragnę powitać w polskim dziale poświęconemu klientowi ApexDC++. Ten dział jest połączeniem działów sekcji angielskiej czyli: * Zgłaszanie propozycji nowych funkcji * Zgłaszanie znalezionych błędów * Pomoc odnośnie konfiguracji albo działania klienta * (nie bądźmy formalistami) innej dyskusji związanej z tematyką Direct Connect Jeśli chodzi o spolszczenie ApexDC++ to mamy dobry plik językowy autorstwa Patrol'a, który możemy znaleźć w dziale "Customize" na stronie głównej. Plik zgrywamy do kat. Apex'a po czym w menu File >> Settings >> Appearance wybieramy do niego ścieżkę i restartujemy (tylko klienta oczywiście). PS Jeśli chodzi o tłumaczenie materiałów np z działu "Guides" to jestem jak najbardziej za. Tylko proszę nie oczekiwać, że się tym zajmę osobiście w najbliższym czasie głównie z braku czasu Niemniej wolontariusze zawsze są mile widziani.

Many options are already here, some are obsolete , outdated or are removed because are always on. Besides putting every available option without consider is not good idea. Use partial file sharing upload => always on when You use multi-source Advanced resume using TTH => obsolete (ApexDC++ always use advanced resume by TTH) skiplist is in Settings => Advanced Load few last lines from log on new PM in Settings => Experts => PM history Search history in Settings => Experts => Search history Max number of alternate source is in Settings => Queue => Manual settings of number of segments (otherwise depends on file size) upload Enable ZoneAlarm detection now in Detect conflicting software Show icons in tabs ... always shown? Blend tabs instead of using bold font I think now Zion style tabs ? Check only unverified chunks after downloading now obsolete Filter userlist on every key stroke (uses more resources) here as Activate search/userlist by pressing Enter Keep duplicate files in your file list - always kept Tab completion of nicks in chat - start typing some1's nick in chat and press TAB

"steal" is such a nasty word. Anyone can pickup am o.s. project and continue it, especially since original one "died" (and AirDC++ become unofficial continuation) . Since we are at "Free/Total HDD" it's always a good time to implement some "don't start download if no free space on device" option :(

Someone has to make the first step. It's not gonna change if we don't do anything. Maybe it would be a good idea to remove emu on ADC first?

I'm just saying Apex should flow in direction of not having emu at all. Anyway it should be only used on "stupid" hubs that doesn't allow this good client.

But this way user at least has to use BRAIN... otherwise he would just leave emulation on all hubs coz it's easier.

This look's like a cool MAN network. Sounds like fun.. how much DC users? Anyway... instead of increasing segments, You should focus on disconnecting slow downloads. There are there several options affecting this behavior, in: Settings >> Downloads Settings >> Queue Settings >> Limits

Definitely NOT and it doesn't have anything with hardware capabilities. It had been discussed a lot in the past so make some effort and search. (and there's no "get Your hands away from max segments" option in the pool..)

It would be not. And why would You want to promote a client anyway? Primo - probably You're not gonna detect (especially as non OP) exactly what kind of client other person is using. For example: there are few leecher mods based on Apex so promoting Apex You would also probably promote them as well. Secundo - aside from faking clients (witch usually are v.hard to impossible to detect) user's client doesn't say anything whenever user is a f***ing lame leecher or good sharer. It already has - check "Grant slot" option. Using 'Favorite users' is good idea also. I do agree that there are still open possibilities to implement (especially in ADC when users are identified properly) and promoting user based on his previous uploads wouldn't be a bad idea.

I think We're missing the problem right now... it's not really that important whenever Apex (or any other) is (classified) an OP client or not. The point is - there are LOT's of moron OPs out there juest waiting for any chaeting string to pop out - without considering what it really mean, is detection accurate or anything. If We're talking about AML (I'm 99% sure we do) then even IF Apex wouldn't be classified as OP-client it would (according to scheme) have "Multisource Client Detected" instead and probably You would still be kicked, only with different reason. I don't see the point in kicking OP clients from my hub as long as they don't contain any bad features (and are up to date with min requirements as userclients) and I'm strongly against it. I also disagree with putting "OP Client Detected" in cheating string in AML - only contain this info in comments. And IMHO what should be done (probably... somewhere in the future) is to modify clients profile list structure. It could contain all possible feature tokens in the header (like: "OP features", "faking share", "emulation", "multisource<10", ect.) and each client profile would only contain info witch features are presented. OPerator would have to consider (using brain is recommended) witch features are acceptable and would be able to set correct RAWs with just a few clicks (even if list would contain hundreds of clients). Much more flexibility isn't it? ;)

You need newsbot... ask hub stuff to put one. Users'll start to use it with time.

imho - thats what log analyser tools are for.

hmmm... Orgazmo? edit: (@*&$()@ hate beeing second :(

Adding user without CID is imposible, and that's not exactly the point of discussion... but wait (testing) Hmm.. It's a good TIP to know If I add user without CID (or broken CID, using notepad for example) but type exact Nick and exact hub address new pseudo CID will be generated. So... in result "NMDC hub favorite user" is generated. If I would like to add ADC user I must type only his true CID - get it from FL (nick is optional ... FL name contain user's nick also). SUMMARY: Aside from editing config, "add favorite user" isn't pointless: all it needs are 3 fields - CID, nick, last hub address. If user type just Nick & hub address or type incorrect CID string - pseudo CID will be generated (NMDC fav user otherwise ADC fav user). PS - Also some1 smart might want to write a patch: whenever You edit NMDC Favorite Hub address it will also generate new pseudo CIDs for all users from that hub.

You can find user's CID in his filelist and You can add Favorite users manually editing Favorities XML. EDIT: but it's a real CID... useless in NMDC hubs, but more then enough to add ADC user. To ADD NMDC favorite user You need exact hub address and exact nick. There might be an option (creator) "Add offline user" asking for either CID or Nick&Address. It could be a confuse to "standard Apex++ user" But if someone is interested - see Tip in my next post to add users by changing Favorites.xml Also I think favorite users nick is just for show (since DC++ 0.68 and users identified by CID's) and You can change it as You wish (I include such option in my mod, and didn't see negative results... favorite users are still identified properly).

but You can: a ) make full release with translations if there was beta or RC sooner b ) make lite version of apex (small without translations and extras) and bigger (more emos & all translations) following later. c ) one can make custom installer with language file making it easy for n00bs besides the point is to make lang. selection as painless as possible ;)

So to the point, my proposition: Add /Languages dictionary to Apex++ root Add language selection button into "cool Apex first startup screen" pointing default to <Apex++ root>/Languages dictionary Simple and very user friendly.

omg... back to the topic. I think it would be great to have language selection box (witch will list all language files in directory), and a quick link to the box (maybe in Settings -> General). Even ability to load some default file in default config. would make a difference.

Yeah I know that. But when the clock is ticking (the minimum_search_interval) the search hasn't been yet sent to hub. So it's 'just' the meter of identity search in queue and remove before it's sent. Since on some hubs it could be a a mater of another 1-2 minutes of waiting, it's worth the trouble. And most of all... since there is already minimum_search_interval option implemented there should also be such possibility, because from user point of view (psychological effect) it's frustrating not being able to cancel his mistake before it bear its fruits.

It would be good if Apex++ remember other options especially what hubs were searched last time (at least I find it very annoying as an OP). Remembering can always be disabled globally in settings. Also "search bu default" on fav hubs would be nice imho. And a small button for "wait, don't search for that" to prevent countdown and abort search (or why just don't make "Pause search" do that?)

Sorry for so much changes, hope it's readable now :wub:

This would probably require some tinkering on other client also, but can be done - ADC is still draft, and NMDC would require some new little extension (like Queue Position sending in recent SDC++). A ) For example adding some FL token (like CRC32 or TTH) to get filelist requests and to filelist itself also. Other client would either send back filelist or "it's ok" msg. It would always send back filelist if not supporting this feature. B ) On ADC proto tokens could be sent with INF (it should be short). This way other clients would know when filelist changes. And when doing it smart (like replace for example FS with token, witch would also contain number of files info) it shouldn't even make more then 2-3 chars more for entire INF! Also in NMDC this could be added for tag, however most hubs don't display tags. It's really a small price to pay for removing re-downloading FLs burden! ...anyway... exact share size (and number of files on ADC) is a very good indicator whenever FL has changed. So option to either re-download or open from disk could be done without any proto extensions. But it won't replace "download filelist" of course since it's not 100% accurate.

It probably can be done... it's just "how to done it the smart way" and "is it worth the effort for dev." Maybe it would require some tinkering ... but doing it the same way fav users are tracked for last hub address wouldn't be probably to much resourceful consuming. Out of the recent suggestions I would vote for A. searching downloaded FLs B. checking if FL has changed and not re-download again* * this would probably require some tinkering on other client also, but can be done.

I was going to try, but need to put up new VM (I formatted partition with my VM's by accident) first.