Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not download latest GE-Proton if it's already exists #1187

Open
OlegAckbar opened this issue Oct 20, 2024 · 7 comments
Open

Do not download latest GE-Proton if it's already exists #1187

OlegAckbar opened this issue Oct 20, 2024 · 7 comments
Labels
enhancement New feature or request

Comments

@OlegAckbar
Copy link

System Information

  • SteamTinkerLaunch version: steamtinkerlaunch-v14.0.20241003-2
  • Distribution: Arch Linux

Feature Description

If you have checkbox "Auto-last GE-Proton" enabled it would download new GE-Proton version even if it's already existing in compatibility.d folder (for example, if downloaded by umu-launcher). Might be a great idea to check for its existence and only start to downloads when it is missing.

@OlegAckbar OlegAckbar added the enhancement New feature or request label Oct 20, 2024
@zany130
Copy link
Collaborator

zany130 commented Oct 20, 2024

It's not just proton ge it's several other tools like reshade that get always downloaded I made an issue about that somewhere I'll try to find it

Ahh here we go :#984

@sonic2kk
Copy link
Owner

Isn't GE-Proton a slightly different case here, because we install it to STLCFG/downloads/proton?

@OlegAckbar
Copy link
Author

Isn't GE-Proton a slightly different case here, because we install it to STLCFG/downloads/proton?

Well, there is checkbox "Extract Proton in compatibilitytools.d" which also works for GE-Proton. But even if there's already latest version of GE-Proton in that folder STL will try to update it.

@sonic2kk
Copy link
Owner

I should've pinged, but I meant specifically in regards to @zany130's comment. #984 might be trickier to solve since we'd be dealing with unversioned files.

This is what I was running through in my head:

  • Don't download a GE-Proton version into STLCFG/downloads/proton if they already exist in SROOT/compatibilitytools.d. I think this is the correct path, we usually default to downloading somewhere in the STLCFG.
    • The upside here is that we don't download duplicate versions.
    • The downside is that, if a GE-Proton version is removed, SteamTinkerLaunch can't guarantee that it has a reference to it, which may cause problems with, for example, mod tools that don't run with the Proton script but run with the Wine executable directly (like ModOrganizer 2).
  • When using the "Extract Proton into compatibilitytools.d" option, don't extract into compatibilitytools.d if it already exists.
    • The upside here is that we will still have the tool downloaded into the STLCFG path, and could fall back to extracting it if it is missing from compatibilitytools.d
    • The downside here is that this does not solve the issue in question, we are still downloading GE-Proton

A broad solution to this is probably not ideal, because there are cases where we do want to download GE-Proton even if it already exists, so that we can manage it ourselves (i.e. for mod tools). Therefore I think we could have some logic only for "Auto-last GE-Proton" that will only download the latest GE-Proton version if it isn't in compatibilitytools.d. This would not apply to other places where we check for GE-Proton. This is because with game launches we do use the Proton script, so if we do fall back to using compatibilitytools.d:

  • We would fall back to trying to download the latest GE-Proton if it is missing from both compatibilitytools.d and STLCFG.
  • If it is missing from both, there is no worries because we can resolve the Proton version mismatch for game launches
    • That is, if we want to use GE-Proton9-16, but it goes missing from compatibilitytools.d, and then for some reason we can't download it, we can resolve the mismatch (iirc SteamTinkerLaunch just falls back to the latest official Proton).

Does that sound reasonable?

@zany130
Copy link
Collaborator

zany130 commented Oct 21, 2024

Isn't GE-Proton a slightly different case here because we install it to STLCFG/downloads/proton?

Kind of, I guess; however, it can be solved similarly to my issue.

The problem we are trying to solve is that we don't want to download GE-Proton if it exists in the Steam compatibility tools.
As I understand, we sometimes DO want to do that.

In my issue, I was going about it this way: We shouldn't download to STLCFG/downloads if the file already exists and is the same version. (same hash is prob easier)

Part two of my issue is that we shouldn't install the same exact file if it already exists.

so for GE-Proton that would be SROOT/compatibilitytools.d

and reshade/specialk the game's directory


Sidenote: we should probably also cleanup older versions of GE proton I noticed I was losing about 2GB in my
STLCFG/downloads/proton/custom/

EDIT: actually don't we want to maybe keep older versions in case we want to use them?

@OlegAckbar
Copy link
Author

How about umu integration and delegating all the Proton management to it?

@sonic2kk
Copy link
Owner

sonic2kk commented Oct 23, 2024

There is no reason for a tool that uses the Steam Client to use UMU to my understanding. SteamTinkerLaunch uses the Steam launch command and builds off of that, my understanding of UMU is that it is for Non-Steam Games and using games in the Steam Linux Runtime container outside of Steam. See #1183.

If this understanding is wrong, please correct me.

I also don['t understand how Proton management is really relevant here with UMU, which is primarily for the Steam Linux Runtime container. I think it has some kind of Proton version management, but that's more for it to be an all-in-one type launcher rather than something for use with the Steam Client.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants