Kulmegil

Member
  • Content count

    175
  • Joined

  • Last visited

Posts posted by Kulmegil


  1. 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?


  2. 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


  3. "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 :(


  4. 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


  5. It also would be great if i can set priority to the client (apex user of course =)

    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 would be great if apex can have priority to a specific user i select.

    It already has - check "Grant slot" option.

    I want to have priority to those ppl who share back those things they dl from me so that other ppl dun hv to wait too long to get files from me

    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.


  6. 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? ;)


  7. 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 :P

    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.


  8. Just tell me where do I get a CID of an offline user first, and then we can think about this :P

    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" :blink:

    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).


  9. 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 ;)


  10. Assuming Apex remembers the location that you open your language files from, I'm surprised people want this. It'd still only accessible from the same place in the Settings? Maybe if it made downloading of language files then it'd help, but this feature is just requesting that Apex detects which language files are installed and presents them in a list for the user... Surely opening browse and selecting the file is just as quick if Apex remembers the directory.

    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.


  11. 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.


  12. 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.


  13. File type

    I love how fulDC remembered what you file type you searched for. Let's say I make a search for "Metallica Master of Puppets". If the file type was set to any I would find the song "Master of Puppets" and I would also find the album. I usually search for directories, but every time I make a new search Apex changes the file type to any. It would be nice if one could set it to remember what the last file type was.

    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?)


  14. some posts ago i linked another topic on this forum ... in which there was a feature request to get a checker who would see if the filelist has not changed since last time, than don't download it, but open from local ..... this few days old could not be always a good one as if someone is putting 0-day stuff in every day .. you won't see it ..... but as in that topic, i wrote an idea if a checker would check if it has the same size from the same username and if some other usually constant values also match, than open the local .... and if the size has changed, then download it again :wub: ... i guess you're thinking of this feature, right?

    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! :wub:

    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.


  15. 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.


  16. +1 for deleting thread linking to cheating client :/

    unfortunately DC doesn't have global search mechanism, and just busting into hubs You don't stay in normally and makeing some searches doesn't make You (to say it lightly) a popular by hubowners person also.