Retroarch: (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?

1. 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)