On MacOS, manual selection/copy past of path of game folder does not work - only complete path to .app file works

[drojf]

On MacOS, manual selection/copy past of path of game folder does not work - only complete path to .app file works

I'm unsure if this is something I introduced inadvertantly or it was always like this. I suppose it was impossible to do before because you were unable to copy and paste the path - you had to use the file-chooser which stopped you from selecting the game folder instead of the game path.

eg this works: /Users/[USERNAME]/library/application support/steam/steamapps/common/Higurashi When They Cry/HigurashiEp01.app

this does not: /Users/[USERNAME]/library/application support/steam/steamapps/common/Higurashi When They Cry

[TellowKrinkle]

Yeah that was never something that worked. If you use the file picker, it requests that you give it an application so the file picker won't let you choose anything but a .app file anyways.

[drojf]

That's OK, I just want a way where if the user pastes in the path of the game folder in the manual path entry box, it will still recognize it on mac (the new path entry box, not the manual path chooser). On windows pasting in the path to the game works fine.

I think I can do it myself, I just need to inspect how you've done the mac path detection. I'll ask you if I have problems.

[drojf]

I looked into this and I think the main reason for the discrepancy on mac is that all the mac logic expects a path to the .app file. On windows and linux the logic expects a path to the game folder, and if it gets a path to the executable, it will automatically convert it to the game folder path.

I tested adding this to scanForFullInstallConfigs(), but I don't want to put it in without testing it, and also it will be twice as slow as the current method since each directory is listed twice (once in this code, and once in getPossibleIdentifiers).

    extraPaths = []
    for gamePath in possiblePaths:
        sca = os.path.join(gamePath, "*.app")
        extraPaths.extend(glob.glob(sca))

    for gamePath in possiblePaths + extraPaths: 
...rest of the existing logic here

So if there are any .app folders in the paths being scanned, the scanner should also scan that path itself (don't need to call recursively).

For now I'll just add a warning under the textbox, you can fix this at your leisure since it's not a very big issue.

[TellowKrinkle]

I doubt double-listing will make any difference in speed unless you're scanning through directories with thousands of items

As for why the difference exists in the first place, it's because of how different OSes treat their applications. On Windows, an application consists of a folder in C:\Program Files with all the application's stuff along with a shortcut to the .exe in that folder which is placed in a user-visible place. On Linux, an application consists of an executable that is placed in /usr/bin, resource placed somewhere in /usr/share, and possibly a .desktop file. The user-accessible part is the fact that /usr/bin is in $PATH. This is a bit hard to track if you're not a package manager, though, so a lot of 3rd party applications ship as a folder with bin, share, etc subfolders that the user can place somewhere and add to their path (or not). On macOS, an application consists of a .app folder (which looks like a single file in Finder) that contains all the things the application needs. It is the user-accessible part and the user can put it wherever they want. Based on this, the .app folder on macOS is the equivalent of the folder full of stuff in C:\Program Files on Windows, going outside of it puts you outside of the area that is exclusively for that application.

If you look at the GOG installers for each of the platforms, they do what you would expect. The Windows GOG installer has a default install location of C:\GOG Games\Name of Game, and fills the folder you choose with game files, while offering to make a desktop shortcut. The linux GOG installer has a default install location of ~/GOG Games/Name of Game, fills the folder you choose with game files, and offers to make a .desktop entry. The Mac GOG installer has a default install location of /Applications and inserts a single .app file containing all the game files and does not offer to make a desktop shortcut.

Based on that, I want to mention, regardless of what's supported, please continue to tell people to select the game's .app file, not the folder containing it. If you tell people to select the folder containing the .app, you're going to have to deal with people selecting folders that contain things like this (the default install location of the GOG version of the game):

Or this:

As another side note, this is the folder layout of the GOG linux install, which I don't think we properly support right now

[drojf]

thanks tellowkrinkle, your explanation helped me understand much better. I think we should save this in the higurashi developer wiki so we have at least some understanding of how the mac system works.

Yesterday I put a Mac-only warning to select a .app file like MAC USERS: You must select a .app file. For example: /Users/[USERNAME]/library/application support/steam/steamapps/common/Higurashi When They Cry/HigurashiEp01.app, however I can't really tell if that will be easily understood by most mac users - let me know how it should sound and I can modify it for you.

I also added some real-time feedback to the selected path in case they choose to copy and paste a path from finder/windows explorer - once the user stops typing, it will verify the path and it will become red colored if it is not valid.

If we don't properly support the GOG linux version through the installer, we should state that somewhere (along with 'windows higurashi on Wine or Proton is not well tested, please use the native linux')

[TellowKrinkle]

I think your best bet is to try to get users to use the file picker instead of the text box (since it will require that they choose a .app file)

For linux, mention that they may need to select the game folder inside of the installation if they're on GOG, though if you add searching the game folder to your patch that should fix it

[TellowKrinkle]

New bug that I think was caused by the scanning changes in conjunction with some of the other detection systems: Selecting the wrong game can cause other games in the same folder to be selected instead of failing to validate:

[drojf]

very wierd, it should use the submod information/identifiers to verify that you only get games which are of the type you chose (of course, it's most likely a bug in something I changed lol).

would the mac identifier thingy allow you to choose one game when you've actually selected another?

[TellowKrinkle]

The issue is that one part of the installer runs the search on the parent directory (I think to target Umineko installs where you select a .app but the main install is the folder containing the app) and then the new checker scans the directory and selects the first game that matches the one you're trying to install.

[drojf]

If you think it's a problem don't hesitate to revert my changes, I can't look into it for qute a few hoiurs

[TellowKrinkle]

It's not a huge issue, it just makes it harder to notice when you're making a mistake

[drojf]

My brain completely misread what you wrote, I thought "you entered the path for chapter 3 but it actually gave you chapter 4". Just to confirm, "you entered the path for chapter 4 (incorrectly) while on the chapter 3 mod page, and then it found the actual chapter 3 install location?"

I can put a note that "the path was autocorrected to ..." so you know if the installer didn't install to where you specified, but still at least installed to the right game. Or maybe a popup to say "did you actually mean this path".

Initially I thought this behavior was OK, but you're right, if you want to keep both a modded and unmodded, it would be annoying if it installed somewhere else, or accidentally overwrite your unmodded installation.

[drojf]

I see another issue on Mac which I wouldn't have noticed on Windows - on Windows/linux, using the manual file chooser, you can only select the correct files for your game. On mac you can select any .app file, right?

That might be why I failed to realize that there is a problem....

[TellowKrinkle]

Yeah you can select any .app, the user can rename the apps to whatever they want (for example, renaming Himatsubushi to Console Arcs) so we can't really do much else.