Crise

ok, but easiest way to do this is, not to have separate small slots but just to allow current small upload slots to upload only filelists, and then just juse slot granting system with these new small slots.... could you follow?

option 1 sounds great thpugh maybe do it like this: Option 1: x small upload slots for files below x MB if they match user suplied filter of file names extensions etc. (x being customisable, and filter being optional) what do you think? ps. why is this topic hidden?

i was thinking just something simpler, something like this perhaps: when using this feature on any hub connected to, add in description prefix [Variable Sharer] to all hubs or something like that, so then op's could easily kick all users using this feature edit: or then it could read the prosentage of total share in it like this: let's assume we have user with 100gb share, connected to 3 hubs using different shares on each hub. In hub A he shares 30gb and in hub B he'd share his full 100gb and in hub C he'd share 50gb then the client would add following to users description: In Hub A: [30%] In Hub B: [100%] (or not at all as he'd share his full share in this hub) In Hub C: [50%]

why would it be banned? I have alredy said that this could be done in a way that it'd: a) be detectable via tag or description for example... be disabled when using DC++ emulation (only would apply to mods with emulation cababilities) and i understand why CraKteR is against this, but i won't understand why you are as you have added many eh.. questionable features to SDC++ before (limiter & segmented downloading) and this features have alredy caused SDC++ to get banned in countless of hubs, though thanks to your efforts with DC emulation SDC is still usable in public hubs... but as i have alredy said this discussion is pretty much pointless....

true but f.ex. GeoIP won't fully work (loads only parts of it) with 2005, due changes MS made to some functions (atoi-functions if i'm not mistaken) this is the only problem that might exist with mods other than SDC++, oh and then there is the toolbar separator problem, that might also appear in other mods...

I made this decision because when we wait RC11 before doing anything we are sure that all the fixes of RC11 will be in ApexDC++ as well. I know that it could be done by merging, but i rather do it this way because between RC10 and RC11 is lot of changes and i'm not too keen on hunting all these changes down. , yes i know there exists many good comparison programs, but as we used cvs with PWDC++, evry file will be different in eyes of such program. And yet another reason is that i want to "get rid off" some of my own fuckups and certain customizations that will certainly not be compatible with RC11... Oh and i have not stopped coding, i'm testing things out with old pwdc src's (nothing big though) and if they work good they will perhaps be in ApexDC++ as well Edit: Also CraKteR getting current PWDC++ source to compile with VS 2005 is not a problem (we released an experimental beta compiled on 2005) but as the changes MS made to VS 2005 cause some weird crashes (and whole lot of other bugs), we reverted back to VS 2003...

you buy me a license for intel compiler and i'll be more than glad to do some optimized builds :)

Please be so kind and read the mini faq at the top of this forum. it'll answer all your questions, also read the mainsite news :)

unfortunetly pwdc don't have this option, but this option will be most likely available for ApexDC++ in some point (only would work, if hub is configured in apropriate way, and you'd be op on that hub)

think the bright sides of the slot system: when user that had no free slots get's free slot it's first come first to serve basis, so you don't have to wait in a queue, like in so many other P2P networks

well only way to make it really foolproof would probably need hubside support... but with no special support from serverside it could only be done by utilizing CID with newer clients (0.69 and newer) and comparing hub adress + nick with older clients. but i still don't see why this is so big deal with this praticular feature, as there are many other features that can be used wrongly. besides it could be made detectable so if op's would want they could easily kick it, just like it's with limitting having the L:x in tag....

makes sence. But i wonder pretty much why so many people are against hub independent sharing, as if it's used correctly i see nothing bad in it (since theoretically any feature can be used wrongly) not that i say this would be good for public hubs in my opinion, but it would be very handy for certain private hubs (and by private i mean really private not the "have enough share and you are in" private.) i'm sure some guys browsing these forums are able think few hubs where this would be very good/useful feature.

couldn't it utilize CID somehow? (as i think that CID is created from nick and hub address) anyway, as i don't know how this actually could be done properly (or as properly as it could be done, with nmdc protcol), i have to drop this request...

i fail to find it (or maybe i just didn't look properly), but it doesn't matter as it's coded in Delphi

well that's easier said than done as even unmodified StrongDC++ RC10 webserver has some problems which should be solved before even planning anything more complicated, (ofcourse i don't know if these problems will exist on RC11 but i think they will) besides making the webserver actually useful in terms of remote administration, it'd need an extreme makeover, which i'm not planning to do (not among the first things atleast)

dyndns works without router, you just have to dl their "DUC" program

and in what other client would this be in i don't think it exist in any as it has only recently been made possible to do it correctly, but if you show me (quite recent) client which has it i'm open into looking into it

true, that's why satans guide is there....

PWDC++ 0.41 Installer: Here PeerWeb Emoticon Pack 2.3: Here (emoticons by: Sarevok)

possible alredy, in settings advanced > max tab rows

true, besides i think dcpro isn't even coded in c++, but not sure. (it isn't dc++ based as you probably know) besides doing this is easy so no 'resources' are needed (but i'm still not too keen on adding it)

Kevo, i saw some links to pwdc++ in your signature over at peerweb, mind pasting them here?

if i remember correctly this feature was in strongdc, but was removed. (can anyone confirm this, as i'm not sure)

Currently there is no other way of getting a tester status, as only previous testers from pwdc++/next++ will get it for now. (new tester positions might open up later though, and in that case you should ofcourse prove yourself worthy of the position) But if someone really wants access to betas, they should check the Mini FAQ Edit: currently though there aren't any betas as we are waiting rc11, only thing that people with access to beta forum will currently get is: Extended todo-list Access to WIP Guides section for ApexDC++ but ofcourse the first beta will emerge at once after rc11 is out (read: within few days from the release of rc11)

I use it because of the community side too, and some occasional downloads, but not much