Zlobomir

Tester
  • Content count

    2403
  • Joined

  • Last visited

Posts posted by Zlobomir


  1. This one just hit me, while downloading. It is dependable on "Automatically disconnect users who leave the hub".

    I was connected to a hub, and downloading from a user. Then, the hub said "spammer" (probably because of forgotten open search window) and kicked me for 30 mins (no hammering was set, but imagine how even worse if it was). Still, when I tried to reconnect, I got redirected, I now have to leave the PC (the house), and there is nobody to reconnect the client after 30 min.

    What I suggest is a timer like "Connect to hub X after X minutes/hours". So it will not require human presence, and not hammer, and will not get redirected.


  2. I wonder whether it is possible to reduce the HDD usage upon ApexDC++ start. Now in PWDC++ 0.41, if one has closed the client with many unfinished tasks, at the next start the program tries to read/write from/to all the files simultaneously, thus causing high HDD activity (or at least I think this is the reason). Is it possible to set some limit (user-adjustable depending on the PC) for the speed/number of segments?


  3. What I am saying is, it may be required for you to (start a) download from someone before this info becomes availble. The easiest option would be to download there filelist... or start to download it to get this info. Anyway, this was an if, although I think it's probable a download from a user is needed I'm far from certain.

    This just made me realize that the current columns for IP, PK String and Lock, that we have, also show info only when you start to download smth from the user (just checked it).

    My idea was that there could be an option to send some ping-like command to the users in userlist (not to all simultaneously, it will probably lead to overload). This command further can be customized to run only when the user clicks another user in the list, or in the background, continuously adding user info, or not to run at all (to have the old program behaviour). Not very clear explanation... :)


  4. I believe the country of origin flag is only retrieved when you start a download from someone? If so putting it into the userlist could be a little less hassle.

    Well, it may be possible to make it show when you mouse-click (select) the user. If it is retrieved for all users when you enter the hub, the entering could be a little longer. Similar with retrieving song info in Winamp... :)

    Offtopic: Glad to see you too, Beertje! :w00t:


  5. Is it suitable to add the following:

    1. A user is connected with emulation to one hub, or to three hubs w/o emulation and to one hub with emulation.

    2. He/she activates the transfer rate limiter.

    3. A message pops up: "You are currently connected to the following hubs: "hub(s) name(s)" using DC++ emulation. Turning on Transfer Rate Limiter could reveal your client. Are you sure you want to continue?

    I know this looks a little Macro$hitty, but all such warnings could be done optionable (turn warnings (user tips) on/off somewhere in Settings).

    This is more a feature request, but because this forum is hidden, just delete if stupid. :)


  6. Still, if I remember well, before we discussed that it could be a case with an Englishman living in Poland, f. ex. Also, I suspect GeoIP is not perfect. So I personally trust more the prefixes, if not I try the 3-4 languages I spoke, starting with English. :)


  7. If you have downloaded over 50MB off a user, give him one point. 100MB, two points, etc.. This probs cannot be stored for every user, so it would only apply for one session.

    The more points, the large percentage of upload speed they require. Obviously this is a very basic idea..

    Another very simple idea would be to give a user more speed if they have uploaded 100MB to you. Maybe this could be configured to the user's preference. I'm not sure how the speed would be detected and distributed.

    1st: It seems quite hard to me, it's kind of an "IP-based shaper" inside the program.

    2nd: It is not bad "automation" for high-speed users or at least for users with separate up/down bandwidth. But for people like me on a miserable speed (I run what-you-can-think-of on my server, namely HTTP server, DC++, BT, and occasionally download manager), it will be a burden. Especially if according to the idea, DC++ requires more, more, more speed, cutting it off the other apps, but the "leecher" can't use it due to his own connection limits (or even worse, DC prefs).


  8. Combo: So basically you want an option to 'reward good uploaders' :) which will prioritise them and give more bandwidth to those users. However, I believe this is against DC rules to prioritise users?

    I do not believe it is, but I believe that with some shaper all our rewards will be useless. So isn't it better to preserve the "pureness" of the program? I personally have proposed such features before, but now I see there is not much sense. If there is not good will, little can be done. At most, "bad" users will start to avoid ApexDC++.


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


  10. Well, just would like to say that if smo wishes, this could be achieved with different clients. But since I do not like to spend in times more resources, users just do not have access to all my content (or I do not stay in the particular hub at all), instead of giving what they like. Since I already run a hub, I always can invite a user to take the "prohibited" content from my hub.

    But all this is the ugly, boring, wrong decision I think. If users can sneak through some limitation, what is the use of the limitation?


  11. Very good idea... but I'm cheap. :)

    Anyway, I need to buy a monitor sometime, the simpel answer is there's other stuff I'd rather spend my money on. Moreover, I'm sure I'm not the only person this effects.

    However, wasn't there talk of having an option or something so the transfers section of the GUI would be hidden when a search window was open.

    Yes, it was such a talk.And if I remember correctly, we found out it is possible...


  12. Well, a decent page for Bulgarians is available on http://vx8.hit.bg . Yep, it is for DC++ only, but multisource and Strong DC++ are barely mentioned, too.

    I do not know whether it is quite suitable, it starts with "If you are a COMPLETE idiot, you have come to the right place". :)

    But still, the things there are explained clearly and simply enough. :unsure:


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


  14. Well, Iknow we didn't went too far before using my logic, but I see it like this:

    a) x small upload slots for files below x MB (x being customizable)

    :unsure: automatic slot granting system

    And the user to be able to choose which one to use... It's just because I would like to see an innovative, powerful, and highly customizable new client. :blink:

    Both do the same job though Zlobomir, it's just two different ways of performing the task.

    No, I think the b*) mode could easily eat up all your bandwidth (not a problem for all though)

    And the a) option gives more freedom.

    It's like the professional cameras with manual focussing and the simpler ones, with auto-focus. :)