Feature/fix request: change priority of launcher types (and/or add per-game setting to override it)

[LeXofLeviafan]

As of now, the priority of launcher types (defined in minigalaxy.launcher.determine_launcher_type) is as follows:

1. Wine (detected by existence of unins000.exe in game dir)
2. DOSBox (detected by existence of dosbox both in game dir and in PATH; dosbox/ folder is only detected when in lowercase)
3. ScummVM (detected by existence of scummvm both in game dir and in PATH; scummvm/ folder is only detected when in lowercase)
4. Wine again (detected by existence of prefix in game dir)
5. Native (detected by existence of start.sh in game dir)
6. Fallback (also Wine but without custom WINEPREFIX)

I see two issues in this list:

• the vast majority of DOSBox and ScummVM games in GOG store (out of those I've tried at least) are always run via Wine unless you manually modify the game files (and you need to actually have the above information to know what to change – namely removing unins000.exe and renaming the likely uppercase DOSBOX/ folder to dosbox/)
• there's not much leeway in modifying how a Wine game is run, unless you're willing to break all other Wine-related features for the game by renaming prefix/ to something else so that you can make your own custom runner start.sh (if, for example, some additional command needs to be run after a delay for the game to be playable)

To deal with these issues, I suggest following changes:

• convert the filelist passed to determine_launcher_type to lowercase (e.g. [lower(s) for s in files]), so that dosbox/ and scummvm/ are detected even if they aren't in lowercase
• give DOSBox & ScummVM launcher higher priority than Wine, so that the users can run them natively without having to know which specific file Minigalaxy is checking to detect that it's a Windows game
• give the native (./start.sh) launcher higher priority than Wine (at the very least), so that the user always has an option to apply arbitrary customizations to the game launching process
• alternatively, add to the game Properties dialog an option to override the auto-detected launcher with a custom one (e.g. a toggle to prefer start.sh, or a text/file input to use as game script/binary when it's not empty)

[sharkwouter]

Thanks for the detailed report, I appreciate the effort. Looking at it like this, I do think 4 and 5 should probably be switched.

When implementing using the native clients for scummvm and dosbox games I did actually try to do it for Windows games too, but it turns out that the configurations for them are not cross platform compatible. If a Dosbox configuration has in it that it uses DirectX as backend, you cannot launch the game with that configuration on Linux for example. There is an old issue for it here: https://github.com/sharkwouter/minigalaxy/issues/64

It would be cool to find a solution for that, but I'm not sure how big the scope would be for it.

[LeXofLeviafan]

I would say that making the file check case-insensitive would be a good thing on its own, regardless of priority order, as it's a rather unintuitive thing to be aware of when trying to run it natively. Also, this information (launcher detection logic) should probably be documented and made easily available to users (as in, “read this if you want to know how to run a DOS game in native DOSBox”); after all, knowing you need to remove a file named unins000.exe isn't quite intuitive either.

Additionally, having an explicit override in game properties (e.g. “run via ./start.sh” toggle) might make a lot of difference for the average user (as otherwise they wouldn't even be aware of possibility).

As for DOSBox/ScummVM having configs incompatible with Linux, there also should be an easy/clear way of switching between native/Wine versions. (Incidentally, out of all DOS games I've tried so far, only TES Redguard failed to run in native DOSBox using original configs; for pretty much all others, the only change I needed to make was replacing .. paths with . in mounting commands. For ScummVM, however, I had to add every game in GUI manually, and then put its ID as launch parameter.)

…Now that I think about it, there's another thing that got in the way when setting up native ScummVM games: the launcher doesn't work without an .ini file (even though it accepts an empty one), and when one is supplied it overrides global config (so if I want to play the game without running Minigalaxy I basically have to register it as a completely separate install).

[sharkwouter]

I've added this commit, which switches the prefix check and the setup.sh check around. Does that address your issue?

[LeXofLeviafan]

You mean this one? Yes, it does make room for Wine game customization.

The launcher detection logic should be visibly documented for this fix to be useful for others, though :-) (Adding a basic script example on top would also be good for user-friendliness purposes, I suppose.)

[sharkwouter]

Exactly, that's the one. This seems like a pretty niche use case, though, that's why I didn't document it. The important thing is that you know it's there and you can use it. Maybe some more people will leave a comment here on if this is useful to them, then I will document it.

[LeXofLeviafan]

…Just had a look at the same file in master; in that version of the file, order between these two doesn't matter as in both cases ["./start.sh"] is used. (Not sure how it's supposed to work with Wine… Unless start.sh is created automatically at some point, it's simply going to fail.)

    elif "prefix" in files and shutil.which("wine"):
        launcher_type = "wine"

    if launcher_type in ["start_script", "wine"]:
        exe_cmd = get_start_script_exe_cmd()

def get_start_script_exe_cmd():
    return ["./start.sh"]