Hey there, I'm very excited for this project and I'm already trying it out on my homelab with my GOG games. I'm currently running the 0.4.0-rc3 version in the server (docker compose from the quickstart guide) and the latest 0.4.0 version for the client in my Fedora machine.
After analyzing how the client works and how it manages Proton and UMU, I found out that the GAMEID attribute is handled wrong in the context of UMU. What I see here is (maybe?) a misconception about the purpose of the GAMEID environment variable in the context of UMU. The GAMEID or UMU_ID environment variables are used by UMU to apply Proton Fixes for games from different stores, as stated by the UMU Database repo and the UMU Launcher repo:
UMU Launcher: GAMEID designates a corresponding umu-id from the umu-database for games that have fixes that need to be applied. Defaults to umu-default
UMU Database: This repository contains the data and tools needed to provide seamless protonfixes integration for games from different stores. Historically, protonfixes have targeted Steam games only but umu makes it possible to use Proton for all existing Windows games.
Currently, when launching a game via UMU, Drop passes its own internal database UUID to the GAMEID environment variable. Because umu-launcher uses the GAMEID variable strictly to look up game-specific compatibility fixes (protonfixes) in the umu-database, passing a random UUID causes UMU to treat the game as UNKNOWN.
This prevents UMU from applying necessary game-specific fixes, and worse, overrides the launcher's built-in umu-default fallback, leading to silent crashes or launch failures for many titles.
Expected Behavior:
If a game has a known ID in the UMU database (e.g., umu-starcitizen or a Steam AppID), that specific ID should be passed to UMU. If the game's UMU ID is unknown, the GAMEID variable should be omitted entirely so that UMU automatically falls back to umu-default, allowing it to apply early-stage global compatibility defaults.
Actual Behavior:
During game import, Drop generates a random UUID for the game:
File: server/server/internal/metadata/index.ts
const gameId = randomUUID();
During launch, this internal UUID is injected into the UMU environment variables (from what I could quickly see in the source code):
File: desktop/src-tauri/process/src/process_handlers.rs
let game_id_env = shell_words::quote(&format!("GAMEID={game_id}")).into_owned();
Important to note that this UUID is also passed in the UMUNativeLauncher struct's create_launch_process function, but I don't know how the UMU Native Launcher handles these IDs and haven't tried it.
This results in the following UMU logs, where protonfixes fails to find the UUID and aborts all fixes (I'm trying Dead Cells in this case with Proton GE 11.3, ignore the 32bit warnings):
INFO: umu-launcher version 1.4.4 (3.14.6 (main, Jun 11 2026, 00:00:00) [GCC 16.1.1 20260515 (Red Hat 16.1.1-2)])
INFO: steamrt4 is up to date
INFO: Running 'GE-Proton11-3' using runtime 'steamrt4'
INFO: Running 'steamrt4' using runtime 'host'
pressure-vessel-wrap[303860]: W: Cannot determine ld.so for i386-linux-gnu: Failed to execute child process “/home/drk/.local/share/umu/steamrt4/pressure-vessel/libexec/steam-runtime-tools-0/i386-linux-gnu-capsule-capture-libs” (No such file or directory)
ProtonFixes[303924] INFO: Running protonfixes on "GE-Proton11-3", build at 2026-07-25 07:16:06+00:00.
ProtonFixes[303924] INFO: Running checks
ProtonFixes[303924] INFO: All checks successful
ProtonFixes[303924] WARN: Game title not found in CSV
ProtonFixes[303924] INFO: Non-steam game UNKNOWN (bdf25da1-7b31-42f9-bea0-7ceae3374b80)
ProtonFixes[303924] INFO: No store specified, using UMU database
ProtonFixes[303924] INFO: Using early stage global defaults for UNKNOWN (bdf25da1-7b31-42f9-bea0-7ceae3374b80)
ProtonFixes[303924] INFO: Non-steam game UNKNOWN (bdf25da1-7b31-42f9-bea0-7ceae3374b80)
ProtonFixes[303924] INFO: No store specified, using UMU database
ProtonFixes[303924] INFO: No early stage global protonfix found for UNKNOWN (bdf25da1-7b31-42f9-bea0-7ceae3374b80)
ProtonFixes[303924] INFO: Setting up FSR4 version default.
ProtonFixes[303924] INFO: Automatic FSR4 upgrade enabled.
ProtonFixes[303924] INFO: Running protonfixes on "GE-Proton11-3", build at 2026-07-25 07:16:06+00:00.
ProtonFixes[303924] INFO: Running checks
ProtonFixes[303924] INFO: All checks successful
ProtonFixes[303924] INFO: Non-steam game UNKNOWN (bdf25da1-7b31-42f9-bea0-7ceae3374b80)
ProtonFixes[303924] INFO: No store specified, using UMU database
ProtonFixes[303924] INFO: Using main stage global defaults for UNKNOWN (bdf25da1-7b31-42f9-bea0-7ceae3374b80)
ProtonFixes[303924] INFO: Non-steam game UNKNOWN (bdf25da1-7b31-42f9-bea0-7ceae3374b80)
ProtonFixes[303924] INFO: No store specified, using UMU database
ProtonFixes[303924] INFO: No main stage global protonfix found for UNKNOWN (bdf25da1-7b31-42f9-bea0-7ceae3374b80)
Proton: /home/drk/.local/share/drop/games/Dead Cells/deadcells.exe
Proton: Executable is a unix path, launching with 'umu.exe'.
fsync: up and running.
What do I proppose:
1. Short-term Fix:
Decouple Drop's internal gameId from the UMU GAMEID environment variable. If no specific umu_id_override is provided by the user, the Rust backend should omit the GAMEID environment variable entirely, or explicitly set GAMEID=umu-default. This will restore baseline compatibility for games that don't need highly specific fixes.
2. Long-term Fix:
Introduce a umuId or compatId field to the Game database schema. During the import process in metadataHandler, query the umu-database API to cross-reference the game's title or store metadata.
- If a match is found, save it to
umuId and pass it to GAMEID at launch (or a dedicated UMU_ID variable and rename GAMEID to something else so UMU doesn't take it).
- Furthermore, UMU relies on a
STORE environment variable alongside GAMEID to route fixes correctly (e.g., Epic Games vs. GOG versions of the same game). Drop should also pass STORE=[store_name] based on the metadata provider.
Other conclusions:
We could also take a close look at how Lutris does things and implement the same approaches in the client for UMU, Proton, DXVK, and VKD3D. There are other things that I found, like how Lutris enables DXVK and VKD3D and passes all the WINEDLLOVERRIDES to ensure that DirectX and the compatibility layers are always present even if UMU's defaults aren't enough. For instance, I can't get Dead Cells to launch in the Drop client (it throws a DirectX error), while it launches fine in Lutris. But this is probably a conversation for another issue!
I'm eager to read the codebase in more depth and contribute to the project in different areas. I don't have a massive amount of experience with Rust and Typescript (I'm a .NET developer), but this project is really exciting for me and I feel it will be a game changer for homelabs in the future.
Hey there, I'm very excited for this project and I'm already trying it out on my homelab with my GOG games. I'm currently running the 0.4.0-rc3 version in the server (docker compose from the quickstart guide) and the latest 0.4.0 version for the client in my Fedora machine.
After analyzing how the client works and how it manages Proton and UMU, I found out that the GAMEID attribute is handled wrong in the context of UMU. What I see here is (maybe?) a misconception about the purpose of the GAMEID environment variable in the context of UMU. The GAMEID or UMU_ID environment variables are used by UMU to apply Proton Fixes for games from different stores, as stated by the UMU Database repo and the UMU Launcher repo:
Currently, when launching a game via UMU, Drop passes its own internal database UUID to the
GAMEIDenvironment variable. Becauseumu-launcheruses theGAMEIDvariable strictly to look up game-specific compatibility fixes (protonfixes) in theumu-database, passing a random UUID causes UMU to treat the game asUNKNOWN.This prevents UMU from applying necessary game-specific fixes, and worse, overrides the launcher's built-in
umu-defaultfallback, leading to silent crashes or launch failures for many titles.Expected Behavior:
If a game has a known ID in the UMU database (e.g.,
umu-starcitizenor a Steam AppID), that specific ID should be passed to UMU. If the game's UMU ID is unknown, theGAMEIDvariable should be omitted entirely so that UMU automatically falls back toumu-default, allowing it to apply early-stage global compatibility defaults.Actual Behavior:
During game import, Drop generates a random UUID for the game:
File:
server/server/internal/metadata/index.tsDuring launch, this internal UUID is injected into the UMU environment variables (from what I could quickly see in the source code):
File:
desktop/src-tauri/process/src/process_handlers.rsThis results in the following UMU logs, where
protonfixesfails to find the UUID and aborts all fixes (I'm trying Dead Cells in this case with Proton GE 11.3, ignore the 32bit warnings):What do I proppose:
1. Short-term Fix:
Decouple Drop's internal
gameIdfrom the UMUGAMEIDenvironment variable. If no specificumu_id_overrideis provided by the user, the Rust backend should omit theGAMEIDenvironment variable entirely, or explicitly setGAMEID=umu-default. This will restore baseline compatibility for games that don't need highly specific fixes.2. Long-term Fix:
Introduce a
umuIdorcompatIdfield to the Game database schema. During the import process inmetadataHandler, query the umu-database API to cross-reference the game's title or store metadata.umuIdand pass it toGAMEIDat launch (or a dedicated UMU_ID variable and rename GAMEID to something else so UMU doesn't take it).STOREenvironment variable alongsideGAMEIDto route fixes correctly (e.g., Epic Games vs. GOG versions of the same game). Drop should also passSTORE=[store_name]based on the metadata provider.Other conclusions:
We could also take a close look at how Lutris does things and implement the same approaches in the client for UMU, Proton, DXVK, and VKD3D. There are other things that I found, like how Lutris enables DXVK and VKD3D and passes all the
WINEDLLOVERRIDESto ensure that DirectX and the compatibility layers are always present even if UMU's defaults aren't enough. For instance, I can't get Dead Cells to launch in the Drop client (it throws a DirectX error), while it launches fine in Lutris. But this is probably a conversation for another issue!I'm eager to read the codebase in more depth and contribute to the project in different areas. I don't have a massive amount of experience with Rust and Typescript (I'm a .NET developer), but this project is really exciting for me and I feel it will be a game changer for homelabs in the future.