DC++

cyberal

and none with a well thought trough concept that don't hogg too many slots.. and blocks bandwidth...

cyberal

just to clarify, hashing has nothing to do with downloading from more than one user..

cyberal

I see no reason to make this request difficult by making it an automatic speed-dependant feature. The user wants to manually remove and ban users... way simpler than coding an automatic speed-slot-closer. The original request was this: An idea... add the ability to prevent a certain user from sendin...

cyberal

since there is no protocol standard.. it will be hard to even get the min slot info Obviously this would only affect hubs that either identify or even require DC++. This would affect all hubs that care how many slots a user has dc would have to keep track of the slot ratio The expected ratio would ...

cyberal

good idea

cyberal

since there is no protocol standard.. it will be hard to even get the min slot info... also.. for this feature to work.. dc would have to keep track of the slot ratio... and as a result of that also max slots... too much numbers to take into consideration for this to be good... what should DC++ do i...

cyberal

this feature has nothing to do with slow sources.. and it certeinly isn't automatic.. so.. no .. it's not the same..

cyberal

Twink> hm... but it should be possible to detect which users that support "date-filelists" and who doesn't.. the same way dc++ decides who it will send xml filelists to.

cyberal

not really.. what he's asking for is an extension to the manual "remove user from queue"-option ... and also ban that source and stop it from beeing added by autosearch again..

cyberal

now when hashvalues has been added to the filelist.. can't this be added to it too... the xml-filelist only that is..

cyberal

this feature is dangerous for one reason alone.. * most ppl are stupid and since we can't force everyone to "read and understand" some guiding text before using the feature... it's likely that alot of users will abuse it in the belief that it helps them get better speeds.. question is.. are we willi...

cyberal

flame time..

1. old request
2. sucky subject
3. asking if it can be done before stating the request
4. D-

cyberal

hm.. I was fooling around with the main chat scanner in Yhub... replacing words with "| <LittleMike>" etc. and suddenly all users in the hub (about 150) got a Runtime error =) .. guess this have to be some sort of oDC/DC++ bug?... anyone got any ideas what could cause that?

cyberal

I'd also like to be able to choose what sources to add when I manually do "find sources" in the queue!

cyberal

good suggestion... !

cyberal

no its not.. at least not in this thread... it accomplishes exactly what the thread starter wants.. a differentiation between normal users and OPs!

cyberal

lol, this is almost beginning to get sad :/
time after time after time new users are requsting old thougt of features like they are the first to come up with them =)

cyberal

[B]bongretarded wrote:i love number 2 but number 3 is pointless *look at dcgui etc* and number 1 well who needs hashing?

lol.. I would say.. no2 is worthless .. who needs it.. and that 1 & 3 is most welcome!

cyberal

then how about doing it the IRC-way?

attach a @ to the front of OPs nicks!

cyberal

[TVS]Dulf wrote: I *always* need to edit the search string.

I never have to edit it! Cause I download rar!

cyberal

GargoyleMT wrote:keeping the lists in memory unless they explicitly refresh the displayed one seems to be reasonable.

or maybe even a must have! wouldn't wanna kill another hunlist feed!

cyberal

Todi wrote:Use a CDM if you need this, imho normal clients shouldn't be finding out other clients IP, unless you're an OP.

imo all clients should know all ips in the hub, that would eliminate the possibility to fake search results or hijack grant slots!

cyberal

different portnumber?
no?

cyberal

megla wrote:You know what hub that user request is from, and then you can send the correct filelist for users on that hub.

no, thats the problem.. the client DON'T know this..

cyberal

an easy feedback change.. I have a big filelist, takes up to 5 mins to refresh.. now, DC++ tells me "Filelist refreshed!" right after I write the command.. ie. he's lying to me.. the filelist is not refreshed! It should say: "Refreshing filelist..." and then, when it's done.. "Filelist refreshed!".....

cyberal

yeah okay, ofcourse you are correct... the under lying reason is a laggy hub.. and I do kick more than one user at a time.. that may make it worse.. Building a routine to handle the ignore seems easy to me, maybe not efficient but easy.. simply add the kicked nick to a list when you activate the kic...

cyberal

yeah, why not

cyberal

Yes, how 'bout that?
An annoying little thing.. users manage to send away pm to you just before they get disconnected.. I would like to be able to ignore those msgs

Should be fairly easy to implement (not that I know C++), but if I were to write it in Java it wouldn't be a problem I think

cyberal

the amount of users that CAN'T go active is big, a solution that excludes passive users is no good, half the swedish university network are passive and they can do nothing to change it!

cyberal

marmarus> you know you can just use the "enter" key right? no need to use your mouse!

cyberal

what it comes down to is that the DC client have lots and lots of information about all users in all hubs it is in. BUT, it does not know what users are in what hub. Solve that, and we can move on.

include hubip+port in MyInfo?

cyberal

marmarus == gourmet

cyberal

Gratch06 wrote:The reason for creating multiple hublists and not just one is to keep the bandwidth down on the hublist operators.

Then maybe the hublist operatorn should make their lists smaller, removing all those small worthless hubs noone will ever notice?

cyberal

This is not true in your case: Everything would be so much easier. However, it would be true if you were to change this behaviour: Other thing is that I don't download rar-archives with DC, very seldom. Almost always full files. ...then this problem would disappear: The thing is that people name the...

cyberal

NOP> adding them like that will show hublist2 only if hublist1 don't work..
adding a separate window for each addy I put in hublist URL's seems like a good idea..

cyberal

oh, he responded to his own post, didn't realize that, sorry

cyberal

huh? it's a DC++ feature!

cyberal

TeNkA> yeah, that sounds kinda boring... but you don't have to do that.. I have a very simple solution to your rar problems.. you are just not using all the neat DC++ features! This is how I do it: 1. find the release and queue it up 2. do "search for alternates" on ONE of the rar-files 3. download ...

cyberal

(and PIE too)

cyberal

me want this!

cyberal

there is no option to turn on/off the reconnect to hubs!

This feature and the possibility to set the reconnection interval has been requested before!

cyberal

I agree that this would be usefull, but DC++ currently have no filtering at all in the nicklist, like oDC has.. the first step would be to implement that..

cyberal

just have to point out..

TheParanoidOne wrote:Or you could just start your own 4GB hub.

B1ffster wrote:Post subject: Nobody mentioned this one
Start your own hub

cyberal

if you want a fixed reason just write the reason directly:

Code: Select all

!ban %[nick] get lost faker

if you want to write a new reason every time you ban:

Code: Select all

!ban %[nick] %[line:Reason]

cyberal

just set max tabrows to 1 and the tab won't jump anywhere..

cyberal

The starter of this thread need bandwidth limiting to make sure all users of his connection has some bandwidth, for this I think netlimiter is the best (althought it seems some what buggy, sometimes corrupting data). The other reason to have UL limiting, to solve the problems with the Asymetric DSL ...

cyberal

why is it always me that says it?

Download original RAR releases!

http://whyrar.has.it (may be down atm)

cyberal

I know! Autogranting favorite users have been suggested before but my proposal is slightly different. I want to be able to set the amount of autogrants to! Say I have 10 friends that are on autogranting, surely they won't be in all at once, but if they are I don't want them all to get a slot at the ...

cyberal

but people will put the brakes on hard , thinking that its going to give them more dl speed the harder the brakes are on This is the biggest problem IMO! ppl that don't know how to use the UL limiting correctly. It's not a question of "abusing" or trying to "cheat", they simply don't know better. A...

cyberal

I think this problem should be solved in the hub software, I know there are many scripts to do it! Gourmet, I suggest you talk to the hub owner about this..

doesn't DC++ react to the "nick taken" string? If the hub would simply send another message, would the client still think his nick was taken?

DC++

Search found 348 matches

protocol chars in Yhub main chat scanner

feedback on filelist refresh

ignore away-msg from kicked users

set number of granted slots + autogrant favorites

Re: re