Replies: 2 comments
-
Ha, originally I started with one idea of just But I think the idea of "automatically generated manifest" files (for both |
Beta Was this translation helpful? Give feedback.
-
Yep, that's a lot of ideas. Too many. It feels like you changed your mind on parts of it while writing it, and other parts feel like three different threads at once. The only thing I can say for certain is that YAML sucks for everything not handwritten (and also sucks in general), and XML isn't much better. If we're making up any new manifest formats, they're gonna be JSON. |
Beta Was this translation helpful? Give feedback.
-
From what I understand,
.ebp
is simply an.ips
patch file with extra JSON information attached (appended) to EOF.I think it's a solid idea & an ad hoc solution to deal with the many problems for
.ips
patches.Altho, I think their branding ("Earth Bound Patcher") might be off:
...as it gives the impression that it's solely for Earthbound romhacks.
I think a better branding to bring this to a wider audience would be
.ipx
:IPX: "International Patch [system with] Xtra [information])".
And I would suggest a change in the interface, implementation, & specification:
...whereby, by default, flips will automatically generate all this xtra info:
Attach the baserom name with all the hash info (crc32, md5sum, sha1sum, etc)...
...along with the hack name with all its hash info as well (in JSON/XML/YAML/Text).
But with the option to override this default behavior, with a Custom "Manifest" (like
.bps
).From a Archiver/Preservationist/Romhacker/Player perspective, having an
.ips
patch with metadata attached (via .ipx "manifest") would be an absolute dream, because there's no longer any ambiguity at all with regard to the ever present question of "Which Parent/Baserom do I need to apply this patch to ?": ...Which on RHDN was often completely WRONG, ending up with corrupted, unplayable ROMs, if you were lucky: ...If you were unlucky, you wouldn't know that your ROM was corrupted until you invested several hours of playthrough, only to find out that the info on RHDN was wrong, your ROM is corrupted, and you need to find the correct Parent/Baserom and completely startover on your playthrough.We could also extend
--create --bps
to automatically create this manifest and attach it ?Altho, ideally, for NES ROMs (with Magic Number
4E 45 53 1A
), it would automatically remove the header, save it as a field to the JSON/XML manifest, and re-attached it on--apply
if the Header Manifest field was present ?Not only would this be an ad hoc solution for
.ips
patches, but it would also solve the problem with NES patches: That it's really hard to look for a Parent/Baserom (even if you absolutely KNOW with 100% certainty its CRC-32 from the end of the.bps
) because there are literally an INFINITE amount of different possible Headers: It's not just iNes1 & iNes2: Because iNes1's are frequently "signed" by the original dumper: Leading to massive confusion when trying to exactly match the Parent/Baserom. There's also the trick that some people use to "blot out" the entire Baserom Header (with all ones viaFF
) to ensure that the Romhack header correctly overwrites whatever Baserom Header was used.Beta Was this translation helpful? Give feedback.
All reactions