[FR] Add additional options for saving settings.

[J013k]

Checks

• [X] I have checked existing OPL feature requests for duplicates and found none

Describe the FR

Till this day I still do not understand how saving settings work...

Sometimes when I have an HDD and a MC, settings are being saved to MC.

When I have a USB device, an HDD and a MC, settings are being saved to a USB device.

In both scenarios OPL was launched from HDD (hdd0:/). None of the above devices had settings before saving.

Describe the solution you'd like

What about adding an option to set where do you want to save settings?

When we choose Save Settings:

We will have a few options:

If I want to save settings to a device that is not plugged in, I will get this error:

If settings on this device already exists or you want to overwrite existing settings:

If Overwrite existing settings is selected and there aren't any settings on any device:

[Haker120]

I didn't think about it but this FR is better than my 'OPL Update' through OPL itself. :D

[rickgaiser]

I like the idea of giving the user more control over where they save the settings. But I'm still missing control for where they load the settings from. The root of this problem is that ps2 was never designed to have things saved on any other location than mc1/2. Only mc1/2 is always available, the rest we cannot rely on.

To solve both problems I have the following in mind (based on initial idea in #497 ):

• A base configuration file at a fixed location that works like a "savegame" (for example: mc?:/OPL), with the minimum amount of settings to load OPL. This config file should define:

  • What drivers to load (usb/eth/...)
  • What driver to use for loading the main configuration file (usb/eth/...).

• A main configuration. This config has all other settings, not needed during early boot.

• A per-game configuration file. We already have this, but I wanted to mention it for completeness.

Loading and saving settings will always go to the main configuration defined in the base configuration file. The base configuration should have a settings page of it's own, and will always be saved as a "savegame" on mc?.

For selecting the correct mc to load/save from/to, we should use the same logic most games use (correct me if I'm wrong):

1. Load from mc0, if mc+savegame present.
2. Load from mc1, if mc+savegame present.
3. Ask user to create savegame on mc0 if present
4. Ask user to create savegame on mc1 if present
5. Continue without savegame (use default settings, changes will be lost)

[AKuHAK]

@rickgaiser this will lead to the fact that memory card settings become mandatory? Without memory card OPL will not load settings from other devices completely?

[rickgaiser]

Yes and no, just like any other ps2 game, if you start without a savegame you will start with default settings, and your settings will not be saved. So at each boot without a mc you will have to manually set:

• What drivers to load (usb/eth/...)
• What driver to use for loading the main configuration file (usb/eth/...).

Then you will be able to use OPL, and save all configs EXCEPT the base configuration on mc.

I think it's an acceptable tradeoff.

[AKuHAK]

This still means that without a memory card you will be able to save settings, not to load. Maybe we can add argv[0] (CWD) into the sequence? I mean that opl first checks argv[0], load necessary drivers (for example if prefix is mass), then tries to load settings from argv[0] and only thenn fall back to the memory card sequence.

[AKuHAK]

Currently, BDM drivers always use the same path for any loaded device (mass0) maybe this can be changed to linux style, like mass0p1, so it will be possible to recognize by path what BDM device is used?

[rickgaiser]

This still means that without a memory card you will be able to save settings, not to load. Maybe we can add argv[0] (CWD) into the sequence? I mean that opl first checks argv[0], load necessary drivers (for example if prefix is mass), then tries to load settings from argv[0] and only thenn fall back to the memory card sequence.

Yes, good idea!

Currently, BDM drivers always use the same path for any loaded device (mass0)

It's the fat32 that uses "mass". Multiple partitions (on multiple devices) can be used as "mass0", "mass1", "mass2", etc... But the number depends on what driver is loaded first.... so that's bad. OPL's "mass1" (second device) would become ingame "mass0", becouse only 1 device is then loaded.

maybe this can be changed to linux style, like mass0p1, so it will be possible to recognize by path what BDM device is used?

I like the idea, but a little different. Each device already has a name "usb"/"sd"/"sdc". And partitions are already named by BDM as usb0p0 (entire drive), usb0p1 (partition1), etc... (look ik the logging while ejecting/inserting a USB stick).

[Migsi]

I like the idea, but a little different. Each device already has a name "usb"/"sd"/"sdc". And partitions are already named by BDM as usb0p0 (entire drive), usb0p1 (partition1), etc... (look ik the logging while ejecting/inserting a USB stick).

More just a random question, but why is BDM using the "pX" suffix on index 0 for describing the whole drive? Wouldn't it make more sense to use the name of the device as is to describe the drive (e.g. "usb0") and preserving the "pX" prefix for partition naming only? Basically the idea is to use the same scheme as Linux/Unix does, instead of introducting a new unusual one.

[rickgaiser]

More just a random question, but why is BDM using the "pX" suffix on index 0 for describing the whole drive? Wouldn't it make more sense to use the name of the device as is to describe the drive (e.g. "usb0") and preserving the "pX" prefix for partition naming only? Basically the idea is to use the same scheme as Linux/Unix does, instead of introducting a new unusual one.

Each block device must have a partition number. For the whole drive, this number is 0. If we where to expose these names, then I agree, we should name the entire block device "usb0", not "ubs0p0". For now it's only used for debug messages, here: https://github.com/ps2dev/ps2sdk/blob/master/iop/fs/bdm/src/bdm.c

With simple messages like: M_PRINTF("connecting device %s%dp%d\n", bd->name, bd->devNr, bd->parNr);