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

Feature Request - Add ability to mass select custom proton #391

Open
Brad7173 opened this issue May 2, 2024 · 2 comments
Open

Feature Request - Add ability to mass select custom proton #391

Brad7173 opened this issue May 2, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@Brad7173
Copy link

Brad7173 commented May 2, 2024

Steam Rom Manager is great tool. Unfortunately, it doesn't have a method to select a custom proton when adding roms into steam. From my testing, I'm not sure that is a viable option in Debian 12. It can perfectly add shortcuts but it's missing compatibility. Imagine having to set 3,000 roms to use Proton Experimental.

That said, it is already apparent why ProtonUp needs this feature. The end user could mass select all the games/roms and choose one proton to use for them all. I'm not sure the best approach for this such as holding shift and selecting a mass of games / roms in the list then selecting one proton for all. This should only work if mass items are selected, otherwise ProtonUp would function normally.

@Brad7173 Brad7173 added the enhancement New feature or request label May 2, 2024
@Brad7173
Copy link
Author

Brad7173 commented May 2, 2024

The other option might be to add a button to mass edit custom protons.

@sonic2kk
Copy link
Contributor

sonic2kk commented May 2, 2024

Why do you need roms to use Proton, out of interest? Usually emulators run natively, right?

That being said that's not quite the point. The idea here is to mas migrate a lot of games from using one tool to another, which is valid. This already sort of exists for GE-Proton, to migrate from one tool to another, with Batch Update.

I'm not sure what the best approach would be to do this "arbitrarily". That is, to select games using any/no tool. The Bath Update works at the tool level, moving games from one tool to another. This approach would need to do it at the game level, as in, take a list of game AppIDs and move them to using a compatibility tool.

The logic for this shouldn't be too difficult I don't think but I'm not sure how to do it on the UI. Indeed, shift-selecting games isn't quite right. Maybe it could be done per-collection? For example, ProtonUp-Qt could add an option somewhere to set a given compatibility tool for all games in a given collection.

In the case of roms, they're likely not using any compatibility tool, so we'd have to add them to CompatToolMapping in config.vdf ourselves. Some might though, so we'd have to consider this. Basically account for tools they do and don't exist in this block.

This wouldn't necessarily have to be limited to Proton versions that ProtonUp-Qt downloads in compatibilitytools.d either. The Games List has reference to Valve Proton versions, as well as the Steam Linux Runtime (which may be less useful as many emulators are native Flatpaks and so there may be a double-sandboxing issue).


So the main points here:

  1. This is feasible to implement in terms of writing a util function to do I think.
  2. I'm not sure how it should work on the UI. Per-Collection may work, and Steam-ROM-Manager creates collections for each rom type anyway. There is also the question of where to put it on the UI.
  3. Most emulators are native already I think so I wonder what the use-case here? Just out of curiosity :-)

There is also an argument to be made here that the Steam Client should offer this feature, but that shouldn't stand in the way of implementing it. I just think it would be good if this was available in the Client officially at some point.

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

2 participants