Crise

Management
 View profile  See their activity

  • Content count

    3008

  • Joined

  • Last visited

Posts posted by Crise

  3. Posted

    I know, I meant just removing it from the about box and only having it in chat commands. But I'd like to keep stats in the aboutbox too.

    i planned on keeping the per session upload and download stats and overall upload and download stats in about box and just remove the uptime...

  6. Posted

    I don't understand Kadmelia code wise, but your post is the reason why it's not implemented.

    I think BM was trying to say that as kad has nothing to do with hubs, the code that is ccurrently on revconnect really cannot be made to work hub specificly, as DC and kad are after all two totally different network protocols which work in two totally different ways... (that's how i understood it anyway)

  7. Posted

    will the kademlia network be implemented in the upcoming release or at all ?

    don't get me wrong not wanting to be rude, but as long as i am in here and DC's implentation of kad is like it is now kademlia will never end up in ApexDC++ :)

    if someone seeks some kind of reason, my answer is private hubs...

  8. Posted

    as sidetrack stated above DC cannot die as long as the development of hubsofts and client programs will be in progress, only possible way to kill dc would be to prevent running the client from end-users computer, and as far as i'm aware only one that can do this completly is our friend micro$hit, by preventing the execution of uncerifricated software on their windows os (ofcourse cracks for this would be out pretty soon), but as this is unlikely to happen, i'd say DC cannot die in long long time

  11. Posted

    wat was the point of neXT++ you never even did anything with it

    am i right

    the forum was up for about a month then you made ApexDC++ and about a month after that you closed that forum. you never even made a home page for neXT++

    so wats the point of even talking about it now or even creating it for that mader seince you trashed it befor you did anything with it anyway

    i'm just kind of repeating myself arnt I.

    we aren't creating it neither is anyone else

  13. Posted

    Isn't it possible to take this particular part of the code and to try? You are the experts, but this seems not connected with Unicode and other changes. Are there any obvious reasons that it would not work...?

    first of all we are not the experts, people like BM, PPK and armethduck are the experts, and let's not forget the others either (i could continue the list a lot further)

    and the unicode isn't a problem and neither are most of the other changes, i'll take look into this but i ain't promissing anything

  14. Posted

    Yes, but as you said in the other topic (I know, the profi mode is link, but the topic about plug-ins), you have the contact details of the author and we suspect him in working over a new version.

    And what you mean with "outdated"? Date of expiry? Like with food, the code is not good anymore? :) Because it's really annoying to manage the files now - you have to either delete the file from the queue, or to wait till it's ready.

    by outdated he means that it (.PhantomDC++) is based on 0.306 version of DC++ (i think) and most current release version is 0.687... so the code is really outdated :unsure:

  18. Posted

    Considering BT and newsgroups max my connection it's kinda hards to beat, especially when not all the stuff on newsgroups is stuff hundreds of people have, same goes for a lot ofbittorrent sites. However, when getting popular files from large hubs I can max out also, most of the time I'm not even getting files which I can get multiple source for with DC anyway. :)

    actually grogs it's not that hard to beat, just find some user with [LYSE]-prefix and you should be getting pretty dam good speeds :unsure: (when you combine that with segmented downloading from other sources you should easily get speeds near to BT or newsgroups)

  19. Posted

    Request 4 is a leeching feature.

    Request 7 is pointless, filelist hashes change all the time... you'll have too many different hashes of the same username.

    What do you mean by request 3?

    maybe an ability to make some kind of link to directory or then an ability to convert links in directory names clickable...

    edit: currently it's possible to do links like: dchub://hub-addy.no-ip.net/SomeUser

  20. Posted

    1. transferring files via UDP protocol (if it isn't done already)

    2. "hidden shares": don't show specified files in the user's filelist, but answer to the corresponding search request that the file is present and allow to download it

    - semihidden files (not present in filelist, but present in the answer to search request)

    - fully hidden files (not present ever in the answer to search request) - for specified hubs/users only

    Maybe this should be specified on per-hub basis or ever per-user basis?

    3. links to the directories :mellow:

    4. disconnecting peer with file size less then X by the client (wery desired)

    5. maybe mirroring functionality

    6. PeerGuardian in the box :mellow:

    7. filelist sharing (download user's filelist from enother user on the hub)

    8. must use saved filelists preforming the search

    9. client-client enscryption (not only client-server)

    Sorry if I've posted any duplicate features.

    numbers 2,5,6,7,8 are certainly no, and 9 is not likely, oh and i don't understand request 4

  22. Posted

    Because the small upload slots (basically for filelists) already does this feature... but only for files below 100KB. We need to somehow change this to only apply to filelists and not allow them to change the max file size. The ability to change the size should be moved to the small lots instead, and put at 5MB default.

    So we have a regular slot, filelist slot, small files slot... all of them being configurable.. I'd say these are defaults:

    Regular: 2 slots

    Filelist: 3 slots

    Small: 1 slot

    ok, but easiest way to do this is, not to have separate small slots but just to allow current small upload slots to upload only filelists, and then just juse slot granting system with these new small slots.... could you follow?

  23. Posted

    option 1 sounds great thpugh maybe do it like this:

    Option 1: x small upload slots for files below x MB if they match user suplied filter of file names extensions etc. (x being customisable, and filter being optional)

    what do you think?

    ps. why is this topic hidden?

  24. Posted

    and what would it write in tag/description ? Something like "Hub A: XXX GB, Hub B: YYY GB, Hub C: ZZZ..." I think it's weird :-P People are lazy so they would share only minimum what they can.

    i was thinking just something simpler, something like this perhaps:

    when using this feature on any hub connected to, add in description prefix [Variable Sharer] to all hubs or something like that, so then op's could easily kick all users using this feature

    edit: or then it could read the prosentage of total share in it like this:

    let's assume we have user with 100gb share, connected to 3 hubs using different shares on each hub.

    In hub A he shares 30gb and in hub B he'd share his full 100gb and in hub C he'd share 50gb

    then the client would add following to users description:

    In Hub A: [30%]

    In Hub B: [100%] (or not at all as he'd share his full share in this hub)

    In Hub C: [50%]

  25. Posted

    I guess that the client with this feature will be banned everywhere ... or hubs will increase their minimum share size

    why would it be banned?

    I have alredy said that this could be done in a way that it'd:

    a) be detectable via tag or description for example...

    B) be disabled when using DC++ emulation (only would apply to mods with emulation cababilities)

    and i understand why CraKteR is against this, but i won't understand why you are as you have added many eh.. questionable features to SDC++ before (limiter & segmented downloading) and this features have alredy caused SDC++ to get banned in countless of hubs, though thanks to your efforts with DC emulation SDC is still usable in public hubs...

    but as i have alredy said this discussion is pretty much pointless....