For a while I thought to myself, there should be a ROM hack format that patches individual files in the ROM, instead of the ROM itself. Meanwhile, psy_commando had a similar idea (I'm making a new thread so that one will be exclusively for PMD2).
The current discussion for those who haven't read it:
I've been working on upgrading Sky Editor to make making ROM hacks like these easier, and before I actually write code for making patches, I think it's time that we ROM hack tool developers discussed and made a standard.
Here's my proposition: a "mod pack" zip contains one or more smaller mods and the patching tools. A "mod" zip contains all the data needed for 1 patch. Having various smaller mods allows them to be reused in other packs, and to let users pick which mods to apply to their ROM. For example, maybe in Rutile Ruby or Star Sapphire, what if I hypothetically wanted the increased XP curve, but didn't want any changes to items. I could then apply the "XP Curve" mod, but not the "Item Balance" mod.
Here's a more technical proposition:
File structure of the Mod zip (probably called .ndsmod or .3dsmod):
/Mod.json
Contains information about the mod like Name, Author, Target ROM, etc.
Lists IO operations that need to be done (maybe I want to swap /Data/Sound/BGM/bgm0045.smd and /Data/Sound/BGM/bgm0003.smd or delete the entire /TOP directory)
Can optionally list other mods that must be applied before or after this one. (For mods of a mod; patching files that are added by other mods).
(Optional) /Patcher.exe
Optional patcher in case weird file types are included, or to allow for randomizers.
Usage: "patcher.exe [directory]", where directory is the path of the ROM directory (the one containing arm9.bin, arm7.bin, and the Data and Overlay directories).
/Files/
Contains certain kinds of patch files in the same directory structure as ndstool extracts them.
Ex. /Files/Data/BACK/expback.bgp.xdelta is an xdelta patch for the file at /Data/BACK/expback.bgp
Ex. /Files/Data/FONT/kaomado.kao.kaopatch is a special file the patching utility knows how to handle that adds more images inside the file at /Data/FONT/kaomado.kao. The advantage over a binary difference is that multiple mods can independently add images without interfering with each other.
Ex. /Files/Data/Back/MyBackground.bgp.file is a brand new file to be added at /Data/Back/MyBackground.bgp
Any directories present anywhere in the folder hierarchy in /Files will be added in the appropriate place.
File structure of the Mod Pack zip:
/Pack.json
Contains information about the mod pack like Name, Author, Target ROM, etc.
/Patcher.exe and/or /Patcher.bat and/or other comparable OS specific patcher file. Should probably be required to support command line arguments (patcher.exe [inputFile] [outputFile]).
/Mods/ - contains one or more mod zips.
/Tools/ - contains any tools or executables needed by the patcher. Exact name doesn't matter as long as end users don't need to worry about its contents.
/Tools/FileFormats.json
Maps executables (or comparable files like .py) that know how to handle individual file patches to the proper extension, like the .kaopatch example above
Ex. Could have an entry for .kaopatch that points to "/Tools/RomEditor.exe -kaopatch -i {Input} -o {Output}", where {Input} and {Output} are replaced with input and output paths.
Ex. Could have an entry for .kaopatch that points to "/Tools/KaoPatch.exe" where usage "kaopatch.exe [inputFile] [outputFile]" is implied
This format is designed for NDS Roms, but should also work with 3DS Roms (as long as the patcher is included).
Formats of the .json files can be finalized later.
This format should be as legal as xdelta patches unless I've overlooked something. Feel to post questions/comments/concerns about any aspect of it, especially if you're a ROM hacking tool developer or a ROM hack developer.
[Edit 8/2] Updated details to match my current development.