The only two real useful changes I can think of are 1) multi-file patching and 2) support for checking the file's CRC32 before patching (to warn you if you're patching the wrong file). Fortunately, with clever filenames neither of these need require any changes to the patch format itself. For #1 you can just point the patcher to a directory, and for every file it will look for a corresponding patch (foo.bar -> foo.bar.ups). For #2, include the file CRC in the patch filename in a way that the patcher can automatically find it (foo.bar -> foo.bar[12345678].ups). Simple.

Even better if the patcher supports filenames on the command line, then we could just write a batch file/shell script to apply all the patches, except on Windows we'd have to either include the patcher or have the user copy it to \\WINDOWS or something to be able to call it. :-/

I wasn't clear exactly what "X File" and "Y File" are in the spec. Do you already have #2 in there? If so it should be possible to create a patch that doesn't specify the destination file CRC. For example, a patch that may be applied to a hack in progress or to more than one version of a game. (Hence why I suggested putting it in the filename - just leave it out and no CRC checking.)

Anyway sounds like a great format. XOR patching is a brilliant idea and I think you're right about RLE being unnecessary if all the patchers support zipped patches. I'll be using this in the future. Maybe a patcher for the DS?

Looks good! I can only add that the patcher won't like pointer values > 2^64, but that shouldn't be a problem for the near future.

HyperHacker:
byuu's patcher already checks the CRC32s and reports a matching error message. Multi-file patching will be done by the container format; UPS is only for single files. The patcher does support filenames on the command line.

I know this is quite off topic, but what was worth changing for the DL update? You guys find more script inconsistencies you wanted to edit, or more bugs or something?

I'll read the readme later, but I wanted to see if there was anything significant. Also, it's not April Fools Day. So you're a liar. 

~DS

Blah blah. D's in China. =P

Are we (the beta testers) supposed to still be testing DL? If so, I apologize, I didn't know. >.>

Interesting, a debug system. Me likes.

~DS

Yeah, it does do that. I should add a safeguard not to select the same input+output file name.

I always create the dest file and start patching it. I have to, before I can verify CRCs. The delete thing happens outside of the UPS lib, it just knows patch apply fails and deletes the dest file name. Don't want to leave the file there for people to try and use.

I can refine this for future releases.

Well, I went ahead and put together a Cocoa version of the UPS patcher because I'm a mac user...and this is what the Mother3 project will be using and I really don't like using weird windowing frameworks on OSX (Qt, Gtk and whatnot....). Sadly I have no way to test this patcher, even on the windows version when I tried to create some dummy files is choked on itself. If someone has dummy files that work in the windows one I will get my OSX version posted up, only 44k zipped, should run on OSX 10.3+.

 - Josh Weinberg

Edit 1:--

Seems that the patching fails in really small files, I tested it on a large file and it worked like a charm...putting it up on my site now...

Edit 2:

Bin:
http://opennestopia.staulkor.com/UPS.zip

Src (Including XCode project):
http://opennestopia.staulkor.com/UPS_Src.zip

n'joy

Oh, oops x.x
For some reason, I thought you came up with that command. Thanks for the correction.


You rock!! Thank you very much :D


That was the idea. Fix what's wrong with IPS, and keep the new format as simple as possible. And as you can see, people can already write their own patchers in ~30 minutes time.


To detect corruption errors in the patch itself. Sure it's rare, but we're only talking about four bytes. Call it peace of mind.


Does anyone really sit there and hack IPS files directly? Modify the resultant ROM for that. I'm aiming for features more likely to be used. People hand-editing patches is less likely than people applying patches and wanting to make sure the patching process succeeded. Compare to something outside your niche: how many people burn ISOs and want to validate the burn, and now how many people manually hex edit the ISOs by hand first?

Seriously, again ... how many people modify IPS patches by hand? How many people will be seriously inconvenienced by not being able to do this? There are more appropriate tools for this, such as xkas (yes, it can even be used on systems other than SNES and GBA, albeit without opcode support.)

And if you can compute XOR diffs between two files in your head while modifying data -- wow. My hat is off.


XOR data doesn't play well with multiple versions. Again, I had to weigh what was more practical. What happens more often? Someone makes a patch that can safely convert multiple versions of a game, or someone patches a game that has a header when the patch was made against an unheadered ROM, or a hacked / modified ROM, or a different version of the same game (v1.0 vs v1.1)?

The DQ6 IPS patch by NoProgress is the only case I think off off the top of my head that applies to multiple input files. Does anyone else want to compare a random sampling of ~50 IPS patches and determine how many contain this ability?


Right, that's the trade off. And with IPS, you can never revert a file to its original state, using only the modified file and the patch. Both are rarely used features, but I believe the latter is more valuable. The latter has novel uses outside of ROM translations (eg file backups), too. We can disagree if you like.


Of course not, you've pointed out every possible disadvantage while ignoring every advantage but one. Not surprising since you're working on your own competing format.

Recap:

UPS is better than IPS because:
- it guarantees that you have converted file X to file Y; it can use this information to quickly determine whether a ROM header needs to be stripped or not
- it verifies the patch file integrity itself
- it's bi-directional, so you can un-apply hard patching if needed; easier to store / re-download a ~100kb UPS patch than a ~32MB Japanese ROM backup
- it supports infinitely sized files, no 16MB limit
- it's easier to implement
- no ambiguity in the file format, and no "extended features" -- all patchers make 1:1 identical UPS patches
- because of its simplicity and PD licensing, we will be adding it to multiple emulators for soft-patching -- ZSNES, Snes9X and bsnes for sure; VBA-M most likely; as it's supported by multiple emu devs, we'll be developing libraries to get this into even more emus

UPS is worse than IPS because:
- you can't apply the same patch to multiple input files to get the same output file
- you can't edit it directly in a hex editor ... yeah

UPS was a peer reviewed format. You're the first person I've seen who prefers uni-directional patching to bi-directional XOR patching. I wish you would have chimed in during the past two years myself, Nach, Derrick and others were discussing the format spec on this very forum.

I understand you want to promote your own format, but please don't attempt to do so by denigrating ours. I'll return the same respect to your XRIF format.