mirror of
https://github.com/Drop-OSS/drop.git
synced 2026-07-25 04:15:36 -04:00
[GH-ISSUE #315] FR: UMU-Run ProtonPath & Drop Instance Proton Repository #162
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Elite-Alien on GitHub (Jan 15, 2026).
Original GitHub issue: https://github.com/Drop-OSS/drop/issues/315
I thought about this when using Drop a bit and finding a good handful of games will not always find proper Protonfixes or even do mf-install or use a Proton version that can do video playback. Which is a major issue for some games.
What I am proposing here is a database on the Drop instance where the "Admin" can assign a folder where downloaded versions of Proton can be placed. When a game is imported there can be an option to select one of the Proton versions inside the folder. The Drop client will then check to see if that version of Proton is in say, "~/Drop/Compat-Tools/GE-Proton-10-20" (This could also be an additional step to check Steams Compat-Tools location, Lutris, Heroic Launcher, and other popular clients locations, but not required), if that is not found it will download the one on the server to the said PC and instantly apply PROTONPATH=/Drop/Compat-Tools/GE-Proton-10-20 GAMEID=umu-id (what you applied already) in front of umu-run "/folder/executable"
Supplying the Proton versions would be on the shoulders of the Drop Instance Admin so Drop wouldn't need some complicated crawler and downloading tool to find them. Along with it using what is already inside of umu-launcher as is so hopefully that would decrease the need for coding a little in this request, if it is to be added.
FR: UMU-Run ProtonPath & Drop Instance Proton Repositoryto [GH-ISSUE #315] FR: UMU-Run ProtonPath & Drop Instance Proton Repository@DecDuck commented on GitHub (Feb 18, 2026):
A little update on this thing:
Hopefully this is enough to solve this issue.
@Elite-Alien commented on GitHub (Feb 18, 2026):
Scanning for the paths and using existing Proton builds is great. This would help, but without the server admin setting a build it kind of works and fails at the same time. Specially for not so technical people using your instance of Drop.
I would say that list, would help, but it will never truly fix this problem, if you've basing it off their list. There are thousands of games that are not in their database. Ones that will never even be added to that list as well since there is just to many games out there.
Here is my reasoning behind wanting a database in Drop. If you would hear me out.
The reason I though it would be nice for admins to package their own database was for the ease of the user. The admin could have to set "Cachy", "GE", and so on in a database and then set it to that game to have downloaded. Then say your mother, grand mother, or kid, doesn't have to know a thing about "ProtonUp" or other tools. Nor do that need to know how to use "umu-launcher" as it would all be setup for them instantly if the game is portable. This would take more of the burden off the admins of the server long-term.
Then umu-run while it can download latest GE-Proton builds. It doesn't exactly alert the user that something is downloading. If you close everything out while it's trying to download you can get non-complete GE-Proton builds. Which will not get verified by umu-run. Not so techy people don't even know where to go to delete these folders and if they don't learn umu-run commands it's also pointless as the current way with the client you can't pick a executable. So in the current state Drop is very much portable games first and setup games second.
Then using existing Proton builds is great and all. However, I have ran across a few games that will work on X Proton build but not a newer one. Due to some regression. This is not always the most common thing. So this can be a bit of a one off. However, if there was a database and you had a backup of that specific GE, Cachy, or whatever build and they removed it from being downloaded. Well you're in luck you have it on your server. (I don't know how often or if this will happen of removal. However, I've been experiencing this problem with older builds of Linux games recently. Where I need a library .so file that is so old that you can't even find it to download from the Github.)
Anyway, that above is some reason I think it would be nice. I will roll with whatever you do as I appreciate the work you put into all this. It's helped me get a lot of my "Portable" games or games I've made "Portable" to my family. I've spent way to much time with Drop importing my games too, lol. I'm now at this
While there imported they are not any where near setup with versions. However, my users thank you through proxy of me.
If I knew anything about Vue or other languages this project uses, I would try take on some of this myself and contribute that way. Though, I know, a bit about coding, I don't do it all the time and my work isn't coding so I don't actively practice it. Despite going to college for coding too, lol. Sorry for being the asking person and putting work on your shoulders. The best thing I've been doing recently is a Phyton application and it's not bad code exactly, but janky I would say. Regardless, of that, take on what you can, thanks for the work.
@DecDuck commented on GitHub (Feb 26, 2026):
Just a couple of heads up:
Edit: and I agree about the ease-of-use problems with the current solution, I'll investigate other options more. But for now, because Linux gamers are, right now, being forced to learn about Proton anyways, I'm happy with the current setup.
@Elite-Alien commented on GitHub (Feb 26, 2026):
Wait so it's forced to re-import everything? F#&@ man. That is a nightmare if so. If that is the case I will just have to use Batch and Shell scripts for everything then. Along with potentially my own solutions. Because I have way to many games to have to import versions for to have to redo all that again. I have a few games too that literally broke my browser just trying to import them. I had to copy the name.exe or name.sh and paste it in the executable drop down. If I pressed the arrow it would take over thirty minutes to even get the drop down menu to appear. While my browser kept popping up "Wait or Close". It wasn't just one browser either. Thanks for the heads up at least, but d@#$ man that stinks and I don't think the automation tool will fix my full on problem with some of my games so nightmares ahead. I might be holding off on an update for a bit until I have time for such a thing.
Linux native through UMU-Launcher for Linux Runtimes? I mean that would help to some degree specially the dependency stuff. Yet, UMU-Launcher with Windows EXE's are still a massive problem. A custom umu-run command using a GE-Proton will still be needed for quiet a few games. Specially games with video that need specific codecs. I've not switched over just yet to v0.4.0 as I basically said above. So if a user can just select a Proton version it makes it a bit easier, but yeah.. The more dumbed down it can be the better it is ultimately. Specially for adoption, since so many people just don't want to think or learn "computer" lol. That and another future reason to dumb it down is for this new future with age restriction laws built into OS's. I think a lot more people will be getting on Linux. I'm not a "Year of the Linux Desktop" person, so not everyone of course, but a handful of power users I would imagine.
I get that it takes time and I again appreciate the work you put into all this. It's not something small and takes a bit of time to get all this stuff right and you've got a lot to deal with for such a job. So, thank you for just considering a lot of this in general.
@Elite-Alien commented on GitHub (Feb 28, 2026):
I haven't updated the server to the latest yet, but I did check out the client v0.4.0. Just to see for myself on how it's done and maybe if I was misunderstanding something.
I like how it has Proton options. I just have one suggestion for the selection process. I think there should be like a default set in the client. Because the wording on the warning of it being set is a little confusing. I let a less technical family member look at it and they didn't even know the selection boxes were even there to be clicked. Maybe a "None" like default option so the box is filled in and they can see a blue dot and be like "Ah okay". Because as soon as they knew what it was it was understandable what to select. This is not a major have to have, but just a nice QoL change.
Other than that it's pretty good. Then a question I have about it. Does this default to Steam or will it find the other directories like Lutris, Epic Games Launcher, or other places as well?
This is not a big problem for me, but this could be a problem for some. Because if not it's very heavily tied to Steam for a DRM-Free client. Because as far as I am aware Proton-Qt and Proton-Up like tools don't start without Steam installed right? Maybe that's just ProtonUp. I remember trying to use one of these tools a long while back and it refused to start without Steam installed. I think for people that are say full on DRM-Free might not enjoy a Steam requirement.
This is just mild suggestions. Not exactly requests. Take them or leave them. I just am trying to think of ways to not scare some people off. I've recommended this to some people here and there. Anyway, that's just my thoughts on that. Though I do like this improvement a lot. Which would fix the video issue in some cases using existing proton versions of GE. It's a pretty solid system I guess for mildly technical people.
@DecDuck commented on GitHub (Feb 28, 2026):
It currently only scans Steam directories by default, because as far as I can tell, everyone puts their Proton installs there for compatibility reasons.
@Elite-Alien commented on GitHub (Feb 28, 2026):
Nope using the very ProtonUp tool or similar can tell you that's not true. I don't have the Lutris Flatpak if there even is one, but I have used the Flatpak Steam, Bottles, and Heroic Games Launcher. Which will create a .var location for Steam and Bottles a single location, but for the HGS a Wine-GE and Proton location. Lutris and Heroic Games Launcher both pull from their own database because they have their own Proton and Wine downloader built into them and by default go to the locations I showed in the images.
I cleaned up Lutris a long while back so it doesn't have the Proton folder in my images. I left the Wine one as when I used HGS it could actually pull the Lutris builds of Wine.
Since Lutris does make their own builds of Wine or at least did. Which you can get from ProtonUp it seems.
ProtonUp seems to be missing three different Proton builds and like two different Wine builders. So you would have to manually get those. That's sort of another reason a database would be nice, but I digress. Anyway, point being nope they don't all use the Steam location.
@DecDuck commented on GitHub (Mar 1, 2026):
Okay, thanks, I'll add some more default paths.