daemoncollector, could you try patching the Der Langrisser UPS file with your patcher to see if it works for you? If so, we'd like to link to it on the DL download page. Thanks in advance :)


Yes, it would. You would just have to apply your patches in order.
Eg, say you have files A, B, C and D. B is A with patches, C is B with patches and D is C with patches.
You would have AB.ups, BC.ups and DC.ups. Apply them in that order and it will work.

Just tested it, works just fine, after i realized my rom had a header on it

Sigh, all I can say is that I went over this with the community. There are posts about UPS as far back as August of 2006, and we pretty much always went with consensus. It's too late now, I cannot change the spec now that it's been published.

I should add though, it is technically possible for a patcher to override the CRC32 check. In that case, you can patch multiple input files, so long as the actual data at each patch location is consistent in all input files.


Oh, you are absolutely fantastic! Thank you so much


Okay, I'll add an option for that. Thanks for the input.

Also, you could technically combine segmented patches and CRCs by using a list of valid CRCs, but of course it would be impossible to list all valid combinations, and it would add a bit of difficulty, especially to patch creation (ugh, I have to select all 37 FF3 variants to make the CRC list for my patch?!)

This makes me smile.  Forward to the land of new code!  Let's hope Gideon and everyone in the community can get on board, this is a great opportunity to update.

There are quite a few reasons one patch might apply to multiple files:
-Applying to a hacked ROM, when you haven't changed anything affected by the patch (e.g. applying a patch that fixes some bug in the code when you've only changed graphics)
-Multiple versions of a ROM that are identical up to a certain point
-Patches that can be applied to many different files (e.g. to change something in the header)
-A hack distributed as multiple patches for customizability (one changes one thing, another changes something else)

Anyway I've always felt one of the most important rules of software is the computer doesn't know best. If the user is about to do something stupid, like patching the wrong file, warn them and explain why they probably shouldn't be doing this, but let them do it anyway. They might have a perfectly good reason for it. That being said, it's probably good enough to have a "patch anyway" button on the warning message, though I'd be cautious with the wording of the message. Something like "this may not be the correct file", that tells people who don't know what a CRC or checksum is what's going on, but doesn't make it sound like something has gone horribly wrong and they should abort immediately. Though I still think it'd be even better if there were some way to skip the check entirely; maybe a CRC of zero?

great job. another option for DS patching! thank you xD

Wouldn't it be a lot nicer if it just included a) the whole files CRC and b) the CRC of all changed bytes from start to end of a file?
That way you could still error that the rom might not be right but at least the places where the patch applies are right.

cYa,

Tauwasser

It seems that everyone wants specific features, but a lot of them add too much complexity and/or are mutually exclusive to each other. There isn't one single magical solution that is going to make everyone happy.

I think a lot of people are missing what the point of UPS is. It's just a replacement to IPS with validation to be absolutely certain a patch was applied successfully.

It works great right as it is on systems without copier headers (GBA, NDS, ...). It will work right now with a few tweaks to the patchers to omit unneeded headers on supported systems, and I'm working on that now, as is Nach. We're going to make SNES emus require that UPS patches are made against unheadered ROMs for soft patching.

It will never be a replacement for something like xdelta, bsdiff, XRIF, etc etc etc. It will always fall short when used on a file that inserts / deletes data before the end of a file. Likewise, it will always be easier to implement both patchers and patch appliers for it. It is designed exclusively for patching and to address the biggest limitations of IPS, while remaining just as easy to implement. That's it.


If I could do both and make everyone happy, I would.

You either get reversibility and/or guarantees that your patch applied, or stacking. I looked at the past history of IPS, the way every last readme had to specify whether or not to use a header and the only way to know otherwise was to apply the patch both ways until it worked. I felt the guarantees alone were more important than stacking -- the reversibility was just icing on the cake that came at virtually no cost.


A file can have a CRC32 of zero. Just a --force option would work.


You would no longer be able to say, definitively, that a patch was applied successfully. It would be possible that the bytes you were matching were good, but code elsewhere was changed / corrupted / hacked that interfered with your patch (eg it bypassed the code where your entry point routine was located.)

Again, as Disch mentioned, these goals are mutually exclusive.

If you really need stacking, you have to give up both reversibility and validation.

It's too late anyway, UPS is out. If stacking is that important, then UPS has already failed. However, I don't believe that it is.

Really, stacking isn't suited for IPS, either. For that, you really want a dedicated patcher / program that can present the user with options when applying a group of patches. Such a system could even validate the input file first.


We're working on it. UPS had to come before NINJA3. We chose not to add system-specific coding to UPS for the obvious reason that it would add infinite complexity to the UPS spec itself. I mean, how would you handle systems coming out in the future, for instance?


It'll be an open standard.