Kulmegil

I wrote of Favorite Users because I usually leave messages for them and it would be easiest to implement because favorite users manager already has GUI + favorite users are recognised by CID (and I expect it to work CID based). As for the OPs I have some idea for special op messanger, but since ApexDC++ OP hasn't even reached it's first release it's far to early to mention. Maybe I'm not a dev but I don't buy it. I expect it would rather be quite easy to implement.

Ummm... and I fought that You can't download form ApexDC++ using some old crap (lack of $ADCGET or something)?? o_0 Obviously this should be disabled if possible.

Not quite. You may cheat ops and hub for min. share this way. If You cheat fake file for some other TTH hash other users will get "tth incosistency" or "error during decompression" (if they got some brain they will report You). And if You create crap file with "good name" and generate correct TTH for it You will probably be alone sharing it. Well I certainly would consider using some preview application if possible before downloading complete file with very few seeders. Your attitude - "wow, I know something about cheating" is nothing really to be proud of. This makes more people with sharing really good / unique stuff going into private (closed) hubs. So what that they allow? Makes me sorry for them (probably if they really grow big they make more strict rules). And are those hubs with 5000 users and so many fakeres and lechers really worth staying? I don't think so.

There are plenty of clients that doesn't have hashing : oDC++, DC++ (0.3XX), ect. There is also lanDC++ for lan only users, who want's to skip hashing (alternative to Network Neighborhood), based on some ApexDC++ version. No one should bother you for staying on Your own hubs that allows You to use them. I would consider switching to using FTP servers. BUT A ) Don't bother operators to allow You to use that non-tth crap on public hubs (they won't if they really have slight idea on what they're doing) B ) Don't bother dc makers to keep compatiliblity with those clients. It's good for DC community not to have anything with non-tth clients sharing fakes, corrupted files and such... OK?

Great! But beware : there is still this misleading " Current Version:0.2.2 (Preview 2) " at top on WWW- in "welcome" news.

EDIT: maybe I change the question a little... is there a possibility to call UploadManager object from Util.cpp? I use UploadManager::getInstance()->getSlots() in static function in Util.cpp and I get this error: Error 1 error LNK2001: unresolved external symbol "protected: static struct Client::Counts Client::counts" (?counts@Client@@1UCounts@1@A) Util.obj PS shame I can't edit the topic, doesn't fit too much now.. :/

No it's not the same. Compatibility is usually kept for a certain amount of time, until keeping it becomes much of a burden or until there are benefits for keeping it (but it depends on the type of app we are talking about).

another "why dinosaurs had to extinct, I wanna see dinosaurs" topic. Except in DC network there are still dinosaurs... amazing topic should be "oDC IS problem" :)

Yeah, very recently .... 8 posts above :P

But IPs are only for active searches. I used it to check who is spamming the hub with constant, same searches.

It's gonna be implemented ... on ADC hubs era :blink:

Wouldn't it be better to use <CID> rather then <user name>?

I'm not 100% sure but: From what I rememberfilelists always can use minislots and filelist size is ignored - so "small file size" option is only for normal files that could be downloaded using minislots. It was kind of different in older clients.

You don't have to quote him directly, just say what great arguments he has - unless they are also a secret. But keeping arguments to himself is not going to convince anyone that his actions are reasonable in any way. Of course he doesn't have to if he don't care, it's his choice after all.

I think it should be something like filters to Transfer View : show only DL, UL, other (connecting, no slots, ect). Emule has some good filters for it's Transfer window. But I wouldn't make this it a priority req (imho).

Great, it's just that adjusting that's need some tweaking... would be good if all <nicks> started from the same line. IP displayed with fixed font... or even allow customize each element (general text, my nick, favorite user) with user selected font and size! or... (easier) Since good pattern, using tabulators can only be done for certain non-fixed font type and size (can be changed by user) I suggest to add posibility: - customize IP pattern just like it's possible for timestamps - timestamp pattern including brackets (so I can remove them)

OK, I give up... "Feature: Show user IP and country code in main chat..." where is it? :P

I wish that tick's could be used with oDC style progress bars... anyway... nice job!

It was removed by BM from SDC++ in the name of less resource consumption. Personally I would like it back, along with 2 other things removed, but maybe not only removed but with some improvements... system log like in DC++ shows to much spam, maybe along with some filter it would be nice (to show only important events, like errors).

You're a smart one posting both question and it's answer at once. It's definitely not in the spirit of P2P, and hubowners certainly wouldn't like to see a bunch of users connecting and disconnecting all the time. And it would certainly put a lot of stress on big hubs (there is a bit of data that needs to be sent when client connects).

This limit exists for a reason (yes, it's slot wasting in the first place). That would make SDC++ / Apex DC++ banned in most of those hubs who already allowed it (like on mine). Hope it won't be "implemented". Maybe You need to setup "disconnecting slow downloads" properly (in the settings >> limits).

Every admin sees his hub his own way. Sorry, I think this one is pretty stupid - "most people in the hub use older clients." isn't really an argument. If most people would use some fakeDC, would it mean that it's good to leave things as they are? I think that this guy just doesn't like that hashing thingy. Since from my personal experience it's quite possible to get corrupted files (and spread them) in lan environment (mostly because buggy clients or users bad hardware) it's already one big argument to kick non TTH trash, even in a small LAN hubs. As for other pros they are pretty much obvious. (...) So it's just 20 people... If Admin wanted to change it's just as much trouble as warn the others to upgreade, and probably most of them would follow. When I banned 0.3XX clients it was only around 1% of users "who just didn't get the message".

agree ApexDC++ still connects to 0.401, right? 0.401's are allowed only because of 9x/ME people (I don't like it, but have to live with just a bit more). Normal hubs doesn't allow nothing older to be used. Well... It's Your choice to stop "evolving", just because few other people decided to stay in the stoneage.

Lot's of people speaks about it... nah there is a lot more important things to implement sooner. If it's an OP client simply hideshare is enough.

It's gonna contain also post SDC++ 2.00 fixes I hope?