[some problems with letters with accent]

many thanks it worked: i forgot also italian letters have diacritic marks or something like that :)

[some problems with letters with accent]

while using last version of apex (1.0.1) i've encountered a little problem.

As i write some italian words like "però" (but) or "è" (is) the client directly writes "pern" or "c" instead of this two words. the only letter with accent Apex replies correctly is à. The others are all replaced.

And this happens only with Apex. I tried also other clients.

Can someone tell me why and correct this issue?In every case many thanks :-)

[user checking]

Yes I see your point FIL, but that depends on the OP version of the client... If there gonna be one, we'll need that feature in that one.

another little point: using apex dc++ 0.4.0 and starting userchecking automatically when joining the hub (as flagged in settings) i was disconnected from the hub where i was checking. That happens only if i have raw commands connected to client profiles. If i only start checking without raw commands connected to profiles it works perfectly. My connection is a DSL 2 Mbit and works well.

If there will be an op version of Apex i suggest you too take something from Zion like the Regexp Tester and also the following functions to flag:

Skip BCDC/CZDC check

Skip Reverse Connect check

Skip CZDC/Strong DC check

Recheck

and also a check key scroll down menu so that you select which key type the client should check relating to the single client profile.

Other things: Reg Exp Parameters and Myinfodetector.

[user checking]

Those two commands are currently not available in ApexDC++. One method is to select the users in the userlist, right click then select Check File List or Get User Response (client checking).

ok but it would be a good idea to add this function. it would be fine to check users whenever you want. I would also add a "back" button while swichting beetween client profiles. Now there's only a "next" button. What do you think about?

[user checking]

it's possible to start and stop user checking with apex as i want and NOT only when entering (checking starts) and leaving (checking stops) the hub? I've tried to use the following commands

/startchecking

and

/stopchecking

but it didn't work.

Please tell me something about. Many thanks. FIL

[Raw Commands]

About this parameter: %[junkshare]

which is the new syntax of it in apexdc++?

[Raw Commands]

the list of variables is very useful: someone knows or has discovered other %[] parameters working with raws in sdc++ and apex? if something did, i'd like to know something about if possible. Many thanks also for the list above.

[ApexDC++ OP]

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.

[ApexDC++ OP]

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? :-)

[ApexDC++ OP]

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.

[ApexDC++ OP]

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