multips

[uNsane]

Multips is a binary patch applier designed to apply multiple patches at once. It explains any conflicts found between patches and refuses to apply patches that conflict. Its intended use is collaboration, but it is by no means thus limited.

https://github.com/zephyrtronium/multips/downloads

Currently, multips is a command-line tool supporting reading of IPS patches and reading/writing its custom ZP format. The future of multips includes a GUI.

Applying a patch:

Code Select Expand

multips -a target.file patch.file
Creating a patch:

Code Select Expand

multips -merge patch.zp old.file,new.file
Convert IPS to ZP:

Code Select Expand

multips -merge patch.zp patch.ips

For additional invocation help, try multips -help.

See also the rationale behind ZP and the format specification.

(Just as a note, I don't plan to submit this as a utility to the main site. I have my reasons for this, but it's currently nearly three in the morning, so I can't re,e,ner tje.)

[snarfblam]

Might I suggest your utility support writing IPS, even if you don't like it, even if you don't make it the default, because plenty of people are going to want to write IPS files. As for your concern about checksums, wouldn't most utilities provide an option or a switch to ignore bad checksums? As long as it's the user's decision in the end, verifying files can't be a bad thing. I can see it helping when dealing with things like headered/headerless ROMs. Or, many NES ROMs have several versions available. I'm looking at SMB3 and I have (not sure what all the codes mean) (J) [h1], (J) [p1], (J) [p1][t1][!], (J) [p2], (PC10), (U), (U)(PRG 0), (U)(PRG 0)[!], (U)(PRG 0) [h1], (U)(PRG 1)[!], (U)(PRG 1) [a1], (U)(PRG 1) [a2], (U)(PRG 1) [a3], (U)(PRG 1) [h1], and (U)(PRG 1) [h2]. I can only hope these are all properly labelled.

[uNsane]

I can see the argument for writing IPS, but it's not the top priority at the moment.

Checksums have more issues than just what I mentioned in the rationale. Two important reasons why I excluded them are the rise in implementation complexity and the slowdown they introduce. I'm not saying that, for example, Adler32 is slow, but it takes a lot more time to read the entire target and calculate the hash than it does just to go ahead and apply the patch. Another problem with checksums is that I don't always have the input files available for hashing, like when creating ZP from IPS. I did notice the JFP format, which is a modified UPS that hashes only changed sections of data, but this is very insecure with small patches (especially since Adler32 would be my checksum of choice). It wouldn't add much, and adding a note in the patch metadata explaining the intended target file would be more helpful anyway.

[Nightcrawler]

I agree with snarfblam and the rationale makes no sense to me.

1. A checksum can simply be ignored if you so desire and it will function exactly as IPS and apply to any file. There is no need for a new format to address this non-existing issue.
2. You support reading IPS, but you then force any output to be only in your new (unnecessary from item 1) format, which no other tool in existence supports.
3. ZP steals everybody else's ideas and brings nothing new to the table anyway.

I'm going to be blunt. The rationale sounds like you were too lazy or simply unable to implement anything else. Everything was not simple enough and too complex for you. I'm not really seeing any real substance as to why other formats are inappropriate for this application and a new format with nothing new needs to be created and forced as the only option.

It's your program and you can do as your wish, but you're asking for early feedback. I wouldn't expect many users with the current development direction. You're not giving anybody reason to want to use this program or convert to your new format.

[uNsane]

1. To me, the non-existing issue seemed the need for checksums at all. This could well be a result of the hacking community in which I spend the most time; Super Metroid pretty much only has header issues to worry about, and it's easy to explain which type a patch targets and just as easy to tell whether you have a header. Since ZP has a lot of freedom in its design, it's easy to place a checksum in the metadata or after the EOF marker. I'll consider doing so later, if this does survive.
2. Writing IPS isn't currently the top priority, but I'll get to it.
3. Valid. There's nothing really new in ZP. I considered making a format with more power, with things like loops and multiple write types, but what would be gained from that? Simplicity is important. I see a format that takes half an hour and 75 sloc to fully implement applying and writing as a good format. That's what I tried to achieve with ZP. The good ideas were already there, so I adapted the ones that fit my goals.

But I made ZP for multips, not the other way around. It doesn't even require use of the ZP format at all; any comma-separated list of files on the command line is treated as a patch via diff. ZP is just a convenience around having to do that every time. multips is effectively a basic version control system. I don't know any other binary patch applier that is aware of conflicts, except perhaps Just F Patch in a sense. I've seen a lot of community projects flop, and I wanted to do something about it. multips is my attempt at that.