Feature: Attempt to apply fixes for games with no STORE

[R1kaB3rN]

Problem

The system of applying fixes depends on metadata being available and for the client or the user to pass it to umu. This works for titles from major store fronts where the client offers a UX for installing games from the UI, therefore being in a position to have some metadata of the game. However, this system wouldn't work for everything else (e.g., side loaded titles). In those cases, we put fixes in gamefixes-umu, so applying the fix requires manual intervention by the user as the client will use its default GAMEID value otherwise. See this example for Star Citizen.

Proposal

Given unique enough metadata, improve the UX by attempting to auto apply fixes for side loaded applications to avoid any manual intervention steps. DXVK's current approach seems to use the name of the EXE for its own fixes. Perhaps protonfixes can do something similar (e.g., EXE name and the game's current working directory)?

[TheOverpassArsonist]

In my opinion I think this is something that would be better handled by focussing on how frontends handle metadata. Admittedly I'm armchairing a bit here, but from my use of tools like this generally the issue isn't so much providing the meta-data so much as it is "what metadata do you even want me to provide and where do you even want me to do it!?".

Using lutris as an example, (no hate towards lutris here, plenty of other software has this problem and I understand that there are a lot of technical reasons why it's around) lutris will try to pull cover art for games, which is good. However, it never conveys where it's getting this cover art, what data you provided it's using to get the right cover art, etc. I've been using lutris for about 2 years now to play windows games on Linux and I only just found out that it's using the little "Identifier" tag to search IGDB (and maybe other stores?) to pull cover art from there. But, even then that means if I have a game that doesn't have an immediately obvious ID (for instance GOW 2018 has the ID "god-of-war--1", if you name the game "God of War" then the ID is "god-of-war" and you get the boxart for the first game.) then you need to open your browser, go to IGDB, search for the game, then check the URL to see what it's internal identifier should be, then copy that, go into lutris, configure the game, clicked the small "Change" button that's next to the greyed out Identifier box, (horrible UX. I understand why they have it this way, because when you change the ID it does actually ping external servers so they don't want every keystroke to do that, but people have been trained for decades to mentally erase anything that's greyed-out as uninteractable) paste it in, then hit apply. And, before I can do any of that I have to be told where lutris is getting it's cover art from, that it's using that weird little "Identifier" to do it, AND that I can go to the site myself and look at the URL to see what the "Identifier" should be. (and if you're like me and also have a lot of super niche games installed, a lot of the time you'll go through this whole process just to find out that there is no entry on IGDB anyway)

In an ideal world there would just be a button on the game info tab that says "search for metadata" that lets you type in the name of the game then pulls up example pieces of coverart, letting the user immediately and effortlessly pick the right metadata for their game. Again, I want to be clear that I do understand why it's like this and I'm not trying to poke at Lutris here. As another example Jellyfin is also quite unclear about how to title/label files and also requires you refer to the ID of entires via a browser-based database, it just uses the TVDB instead of IGDB. I use both of these pieces of software daily and now that I do know how they work I don't find it that annoying... but, it took me a lot of annoyance before I did learn how they worked and I really can't imagine most casual users ever do. (and even now it is sorta annoying to have to open up the page in my browser just to figure out what ID I need)

Generally speaking defering to the user's input is the best and easiest way of identifying the right metadata (that might change with AI, but even if it does I'm really not sure how much I'd like relying on a system like that) but the issue is that the methods we have for the user to provide metadata typically just aren't very good. Historically this wasn't as much of an issue because getting things working on linux at all took a lot more work so it could be reasonable assumed that anyone trying knew what they were doing and didn't mind taking an extra minute to put in all of this metadata manually, but as gaming on linux gets easier and easier (due in no small part to efforts such as UMU) that's going to be less and less easy to take as granted. Even if it were possible to consistently and reliably have UMU itself determine metadata from information like the layout of the file structure, name of the exe, etc. it really seems like that'd just be asking for issues when there are conflicts, false-positives, false-negatives, etc. In my opinion just having a better, more consistent and effective way to transparently and clearly ask the user for metadata that's missing is the better solution. This is especially since the only users who would need UMU to directly grab this metadata would be users running UMU directly from the commandline, i.e. the one usecase where the fact that you as the user must provide meta-data is probably most acceptable.

I'm not entirely sure the best way to go about improving the UX when it comes to metadata (as a generalized solution that is. I use lutris but I know plenty of other people don't so ideally whatever solution would be somewhat easy to implement on any launcher) but I do think that's the better route to go down then trying to have UMU itself infer metadata. I think this is one of those cases where the 'unix philosophy' really applies, the front-end should be what's held responsible for making the user-experience good, not the underlying compatibility layer(s).

But, again, I'm not a developer in this space. I fully accept that I could be talking way out of line here, this is just what my experiences have been and what my opinions on the meta-data issue are. Personally, my ideal world is one where software asks "hey, what game/movie/show is this?" and I can just click the right one from a list of options underneath a search bar. Maybe that's not an opinion that's shared as widely as I believe, and even if it is I don't claim to know the best way of getting there across countless different frontends, but from what I've experienced firsthand the most painbless and reliable way of getting metadata would be to just ask the user clearly and simply in the frontend.

[R1kaB3rN]

Hey, thanks for making the time to share your perspective. 😄

Yes, another option is to not do this within protonfixes at all and keep the current system. Instead, have umu support more storefronts and require the client to be responsibility for creating a UI to either select a fix for the game or pass umu metadata that the client had either inferred or acquired themselves. This approach would avoid any special handling within protonfixes, and the potential risk of incorrectly applying a fix due to a game having the same metadata (e.g., file name) as another or not applying a fix at all due to metadata changes, which may happen on update.

In the future, long term, we're thinking of extending umu's architecture to applications other than games, so I think this is something we'll have to think about handling eventually. Because if we're continuing to dump titles without storefronts in gamefixes-umu, clients will need to figure out how to reliably map and identify an arbitrary application that was side loaded to its correct fix saved in gamefixes-umu. Right now, no clients that I'm aware of are doing anything about that. And suppose they did handle it in an automated way, right now to get the correct fix (e.g., umu-starcitizen), clients will need to figure out the application's title, query the database, and do some sequence matching against the relevant record's fields. As you can imagine, this can be a bit brittle, hence this issue.