Kulmegil

My post is not related to any official TODO list, it's my suspicion It's upto client devs to confirm any informations it there are such Speaking of Apex itself - what happened to development page?

Many people are waiting for this, including me... I rather shouldn't expose TODO list, so let's say that Your preys might have been heard and may (or may not) be answered someday, who knows?... so stop complaining. :)

Oh why all those "super" mods include: removing max segments limit, limiter ..limitations. With all good intentions I rate it as cheating mod (as well as SMT's mod, Still I like some of his ideas). And with those public available maybe I will have to think of banning Apex someday. So make world a favor and keep those as private releases or available only to Your group of leechers, like Stealthy. :/ => full automatic mode for slow users disconnecting And how's this toy working exactly?

OMG, what a pile of crap... 0 true arguments. Thank God You are wrong, and not everyone is stupid enough to give up TTH... and if they really want to share without hashing they chose either FTPs either other P2P network. IMHO - DC community IS ****ed up by people thinking like You (especialy when they are hub admins), and demanding DC to stay their way. IF You hate hashing so much then why do You use TTH based client anyway!??? If God didn't create Woman it would be really gay world to live on TO very1 - Sorry, I can't stand those idiots any longer :)

1) Adding all kind of winamspam additions is a waste of devs time imho... There is one winampbar already, end it's one to much. I don't get the idea of adding any player controls to webbrowsers, P2P apps, FTP clients, antyvirus software or whenever. 2) How? And what's wrong with this one? (except for search frame that need some improvements) 3) One magnet link points to a single file. Probably it could be a idea to make possible of adding multiple magnets from clipboard at once (like in emule pasting many ed2k links) 5) This feauture has been there for eons. You have to tick checkbox for each favorite user in Favorite Manager window.

5-6MB in Your case. Probably much less then hashindex + hashdata. FL size isn't a problem here... but the actual implementation of generating and distributing them. Although I write all this - it's definitely not my top REQ. I wonder why devs keep saying that it's possible only on ADC. Maybe it would simply be easier or they plan to implement it some other, simple way. If so I wouldn't really force them...

FL will be generated in settings directory when needed (use File >> Open own file list to force it's creation). 40K files would generate around 1,5MB FL? We are really getting offtopic here :D

To be precise - FL size depends directly on number of files (and average filename size but we can skip that coz it's totaly unpredictable; dir takes up only around 1/3 space compared to file entry). And one more obvious factor is that "old style", uncompessed *.DcLst is larger then new *.bz2. I could found easily guy with 17,36GB share and 1,8MB FL. I have 11k files total. PS Size won't will be even less important (in terms of getting them) on ADC where You can grab only important part of FL

hashindex / hashdata will keep all files overall. Changing that will rather make more mess then helps. All You have to altered is: * what exactly will be generated on FLs (FL is relatively rather small... but I saw very few users with FL over 10MB) (I have 1,4TB and FL only takes 450kb - but it's really number of files that metters) * witch FL is send to users depending on hub, much like Hide Share mod (I'm not sure if hide share works in ADC correctly) * last but not least - search responses also depending on hub.

Well... judging from the fact that "hide share" works perfectly and block responses for hub with hidden share it's also possible to alter search results for this purpose. And for filelist it's just a matter of generating additional one (or more) I think (whenever you generate normal one) with filtered content only. Although I didn't day it's that easy when comes to implementation :x

I think it could be done to make DC++ generate different filelists, but I don't know about search responses.

Nooo... DC++ devs removed support for non TTH downloads.

it looks quite easy "on the paper" but I really was going to put similar feature into action. I definitely lack skills from all dc devs unfortunately. But since someone has put out this req. I have this question somehow related to implementing similar thing... I'm trying to figure how much userconnections are related with hubs. All I know now is that userconnection object has "hubUrl" string. I also know how DC behave in NMDC environment, but ADC is quite new to me: I have this user who has an interesting file I want to get (so he's a source). We are connected together to let's say 3 hubs. In those are NMDC hubs it will try to make connection on each of them, coz it doesn't recognised that my source is the same user. But how will DC++ react on ADC? Will it make a connection on each hub? (if not how can I determine witch hub specific slot should be taken by user?)

+ I basically think that would be both to complex (PM send interval, number of warnings before disconnect, fitting PM message controls into gui). And as I know reality devs probably won't like to bother simple users with such stuff as 'customizing PM warning message for multiple users uploading from same IP'. It looks more like a job for some comlex LUA scrpit rather then build-in option. As for this "ipsend"... (some addition to send internal IP address of user, right?) I'm not sure about technical possiblities of implementing. Yes, IF possible and someone bother this could solve problem. But only limited number of clients supporting it and ADC next door is it worth the trouble?

Makes no sense for me to do it other way. Users has no control how their client choses sources, the can only manually disconnect extra downloads (or disable multisource). And PMs can be simply ignored by users who want to leech at max speed. And sending PMs..... umm, there was some client that sent back PMs when other passive user tried to download... we (OPs) had a lot of fun reading those spam warning messages on OPchat Don't think it's a good idea. When ADC will become common there will be no need to worry about current problem, when users will be recognized properly, not depending on nick or hub. It's not to common to find 2 different users with same IP DLing from You at the same time. Even if such situations happen all they have to do is wait a bit longer until users they share IP with will finish (small price for sharing same IP) Well.... maybe on some special hubs with a lot of users from same ISP - if You use those don't turn on "maximum connections from same IP" or use high value.

Well I would like to know what the devs thinks from both "ethical" and technical point of view. FulDC++ has terminated compatibility by removing support for clients not using $adcget. I don't care to much whats the min. DC++ version to connect* (0.6XX?), but how it affects other non DC++ based clients. It would be better to cut them at lower levels - like in SDC++ or DC++ best. * Coz all "alive" and non-op DC++ mods are based on 0.674 or newer.

Wouldn't it be easier to simply ask for "maximum connections from same IP"?

I think topic title is pretty self-explaining.* Makes even more sense on ADC when favorite user is not bounded to hub anymore like it's done now. And not all hubs has offline messaging functions/plugin. * In case if it's not: You type a message in Favorite Users manager and message is send as soon as user becomes online. Message can be send directly if user is online already in any hub - this could be useful also in case if You want to find favorite user fast in a bunch of opened hubs (ADC). Extra req: Please add some additional fields (columns) like properities for favorite users. This will be useful for stroing additional information about them, and each column is sortable. One field is not enough sometimes.

Personally I don't care that much since min version on my hubs and other I visit is 0.674. It's not really worth all this fuss. But if You really can block only those old clients then it's perfectly fine... I'm afraid there is a catch, isn't there? like cutting off much more versions then 0.3XX (even 0.4XX) and ODC :/

So why this topic exists? The main reason is that old clients ARE able to download from ApexDC++ but they souldn't - since You cannot download from them either. It would be reasonable and fair. on the other hand - ODC and similar ... things fanatics can stay in their own hubs and no one should bother them - it's their choice of religon PS I think more then enough has been said in "old crap" topic. Still topic is coming back (with old arguments rather) all the time... why?

Am I wrong or is all this topic shortend to : "I want to remove those restrictions limiting speed limiting" If You want "freedom" don't use limiting at all. I'm sorry but DC is not a torrent, witch is ratio based, so all it has against leechers is to force temporarily upload speeds to be set as high as possible. Well keep building Your policy, and if You are really persistent about having freedom to chose both limiter settings and slots go and search net out there. There are plenty of leecher mods on the net without any "stupid" restrictions. They often even include fakesharing feautures extra :D

I really think that just online messaging system is easy enough to get implemented in this century but, in case someone has the time to prove me wrong, here is how I see this: (it's close to Ð.Sp!dér idea, meaning it's hub independent) An offline message is sent to Your favorite users (and saved by Your client also). Those, who also have You as favorite user and their client support offline messaging, will save the message. Yes, this will make offline messaging very limited at the beginning, but as it's popularity grow, and implemented in more clients it will work fine. And this should be really necessary to keep all kind of flooders, spammers and other trash away from exploiting this feature. All messages should contain, except message itself: receiver CID - to get the message exactly to the target person (no need to pass nick) sender CID - Your CID so reciver will know that it was You who sent it sender nick - well nicks are recognized by humans instead of CIDs so this might be needed also (maybe instead of sender CID?) expiration date - time after message is discarded if not deliverd (in days, optional*) data sent - date message was created Just in case if it gets to easy: Clients should recognize same messages passed from multiple favorite users so either by existing variables (text, sender CID, ect) or by addidional message UID. Filtering multiple copies and showing message in separate window (as if it was sent from You on PM). Recivers who don't support messaging system will get multiple copies and as PMs from favorite users passing message. Maybe offline messages should be passed only to X favorite users or should be passed directly between clients (ADC) to avoid to much hub spamming... * clients will discard undelivered messages after some max. period of time anyway

Yeah. but You have no guarantee that those sources You keep as "backup" will still give You slot when You want to switch. There is a 'chunk overlapping' function already in SDC++ witch is suppose to leave fastest sources when there is "no free block" - it disconnects slower and faster user continues his segment. I suppose it's not working perfectly since no one mention it earlier? :)

Well it won't be exactly as torrent. You'll depand on lots of open connections (killing Your own or ISPs routers) while good torrent clients don't need it. So don't forget to remove 1,2KB/s (as far as I remember) min download limit for segmented downloading coz You'll need it Torrent clients connects to different users to get parts, while DC slots are "permanent" (unless You get disconnected under some conditions). Maybe it would be good to (experimentally) implement a slot rotation system based on waiting user queue size? (I was thinking to do it some day - just lack skillz) Part distribution is also very important here, and even clents like ApexDC++ or SDC++ misses a lot to torrents. Still it may be worth to experiment as long as it remains a non poublic experiment. And You'll need to convince a bit of people to get some reliable test results.

Ummm... Did I say it should work when I'm offline? I wanted just simply messaging addon so it would send message if I'm away or unaware of user joining presence - but online. As for 100% offline messaging it would be nice but needed hub support (some standardizations would be necessery). But small problems arise here: You would have to leave msg on all hubs connected to since in ADC user is not bounded to hub anymore. Some hubs won't like it and disable. Some UID for messages so You wont get multiple copies of same message from different hubs when joining... and so on.