[RetroRain]

I've read this page:

http://www.romhacking.net/system/common/rominfo.html

And I'm not ashamed to say that even after reading that, I just don't get it.

About a month ago, before I started work on my Zelda Optimum hack, I took all of my mapper conversions out of the pack I had, and tried to upload them all onto the RHDN database, but they all got rejected because I didn't provide adequate ROM/ISO information.

I can put the ROM name (for instance "Megaman (USA).nes"), and according to that page, I can use a hex editor such as HxD to get the checksum, but all of the other information, I'm not sure how to go about getting (I don't even know what the hell it all means).

I would just like to know what's the easiest way going about getting the ROM/ISO information, so that I can upload my hacks without having a problem.

Thanks.

[Disch]

For an NES ROM, you can get the CRC/MD5 from FCEUX.

Load up the original unmodified ROM, go in Help | Message Log.  It should give you a bunch of info about the ROM.

A suitable entry would be:

GoodNES name:  Adventures of Lolo 2 (U) [!].nes
ROM CRC32:  0x1992d163
ROM MD5:  0x6ea5a463d04ddc42e9483dcfef86b0cf

The idea is to remove ambiguity over which version of the ROM the patch requires.

[RetroRain]

Alright, thanks Disch.  I'll take a look at it.

[Zynk]

For an NES ROM, you can get the CRC/MD5 from FCEUX.

We prefer that you use ROMHasher or GameHeader for generating ROM information tho

[Disch]

We prefer that you use ROMHasher or GameHeader for generating ROM information tho

Does it matter?  Does FCEUX compute it incorrectly or something?

EDIT:

I guess ROMHasher includes SHA-1 hashes as well as optionally including the header in the hash.  But yowsa 1.5 MB download just to generate hashes when an emu you're already using has the same functionality built in?

[RetroRain]

I had my Megaman 2 MMC5 Patch rejected because I already released Megaman 2 Optimum, which is MMC5 + CHR-ROM.

My MMC5 patch is simply that, a conversion to MMC5.  The game uses its original CHR-RAM, where-as my Optimum pach uses CHR-ROM, and it took me a month to make.

Could you please re-instate my submission?  There was no reason for it to be rejected.

Thank you.

~RetroRain

[Zynk]

I had my Megaman 2 MMC5 Patch rejected because I already released Megaman 2 Optimum, which is MMC5 + CHR-ROM.

My MMC5 patch is simply that, a conversion to MMC5.  The game uses its original CHR-RAM, where-as my Optimum pach uses CHR-ROM, and it took me a month to make.

Could you please re-instate my submission?  There was no reason for it to be rejected.

Thank you.

~RetroRain

But they essentially do the same thing, there is no point making another page. I suggest adding that patch with the MM2Optimum page.

Does it matter?  Does FCEUX compute it incorrectly or something?

EDIT:

I guess ROMHasher includes SHA-1 hashes as well as optionally including the header in the hash.  But yowsa 1.5 MB download just to generate hashes when an emu you're already using has the same functionality built in?

GameHeader is 125kb tho. I'm not saying you can't use what the emulator generates tho, as long as the crc32 or md5 or whatever info that has the match for the base rom used for the patch are provided.

[Recca]

I hate to be rude, but in my honest opinion, I find this whole new policy with the ROM/ISO information to be rather annoying and pointless. Most people don't even know what any of it actually means. Wouldn't it be enough to just have a readme text file included with the patch that says "use version 1.0 or 1.1 of the ROM - headered or unheadered" or whatever?

Before I was able to finally submit my Silva Saga-II translation last year, it was rejected about two or three times because I didn't add this useless information in the ROM/ISO field. I had to ask my team mates for it just so I could get past this new field requirement for submissions.

I'm not saying that it should be removed, but could it at least be made an optional field? I firmly believe that if RHDN keeps up this new rigid enforcement of pointless rules and requirements, many fans will stop submitting hacks and translations here because they simply don't want to put up with their submissions being constantly rejected. This otherwise great site will then miss out on many possible future hack and translation submissions. Again, I don't mean to be neither rude nor pushy. This is merely a suggestion, not an order, nor anything else.

Thank you very much for your time and understanding in this manner (holds for applause)...

[Disch]

I don't hate to be rude, but IPS is a completely retarded format and is the cause of all these ambiguities in the first place.  And any halfway respectable patch format would have the ability to do a basic CRC to make sure you're patching the correct file and at least give a warning if you're not.

If you're worried about ambiguities in patches -- maybe requiring new hacks be submitted in a less naive format is a better approach than having the submitter specify MD5s that most people are going to ignore anyway.  It might be an inconvenience at first, but if any site has the weight to push people away from the POS format that is IPS, it's this site.

[RetroRain]

But they essentially do the same thing

The difference between the two patches is huge.  There is a big code and graphical difference in MM2 Optimum.  I wanted to keep them separate.  The MMC5 patch actually came first, but I uploaded Optimum instead.  I feel it is better for people to have more options.  They can use MMC5 with CHR-RAM, or MMC5 with CHR-ROM.  It is their choice.

So if I get my Zelda MMC5 patch approved, and then I decide to go and upload my Zelda Optimum hack (which is MMC5 + CHR-ROM), that will get rejected also?

I can add my MM2 MMC5 patch to the Optimum page, yes, but then I'd have to post a link to where I have it on acmlm.kafuka.org.  I thought the RHDN database was meant as a more official place for hacks.  Incase my hack ever got deleted on acmlm.kafuka.org, it would still be on RHDN.  You can't submit more than one file on a RHDN hack submission.

So from what you're saying, I have to link to the standard MMC5 patch in the hack description.

I'm not going to make anymore issue out of it.  If that's the way it is, then that's the way it is.

[Zynk]

The difference between the two patches is huge.  There is a big code and graphical difference in MM2 Optimum.  I wanted to keep them separate.  The MMC5 patch actually came first, but I uploaded Optimum instead.  I feel it is better for people to have more options.  They can use MMC5 with CHR-RAM, or MMC5 with CHR-ROM.  It is their choice.

All right then. Just let the queues get cleared first.

And any halfway respectable patch format would have the ability to do a basic CRC to make sure you're patching the correct file and at least give a warning if you're not.

Isn't that what the bps patcher does?

[Disch]

Isn't that what the bps patcher does?

It's one of the many things BPS does better than IPS.

Seriously, IPS sucks.  Hard.

[puzzledude]

Seriously, IPS sucks. Hard.

Thumbs up. There is also a German "version" of a romhacking site and guess what, IPS is not allowed. All patches are required to be in UPS format (which has a CRC validation of the original rom and will not patch if CRC of the original rom doesn't match), plus all patches have a txt with the info on original rom again in crc and if it needs to be headered or unheadered and a version as well US, EU, Jap, Ger). This should be a rolemodel.

I hate to be rude, but in my honest opinion, I find this whole new policy with the ROM/ISO information to be rather annoying and pointless. Most people don't even know what any of it actually means. Wouldn't it be enough to just have a readme text file included with the patch that says "use version 1.0 or 1.1 of the ROM - headered or unheadered" or whatever?

Unfortunatelly thats not enough. Every patch needs to have the exact ID of the original rom to patch to. Usually the CRC checksum will do, but ofcourse the MD5 and SHA are too much, however one byte can still be different on identical CRC. So the MD5 id checksum is necessary. It's like going into the bank, you need your personal bank account: id est a number.

When dealing with IPS, you also need such an id number for the original rom to patch to. If the number doesn't match, the patching will produce a bugged rom. So the Rom/Iso info is vital, as well as the header info (since sometimes the header is not included into the id number, which is a false thing to do).

Mandatory info should be this: the id of the original rom (but CRC and MD5 only) and also of the correctly patched rom. And the header should be included into the id calculation. 4 numbers which would ensure correct patching.

The other possibility would be to unallow IPS and switch to UPS format or xdelta. Anything which has this id CRC calculation info in the patch itself and won't allow patching if the original rom CRC is not the same from the one the author used to create the patch.

Of course I agree though that the submission process is quite complex in general.

[FAST6191]

Though I am certainly no fan of IPS (no relocation, no hashing, offsets a kind of hack/addition if available at all, adding data on being tricky, 16 megs or thereabouts max file size if windows/offsets not supported...) it is supported by various emulators, flash carts (as in actually in hardware), flash cart programs, is output by various editing programs if you want it to be and other things that might be easier said than done on matters of changing them. It has been a while since I looked at the UPS spec and I am not even going to humour something like xdelta in this but if memory serves it would be considerably harder to do UPS at microcontroller/already overloaded programmable chip level, assuming you are not going to do a limited feature set, than it would be to do IPS. Also there would probably have to be a debate for the new format -- UPS falls quite short on some of the newer (but still non current) systems.
To that end I think I would sooner back a call for more hardline approach to the base ROM supported (only with ? type of header, only non interleaved, only untrimmed....) first, and I am very unlikely to do that.

What is the collision rate or lack of change for small changes for CRC32 then? I was under the impression it was more than reasonable for basic corruption detection and verification.

[RetroRain]

All right then. Just let the queues get cleared first.

Thank you.  Do I have to go through the submission process again?  Or will you approve it once the queues get cleared?

puzzledude, I tried to send you a PM, but I guess you have PMs blocked or something.  It was nice to see a reply from you.  I hope things have gotten better for you.

Disch, thanks again for your help.  I now know how to fill in the ROM/ISO information of the hack submission page.

[KingMike]

Does it matter?  Does FCEUX compute it incorrectly or something?

FCEUX ignores the header when it calculates the hashes.

Actually, CRC validation could create another annoyance with NES patches: header garbage.
Back in the Nesticle days, some people (such as whoever/whatever "DiskDude!" was) would insert garbage in the headers (including byte 0x7, which is the high bits of the mapper number, since apparently the last Windows version, the most widespread, of Nesticle didn't support beyond mapper 15). Unfortunately while Nesticle died, that crap got into the "GoodNES" database as "good" ROMs where it lived on forever, as the most commonly distributed ROMs on the Internet as GoodNES became the defacto standard in NES ROM sets. Can only imagine how many ROM hackers made hacks out of those ROMs and were unaware of the issue.
I think I may even once deliberately made a patch with a cleaned header against one with a dirty header as, in IPS format, that would wipe that crap out as a bonus to ensure no complaints of "it doesn't work" because of a corrupted header.

[Disch]

FCEUX ignores the header when it calculates the hashes.

Actually, CRC validation could create another annoyance with NES patches: header garbage.

Perhaps that's why FCEUX ignores the header? 

I know all about DiskDude and the unreliability of iNES headers.  But frankly this is another problem entirely.

If we are comparing the merits of a CRC validated patch format vs. IPS -- any problem that exists with CRC validation will exist with IPS.  The only difference is that with IPS you won't know about the problem because it will just silently succeed and leave you with a ROM that doesn't work.  Whereas with validation you'll at least get a warning/error message saying the source ROM is the wrong version.

[STARWIN]

I believe the current guidelines are somewhat broken as far as NES hacks are concerned. While it is clear that a checksum is required, it is not clear if it is over the header or not. I think the rominfo page would on average cause the file checksum to be provided (which then differs from what FCEUX or ROM Hasher shows, for example). Any "CRC32" currently given could refer to either, and even if you clarify the supposed interpretation, those old checksums will stay. And what if an old hack or translation specifies file/ROM checksum in its readme as opposed to what RHDN would currently require? Hence the field for NES should always specify file or ROM..

Regarding IPS being outdated, there is one more property that IPS fulfills and a checksum-enforcing patching format doesn't: the ability to patch a small hack / hack component to any version of a ROM (assuming they are similar enough). It would be seriously annoying to require a patch format that would disallow high compatibility hacks. For this use case file/ROM checksums are too broad, instead a checksum over the sequences of patched byte locations would work (yet shouldn't be enforced even then).

[puzzledude]

puzzledude, I tried to send you a PM, but I guess you have PMs blocked or something. It was nice to see a reply from you. I hope things have gotten better for you.

The setting should be fixed now.

While it is clear that a checksum is required, it is not clear if it is over the header or not. I think the rominfo page would on average cause the file checksum to be provided (which then differs from what FCEUX or ROM Hasher shows, for example).

ROM/ISO info should be changed into Original file info, and the hashes should always be provided for the whole file. If headered file is necessary, then the info should be different from the situation, where the unheadered file is necessary.

[ShadowOne333]

@Rockman

Why don't you add the MMC5 patch to the Optimum release?
You could do the same with other Optimum releases of yours.

Simply add the complete Optimum patch along with another patch that has only the MMC5 modification in a nice .RAR
Just be sure to edit the hack description to mention what each one of the two patches does.