[Feature] VMC Group Support

[MinZe25]

Pull Request checklist

Note: these are not necessarily requirements

• I reformatted the code with clang-format
• I checked to make sure my submission worked
• I am the author of submission or have permission from the original author
• Requires update of the PS2SDK or other dependencies
• Others (please specify below)

Pull Request description

This implements a VMC group feature like the one on neutrino xeb+.
When creating a VMC it will check against the vmc_group.c ""db"" and return a group name if it exists. I have added a couple of PAL games that were not in the original list, so some obscure games may be missing.
This just modifies the default name, so no functionality is broken.
(I checked that it worked using a build based on 2201, you can check that it works in https://github.com/MinZe25/Open-PS2-Loader/tree/feature/vmc using ghcr.io/ps2homebrew/ps2homebrew@sha256:08eef2808d40324dfc704fac730c690b2018e095456a98d54d648dbac0629e2d )

[rickgaiser]

What happens to exising VMC's users have? Can they still select their precious VMC's with saved progress? Or do they get a new empty group VMC?

[MinZe25]

What happens to exising VMC's users have? Can they still select their precious VMC's with saved progress? Or do they get a new empty group VMC?

They can still select their existing VMCs. This just changes when selecting a new vmc, if there's one already selected it won't change anything.

• If a game matches a group
  • if the user has a previous VMC
    • if the user does nothing => previous save used
    • If the user chooses to prompt another VMC. the new group name will be suggested by default. They can still choose to manually write the previous VMC.
• if a game doesn't match a group nothing new will happen. This pr doesn't really do anything in this case.

[MinZe25]

I guess that we could detect if a vmc for the current game exists and prompt it even when a group matches, but it would kind of defeat the purpose of this.

[rickgaiser]

They can still select their existing VMCs. This just changes when selecting a new vmc, if there's one already selected it won't change anything.

As long as existing game progress is not automatically lost when upgrading OPL I think it's good.

Can you take a look at the codacy issues?

[MinZe25]

Codacy it's fixed now. (It complains about string.h for some reason)

[rickgaiser]

1 minor cleanup, but the rest LGTM

[sync-on-luma]

I'm the one who originally designed this VMC grouping feature for the XEB+ neutrino Launcher plugin. I could be wrong, but it looks to me like this implementation omits a crucial part of my design.

There are two memory card groups (specifically XEBP_100.24 and XEBP_100.40) that require a 32MB memory card image to fit the save data of every game contained within them. There does not appear to be any condition in place to create a larger VMC file for these two groups. If a user tries to save a lot of games from either of these groups to a shared 8MB VMC image, they will run out of space.

[rickgaiser]

I think the size and name of a VMC is a user selection.

This PR only changes the default name that a newly created VMC will have. Would be nice to also change the default size according to the group requirements.

Is this correct? @MinZe25 can you respond to this?

[MinZe25]

implementation omits a crucial part of my design.

Yep, I didn't know about those two cases.

And yeah, it only changes the default name. Maybe another PR could be done to also change the default size in those two cases

If I find some time I'll do it