Feature Request: More Custom Command Control #625
Comments
This would be nice. Not sure how easily this could be done, but having a Community Profile browser within STL where users can download and apply custom configurations straight through STL would be a nice addition as well. |
|
yeah this is close to the rough idea I presented yesterday here
So, let's simply use this issue to list target features. |
|
Yeah, I saw that shortly after I typed that. I'm curious if tackling this first would in any way be beneficial to the MO2 rewrite. |
Oops, I actually did see that comment but I guess the pieces didn't click in my head. Super sorry, I wasn't trying to take your idea or anything! Maybe it subconsciously played on my mind and that's why I thought about posting this.
Absolutely, and I hoped to get that across in some way in that post (and you said as much in your comment on the other issue). Of course it doesn't need to happen anytime soon either, and hopefully as mentioned this can serve as a checklist of sorts to work through if/when this idea gets tackled. And if anything doesn't make sense to implement or the implementation needs to change, that can all be discussed :-) |
|
No worries, everything is fine :) |
|
While fiddling around with custom commands earlier, I thought it would be nice if we could launch a custom command without closing STL. I was actually testing around HedgeModManager (no update on getting it to work on my end yet...) and having to keep re-launching STL each time during testing was a little bit of a pain. Not even sure if this is possible or if there are other complications around it, but it would be nice if part of this custom command overhaul included being able to launch custom commands without closing STL. Or maybe even launching games without closing STL too? 😅 Launching games while keeping STL opens means you can launch with tweaks for testing, and if something goes horribly wrong, or if there's a problem with a flavour of Proton you're trying out, you can quickly go back to the STL menu. Maybe the options for running custom commands/games with STL open could also be a tray icon option? Though if it was somewhere else in the menus that would be very handy (Plasma Wayland can be temperamental with tray icons). Of course this is just a rough idea. The best way to go about the "UX" for this is definitely something to tackle 😃 |
|
That sounds very convenient, especially since with HMM, certain mods need to be loaded before others, and it isn't entirely clear what order they need to be in until you launch the game and it yells at you. |
|
thanks for the suggestion. Should be doable, and probably relatively easy to implement. Let's add it as a possible feature
just "Added option to keep the game open after the game closed" in this commit in the mo2-overhaul branch. |
|
Is there any way to allow for the custom command to have different settings than the main game? Mass Effect Legendary Edition for example doesn't work with WineD3D, but the only way to use the ME3Tweaks Mod Manager is with WineD3D. I use the mod manager as a custom command with STL. If this isn't something that can be done, that's fine, its more a quality of life thing to usably inject it rather than have to do use custom command only. |
Not currently, though this feature request would implement it -- But not for the example that you have given. This example, as far as I know, will likely never be possible under Wine as there is no way to know which process is the mod manager and which is the game (i.e. when it knows it's the game, turn off There is also no way currently to enable/disable environment variables at runtime, for Wine/Proton in general and not just with STL. In the case of something like a mod manager, since the mod manager itself is the only thing started as a Wine/Proton process, there is no way to pass Linux environment variables to an executable/command that gets ran by that already started Wine process. With the example of ME3Tweaks, afaik you have to launch the game with that mod manager. There wouldn't be a way to SteamTinkerLaunch, or any program really, to differentiate between a custom program and the actual game you want to run. For Wine especially I don't think this can be done, as the environment variable applies to that whole Wine process and not just that program, and I don't think flags can be enabled/disabled at runtime. You could probably have two separate Wine processes, one with More generically it could be possible with the idea of this proposal, where you have much more granular control over custom programs. If the game and program were running separately, that is if you were running a custom program and the game as separate programs, it could certainly be done. As an example, say you have some custom program that you start forked with a 300 second (5 minute) delay from the main game. This program might directly alter some config files but the game doesn't need to be launched from this program. This scenario would work. The custom program would be started as a separate Wine process with a separate launch command, maybe something like Hope that makes sense on why this is not really feasible in your mod manager instance, it's a generic Wine "limitation" in that you can't really differentiate programs like this. That's not how Wine works. They need to run as separate processes. In more general terms though, if the game and custom program are started separately as separate Proton processes with separate commands to run them, then it is certainly possible to give these commands different environment variables, but that is not implemented in SteamTinkerLaunch yet. |
Vortex runs with Proton, but doesn't run inside of the SLR. This may be causing compatibility issues on Steam Deck. This PR adds a new option to the Vortex options in the Global Menu to enable the Steam Linux Runtime with Vortex. The changes required to implement this were non-trivial, but a combination of Proton and native games were tested before and after launching Vortex from the Global Menu (to ensure SLRCMD from the Vortex launch was not being re-used for the game launch). Everything in testing appears to still work fine. The `setSLRReap` function was changed significantly to enable this functionality. It can now take an option to force Proton (instead of falling back to ISGAME=3 which causes native Linux SLR to be selected). It can also take a custom Proton version to use, so we don't use RUNPROTON by default. This means we can pass the Vortex version to getSLRReap and fetch the correct Steam Linux Runtime specified in its toolmanifest. This implementation has the issue of very old compatibility tools which pass the SLR to use from the launch command will probably not work, as Vortex cannot detect this. However, recent Vortex versions require an up-to-date Wine anyway, so I doubt this is a problem. The changes made to setSLRReap here should make it more straightforward to integrate with One-Time Run, MO2, and any other third-party application. It could also help with a future custom command overhaul where custom-commands could have a dedicated Proton version separate from the game (#625).
sonic2kk
added
the
Initiative
System Information
Feature Description
Background
I had an idea today while working through #624. That feature request was to add support for a specific mod manager to make setup easier. As it turns out, that mod manager pretty much only needs a winetrick or few. But because of how mod managers work, each game's prefix would need that winetrick. This got me thinking about ways to drastically improve and change how custom commands are handled with STL.
Problem
Some custom commands such as those related to modding, require tweaks and winetricks to get working. A user is very much capable of doing this with STL with its Winetricks menu, but for standalone executable programs that need to be selected on a per-game basis, this can get really tiresome. Having to go in and choose the winetrick each time, plus a user might forget if it's been a while!
There is also the case where a user might want a custom program installed to a specific prefix, either with or without Winetricks, unrelated to the current game's prefix. Say Cheat Engine for example - A user might want to download and install Cheat Engine once, into one prefix, and set that as a custom program for each game. Well as far as I know currently they can't choose a custom prefix for custom commands, and they'll have to remember where the Cheat Engine executable is for each game and set it (or check the config files with a text editor), and so on. You get the idea, this isn't ideal (and also not exclusive to Cheat Engine - Just a relevant example like HMM!)
The problem basically boils down to a lot of manual effort on the user's behalf when they want to set up a custom program for use with STL. In fairness, they could write a script that runs the application in the specific prefix, but that's not super user friendly :-) Having STL do some of the heavy lifting here would really help imo.
Enter: Overhauled Custom Commands
This feature request would solve the concerns I and others had around #618, and would also help solve #624. The idea I had to resolve of this is basically as follows:
Custom Command Management Menu
This would be a new menu where a user can manage a list of custom commands/executables that they create and configure. Initially it would be blank, but there would be some buttons along the bottom: "Back" "Edit", "Delete", "Duplicate" and "Add". When a user clicks add, they'll get a dialog asking them to enter information about the custom executable, similar to the "Add Non-Steam Game" dialog. This would add a custom command with a set configuration that can be accessed globally for each game.
For example they could add a CheatEngine custom command with a bunch of parameters, then for each game they can go into the Game Menu and see a dropdown where they can access a custom command for every game. That way, per game, they only have to select "Cheat Engine". They can also choose where the Cheat Engine prefix is stored and configure other options described below.
A custom executable would need various options, and when "Add" is clicked a dialog would open asking a user to enter that information. This dialog will be very similar to the "Add Non-Steam Game" dialog in terms of basic layout, and have options along the bottom with "Add" or "Cancel". Below are a list of fields I had in mind:
This expands upon the functionality in the Game Menu by letting a user choose a custom prefix, a custom Proton version, and custom Winetricks.
Let me explain the Winetricks idea. Some custom programs need some Winetricks. To use a real world example, HedgeModManager, a mod manager for several Sonic the Hedgehog games. HedgeModManager (or HMM for short) is a standalone executable and with
dotnet48you can run it in any game's prefix. This is crucial because this improves mod compatibility as HMM can run in the Sonic game's prefix! The problem arises when a user wants to use this with several other Sonic games. They'll need to installdotnet48for every game's prefix before they can use the program!With the approach described above, a user could simply add "HedgeModManager" as a custom command in the menu I described above, and add
dotnet48in the Winetricks box. Then, each time a game tries to run this custom command, if any of the listed winetricks are missing, STL will attempt to install them for that prefix. For a program that only needsdotnet48that's probably not a big deal, but it's easy to envision a scenario where four or five or more Winetricks could be needed! Having this taken care of would be a huge help in my opinion. Of course a user is expected to know what their custom program needs to run, but once they know, STL can do the tinkering for them!If a user later decides they need to edit a custom program's options, they can click on an item in the custom command list I described and choose the "Edit" button, which will open a dialog identical to the one above but it will be populated with their custom command information so they can edit it.
Storing Configurations
I'm not an expert so this might not be possible or the idea might need some tweaking, but in my head I envision something like this:
The SteamTinkerLaunch config folder gets a new folder:
$HOME/.config/steamtinkerlaunch/customcmds/and under here, we have some kind of file, probably a.conffile for convention's sake. And the name of this file will match the name of the custom command name provided, or perhaps a custom generated ID/incremented ID based on the last ID, or both with aliases like we do for game configs withtitleandidfolders.The file might look something like this:
It would be nice if somewhere, there was a way to store which games were using it, but this seems overkill and might be complicated to implement, so not very important. This file is used to store the custom command data, and is also used to display and track the information in the menus I described above (the custom command list and the "edit custom command").
User-Created Configuration Templates
Using the configuration format I described above opens the possibility for user-created preset configurations! Let's say there's a popular tool, we'll go again with HMM. Well, to get it running on different systems, the only thing that will change is the path to the executable. The proposed system would allow users to copy these config files between installs or share them online, then they can download them and edit them to have the correct paths for their system - Either with a text editor or from the STL Yad frontend - Keeping in line with virtually all of SteamTinkerLaunch's configuration!
We could even have a section on the wiki with a list of common configuration templates that users can download. Users could submit them on the issue tracker or add it to the wiki themselves.
To me at least, this sounds super cool!
How Does This Tie Into The Game Menu?
Once a user has added their custom commands as described above, they can go into the Game Menu and it'll look a little different.
First off, keep the "Use custom command" option. This is nice to toggle on and off during testing!
Second, the "Custom command" field is going to change slightly. It would be a dropdown which by default has "None" (or "none" or "(none)" or whatever fits best). But when the user clicks it, the dropdown would contain all of the custom commands they have added. It would display "None" and under that would be all their custom commands, then there would be a separator and an "Other..." option where they can select a custom executable.
This allows for keeping of the existing functionality if a user just wants to load a program once.
On that note, the other options for custom command args, fork/only custom command, etc, can all stay because they're useful for choosing "Other" custom commands that a user may not want or need to add as an entry in the custom commands list.
However, "custom command arguments" should be ignored when a user has selected a command from the custom command list.
But I'm not totally sure how to handle this. There are cases where a custom command might need arguments for one game, but might not need them for other games. As a result, maybe the prepend/append custom command arguments should be in the Game Menu and not in the custom command's configuration file like I described above. I'm not sure on this one honestly! Maybe having it in the Game Menu gives the greatest flexibility.
The other options for fork/only custom command, wait custom command etc are virtually useless imo to configure per-custom program, but very useful to configure per game. A user might want the same custom program to launch instead of their game in one instance but might want it to launch with their game in another. Or they might want to switch between these choices for testing.
What's the tl;dr?
Add a menu where a user can add, edit and delete custom commands that can be shared across all games. These can be selected from a dropdown on the Game Menu.
Each custom command can have its own configuration, like what prefix to run in, and any relevant Winetricks, etc etc. Particularly for the Winetricks, when a user selects this custom command and presses "Play", the entered Winetricks will be installed into each prefix if they aren't installed there already. That way custom commands that need a bunch of Winetricks can have them easily installed each time without a user having to remember what Winetricks are needed, and installing it themselves.
Considerations
I do have a few concerns about how this would be implemented.
This is just what I can think of right now. There could be other things I'm failing to consider or don't know about that could cause big problems!
Notes
This is not urgent, but I had the idea fresh in my head today and made a bunch of notes. I wanted to get a fleshed out proposal for this with as much detail as possible up as an issue while it was in my head. Since other things are in the pipeline for STL, this should absolutely wait until those are done.
I'd gladly make an attempt at this myself but I have other projects I'm working on (including a couple of other ideas for STL), plus it might take me a while to implement something like this - actually, my experience in actual Bash scripting almost entirely begins and ends with my contributions to SteamTinkerLaunch starting in January this year!
Over the weekend I will try and see about making a few UI mockups in Yad to help illustrate how I envision this looking. Reading a whole bunch of text can be really tiring and confusing, so visually showing my ideas might help. At the time of writing I just don't have the time sadly.
Okay, that was long. I hope it at least sort of made sense. Maybe this is way too complicated to ever add, but I hope not. And of course just in case it comes across the wrong way: None of this is a demand or anything like that. I gave as many details as I could about the idea in my head in the hopes of illustrating why this would be a useful feature and worth implementing. And of course, having all these details can help with implementation - For anyone that might decide to pick it up.
If anything is unclear please feel free to ask. And of course feel free to leave comments about what might/might not be possible on a technical level for this. We can get a discussion going 😄
Thanks!
The text was updated successfully, but these errors were encountered: