Launch from PFS (non-game) partition

[parrado]

Pull Request checklist

Note: these are not necessarily requirements

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

Pull Request description

The idea behind this PR is to allow OPL-Launcher be loaded from a partition with no game in it, for instance an executable partition with PFS filesystem.

This will help users to launch a single OPL installation from either game partition (behaving as miniOPL) or OPL GUI by using an executable partition from HDDOSD, otherwise OPL will hang on white screen.

The origin of this PR took place after this question at psx-place https://www.psx-place.com/threads/how-to-boot-opl-gui-through-hddosd-with-opl-launcher.35547

[KrahJohlito]

Nice work, I appreciate your efforts I’m just not sure whether this should be done Launcher side or OPL side; ie I imagine when launched from a non game part the game startup for example would just be blank, perhaps it’s better/safer for OPL itself to just revert to GUI under certain circumstances? It may just be that the arg checks put in place in main() of OPL are not stringent enough?

@AKuHAK what are your thoughts?

[parrado]

Nice work, I appreciate your efforts I’m just not sure whether this should be done Launcher side or OPL side; ie I imagine when launched from a non game part the game startup for example would just be blank, perhaps it’s better/safer for OPL itself to just revert to GUI under certain circumstances? It may just be that the arg checks put in place in main() of OPL are not stringent enough?

@AKuHAK what are your thoughts?

Thanks. Is it reliable to assume game startup bytes are blank for a non game partition? Are those bytes cleared when a new partition is created, i.e by wLE?. At first, I used a similar approach you propose but it relied on 0xdeadfeed magic number, but it didn't work, somehow it threw false positives when identifying a game partition. So in the end I decided to use the PFS attribute in OPL-Lancher side, which IMO is reliable and safer for OPL. In addition, that way OPL-Launcher KELF can be placed on either PFS filesystem or PATINFO.

Edit: The idea is to identify the partition where OPL-Launcher is loaded from, so I guess the best side to do it is at OPL-Launcher side. In addition, wLE filer uses that PFS attribute to identify which partitions are listed to browse, as well.

[KrahJohlito]

Thank you @parrado

[AKuHAK]

@parrado I am too late to the party - but did this PR tested? I do not quite understand what it is doing: Before this commit, everything was working in such a way.

1. End-user launch OPL-Launcher from PP. partition.
2. OPL-Launcher extracts HDL game details from PP. partition
3. if the PP. partition doesn't have an HDL game, it will try to extract HDL game details from the __. partition with the same name as PP. partition.
4. OPL-Launcher reads hdd0:/__common/OPL/conf_hdd.cfg
5. pfs0 mounted from information from conf_hdd.cfg or +OPL if file does not exist
6. pfs0:/OPL/OPNPS2LD.ELF (for example +OPL:/OPL/OPNPS2LD.ELF) launched with the details that were retrieved in step 2/3

But this commit seems to be doing weird things at step 6: looks like it will launch +OPL:/OPL/OPNPS2LD.ELF without arguments if PP. partition is not of type PFS.

[AKuHAK]

If the goal is to launch a specific OPL build and also redirect all OPL resources into the current PP. partition, I don't think that this can be done on the OPL-Launcher side. hdd0:/__common/OPL/conf_hdd.cfg will contain OPL resources if the file is empty default +OPL partition is used for resources. As you see there is no way to use argument as resource path, cause argument is already reserved for HDL game path. Even if PP. is pfs partition - this most likely means that it contains resources for PSX DESR xmb or for BB Navigator. It can be useful to make OPL more portable, but this will require changes on the OPL side (for example to check for some file existence, like opl_conf or something similar).

[AKuHAK]

Or maybe between steps 2/3 and 4 add some flag check (like opl_conf.cfg existence) and if the flag exists then steps 4 and 5 skipped.

[parrado]

This PR aimed to allow OPL-Launcher to launch OPL GUI if OPL-Launcher is ran from PFS partition, before this, OPL hung on white screen.

Are you 100% confident about step 3?, in particular if hddGetHDLGameInfo returns error if partition has PFS filesystem. Because, it seems only checks are: partition existence and ability to read 1024 bytes from HDL game data offset, but actual check about game existence is not made at all. So, I think BBN compatibility is broken even in the stable release, but I'm not 100% sure.

[AKuHAK]

@parrado yes, you are correct, looks like hddGetHDLGameInfo will never fail. I see, I will fix that cause now step 3 is broken.