(Menu) Allow selecting soft-patch in the menu

[rszasz]

I think support for the huge number of "romhacks" would be increased if there were a way to simply specify a patch file along with the other data in the playlist file. I don't know how patch information is handed off to cores (or do they currently handle that on their own?) but it seems like having the info available to the menu/launcher would open up options beyond avoiding massive file duplication.

---

As it is now I've duplicated and renamed the base rom for every romhack patch. It would be great to have some way for a bunch of patch files work against a single copy of the base rom.

[RobLoach]

https://docs.libretro.com/guides/softpatching/

Just name the patch the same name as the rom file, and it'll soft-patch it when you load the game.

[rszasz]

Just name the patch the same name as the rom file, and it'll soft-patch it when you load the game.

And if I would like to have a playlist with, say, 3 different romhacks of Super Mario World? Filename based matching works ... Ok ... if and only if you want to have one patch you always use for a given rom.

[RobLoach]

I believe you could...

1. Copy the rom three times (name them the hack names)
2. Stick the patch files beside each rom
3. Use the manually add playlist creator to build a playlist of your hacks directory.

Yes, there's duplication, but it is a workable solution. Could you think of a clean user interface method to do this?

[rszasz]

Sure, but that's little better than just hardpatching. Since the frontend already set up for softpatching, there really should be a better option than launching from the command line with a -ips flag.

It would be useful in quite a few situations, and I'm not seeing any downsides to adding the option of putting the information in the playlist.

I guess it breaks 6 line equivalency if used. But having the frontend automatically select a file and not having a good override stinks.

[i30817]

I believe you could...

1. Copy the rom three times (name them the hack names)

2. Stick the patch files beside each rom

3. Use the manually add playlist creator to build a playlist of your hacks directory.

Yes, there's duplication, but it is a workable solution. Could you think of a clean user interface method to do this?

4. use hardlinks on the rom file in linux to 'duplicate' it without wasting space

The actual main problem with softpatching in retroarch is that all of the patch database data, of which i contributed many is not used and RA keeps saying the game is the original. This was even before RA changed the scanner to scan filenames/serials instead of CRC, so it can't even work if that is 'fixed'.

I proposed a solution but got ignored : https://github.com/libretro/RetroArch/issues/8873

Basically RA shat on hack metadata decisively because people complained about scanner speed, so there isn't even a reason to keep contributing hardpatch hack metadata, and softpatching was already 'unrecognized'.

You can envision a menu where you'd select a hack, retroarch would associate the hack file checksum to the hack metadata and then you'd select the rom, but that kind of idea runs into the facts that sometimes there isn't a original patch (translations released as the complete game); or that there are many different hack formats and sometimes they have to 'transform' the roms or aren't single files (for instance, many snes patches need header adjustments, or all pc-98 translations are organized as a executable patcher to work on the many releases of the game, but you can turn them into a bps yourself, for if RA patched that, which is debatable to even stick into a database since it's not 'original' code and RA can't run that patcher).

The other problem with RA 'support' for softpatching, is that it's core code, not frontend code, so it doesn't work unless the core says so. And many many cores say no - so doing it 'ahead' of time before launching the game requires at least moving the softpatch to that frontend level.

[RobLoach]

use hardlinks on the rom file in linux to 'duplicate' it without wasting space

That's a great idea!

The actual main problem with softpatching in retroarch is that all of the patch database data

Correct... Would love to have it index patches outside of the database. To have it self-discover the hacks/patches would be awesome. We can't have all the hacks in the database, since it would grow infinitely. But having it find patch files, and add them accordingly in the playlists would be great.

I proposed a solution but got ignored : #8873

It's not that you're ignored, it's just that it requires a lot of work to figure out the design, and how to implement it.

[i30817]

use hardlinks on the rom file in linux to 'duplicate' it without wasting space

That's a great idea!

Not that great. The main place where this would be useful is cdrom hacks (huge), which can't actually use softpatching because the softpatching formats don't stream and dump the whole patched file to memory. If chd gets parent-child relationships that's almost as good though, if more complicated to create.

What i currently do for cd hacks is to keep a revert hack from the patched file to the original cd, which doesn't help when the same game has multiple hacks (CSotN comes to mind).

The actual main problem with softpatching in retroarch is that all of the patch database data

Correct... Would love to have it index patches outside of the database. To have it self-discover the hacks/patches would be awesome. We can't have all the hacks in the database, since it would grow infinitely. But having it find patch files, and add them accordingly in the playlists would be great.

Uh, i wasn't even thinking about keeping the 'hacks' or the 'patches' in the database, just the checksums (and website links if possible). You really don't want to keep patches in a database or your server, because cd patches can easily get multigb for a single game.

I proposed a solution but got ignored : #8873

It's not that you're ignored, it's just that it requires a lot of work to figure out the design, and how to implement it.

My intuition was this this was ignored because

1. it's not a 'windows' ready solution (though ntfs has its own support for something similar)
2. while this is a ok memoization approach, you can memoize the checksum after it was calculated just as well with the modern json playlist format and RA already rejected that when it changed to serial scanning. What this is for, is for external tools (like rhdndat) to figure out those checksums (with the advantage i mentioned to 'associate' a softpatch to the file possible). I'd probably be just as satisfied with a playlist entry i could fill with the 'result' checksum actually, if RA actually used it to fetch.

Actually now that i think about it, and checked; apparently hardlinks and extended attributes don't actually work together, so i'd prefer a setting on the json playlist entry to 'force' a checksum check.

[hizzlekizzle]

I'm struggling to think of a way to associate patches with a specific game (other than the current same-name system) in a way that doesn't require making magical manifest files by hand.

The best I've come up with is if you make a directory that shares the same name as the game and throw your patches in there. Then RA could check for the directory at the same time it checks for patches and then pop up a menu to choose among the contents.

[i30817]

It's even more complicated than that, though you probably want to shut down that 'feature'. Some patches need or could be combined with other patches. Fuck, some of them have combinatoric options because they're distributed with a executable (easily the worst idea of the decade in romhacking).

I honestly think i'll just request a way to force a rdb database lookup with a crc32 method. Then i could just 'auto' associate the right crc32 (because i already have tool calculating those for patch updates). Doesn't help anyone else though, but it would help me and that's what's important aha. And it would be a reason to keep updating those database files.

[rszasz]

Duplicating and renaming the rom file is an option, hardlinks are an option, building a fuse based patching system is an option, hardpatching and ignoring the checksum is an option, running from the CLI and using the -ips flag is an option.

If I want to use retroarch to do softpatching, avoid file duplication or hardlinks, and browse/run patched multiple titles based on the same rom from within retroarch, would adding the patch URI to the playlist, and have retroarch use that in preference to searching for a filename match make sense.

[i30817]

RA needs to keep using the 'filename match' method when available for backwards compatibility (including mine). No way i'm going to move hundreds of files or recode my tools to assume a same named dir instead of a same named file. Which one has priority i don't care though.

I feel that method will have trouble if you want metadata on the rdb (instead of the patch file name), for many not obvious reasons, so if the assumption is that that will be possible, i'd reexamine it.

[rszasz]

Selecting a Softpatch in the menu (of a rom) sounds almost exactly the OPPOSITE of what I think would be easiest to implement and be helpful.

[rszasz]

RA needs to keep using the 'filename match' method when available for backwards compatibility (including mine). No way i'm going to move hundreds of files or recode my tools to assume a same named dir instead of a same named file. Which one has priority i don't care though.

I feel that method will have trouble if you want metadata on the rdb (instead of the patch file name), for many not obvious reasons, so if the assumption is that that will be possible, i'd reexamine it.

I was specifically suggesting allowing another entry in the playlist JSON that would give point to a patch for that title. If there was no entry, default behavior would continue, with an entry, it would treat it like the -ips cli flag and softpatch. No need for a bunch of deep changes, no DB of patches, browsing romhacks would be just like browsing roms....

[i30817]

Manual editing of playlists...

Ok I don't actually care as long as the current same name method keeps working. If it's in another dir and a menu appears, or the user opens the playlist and copy pastes a entry and adds a property, that's all ok for me as long as that property is maintained.

[rszasz]

Editing/generating a playlist is something I can write a script for, or just edit in atom or notepad++. Checking for a value in a playlist entry and duplicating steps the patch file check uses is probably something I can manage.

[i30817]

You realize that if that was implemented you get no metadata but what you can fill in (basically the display label)? RA database doesn't have crcs or names of 'patch' files, only complete patched roms (and i agree with this for the several reasons mentioned before). And since as mentioned the RA frontend doesn't patch files (only the cores do), that's no good to find the crc for softpatches either.

Just FYI. Then again the main thing you lose is the main hack name(s), and if RA had a feature to display/open it, the source of the patch, it's not like anyone is going to make images of hacks or libretro-db going to accept them.

The issue i opened recently https://github.com/libretro/RetroArch/issues/10136 is a way to allow a post processing tool to fill in the crc if you have a way to calculate it and recognize a softpatch (or a hardpatch), and i do, but i don't follow the 'directory for softpatches' structure, rather 'single dir per hack, with a 'manifest' - a version file to check for updates in rhdn.net.

[rszasz]

You realize that if that was implemented you get no metadata but what you can fill in (basically the display label)?

Yup. This is adding a minimal feature with compatibility in mind. Might be built on in the future, might not, but shouldn't break things, and fills a minor need. (following the structure of the frontend code is driving me a bit batty right now though, I'm trying to find where the CLI does it's thing and use that as an entry point)

[andiandi13]

I just came to the same conclusion as you @hizzlekizzle regarding having a directory with the name of the rom in the same folder.

Multipatching is an exception, and @eadmaster or someone else may find a way to add that feature I hope.

But for simple patching I think a folder-based system would be perfect.

In order to soft-patch a ROM, a better way than an additional option would be to simply ask users if they want to choose a patch or not before running a game, just like this :

Clicking on the ips file would directly launch the game with that patch instead of having to patch then run. Also, save files could then be named after ips/ups/bps files.

I don't think many people use their hacks and translations in RA, it's overcomplicated (duplicating saves, duplicating the 3 thumbnails, remake your whole playlist each time you add a rom hack...).

I also thought about being able to check boxes of patches we want to apply before launching the game, which would stay checked at each launch until we uncheck them, and that would be a way of using soft-multipatching.

[andiandi13]

Still no updates about this feature ? Imo that'd be a very appreciated option to avoid archiving tons of patched rom, plus patched roms have their own save files, that's such a mess.

[i30817]

@andiandi13 although i'm not involved in coding RA, i'm going to open my big fat mouth and suggest that that feature you want probably requires changes to the softpatch virtual file system.

And it only works for small roms so forget anything larger than the N64 using it (i imagine it could work for current day computers with 16 or 32 gb, but RA is all the rage in X-box one emulation and even smaller devices, so it would have to be adaptive if support for larger files was not hardcoded out and some users would probably get mad if RA doesn't magically support softpatching ps2 isos on their 512 mb jailbroken consoles).

Although this second one is not a showstopper (because users can always hardpatch), it's something that should be communicated clearly to users (maybe with a retroarch notification that the patch file is too large for the host platform).

[andiandi13]

@i30817 I see, that could be an issue you're right. Maybe just a line saying "can cause crash" could be ok.

I guess soft-patching GBA or Megadrive ROMs wouldn't be an issue even on a 3DS.

[eadmaster]

Adding my own ideas/preferences about this:

• having a separate dir for each rom to patch sounds an overkill to me, and i definitively won't like to use dirs for this purpose (i'm already using dirs to categorize my rom collection, so i think this will add confusion).
  • patchlists are a bit better, but still not very attractive for me since they will only work in RA as intended, and you need a separate tool to edit them, which you may lack on a console.
• using a menu to manually select the patches to apply from the same dir of the current content sounds the best solution to me (while keeping the saves with the same filename of the base rom). So no playlist, but only a file browser filtering with the patches extensions, so you could load any patch with any filename.

[i30817]

Notice again this solution would essentially mean that there would be even less incentive than today for libretro to get patch metadata (i wouldn't be surprised if it was purged), and thus no images except the original game. Moreover since it would be a solution - inside - a game menu, discoverability of the softpatches would be poor.

Which means hardpatches are metadata void - but they kind of already are since the database is extremely reluctant to add large collections of metadata where it matters (ie: if you try to make a pr with hundreds of nes hacks, you'll get rejected out of hand, even if you have a automated way to keep them up to date), so essentially retroarch 'support' for hardpatched roms is already a joke, even if they didn't think serials are 'the way'.

Also notice, many many many patches need to alter the original rom somehow, or be altered themselves as a alternative. Adding headers or removing from patches is common, but so is changing the rom format (for instance shemue translations need a iso format and shemue dumps are cue/bin, or many N64 patches apply to byteswapped). It's not that big a issue because this feature would be orthogonal to the hack database, but it's something to keep in mind if you go forward with recording ips/xdelta checksums.

Speaking of xdelta, could we finally add support to softpatching isos and dvds on large computers? Or at least fork the holdouts (ppsspp) enough to add chd support, which has a softpatch funtionality?