Ah, yes, today is a “why the NMDC protocol suck and ADC is so great”-post. And today’s protocol bit is brought to you by $Search (paid and sponsored by SCH in ADC) and the file types used. (You should have a look at the Search types post I made a while ago.)
Now, on to the (NMDC) protocol bit. All of the search types are “hard coded” into the protocol, meaning you will need to upgrade other clients to respond to your file type searches. This is unfortunately not enough of the NMDC sillyness. When you pick a certain file type in DC++, DC++ will change the caption of your choice (”Audio” eg) and to a number. This number is predefined (as the wiki post says) and cannot be changed (because otherwise, you’d recieve wrong search results or not get any - depending on what you change the number to). This basically means that you cannot tell DC++ (code wise, considering there is no way to do it in the GUI) to “search for _filename_ but only include audio extension AND video extension”. This is because there is no way to combine the different numbers. Now you’re thinking “but can’t you add them and the send that number out?”, and sure, you can do that. But you won’t get the result your after. Eg, “Audio” is 2 and “Compressed files” is 3. Now, if you add these, they (of course) become 5. Now, the problem is that 5 is “Executables”, making all of the other clients think you’re after “executables” and not “audio” and “compressed files”.
“Sigh… Every time you talk about NMDC, I hear something bad… Fine. So, what’s so good with ADC then?”
Ah, my dearest Watson, it is very simple. In ADC’s SCH, one can specify a “EX” (”extension”) when searching, and the responding client have to match files with atleast one of those EXs. This means that we can specify completely what kind of file types we want - even if the other client hasn’t hard coded any file extensions in its client).