Isn't that already in the spec in one way or another? I remember D mentioning that it's possible for patches to apply changes to several files at once.

Well, there's really not much difference. You would just need to open file twice.

The only issue is the way single-file patches. Right now a filename length of 0 signals a single file patch. I could do it where you can have two patches for the target file executed one after another.

The problem is this: even if you do that, it defeats the purpose of NINJA, because that second patch will be in RAW format. This means it would be applied to ALL formats of the NES ROM: iNES, UNIF and Famtasia. I cannot think of any way to flag it to only one of those file types without changing the spec.

The point of NINJA patches is that they modify the game data -only-. They extract all header information and patch the data directly. Unfortunately this approach sucks when it comes to header modifications.

RAW patches are just fancy IPS patches... which makes the point of making a Ninja patch... moot. I still think there should be a way to modify the header, at least with NES games, but my bitching isn't going to be enough to convince D.

Disch: Then just make a RAW patch. I really am failing to further see the issue here.

The point of selecting NES format is it can be applied to any version of that NES ROM whereas IPS can only be applied to the source file. First off, headers do not exist in the ROM, this is data added to the file by dumpers. If you need to patch data that doesn't exist in a ROM, you are then talking about patching one specific file, and in that case you should be using RAW. You are talking about patching ONLY ONE FILE: the exact matching iNES ROM to the one you hacked, since only that one stores the mapper data that way.

Look, it was hard enough to translate the ROM into and out of UNIF form to get patching working as it does, but unless someone else wants to write a routine to parse an entire UNIF ROM and extract its chunks however necessary, to form an iNES equivalent header, and then repeat this for Famtasia ROMS, this is not going to happen. You will have to settle for using RAW or NES plus a second patch to fix the header.

If you think that's the only difference between NINJA and IPS, you are on crack. Sure, on an iNES ROM it only skips the first 16, but it will pull out all the PRG and CHR blocks from a UNIF to match the iNES form, patch those blocks, and then re-insert them into the UNIF ROM. It does this on virtually every game platform where things like headers or multiple formats exist to prevent failed patching. NINJA's patches are also XOR based to allow for unpatching of ROMs. What's that matter you say? Everyone soft patches? Not people playing the games on their X-BOX or Dreamcast with a NES emulator or people playing patches on any of NINJA's other systems. It's especially important for directory patches. NINJA is also th only format out there in the ROM hack world to support creating binary patches between directories which is useful for people hacking PC games. Do you really want to reinstall a new 3GB PC game every time you need to update your patch? NO. You want to unpatch it, slap the new one on,a nd go back to playing.

If you have a hack like the kind you are describing and have written yourself into this situation, you really have no choice except to bite the bullet and use RAW format which is basically an XOR based IPS with MD5 file validation, or use a NES format one and then a second patch in any format to fix the header (hell, use fc /bunfixed.nes fixed.net >headerfix.pat, NINJA will even use that).

I do not want to make NINJA even more complex than it is because the more complex a patch format gets, the fewer people will support it by writing more patchers for it or writing support into emulators. I'm sure I could write a whole assload of stupid tweaks to support specific cases like this on every system imaginable and a whole if/else logic system within the patch--but no one will fucking write support for NINJA patches then.

What you advocate is almost exactly what I want to avoid. You are nearly talking about entirely different, specialized patch engines for every system to patch twisted shit that doesn't even exist in the ROM. Such patchers exist already:

Look at XRIF. This was written for NES. Its only extension is for NES. How many XRIF patches exist? Zero. How many PATCHERS to apply XRIF patches exist? Zero. Patch creators? Guess.

How about for SNES? Well, you can go use UPS format by Byuu and Nach for that, because even though they have a byte to let them add future types to it, the only one they thought about while creating the format is SNES. I'm sure UPS is the greatest SNES patcher ever made and kicks the shit out of NINJA, because patching SNES was the idea it was designed around.

...

Please re-read the above post and pay more attention.

Figure out a way to do this within the existing patch framework, make it work on every format of NES ROM (at least interNES, Famtasia and UNIF), and not require more than 8 lines of code.

If you do, I will add it.

I understand totally what you are saying about NES headers. That's what prompted me to rewrite NINJA to preserve headers on all ROMS. Before it just dropped them on SNES images. Systems like NES and Lynx have critical data in that header and I understand it can't be emulated correctly without it.

This really comes down to an issue of the few people out there who have the hacking skills to be rewriting NES mappers. But these games are a minority. I really don't see the issue with just including a second patch then to fix the mapper. Or of course, going with RAW. The MD5 validation and XOR alone should make it worth using RAW over IPS or PPF. Besides, you'd need a separate patch anyway to fix the mapper for a UNIF version of the ROM, so you really want to authenticate the entire interNES file.

Yes, my NES mode is a bit of a nightmare. That and SNES make up the bulk of NINJA's complexity. I would write a library, but I am not a C programmer. My whole implementation of NINJA is written in PHP as a console scripting language. I just wrote a frontend to it. It's still quite fast, and it should be fairly easy to port to C since it relies on no PHP specific libraries, but I just don't know enough C to do the port and I really don't have time to learn C just for this.

MKendora was working on a DLL for NINJA, but I think he's at a standstill right now due to other things like real life.

Pretty much. And while we haven't worked on any formats (including SNES) yet excluding raw, we have an XML section that will basically be used to store header information in XML tags. Thusly, it will store information about the headers of both ROMs, so that whatever header you need can be generated from that info. We haven't gotten to NES so there are no details mapped out. Essentially, I'd like the XML data to be auto-generated by the patcher at creation time, but also allow for manual insertion of header data, eg in case you need additional info for UNIF, but you're patching against two iNES ROMs that lack the additional info.
Now, as far as you're thinking ... "ok, well who the hell is going to support XML parsing in their applications?", well, we're both c++ programmers, and we're both writing 100% compatible libraries. Two just for the sake of coding styles and such (Myself, I like OO, but don't believe everything should be objects; can't speak for Nach's style). The libraries will handle all of these details. They can easily be compiled into DLLs or SOs for use with other programming languages.

Also, there is now a header flag for embedding a small amount of info (~1.5k worth) with authoring information and such, so that parsers don't have to parse the XML data to get this info. I kind of like the consistency of having it all in the XML data, but I don't expect many to support that, even with the XML lib. But, we'll see how well my XML parser works. Perhaps I'll change my mind and go back to Nach's plan to have it all in the XML section.


It's easier when you're the only one designing a format. But collaboration and well planned ideas take time. Not to mention we're both very busy. We shouldn't be rushing a format that's supposed to supercede IPS patches for the next ~10 years. But yeah, NINJA's way ahead of us and does a lot more, and does it now. Use whatever you want, they both roughly accomplish the same goals anyway.