You screwed up the link, dude. >.>

An IPS replacement is still needed, though. A lot of GBA games are bigger than 16 megs, IIRC.

Edit: Plus, N64 games...

Plus, the (minor) difficulty of making incremental tweaks can be used as an integrity-preserving measure by some. Not everyone wants you to change their translation patch to replace every character’s name with “COCK”. Won’t really stop anyone who really wants to do it, but at least it makes your patch ... more your patch.

(beaten to the punch, but just had to get it out there)

Then you use the "override" option of your favourite UPS patching program. (EDIT: As nomit said.)



Complexity is one of the main reasons why projects fail. Separating tasks is a good thing - it actually makes matters easier and more maintainable. It's a very important concept in writing software; The Art of Unix Programming has some nice chapters about that.

With UPS, NINJA3 is much easier to create because a part of the job is already done.

While I agree with many of the issues raised with UPS, it's looks to be really good for it's aims. As both of the projects I'm currently working on are ROM expansions, it doesn't address my major concern with IPS, but that's not it's intended application. It's intended to be a better IPS and aimed at the same problem domain. From this perspective, it's looks to be quite well thought out.

The decision to leave out any sort of compression is a good one. I'm reminded of the Gimp, who's native file format has no compression either. Rather, it leaves compression to other programs. (It does have support for gzip and bzip2, but they're simply applied to the real native format, rather than integrated into it.) This has shown to be a good choice on thier part as the compression provided is exelent, while the file format is unaffected by the complexities of compression. It is also useful that the compression algorithm can be changed at will.

The checksums are a nice touch too. Personally, I'd have prefered to see a real hash algorithm, but I can understand the reasons that you would wish to avoid that level of complication.

The choice of XOR rather than overwriting is a interesting one. I definetly appreciate the utility of being able to transparently reverse a pactch. As all my patches so far have been in IPS format, I've felt that it was proper to include a reversal patch with my packages, which wouldn't be neccessary with UPS. However, the inablility to cleanly patch a number of differing source files with a single patch is unfortunate. I suppose it was a judgment call that had to be made.

I strongly disagree with the suggestion someone made that UPS be required for all new patches uploaded to RHDN be in UPS format. I belive that we shoud "let the market decide". While it may be a good idea to encourage the use of the format, such heavy handed measures would be inappropriate.

Best of luck with the new format.

Just curious ... which concern is that? UPS can expand and shrink ROMs quite easily. Inserting data in the middle of a file is the problem -- which is something you'd never do with a ROM-based system -- but even that works, the patches just end up very large.


I agree wholeheartedly. The patch format should be the decision of the patch author.

The one thing I'd really like is for it to replace IPS soft-patching for the SNES. The header issue is too severe. I'm not going to implement a patching algorithm that has a 50/50 chance of working. I believe it's also very helpful for finalized patches for any ROM-based system, especially those >16MB, but that's up to you guys to decide.

byuu said a few pages back that he doesn't have the equipment or resources to create a Mac patcher (i.e. he doesn't actually own a Mac or the tools for writing Mac software), but if UPS takes off, we'll probably be seeing patchers for multiple platforms in short order.

From the image posted on the site, this looks like a great successor to ips. It's simple like lunar ips, but it can support much larger files.