Zlobomir

IF you are sure that he is abusing, try to PM, then if no answer/bad answer, if he is with static IP, go to settings and use the IP filter. It will block not just his download, but your download from him too (i. e. IP filter blocks any communication with the set IPs or IP ranges).

imo when we assume that the majority of the users are fair, and not cheaters/leechers, we will be able to produce a decent client. As I have said before, the atomic energy can produce electricity, but it can kill as well. It all depends on the man (user). If the user is a potential leecher, he will use one of the many already available leeching mods anyway. If he is a fair user, he will go for a fair mod like Apex. Am I stupid, is it too hard to understand or what? :)

//OFF There are many nice and useful features in the mods, which I prefer. Say storing TTH in hash data, so regeneration at each resharing is avoided. ** Connecting to dc++.devs.all... //OFF

oh, actually you can do this manually by simple merging of packs and xml-s. If you open the xml, I am sure you will get the idea. But prepare for some slowing down in client's speed and responsiveness, and check RAM usage.

Dummy solution is to add also "LAN search counter" in the search frame.

don't like the bit with sharing of install package. Might get viruses, and we will loose download hits.

+1 ----- 3 More?

afaik it was discussed already, can not remember what Crise decided tho. But it will not be too complicated, neither resource-eating (maybe just a timer on the already existing "Get external IP" button). It is worth to have, but imo not top priority, since there are third-party apps (f. ex. the DUC client), which will work for all your active apps when IP changes, while Apex updater probably won't help for the other apps.

@spaljeni - I am not sure whether the protocol allows such speed distribution between slots (at least with a reasonable amount of code). @AcidStew - Actually isn't the "slot ratio" feature what U are looking for? It is already implemented. Sorry if I look stupid by asking this, at least it is not intentional.

Calm down, both of you! Make , not ! As per the topic, I do think that a fancier package will be nice to have, but I am not sure whether we can afford the resource drain for it (not only time but also tech)

imo each feature which lets uers to auto-meet the minimum requirements of a hub is a leecher's feature.

It will work, but how to ensure that users will not abuse the feature?

Наистина е необходим малък наръчник, но най-общо, след настройка на RAW командите, във Fake Detector се правят нещо като шорткъти, и накрая шорткътите се задействат с настройка във Favorite Hubs. След малко опити ще се ориентираш, не е трудно. Вече имаш RAW, което е най-сложната част.

You are sure that the "failing" peers have everything set up correctly?

Can you connect to our TGO support hub (see my signature)? If yes, please contact some of us there for online help.

Any change in download directories? Do you have those items in your Download Queue? If so, remove them, or CAREFULLY edit your Queue.xml. If you do not have pending downloads, you can even wipe it out.

Seems convenient, but what about the users with slower upload, their speeds will be awful.

Discussed. Not too good due to protocol restrictions under NMDC, tho now when ADC is ready, it might become actual again.

He means having all packs preloaded and scrollable imo

+ -------------------- Idea Also, maybe it is reasonable to enter in a box somewhere in the client, the LAN's range, say 192.168.5.1-192.168.5.254. Then restrictions could "fall" automatically for all connected hubs in this range. Cheating might be avoided by a speed test to hub/checking hops no.?

http://forums.apexdc.net/index.php?showtopic=1567 If this does not suit your needs, I think zK++ had some commands build-in.

Mine is on Yn too, but I've heard that HexHub is with superior security. Have even ran it for a test, nothing too scary in settings.

So as a hub owner I am a fool. Maybe that's why the eMule, w/o fool-proofing, can be used by fools. :-P Actually it can be solved quite easy - if Apex detects that the hub and PC's IPs are respectively a.b.c.y and a.b.c.z, obviously this is a LAN environment, so restrictions could be less.

Yes, the third option is correct (above Firewall (worst case) ). As for the rest, try to find help in our support hub (address in my signature) or we may arrange a VNC (remote desktop) session.

Again taking decisions on behalf of the hub owners. :crying: