ApexDC++ OP

[john1163b 0]

Ok I"m a fairly new op, but I have tried several clients , Zion blue 2.06, DC.699, ICEDC++,LDC, And Apex.

ok Zion has some really good features but seems to have compatibility issues wihth too many other clients, DC 699 is just too basic, LDC works pretty well comaptibility issue with DC++ .698 though, ICEDC++ nearly sasme as apex with a few minor addtional features, like instead of bolding text for inactive notify , I can make the tab background change scolor making it more noticable,

features I'ld like to see would be a better and more automatic to find fakeshare and cheaters, and some auto sets for adl.

[bombardier 0]

Well Well, its nice to see it being called an op client , when any old tom dick and harry can get their hands on it and use it.... pity there was no way of preventing users from getting it since there are some obvious leeching features in apex, like most op clients.

Having said that, its a quirky little client that could be a great client. Personally I found dcdm was an excellent op client since all the check and kick functions etc, could be customised and disabled, but above all, the one thing I found with DCDM that was better than apex was the fact it was capable of getting filelists from most clients... Apex has a serious issue here and I have seen many ops kick users for connection timeouts....yup, dc++ ver0.688 the answer was to use a second client to get these lists.

So, for me, the way forward for Apex must be to achieve a better success rate for getting filelists from all clients and leave out the

obvious cheat functions. any good op on Dc will know 3rd party apps to achieve bandwidth control.

Dont think I'm tearing apex to shreds.... I actually see it has great potential but at this time is causing some issues in large user hubs where almost all clients are allowed.

Incedently, most ops use this as a normal client setting up only adl searches but not using raw commands and letting the client

run on its own checking each connecting user the way you do with dcdm.

[Guest Toast]

DCDM xD that was when jesus lived and dinosours roamed the earth xD

:)

[bigcanuck 0]

[quote name='

[bombardier 0]

The Current relase of apex is not the Op Client, while it does have some helpful features for OP's it's primarly a user client, the OP client which is being developed will be further tailored to Op's Lee etc. can correct me if I'm not on the right track with my comment. Should also be mentioned that this is a port of StrongDc so somethings may need to be improved (like your file list comment).

Humble appologies if this is this case, however please take note of my observations with regard to d/l filelists from various clients,

And as for being a user client, sure, its got some real neat features which i use, but being admin and owning a 15000 user hub i find a lot of my time is spent explaining to n00bs why they get filelist fake check messages, which incedently are only a guide and not 100% proof everyone is faking, and i am a little bit loathed to recommend it since it has bandwidth limiting capabilities.

having said that, i think you have been really fair with the way the limiter works and if the fake detector is removed from your "User" client I would recomend it to all users. if theres a sepetate Op client the only thing i would recomend is a comprehensive setup guide or readme, since this is where most Op's and hub owners fail.

Thanks again guys, and keep up the good work.

[Crise 26]

i just have to ask, what's wrong with the ability to limit?

because:

a) user could use any 3rd party limiting software to do the same (and you couldn't really say for sure if he or she is limiting or not, if this is the case)

apex broadcasts the upload limit in tag, and thus in case of abusive usage it is know instantly (tho. you most likely aren't really able to abuse the limiter in apex)

[Guest Toast]

so when is apex breaking out of the "user" area and into the op version ?

[Zlobomir 3]

I just wanna ask, what is wrong with OP features in user version? If smo wants to play nasty, he will get the OP version anyway. So I do not see any point in removing f. ex. the fake checker, it can be fairly useful in hubs, where regular users are granted the right to use +report, thus making OP's lives easier and eventually be promoted into OPs. At all, OP features are hub-side activated, there is even a topic for this somewhere around... :)

[adrian_007 0]

if user version have fake detector and op functions, there is no reason for making op version at all imo. i know that op ver will have extended and new functions, and if it will be relased, fake detect shouldnt be in regular client while you can use it only if you're op in hub. and you dont have to make ops life easier - they know what they have to do and probably they have everything to make they job.

so, when apex-op-version will be relased, fake detector in regular client would be just a waste of resources [not much, but always sth] while user chave a choise :)

[Zlobomir 3]

afaik about OPing, in huge hubs, or in many hubs, extended and new functions matter, and OPs know which exactly - and it is not only that OPs need smth better - it is also the prestige in having good, full range of clients for users and OPs, for as many OSes as possible, like Zion (Amen, you see what I mean, no clients, except some private ones!). We are just on different sides, if there is about to be only one client, I want it OP, you want it user. It is OK and understandable.

But, again afaik and pls correct me if needed, if no active options in the fake checker, no more resources consumed. Let's not make it a question for 1-2MB or less in installer/installed size. :P

[Greg 0]

if user version have fake detector and op functions, there is no reason for making op version at all imo. i know that op ver will have extended and new functions, and if it will be relased, fake detect shouldnt be in regular client while you can use it only if you're op in hub. and you dont have to make ops life easier - they know what they have to do and probably they have everything to make they job.

so, when apex-op-version will be relased, fake detector in regular client would be just a waste of resources [not much, but always sth] while user chave a choise

Maybe this is the case, this decision will be made once the OP client becomes availble. At the moment, it is not, we understand these points of view but see no point in making decisions about this until the release of an OP edition.

[da_asmodean 0]

try to look for something like crossmix of apex and fuldc

[Guest Toast]

Plz dont instead try to find a OP version that is better at detecting clients instead of coping feats of everyone else

[Teobald 0]

Almost every p2p client got a limiting ability. If ApexDC wouldnt have it, im pretty sure that even more users would decide against the DC network and change to an other p2p. Its the hubowners and their op's that have to make sure that users do not abuse the limiter (by checking the users tag).

What i would like to have on the OP client is a button to start/ stop the fake checking. Maybe even for every hub seperatly, because checking large hubs will take time and recources (and some OPs are in a few large hubs).

Edit: I think its wise to keep the users client as slim and easy as possible.

[Noctis 0]

Yeah checking is a must for a decent OP-client. Easiest way to do it, that by default when you turn it on it starts checking in the hub you are currently viewing, so you can do checking in couple of hubs, where you want... and to start checking in all hubs.

[Greg 0]

Almost every p2p client got a limiting ability. If ApexDC wouldnt have it, im pretty sure that even more users would decide against the DC network and change to an other p2p. Its the hubowners and their op's that have to make sure that users do not abuse the limiter (by checking the users tag).

What i would like to have on the OP client is a button to start/ stop the fake checking. Maybe even for every hub seperatly, because checking large hubs will take time and recources (and some OPs are in a few large hubs).

Edit: I think its wise to keep the users client as slim and easy as possible.

There's anti-leeching safemeasures behind the limiting feature, people can't really abuse it massively.

[FIL 0]

* Why the client you chose (stability, positive development, respectable dev team)

* What features do you like in the client

* What features would you like to see in our version

i chose DCDM because of it worked very good as op client although now it has some problems like disconneting the op from the hub where he's checking because of the high ping on big servers. But this problem is easy to solve: dcdm++ (also in his last version, DCDM Special released in September 2006) is dc++ 0.401 based and makes it difficult.

But DCDM works very good with raws and its parameters. For example, dcdm supports important parameters like %[cheatingdescription] and %[clienttype], zion++ blue and strong dc++ only support standard dc++ parameters like

%[nick] = Users nick

%[tag]

%[description]

%

%[share] = share in bytes

%[shareshort] = xx Kb

%[ip]

and that stuff is really far away from being enough for complete OP working. I also think the DCDM team is cute and works very good. I like the op controls and the /startchecking or /stopchecking which for example isn't working in Strong DC++. The /sc feature makes possibile to start and stopchecking whenever you like.

I like also Myinfo Detector, Fake Share Detector and Filelist Detector and obviously Fake Detector with client profiles with the back/next buttons to switch easily from one client profile to another. Also the following features from zion are very interesting:

Skip BCDC/CZDC check

Skip Reverse Connect check

Skip CZDC Strong DC check

and also the possibilty not to share partial downloaded files during the download. Then the Malevolous file checking and the search of forbidden files. It should be like DCDM but DC++ 0.698 based (obviously ADC Protocol is very important). Interesting features are also the auto update of the IP directly into client and also multisource downloading could be nice even if not really important.

Most important thing it has to be stable and it should have the feature to make some tags being protected from raw actions: that feature depends on the hub and should be therefore inserted in the favorite hub window (see Zion++ blue).

NO netlimiter,not so sure about lua scripts, yes multihubkicking. It should be a light and stabile client no taking much RAM when working intensive.

[Noctis 0]

But DCDM works very good with raws and its parameters. For example, dcdm supports important parameters like %[cheatingdescription] and %[clienttype], zion++ blue and strong dc++ only support standard dc++ parameters like

%[nick] = Users nick

%[tag]

%[description]

%

%[share] = share in bytes

%[shareshort] = xx Kb

%[ip]

Zion++ Blue also supports the strings cheating description and client type, just you need to use the new method:

%[userCS] for cheating description, and %[userCT] for client type.

Due to DDMD++ old based, it has problems with checking newer segmented clients, unless you have a stripped one.

Edited March 29, 2007 by Noctis

[Crise 26]

Plz dont instead try to find a OP version that is better at detecting clients instead of coping feats of everyone else

There is no risk that I will ever mix ApexDC++ and fulDC++ because i just don't like that much fulDC++.

In regards of copying features from other clients, I wouldn't want to do it too much, but there is also the fact that if certain clients have created good features... why should I "reinvent the wheel".

[FIL 0]

Zion++ Blue also supports the strings cheating description and client type, just you need to use the new method:

%[userCS] for cheating description, and %[userCT] for client type.

Due to DDMD++ old based, it has problems with checking newer segmented clients, unless you have a stripped one.

many thanks for the clue. Considering that we are all speaking the same language (C++) why can't we program all the clients in the same way and base interface(that not affects features) setting the same parameters for all for example. I'm not asking, only reflecting about.

[Zlobomir 3]

many thanks for the clue. Considering that we are all speaking the same language (C++) why can't we program all the clients in the same way and base interface(that not affects features) setting the same parameters for all for example. I'm not asking, only reflecting about.

Well, in my guess things are developing, coders inventing %[userCS] as shorter and more convenient. And it is good to be like the other strings, in equal format, so all changed. Not a real problem btw, as long as there are text editors with Replace function.

And IMO you will like the next public release of Apex. :)

[FIL 0]

And it is good to be like the other strings, in equal format, so all changed.

And IMO you will like the next public release of Apex.

yes as long as you know the correct syntax of the parameters or if you know where to get a list, because i think the one you find into the client isn't up to date. Are you referring to a normal Apex or to an Apex Op? :-)

[ifmn 0]

AFAIK there's no difference in the commands for normal and op version.After all, the op version isnt out yet...

[Sidetrack 0]

You know, I have thought over and over, What makes the idea of the OP client vs the standard client so much more beneficial, Crise, this part is for you. Maybe a MERGE of the 2 clients WOULD be possible, AND beneficial. I have been using apex, since before PWDC 2 was released, (before it was apex). It has come along way. alot of features have been added including some new features in the MOST recent Beta's. But we are or MAY be looking @ this totally wrong. Why have a separate client all together. Bragging Rights? In the current version of Apex, try logging in as a Regular User, Look @ your Client Side RC set. they are different than if you have keys. Because, the client recogizes that you are an OP or higher. IF Apex was able to keep the size down, and put in ALL of the Op Features Planned, then lock them down (via code, not user option) Then we would have a new idea in DC wouldnt we. A client everyone can use, from new users, to OPs, and as they progress in DC, and start to become OP, they would find MORE options are available to them automatically. This would require the client to recognize if the user has keys or not, but it does that already.. So why NOT? Apex is evolving into something far better than what is currently out there, on all fronts. why not make it a totally new idea. The client actually evolves WITH the user, not making him/her upgrade to another client, if they get keys somewhere.

Regarding the NMDC/ADC filelists issue. Personally I think WE all are looking at this entirely wrong, There are 2 totally different ideas about how DC should be done, its not the clients, its not the bots or the hubsofts, but HOW the protocol itself should be changed. any source software, that is required to support BOTH of these will be bloated badly. and lag, and be slow, and be.. (insert your comment here). WE as members of the community, both OP, Admins, owners, developers, creators, and evermore, need to work on getting a new standard set and locked in place, THAT is the problem, the teams involved in changing the Protocol itself, are not working together but are splitting it up, which only makes it harder for coders to write. Then they are forced into politics. "Well if you dont choose ADC, you cant access my hubsoft, or my files", "If you choose NMDC extended, then you can do this or that, but not this" etc. DCC was best because all clients worked together, all hubsofts worked together, it wasnt like most other p2p softwares because it allowed choice, yet, used same protocol so everything simply Worked. MOST of the older Op Clients, DCDM, rmDC, MCDC, R2++ etc.. are dead projects, or not getting much work. MOST are based on source .401, which is NOT even nmdc extended. We need to push as a community for a STANDARD in DC protocol. I for one am working on this. Many devs already know this. I dont care which protocol layout is used, just freaking pick one, and make it the best it can be. MORE info on this project will come as the resources are setup. IF your interested in participating. Please send me a PM here. ! (typical Sidey book, sorry guys)

[FIL 0]

Regarding the NMDC/ADC filelists issue. Personally I think WE all are looking at this entirely wrong, There are 2 totally different ideas about how DC should be done, its not the clients, its not the bots or the hubsofts, but HOW the protocol itself should be changed. any source software, that is required to support BOTH of these will be bloated badly. and lag, and be slow, and be.. (insert your comment here). WE as members of the community, both OP, Admins, owners, developers, creators, and evermore, need to work on getting a new standard set and locked in place, THAT is the problem, the teams involved in changing the Protocol itself, are not working together but are splitting it up, which only makes it harder for coders to write. Then they are forced into politics. "Well if you dont choose ADC, you cant access my hubsoft, or my files", "If you choose NMDC extended, then you can do this or that, but not this" etc. DCC was best because all clients worked together, all hubsofts worked together, it wasnt like most other p2p softwares because it allowed choice, yet, used same protocol so everything simply Worked. MOST of the older Op Clients, DCDM, rmDC, MCDC, R2++ etc.. are dead projects, or not getting much work. MOST are based on source .401, which is NOT even nmdc extended. We need to push as a community for a STANDARD in DC protocol. I for one am working on this. Many devs already know this. I dont care which protocol layout is used, just freaking pick one, and make it the best it can be. MORE info on this project will come as the resources are setup. IF your interested in participating. Please send me a PM here. ! (typical Sidey book, sorry guys)

that's exactly what i meant as i said

Considering that we are all speaking the same language (C++) why can't we program all the clients in the same way and base interface(that not affects features) setting the same parameters for all for example. I'm not asking, only reflecting about.

obviously the point is not only about C++. i'm referring to more common points that WE should have.