Lotus

Member
  • Content count

    81
  • Joined

  • Last visited

Posts posted by Lotus


  1. Good ideea, as you lost so much time and energy developing an tremendous program which is both free and so useful for many people. In fact, I wonder how you did not think of this long time ago. You should not only cover the site & project cost, but also gain some money for yourselves. Not doing so means you are either rich or stupid.

    Life is hard. Not taking this into account is just stupid. Good luck!


  2. IMHO: some way of clearly showing search results from DHT "virtual hub", something simple and easy to see, like a special color for those search results, or some statistics... so that we can easily see that is working (or not) and how efficient it is...

    I even propose this (cool thing): add a "DHT/Virtual Hub" to favorites... when I join that hub I can see (in userlist) all "DHT users"... the chat is of course disabled but MOTD can have usefull informations about DHT and I can use !info for some statistics etc... wow... :)

    Of course, I will use DHT regardless of "joining" or not that hub. That hub will be only for feedback.


  3. Sharing different folders on different hubs implies that you don't have a fixed sharesize for all hubs, and they are not willing to implement this. One of the reasons is that NMDC protocol is not well-suited for this. Another reason is they fear users will start to share only the minimum amount required for each hub. However, I myself think that if such a situation wil occur then hub owners will start to raise their min_share and hubs will begin to sort based on quality. Today we have a terrible mixture, good hubs, bad hubs, they all have almost the same share requirements.

    For example, if a hub owner set min_share to 1 Gb and they all start to share only 1 Gb there, that hub will start to fade because nobody will want to join that hub anymore (the total share is very small). So, the owner of that hub will be somehow forced to raise min_share. And also people will understand that they have to share. Today it is a mess, noone knows what min_share actually is...

    I would REALLY like this option too!

    Yes, I would like this to...


  4. It's not that we don't understand... the behaviour of that checkbox will be changed slightly with next version to address these issues (ie. the old behavior of "Update IP on startup" will be merged to the "Update IP on DHT firewall check").

    Tnak you. And for the 1.3.1 version too.

    Also, if you would use ADC or NMDC with UserIP2 then your IP would be updated correctly on hub join. The problem is that many NMDC hubs violate NMDC procotol - they report UserIP2 support, but don't send user's IP at all (especially when such option is disabled).

    BigMuscle: It is possible for me to have more then one IP on different hubs in the same time ? If not, then I think it is enough a single hub that sends my IP to my client and you can use that IP for all the hubs that I join... isn't it ?


  5. Yes, but can you be more specific ? How exactly does it work ?

    It is a very interesting and powerfull option. Today almost 2/3 of users are passive.

    I think this feature deserve more credit and some explanations so hub owners can understand it.

    Thank you.


  6. I never fully understood all these colors involving users. Some overlap others, for example I set passive users to gray and users with fireball to blue, and a passive user with fireball will no longer be gray, even if it is passive... somehow murky.

    I would like something like this:

    [x] OPs: [green] <-- i have enabled this

    [x] Active users: [white]

    [x] Passive users: [gray]

    [ ] users with fireball: [blue] <-- i can disable this color

    [ ] users with server: [cyan]

    ...........

    And there will be only 3 colors activated in this scenario: green, white and gray. And i will see very clear active <-> passive users.

    Can this be done ? Please..

    Thank you.


  7. You know better.

    But maybe you have misjudged or misinterpreted me.

    Your work is highly appreciated but I consider you open people. I speak frankly to you.

    Never the less, the point remains. And the point (and my ideea) was: Why not release a 1.3.0 but NOT FORCE update, then wait a little bit, if it is stable, ok, if not, correct it, then RELEASE ANYWAY an (eventually better) 1.3.1 and THEN force update to it ? We ran 1.2 for such a long time... is such a disaster running it a bit more ?

    It is expected that every version will have bugs. But you should agree, I think, that sometimes, especially when adding NEW features to the program, some NEW bugs may be introduced, and the stability or overall look of the program may be compromised more severe then usually.

    But if I am wrong or I have upset you, then I am sorry and please accept my apologies. I never intended to say that your work is futile or not observed.


  8. When guys will you start to be honest about your reasons for adding/removing something ? :)

    You tell us: because of this. Then we jump in and reply... and then you say: Well, you see, it is not purely because of this... :)))

    I have DHT on and it is working fine for me, at least I think so, since I didn't downloaded much these days.

    Question: if i change my IP (without restarting the PC) and then restart Apex, will my IP update instantly ?

    If yes, then it is ok for me. If no, hmm... ugly :D


  9. I agree with BM about search spy.

    But about CDM Debug Messages:

    A filter for the text that is displayed or the DC commands shown, and a log.

    It will be much easy to spot CTM flood (fake CTM messages) emerging from hub X.

    A MUST.


  10. I would like an option for each favorite hub to send a specified set of commands on login to that hub.

    For example, this could be useful for automatically sending +history on some hubs, immediately after connection.

    I don't know if this can be accomplished by using scripts, since I never used client scripts...

    And something more more: a scheduler to join/exit/search x file on some hubs ? :D

    Thank you.


  11. Grrrr

    If it is usefull, why delete it and tell us to install DUC and use the dyndns/no-ip stuff ?

    But common... it is not like this option was never here and you have to implement it for the first time. IT WAS... and you removed it...

    Don't have space ? Use a bigger window.

    JESUS.....

    PS: I have to note this somewhere: "cosmetic reasons".


  12. Crise: I agree that upgrating a buggy version is a must, especially since we are talking about Direct Connect.

    However, you should only force update to a *very stable* new release. I also found myself into situation of updating to a buggyer version... :|


  13. Yes, very strange behaviour for user commands. No name, they don't do what they are supposed to do...

    I didn't check in Strong deeply, but at least the name is saved in Strong.

    Bug confirmed.


  14. Thank you for the reply.

    Also I noted that, both in Apex and Strong, the color for URL is behave very strange. It is usually blue, no matter what color I chose... unless I set the background to Black, in wich case URL color is WHITE. Grrr..


  15. The idea of grouping hubs in favorite is nice. It also look nice in apex, however...

    My background color is black... and group names are listed in black too... And I don't see where can I change that color...

    Additional question: I noted groups are sorted in alphabetical order. What hubs are listed now, when I don't fully open the favorite hub window, just click that little

    down-arrow from the right ?


  16. If I want to host a small hub on my home pc (running windows), here is what I would like about the hubsoft: a) to be fully featured, yet :) simple and easy to use; c) well-done and clear GUI; d) i kinda like the concept of "hub in a box". A small hub does not eat resources so this is not a key factor if I only have a small hub. Currently YnHub fits best to my taste, YnHub also is pretty optimized and handles many users, if I have a big hub.

    Here are some other interesting options (imho) that I like. They are only some of them, just to open your taste... :)

    1. YnHub: You can ban a user so that the user can no longer connect to hub (even if the ban has expired) until he updates his share. This is not a shareban, because other users that have the same sharesize can still join the hub...

    2. HexHub: you have an option for spam so that if I spam the hub, I receive back my message (thinking I was successful) but the rest of users see nothing. An optional warning can be given in OpChat.

    3. HexHub: can detect proxy users even if their clients does not send M:5 in tag.

    4. No hub support this yet, however since #REF extensions was implemented in DC++, you can use it to detect and inform in OpChat what is the hub that attacks you (in case of ddos by the means of ctm). Easy to do, as you just have to read what they send when they connect to you... This is even better then the method currently used by HexHub to detect the source of attack (picking up nicks and querying dchublist or qsdchublist).

    But, as a key point, the easy of use should be a main feature of the next adc hubsoft. Easy to use but powerfull. Plenty options...


  17. If you want to skip from hub1 to hub5, using "next" mouse button is somehow awkward.

    I would like even some Ctrl + Tab and then the possibility to chose from all the hubs, like Alt+Tab in Windows..

    They can eventually by displayed vertically. Ok, I know they are low chances that you will do this :)

    But the next request is more important.

    I would love if changing a hub tab from normal to bold font will not modify the size of the tab... this is just frustrating. When someone writes in mainchat, that hub tab become bold... nice... but it changes is't dimension (becomes bigger)... grrrr... ugly

    Thank you.