We can't remove extensions from XML DAT since it has to be compatible with CMPro too (ok we could supply 2 XML, but then what's the point of using a common format?). I think the correct ROM manager behaviour would be to always use DAT extensions if included. After all you are using the DAT to name your files, so extensions assigned by DAT author should be used too, no matter expected ones.

Then, in this case (header, but mono format (.fds)), we should use a dedicated plugin which calculate a header free crc, but doesn't return the identified format.

I'm working on the lynx plugin which are in trouble, this fds plugin would be the same thing with a different header size.

I built a fds plugin, and noticed that the crc and the size in the dat is the crc and the size of the full rom.
In other words, no header is skipped.

In this case, the arcade dll will do the job.

Anyway, wouldn't it be better to skip the fds file header, as it's not part of the original cartridge ?

Well Eric, I sincerely apologize for wasting your time then.

I don't know FDS system very well. I assumed that since we are supplying a CMPro header for FDS, it was because it is *actually* required like for NES and Lynx.

Now I'm not sure if our intention is to skip that header. Maybe xuom2 can be more helpful here.

Thank you for the tweaked plugins anyway. So now "lynx.dll" and "nes.dll" should not force double extensions, isn't it?

Lynx.dll should be good (posted here)

fds also, by using arcade.dll plugin.

About nes, we have a problem here.
nes.dll can identify iNES, UNIF, Pasofami, FFE, FDS and FAM format.

It means a final_fantasy rom will be identified as a final fantasy game, no matter the file format (using header-skipping and byte swapping if needed).
Then, the extension is identified from the file format. Ines format should get a .nes extension, the unif should have .unf etc...

The p/c nes file (xml) have the '.nes' format hardcoded. So, what should happens if you get a unf final_fantasy ? It is identified as a final fantasy, because of header skipping, but then the .nes format is used because it is part of the rom name in the dat ?

This dat must be used with a very basic nes-only identifier plugin. All other format will be rejected as unknown. You will identify 2550 roms (2550 games in nes format).

A dat without extension using the full features nes.dll could identify 15300 files (2550 games in 6 file formats)

Do you see what I mean ?

Yes it is, with 1 exception. See reply on that thread.



Yes, ok too, but now at least 7 entries are not recognized. The problem is in dumps (this is not RC-related). The following 7 still have a 16 bytes FDS header (it is not the one in your image, I think that's part of the actual data), for the rest it is removed. The DAT lists size and hashes for header-removed dumps consistently. That's why the CMPro header is probably supplied, in case user has dumps with 16 byte header they get properly recognized.

So nes.dll is required after all.





Yes I understand what you mean. Your plugin allows to validate user files against DAT hashes even when they are in a different format. This is good, because this saves the user the trouble of searching falsely missing files.

However our point of view is that we expect the user files to be in a *specific* format, because we think that it is the correct one.

I've checked NI NES XML DAT using "nes.dll". All files are recognized, but there is the double extension problem (.nes.nes) On a side note to NES maintainer the following entries are recognized as ".pas":



So how to solve this extension conflict for the XML DAT? I can't really blame current RC plugin behaviour, trying to determine actual format and reporting correct extension for user files, this is technically correct, user friendly and useful indeed.

How about an option under "Preferences" allowing to enable/disable "Use Smart Filename Extensions" for DATs using plugins? The user could enable it to check whether his files have expected format and disable it when renaming.

I thought about the problem this night, and I will implement a smart extensions detection (based on 50 roms for example). If I find extensions on all roms, I will mark the datafile as 'extension_provided' and will remove it if plugin has another one.

This will solve all problems without recompiling all plugins.
It will be available in the next 3.40 version.

Put that still leaves the problem of wrong formats. I uploaded my NES roms recently (checked with RC) and another user checked them with CMP and detected that some of them were on the "wrong" format. Imho, there should be an option in RC to select the format (or an option to use a format flag in the dat). I want my set to be in one format only (iNES I think it is for the NI dat, right?)

Yes, expected format for NI NES is iNES. Recently BigFred converted remaining UNIF entries in DAT to iNES, but since RC "nes.dll" plugin can handle required conversion to match new hashes in DAT, you didn't notice required changes. Also you were probably using the old RC DAT format too, without specified extensions, so all looked good on your side.

I've been thinking into it and a possible easy solution is adding a new column to ROM paths main window, containing "Format" (iNES, UNIF, etc) as detected by plugin. The user just need to sort by this column to quickly check the format (and then select files, move, convert externally, etc). Or modify the current "Zip Comment" column so it reports detected format in addition to current "not a valid plugin format".

Also, I would like to suggest adding a "Copy to" shell operation in addition to "Move to". Sometimes is useful.

I did indeed use the old RC DAT format as I'm still using RC2 as I don't like the new concept at all (sorry). For people that usually don't need to merge in stuff but just check their full sets for errors RC2 is still best imho.