SteamTinkerLaunch (short stl) is a Linux wrapper tool for use with the Steam client which allows to customize and start tools and options for games quickly on the fly (see Features)
By using a versatile configuration structure it is both easy to setup and flexible.
stl works with linux native games and with games using proton! (Some features (f.e. ReShade) are only available for games using proton)
To use stl as Steam Launch Option just add it to your Steam Game Launch Option command line like: 'stl %command%'
A little script which automatically does this for every game in the Steam library can be found here
stl can also be used as Steam Compatibility Tool, simply by using the stl builtin command line options:
stl compat add (adds stl under compatibilitytools.d/SteamTinkerLaunch)
stl compat del (deletes compatibilitytools.d/SteamTinkerLaunch)
stl compat (get) (checks the state of compatibilitytools.d/SteamTinkerLaunch)
If add is selected and stl is started from a different path than before, the symlink will be automatically updated.
(as usual, when a Steam Compatibility Tool was added, Steam needs to be restarted to make the added Tool available)
(It doesn't make any sense, but a game also works, when stl is set both as Launch Option and as Steam Compatibility Tool)
When starting a game a small requester will popup. If within a short waiting period (default 2 seconds) the spacebar is pressed the Settings Menu will open where everything can be configured comfortably. When done with configuring (or when the requester timeouts) the game will be started regularly with all tools and options configured.
This is one single bash script. Just copy it wherever you want (f.e. '/usr/local/bin/') and make it executable:
chmod +x stl
The enclosed directories containing optional configuration files can be either dropped into '/usr/share/stl/' (prefered location)
or automatically pulled from git (default if '/usr/share/stl/' does not exist).
If you are on Arch Linux you can install stl from AUR (f.e. using yay):
yay -S steamtinkerlaunch
When stl is started for the first time it will create its default configuration structure. Almost everything can be configured with the built-in Settings Menu, but optionally also with a graphical text editor. It might be a good idea to start with configuring everything in the Settings Menu to your needs (for general configuration the most important tabs are the Default Settings and the Global Settings).
(no special order)
- ENV Variables can be easily set for every single game (f.e
PROTON* ,DXVK* ,MANGOHUD,RADV_PERFTEST,WINE...) - Custom Program launch custom programs before or instead the game itself (also windows exes)
- winetricks start winetricks before game launch (gui or silent)
- winecfg start winecfg before game launch
- GameMode start/stop gamemoderun per game
- Notifier start/stop notify message per game
- Strace for easily debugging a game
- Editor Hotkey for editing the gameconfig
- Editor URL automatically open a defined URL for the launched game with the editor
- ReShade automatic installation and configuration
- Depth3D automatic shader installation
- vkBasalt basic vkBasalt configuration
- SBS-VR automatically play regular games in side-by-side mode in VR!
- Tweaks community mini configfiles (so-called Tweakfiles) to automatically start problematic games ootb - can also start custom Tweak Commands
- Auto Tweaks support for automatic import of game configs from several other platforms
- Nyrna start/stop ReplaySorcery per game
- ReplaySorcery start/stop ReplaySorcery per game
- NetMon basic network monitoring
- Boxtron support via steam
DOSBoxcategory - Roberta support via steam
ScummVMcategory - Luxtorpeda support via steam
Luxtorpedacategory - Vortex Mod Manager via steam
Vortexcategory see Video of usage - GFWL/xlive automatic support for games using GFWL
- WMP10 automatic support for WMP10 installation
- self maintaining configs optional automatic cloning of this repo as replacemement for missing system wide installation
- GameConqueror automatically open gameconqueror (scanmem gui) with the game exe on game launch
- Custom User Start/Stop scripts optional start custom scripts when game starts/ends
- GameScope start/stop gamescope per game
- Settings Menu easy configuration for almost all settings with the builtin Settings Menu
- native Support support native Linux games
- [Steam Compatibility Tool](#Steam Compatibility Tool) can be used as Steam Launch Option and as Steam Compatibility Tool
- Proton Selection switch between Proton-Versions, automatically download custom Proton builds...
- Multi Language Multi-Language Support
- Steam Linux Runtime the Steam Linux Runtime can be disabled optionally
- Game Launcher built in game launcher mode
- Game Pictures uses Game Pictures
- Desktop Files automatic creation of (stl-internal) desktop files
(no special order)
Programs required for a full internal functionality:
- bash (only shell tested)
- git
- pgrep
- unzip
- wget
- which
- wmctrl
- xdotool
- xprop
- xrandr
- xwininfo
- Yad. The (by default enabled) Settings Menu and the Tray Icon only work with yad.
The Editor Dialog, which can be used as limited alternative to the Settings Menu also works with zenity.
(so this should be an
or dependencyin distribution packages) Only tested yad 7.2 on Arch linux (at least Debian (derivatives) seem to use a very old yad version by default, which will not work - see #98)
Programs needed for optional external features (no special order):
- strace
- Gamemode
- MangoHud
- winetricks
- vr-video-player for playing regular games side-by-side in VR (SBS-VR)
- a graphical text editor and optionally a internetbrowser see global.conf
- vkBasalt
- Nyrna
- ReplaySorcery
- netstat from net-tools for basic network monitoring
- Boxtron and dosbox to optionally start dos games with linux native dosbox
- ScummVM to optionally start compatible games natively using Roberta
- luxtorpeda-dev or Luxtorpeda to optionally start supported games with a linux native binary
- wine for optional Vortex support
- GameConqueror/scanmem to optionally cheat
- GameScope
- zenity (see description for yad above)
- cabextract (currently only used to extract the WMP10 setup exe)
- lsusb (for an optional SBS-VR check if a VR HMD was found)
- jq (currently only used to extract game names from the steam api)
All configuration files are self-contained documented and always growing, so not every option is documented in here. For a general overview what can be configured, just check the Features or simply browse through the Settings Menu, which covers almost everything available.
Almost all user configuration options can be changed with the built-in Settings Menu (using Yad) Tooltips give a basic description for every entry.
(Currently) the Menu has following Tabs:
- Tab 1 is the GAME SETTINGS Menu for the selected game (either started from steam or via commandline) (
$STLGAMECFG) - Tab 2 is the DEFAULT SETTINGS Menu, which is the template for all newly created GAME SETTINGS (
$STLDEFGAMECFG) - Tab 3 is the GLOBAL SETTINGS Menu, where all global applicable settings can be configured (
$STLDEFGLOBALCFG) - Tab 4 is the VORTEX SETTINGS Menu, for Vortex Configuration (
$STLVORTEXCFG)
The Options apply to all config files at once!:
- EXIT - leave Settings Menu without doing anything
- PLAY - start the game
- EDITOR MENU - Opens a little Editor Menu from where all found user-editable config files can be opened in the Editor
- RELOAD - discard all changes and reload all config files
- SAVE AND RELOAD - save all changes and reload them
- SAVE AND PLAY - save all changes and start the game
When stl was launched "standalone" via command line the corresponding game will be started using the steam -applaunch parameter.
If you prefer to simply use your favourite texteditor or have problems with 'yad' you can change USEGUI to "zenity" in the Global Config Tab or global.conf.
stl won't use/depend on yad then and uses zenity instead.
Instead of the Settings Menu zenity will open the Editor Dialog, from where you can choose which configs to edit.
This also applies to the [command line](#via Command Line).
When enabled an optional self-rolled stl-steam gtk-css theme is installed into ~/share/themes/stl-steam/gtk-3.0/gtk.css
which tries to mimic the steam theme to integrate as good as possible. It can be en-/disabled in Settings Menu.
Every gtk program which is started from stl will use the theme as well (f.e. winetricks).
The css is no complete theme and might look incomplete when used with other gtk programs.
Feel free to improve and contribute it though!
When a game is started a small requester will wait WAITEDITOR seconds for User input (either Space or press OK)
If selected the Settings Menu will open directly with the settings for the launched game in Tab 1 (see Settings Menu)
When WAITEDITOR is set to 0 stl will directly start the game.
If MAXASK in the global.conf is defined, the requester can be cancelled maximal MAXASK times
before WAITEDITOR is automatically set to 0 for the selected game.
Letting the requester timeout does not count as cancelled.
The "Cancelled counter" is stored directly in the Game specific configuration file as ASKCNT
and is resetted to 0 when MAXASK was reached and WAITEDITOR was set to 0.
If USEGUI is set to "zenity" the Editor Dialog will open instead of the Settings Menu, but the parameters are the same.
The Settings Menu can also be opened via commandline:
stl settings opens the Menu with placeholder SteamAppID 31337 as default
an optional commandline argument can be either a SteamAppID or last for opening the config of the last played game stored in LASTRUN
If USEGUI is set to "zenity" the Editor Dialog will open instead of the Settings Menu, but the parameters are the same.
When SAVESETSIZE is enabled in the Global Config Tab or global.conf (by default it is) resolution changes of every stl window (both yad and zenity) are automatically saved
when the corresponding window is closed. This function requires xwininfo to work.
All resolutions will be stored in the gui config file.
If you prefer window decoration to resize windows, you can enable it in the Global Config Tab or global.conf
(else hold Left-Alt while resizing the window while holding the right mouse button).
When yad is used stl also offers a Tray Icon, which automatically starts and is available until stl (or the started game) exits.
Can be disabled (by default enabled) with disabling USETRAYICON in the Settings Menu Global Config Tab or global.conf.
Right Click opens The Menu.
Middle Click Closes The Menu
- "Pick Window Name" (pick the window name and save it into the Game Config)
- "Get Active Window Name" (waits 5 seconds and saves the window name of the active window into the Game Config)
- "Get Active Window Size" (waits 5 seconds and saves the window size of the active window into the Game Config) (f.e. for minimal SBS-VR window size)
- "Kill Proton Game" (kills the currently running Proton game by killing its wineserver)
- "Pause/Unpause active window" (waits 5 seconds and un-/pauses the process of the window which is currently active)
The main user configuration directory STLCFGDIR can be found under
$HOME/.config/stl (or XDG_CONFIG_HOME/stl if XDG_CONFIG_HOME is set).
When started for the first time stl will initially create a default configuration structure in its configdir STLCFGDIR
The systemwide configuration directory SYSTEMSTLCFGDIR can be found under /usr/share/$PROGCMD (/usr/share/stl/)
All configs used here are read first, so user configs override them if required.
System-wide configs help to keep configuration easy and get things to work ootb.
f.e. there are preconfigured Steam Category,
custom per-game registry files, which are autodetected and applied (when REGEDIT is 1),
community contributed tweaks which make sure specific games work ootb using the provided configuration options,
community contributed sbs tweaks which make sure specific games work ootb in SBS-VR mode using the provided configuration options
With the variable DLGLOBAL being set to 1 (it is by default) stl
uses systemwide configurations from the directory STLDLDIR/stl and also git pulls this repo into there (max once per day).
This only is used when the systemwide configuration directory SYSTEMSTLCFGDIR does not exist at all!
As almost no distro provides a stl package, the idea is that the user only has to copy stl into $PATH
and still can make use of the bundled config files without having to install them manually.
No executable files will be used from here!
Auto-generated [auto tweaks](#Auto Tweaks) imported from other platform will be loaded before global configs, so global configs override them by default.
STLDEFGAMECFG ($STLCFGDIR/default_template.conf)
Contains the default configurations options used as template for every new game specific configfile. Most options are disabled by default. To deploy appropriate global options early this file should be adjusted early.
STLDEFGLOBALCFG ($STLCFGDIR/global.conf)
Contains universal configuration options used all games, f.e. file paths, command line options for supported 3rd party programs, but also general "behavior" settings (f.e. Logs mode or timeout for the Settings Menu and EditorWAITEDITOR)
STLGUICFG ($STLCFGDIR/gui.conf)
All window sizes will be stored in this config when SAVESETSIZE is enabled (by default it is).
The initial resolution of all windows is calculated based on the screen-resolution.
STLURLCFG ($STLCFGDIR/url.conf)
For a transparent and easy overview all URLs available in stl are stored in here.
As all variables are in plaintext, there's no extra URLs Tab in the Settings Menu
but the file can always be selected in the Editor Dialog.
$STLGAMECFG ($STLCFGDIR/gamecfgs/$SteamAppId.conf)
When starting a game using stl the game specific config file is searched in STLGAMEDIR
and created if not available from the default config file (which in turn is automatically created as well if not found).
Additional individual configs can be loaded via multiple different Tweaks.
Any option configured in here and also in global.conf is overridden by this config.
stl parses the Steam categories of the started game and examines if a associated stl configuration file exists under the same name (case-sensitive, but written uppercase in Steam !)
If a configuration file is found it is initialized as additional config file.
This makes it easy to create "Configuration categories" by
- simply creating a Steam Category
- creating a categories configfile under the same name and defining settings in it
- adding a game to the category to use those settings automatically
Category Configuration Files are searched in the User Configurations STLCATEGORYDIR (STLCFGDIR/categories)
or in the system-wide dir GLOBALCATEGORYDIR (SYSTEMSTLCFGDIR/categories)
where some category files are already preconfigured:
a game in the corresponding category
- DOSBox.conf is started automatically with linux native dosbox provided by Boxtron
- Luxtorpeda.conf is started automatically with linux native binary provided by Luxtorpeda
- ReShadeVR.conf is started automatically in SBS-VR mode using ReShade
- SBS-VR.conf is started automatically in SBS-VR mode without Shader (for games with builtin Stereoscopic3D support)
- ScummVM.conf is started automatically with linux native scummvm provided by Roberta
- Vortex.conf is started automatically with the Vortex Mod Manager
- vkVR.conf is started automatically in SBS-VR mode using vkBasalt and
- Installer.conf won't be started at all, but a requester lets one choose an exe which is started instead.
- Cheat.conf GameConqueror is automatically started with the game.
Multiple Category Configuration Files are possible, they are loaded one after another, with the last one overriding settings also found in the previous files.
All settings which are also configured in $STLGAMECFG are overridden (but not overwritten).
The function can be diabled per game with the option CHECKCATEGORIES
All different user writable tweakfiles live in their own subdirectory under TWEAKDIR ("$STLCFGDIR/tweaks")
If a tweak config TWEAKCFG ( SteamAppID.conf ) in GLOBALTWEAKDIR or USERTWEAKDIR (overrides global) is found its settings
overrides the settings in the $STLGAMECFG.
By means of this function it is be possible to contribute tweak configs required to get games to work hazzlefree out of the box to the community.
With CREATETWEAKS a default template tweak file is autogenerated on game launch, to make creating one a bit easier.
Some systemwide tweaks can already be used (see Installation).
If you use/create tweaks make sure to retest your game with later proton versions without the tweak and report upstream if the bug is fixed!
The used proton Version is automatically written into the tweak file when created with CREATETWEAKS.
User tweak-files in USERTWEAKDIR override global tweaks in GLOBALTWEAKDIR, [Autotweaks](#Auto Tweaks)
An example tweakfile looks like this:
stl/tweaks/user/8080.conf:
#########
#GAMENAME=Kane and Lynch Dead Men
#GAMEEXE=Launcher
#GAMEID=8080
#PROTONVERSION=proton-5.0-10-rc4
#########
WINETRICKSPAKS=d3dx9_31 d3dx9_34
PROTON_NO_ESYNC=1
PROTON_NO_FSYNC=1
NOGFWL=1
Explained in detail: When the game "Kane and Lynch Dead Men" is started stl will find its tweakfile (8080.conf = SteamAppId.conf) and apply following configurations:
- d3dx9_31 d3dx9_34 will be installed via wintricks
- PROTON_NO_ESYNC and PROTON_NO_FSYNC will both be set to 1
- gfwl will be removed
This works completely automatically and transparent without any user interaction. (of course the first start will need some time when aditional packages are installed)
It is also possible to define a script under TWEAKCMD (f.e. in TWEAKCFG) which should be started before the game launch.
This is especially useful when it is necessary to move or rename game files to get a game working.
When a TWEAKCMD is defined stl will check if it finds the file
- as absolute path
- in the system tweak directory
- in the user tweak directory
- in the gamedir
In case the file was found stl checks if a TWEAKFILE is defined in the TWEAKCMD file.
This comes in handy when the script requires a specific file (f.e. a custom game exe) which is not available for everybody.
With this little "dependency check" the tweak file is simply skipped if the file was not found and the tweak can still be shared in the community.
Not exported variables are not available in the script, but usually none should be required (yay might want to check env for available vars)
GPFX="$STEAM_COMPAT_DATA_PATH/pfx":can be used as variable for the gamesWINEPREFIXGFD="$(awk -F 'common' '{print $1}' <<< "$PWD")common/$(awk -F 'common' '{print $NF}' <<< "$PWD" | cut -d'/' -f2)": can be used for the base game dir
Game specific config files SteamAppID.conf both in and system-wide (GLOBALSBSTWEAKDIR) and User Configurations (SBSTWEAKDIR)
with optimal settings for SBS-VR (f.e. launcher skips using the game exe as custom command).
Here's an example config for trine 2 STLCFGDIR/sbs/35720.conf
#########
#GAMENAME=Trine 2
#GAMEEXE=trine2_launcher
#GAMEID=35720
RUN_CUSTOMCMD=1
CUSTOMCMD=trine2_32bit.exe
ONLY_CUSTOMCMD=1
GAMEWINDOW=Trine 2
Means, when RUNSBSVR is not 0 in the main Trine2 config file it will autodetect above sbs tweak config and use the defined variables:
Trine 2 won't start it's original launcher (ONLY_CUSTOMCMD=1), but only the custom command trine2_32bit.exe and will wait for a Trine 2 window to open in VR
So in general sbs configs are automatically loaded when found and override settings in the main config
so you just have to enable RUNSBSVR in STLCFGDIR/gamecfgs/35720.conf and everything else is configured automatically.
stl allows to import required game config files from several other platforms.
The path to those autogenerated tweaks is
AUTOTWEAKDIR ("$TWEAKDIR/auto") with "$platform" as subdirectory.
All platforms from where configurations shall be imported need to be listed in the
global AUTOTWEAKS variable.
All enabled autotweak platform tweak files are loaded before all other configs, so it is always possible to override them later.
This is necessary, as aparrently not all autogenerated configs can be tested.
When ATVALIDATE=0 the order in AUTOTWEAKS decides in which order they are loaded.
The later a config is found the more important it is, as it discards the configs found from previous platforms.
With ATVALIDATE being disabled there is apparently no control over what will be actually loaded.
When the variable ATVALIDATE is >0 a requester will pop up
asking the user if he wants to open the autocreated config with the editor
(also her in the same order as the platforms are listed in AUTOTWEAKS)
Afterwards another requester asks if the config should be loaded or skipped.
When multiple Auto Tweak Configs are found the requesters are opened for all of them,
but only the last accepted config is actually loaded!
If IGNOREAUTOTWEAKS=1 is set in the current gameconfig $STLGAMECFG all autotweaks are skipped automatically.
If ATADOPT=1 is set in the current gameconfig a requester will pop up when th game exited
asking if the used AutoTweak config should be converted into a regular tweakconfig.
Autotweaks will be disabled in this new config then.
Auto Tweaks are either autocreated on game launch automatically (if the chosen AUTOTWEAKS support the game)
or can be .
stl will download an active repo on the first run and prepare the datafiles for better searching if required. To keep downloads as low as possible, on later runs the already downloaded data will be re-used where possible.
When started directly from Steam stl searches for a gamefix for the current SteamAppID.
If one is found the gamefix will be converted into a stl autotweakfile under AUTOTWEAKDIR/protonfixes.
This config is then applied like described in [Auto Tweaks](#Auto Tweaks) above.
Creating Auto Tweaks via stl command line:
stl autotweaks|at ('dl') PLAFTORM (optional steamid)
Will autogenerate all tweak files for every parsible game of platform PLATFORM or just for the optional SteamAppID Example:
stl autotweaks|at lutris
Creates for all supported Games Autotweak files in AUTOTWEAKDIR/lutris
stl autotweaks|at lutris 883710
Creates only for game 883710 an Autotweak file.
Using the option 'dl' the corresponding platform source is updated before the actual process starts - f.e:
stl at dl lutris
Depending on the platform stl filters several original configuration options. If you think something important is missing please open an issue!
Some protonfixes gamefixes are marked as deprecated inside protonfixes. Those and a handful more (mostly those copying/changing files) are skipped automatically. When run from terminal those skipped will be listed. To see how Auto Tweak files are created read general describtion from above [here](# Creating Auto Tweaks)
Currently following options are imported into the Auto Tweak file:
- winetricks packages
- alternative executables
- env variables
- dll overrides
- game command line arguments
Lutris is pretty huge and supports many different platforms. stl uses multiple filters to extract the following options into the Auto Tweak file:
- winetricks packages
- commandline arguments
- env variables
- dll overrides
- pulseaudio latency
- xlive
- mfplat
- basic script creation (
TWEAKCMD) - downloads and their extraction will be added commented out in the autotweak file
To see how Auto Tweak files are created read general describtion from above [here](# Creating Auto Tweaks)
The STLDLDIR directory stores all downloads started through stl
As of writing those are
Depth3D shader files
Vortex the installation setup exe
ReShade ReShade itself and required d3dcompiler dlls
Auto Tweaks downloads for all enabled Auto Tweaks are stored in here
GFWL/xlive xlive replacement
self maintaining configs stl itself will be downloaded here when self-maintaining-configs are used
Proton packages Proton packages
Logs are written into the LOGDIR defined in the global.conf.
The verbosity of the logfile depends on WRITELOG (write logfile if not 0, increase verbosity from 1-2 (1:less, 2:all))
also defined in the global.conf.
There are several logfiles, those which are written mostly are the game specific ones ($SteamAppId.log)
stl provides the option to easily choose a specific Proton Version per game, by simply selecting one from an autogenerated dropdown Menu in the Game Settings Tab of the Settings Menu.
The function can be en-/disabled in the Settings Menu (by default disabled!), but if stl is used as Steam Compatibility Tool with a Proton game, a force override flag disables the set flag, as it obviously requires any Proton version to start. In this case the latest official Proton Version is set by default.
The List of available Proton Versions is generated on the first stl launch (in /dev/shm) and recreated when a new Proton Version was added on the fly.
stl searches in the following sources for Proton Versions to generate the list:
- user installed compatibility tools (~/.steam/steam/compatibilitytools.d/)
- system-wide compatibility tools (/usr/share/steam/compatibilitytools.d)
- official proton versions installed via Steam in default SteamLibrary (~/.steam/steam/steamapps/common/)
- official proton versions installed via Steam in additional SteamLibrary Paths (the additional Paths are extraced from ~/.steam/steam/config/config.vdf)
- a custom Proton List
The optional custom Proton List CUSTOMPROTONLIST in STLCFGDIR
is used as additional source for custom Proton Versions for inclusion into the autogenerated Proton Version (dropdown) List.
There are several methods to add new entries to the list (besides editing it manually / via Editor Dialog):
a locally installed Custom Proton can be added either by
- using the button
Add local Custom Protonin the Game Settings Tab of the Settings Menu - via command line:
stl addcustomprotonor juststl acp(accepting an absolute path to a proton executable as optional argument)
With either method a proton file can be selected via file-requester
and an optional "proton version name" can be entered in a separate field.
Custom Proton packages can also be downloaded and added by
- using the button
Download Custom Protonin the Game Settings Tab of the Settings Menu - via command line:
stl addcustomproton dlor juststl acp dl(accepting direct download URL as optional argument)
With either method a download requester with a dropdown menu is opened.
The menu is autogenerated, by parsing all CP_* (Custom Proton) URLs from the Url Config
for proton packages. Currently following Custom builds are parsed (feel free to recommend one if you think something is missing)
Packages (tar.*, zip) containing a proton file will be extracted and added to the List of available Proton Builds.
Using the variable WANTPROTON in configs and tweaks it is possible to automatically request a specific proton version to be used with the corresponding game.
If AUTOPULLPROTON is enabled (it is by default) stl will automatically download the specific proton version and install it.
stl Multi-Language Support (currently with these languages).
At least the default language file (english) needs to be found, else stl will exit with an error. stl searches both in the Systemwide Configuration and in the User Configuration for language files, where those in the latter have a higher priority (so copying a systemwide file to improve it is possible)
Every language found can be selected from the Language Dropdown Menu in the Global Settings Tab of the Settings Menu. (a change requires a restart to take effect).
To give also the option to get a translated description in freshly created stl configfiles
it is also possible to define an available language or an absolute path to a valid language file with the lang= command line option.
When no language file was found as a last resort stl will download its own projectpage and use the language file from there.
(every language file simply consists of multiple variables defining a text, so to contribute a translation, simply duplicate one of the existing ones and translate all variables inside)
Introduced with proton 5.13-1 the Steam Linux Runtime is autostarted and part of the game command line parameters.
This (currently) breaks compatibility with several tools like MangoHud, vkBasalt, Gamemode, GameScope, Boxtron, Roberta, Luxtorpeda (not sure of all of them are affected or others are missing, feel free to test and report bugs)
With stl is used as Launch Option
both the Steam Linux Runtime and the [Proton Version](#Proton Selection) show up in the Steam Game launch command and therefore can be read by stl.
In that case the Steam Linux Runtime can be disabled per game in the GAME SETTINGS of the Settings Menu or in game configfile $STLGAMECFG
and if one (or more) of above confliciting tools are enabled stl warns that it is incompatible with the Steam Linux Runtime (for now).
When starting stl as Steam Compatibility Tool there are no Steam Linux Runtime parameters in the Steam Game launch command and therefore cannot be disabled (maybe comparable to the [Proton Version](#Proton Selection) which doesn't show up as command line parameter as well and is used 'under the hood').
stl comes with a small Game Launcher, which starts selected games using the steam -applaunch parameter.
The Launcher has several modes, which can be selected via command line:
-
Without additional command line parameters:
stl launcher(will start the Game Launcher with all installed games) -
Optional arguments for launcher are:
-
stl launcher $CATEGORY(will show only the installed games in the steam category$CATEGORY) -
stl launcher menu(will open a small menu with all available steam categories) -
stl launcher last(will open the last played game as 'menu') -
stl launcher auto(automatically creates/downloads required data for all installed games before opening the launcher with all installed games) -
stl launcher update(recreates the already autogenerated category menus - can be combined with auto') -
stl launcher $INVALID(with any invalid parameter all faound valid Steam Categories will be listed)
The contents of the corresponding categories are autogenerated on the fly (in /dev/shm/) using Game Pictures and Desktop Files.
With above auto both Game Pictures and Desktop Files are autogenerated/downloaded if missing.
By default stl downloads automatically the main header.jpg picture from (configurable STASSURL) if not found and saves it under the SteamAppID name.
Those pictures are used in the Game Launcher (via Desktop File) and also in the "Main Timeout Window",
in the Editor Dialog and in the Settings Menu.
Downloading of the Game Pictures can be disabled with DLGAMEDATA in the GLOBAL SETTINGS of the Settings Menu.
Displaying the Game Pictures can be disabled in the GLOBAL SETTINGS of the Settings Menu as well or directly by disabling USEGAMEPICS.
Displaying the Game Pictures only can be disabled in the Settings Menu or directly by disabling USEGAMEPICINMENU.
The Game Launcher (yad) takes a directory containing desktopfiles as argument and lists all of them.
Those Desktop-Files are autogenerated using the (big) Game Pictures in the STLCFGDIR and therefore are of no use for generic usage.
Both Game Pictures and Desktop Files (for the Game Launcher) are autogenerated/downloaded per game start by default but also can be batch created via command line:
stl update gamedata(updates missing desktopfiles and pictures of installed games and exits - depending on the missing files this might need some time)stl update gamedata $APPID(updates missing desktopfiles and picture for game$APPID)stl update allgamedata(updates missing desktopfiles and pictures of all games in 'sharedconfig.vdf' and exit - depending on the missing files this might need some time)
When enabled you can start custom programs easily with the following per-game config options:
RUN_CUSTOMCMD: set to 1 or 2 (see below) to start the custom commandCUSTOMCMDCUSTOMCMD: start this custom commandCUSTOMCMD_ARGS: startCUSTOMCMDcommand with those argsONLY_CUSTOMCMD: set to 1 to only startCUSTOMCMDand not the game command itselfFORK_CUSTOMCMD: set to 1 to fork the customCUSTOMCMDinto the background and continue with starting%command%
If only RUN_CUSTOMCMD is enabled, but CUSTOMCMD is empty, a requester will open where a executable file can be selected.
When RUN_CUSTOMCMD is 1 this selected file is automatically written into the in game configfile $STLGAMECFG.
When RUN_CUSTOMCMD is 2 this selected file is only started this time without saving the exe into the config.
This is especially useful for installers (see provided Steam Category 'Installer')
If string CUSTOMCMD can't be found as file in either PATH, in game dir or as absolute filepath the requester will open as well.
If commands are defined in USERSTART USERSTOP they will be executed when a game starts/ends.
Of course the user is responsbile for what is executed here and needs take care that it both works and exits correctly!
Both scripts make use of following commandline arguments:
- SteamAppID as argument1
- the absolute path to the game exe as argument2
- and the WINEPREFIX of the game as argument 3
Winetricks
GUI:
Set RUN_WINETRICKS to 1 to start winetricks gui before game launch
Silent winetricks installation:
WINETRICKSPAKS: install all packages in WINETRICKSPAKS silently with winetricks
RUN_WINECFG: set to 1 to start winecfg before game launch
The global configs BOXTRONCMD and BOXTRONARGS in the global.conf need to be set correcty initially.
It should not be necessary to change the default ROBERTAARGS.
Defaults are:
**
BOXTRONCMD=/usr/share/boxtron/run-dosbox
BOXTRONARGS=--wait-before-run
**
which is at least valid if you are on Arch Linux and installed boxtron from AUR.
To start a game with boxtron either set USEBOXTRON in the gameconfig $STLGAMECFG or put the game into the steam category "DOSBox"
Alternatively duplicate the file to a different name which you want to use as category name, ideally into STLCATEGORYDIR..
The global configs ROBERTACMD and ROBERTAARGS in the global.conf need to be set correcty initially.
It should not be necessary to change the default ROBERTAARGS.
Defaults are:
**
ROBERTACMD=$HOME/.local/share/Steam/compatibilitytools.d/roberta/run-vm
ROBERTAARGS=--wait-before-run
**
which is at least valid if you installed roberta manually.
To start a game with roberta either set USEROBERTA in the gameconfig $STLGAMECFG or put the game into the steam category "ScummVM"
Alternatively duplicate the file to a different name which you want to use as category name, ideally into STLCATEGORYDIR..
Luxtorpeda-dev or (untested) the main branch
The global configs LUXTORPEDACMD and LUXTORPEDAARGS in the global.conf need to be set correctly initially.
It should not be necessary to change the default LUXTORPEDAARGS.
Defaults are: ** LUXTORPEDACMD=$HOME/.local/share/Steam/compatibilitytools.d/luxtorpeda/luxtorpeda LUXTORPEDAARGS=wait-before-run ** which is at least valid if you installed roberta manually.
To start a game with luxtorpeda either set USELUXTORPEDA in the gameconfig $STLGAMECFG or put the game into the steam category "Luxtorpeda"
Alternatively duplicate the file to a different name which you want to use as category name, ideally into STLCATEGORYDIR..
The luxtorpeda-dev dev was so kind to add a manual-download option in v20, so if native game files are missing they are downloaded before the actual game launch now.
Therefore it is recommended to use the lastest luxtorpeda-dev version.
stl also works with native linux games.
The implementation is pretty new, so please report back if there are false positives in the detection. Currently the first distinction is if "waitforexitandrun" appears in the game %command%.
If yes, stl assumes we have a proton game. Now, when another check finds "steamapps/common" (without "waitforexitandrun") a linux game is assumed, and the (now generic) launchSteamGame function is started.
Looks like only proton games have the Variable STEAM_COMPAT_DATA_PATH, so if it is missing several features are disabled in the setLinGameVals function,
as they do not work with native linux games (f.e. ReShade) (still visible in the Settings though). The Game and Exe Path Variables are differently extracted as well when STEAM_COMPAT_DATA_PATH is missing.
Some games still depend on GFWL which is discountinued and doesn't work under wine.
With the variable NOGFWL set to 1 for a game stl takes care that
everything is configured automatically to start the game ootb.
If the dependant xlive.dll is missing it will be downloaded automatically
( from Ultimate-ASI-Loader )
into $STLDLDIR/xlive/ and installed into the gamedir.
stl ships already several tweak files, which enable NOGFWL for several games (f.e.: "Fable 3 (105400)", "Resident Evil 5 (21690)", "Kane and Lynch Dead Men (8080)", "FlatOut Ultimate Carnage (12360)"
Games which depend on WMP10 can be played by setting the variable HACKWMP10 to 1.
Tweak with automatic support already implemented for
** Giana Sisters Twisted Dreams (223220) Giana Sisters - Rise of the Owlverlord (246960) **
Vortex can be used without any stl configuration and will work ootb without zero configuration.
There are 3 different ways to start Vortex:
Just create a "Vortex" Steam Category and add your (Vortex compatible) game to it and start the game regularly. Vortex will start, with the selected game preconfigured and ready to mod and when you exit Vortex the selected game will start normally (with your mods).
see stl --help
The VORTEXMODE option in the Game Tab of the Settings Menu has the following modes:
- "disabled": Vortex won't be used
- "normal": Vortex will be started regularly
- "quickstart": Vortex will be started but some checks are skipped
- "editormode": Vortex will be started in quickstart mode, but the selected game won't start after Vortex is closed
Installation?
If Vortex is not yet installed, it will be installed on the first launch, so the first launch will need some time (mostly depends on dotnets mind of its own... maybe 5 minutes).
Alternatively you can also install it via command line (see below).
If using proton-wine for VORTEXWINE (which is default if it is not configured) the WINEPREFIX user is "steamuser" (as always with proton wine).
When you switch to a wine version which doesn't patch the username to "steamuser" your user-settings are emtpy of course.
stl will not symlink in between those two users!
Functionality: Some settings are preconfigured, to make this working without any user configuration, but of course all of the settings can be as well configured if you want.
stl uses an extra vortex directory inside STLCFGDIR defined under STLVORTEXDIR
This directory contains the Vortex configfile STLVORTEXCFG (STLCFGDIR/vortex/vortex.conf`)
Here are the main configuration options, for a full list, simply look into the Settings Menu
VORTEXWINE: the wine binary used for Vortex - defaults to wine from Newest Official Proton installedVORTEXPREFIX:theWINEPREFIXpath used for Vortex - default isSTLVORTEXDIR/wineprefixVORTEXDOWNLOADPATH: the path where all Vortex downloads should be stored - default isSTLVORTEXDIR/downloadsVORTEXINSTALL: download and install Vortex automatically if set to 1 default enabledDISABLE_AUTOSTAGES: set to 1 if you don't want stl to try to auto set/create Vortex Stages directories default 0
Vortex uses 2 main Deployment_Methods to enable Mods for the managed games. "Hardlink Deployment" and "Symlink Deployment". Symlink Deployment doesn't work under wine, so Hardlink is required (and automatically set for every game from stl, although it is default anyway) Those "Hardlinks" only work if the "Staging directory" is on the same partition as the game (yes the same physical partition, not the same "windows drive in wine). As Steam Library directories can be on multiple partitions a "Staging directory" is required for every one of them.
When you start a game stl will parse on which mount point it actually lies. Then it tests if it can create/write a "Vortex" directory in the root directory of the partition. If it fails to create a directory in the previous step, it tests next if it can create/write a "Vortex" directory directly in the "Steam Library" directory of the started game besides the "steamapps" directory.
The first succeeding directory will be added automatically to the VORTEXSTAGELIST list
and will be used from now on as "Staging directory" automatically for all games lying on the same partition.
So after you have started one "Vortex" game from each of your "Steam Library" partitions the VORTEXSTAGELIST variable is ready for all of your games.
The only exception is the partition where your steam is installed ("/" or "/home" if you have an extra /home/partition).
Here the default "Vortex Staging directory" is STLVORTEXDIR/staging instead.
Other additional paths can be added easily, just make suggestions.
If you don't want that automation just set DISABLE_AUTOSTAGES to 1 and set them manually instead:
Simply add one writable directory per Steam Library partition you want to use to the VORTEXSTAGELIST.
This can also be done directly by using the add Vortex Stage button in the Vortex Tab of the Settings Menu.
Several games (Skyrim, Fallout flavours) have many mods which depends on a special "Script Extender" program ("SE"). Unfortunately those "SE" programs don't work with default proton since some time. When stl detects one of those "SE exe" files in the game dir, a requester will pop up with following options:
- start the regular game exe
- start the regular game exe and save the decision (so don't ask again)
- start the found "SE exe"
- start the found "SE exe" and save the decision (so don't ask again)
When choosing "SE exe" make sure the selected Proton Version is can actually run the exe!
(The "don't ask again" option SELAUNCH can't be set in the Settings Menu
and must be removed manually from the [game config](#Game Configurations) -f.e. via Editor Dialog
- On the first start Vortex warns that it is started with admin privileges. Very likely wine related, just click it away, it won't pop up again
- I tested ~25 games and they worked ootb, feel free to open an issue for a not (automatically) working game if you think this is a stl bug. (Nehrim doesn't seem to work (yet))
- It was pretty much work to get this into the current state, but although I tested a lot there still might be glitches and problems. Also Vortex can stop working under linux/wine anytime after an update (as it already did before). Don't complain and rant when it doesn't work as expected (anymore) (as it happened already before with other Vortex-linux solutions), but try to help fixing the issue instead then (no offense, but imho linux already had better times regarding this).
Auto-applying registry files:
If REGEDIT is
- set to 0 it will be skipped completely
- set to 1 a registry file
$SteamAppId.regwill be searched and used inGLOBALREGDIRandSTLREGDIR - set to anything else the file
$REGEDITwill be searched and used inGLOBALREGDIRandSTLREGDIR
when a registry file from above was applied REGEDIT will be set to "0" in the game config, to skip regedit on the following game starts
To play games with built in side-by-side you just have to set RUNSBSVR to 1 (or greater to delay the VR start for RUNSBSVR seconds) in the game specific config,
everything else is done (almost) automatically:
- start SteamVR
- start the game (game settings required to enable sbs are not automatically enabled! added a tweakcmd for Crysis 2 though )
- start vr-video-player
- when exiting the game, vr-video-player wil be closed as well.
There are also two quickstart options to choose from to directly start regular games in SBS mode without any further configuration by auto-enabling side-by-side with the shader Depth3D:
SBSVRVK: set to 1 as shortcut to enable all required flags for SBSVR with vkBasaltSBSVRRS: set to 1 as shortcut to enable all required flags for SBSVR with ReShade
Where Reshade has more features and vkBasalt is probably more stable, because it works natively.
Before Starting SteamVR stl checks if a HMD is present (using lsusb).
If none was found the SBS VR mode is cancelled and if SBSVRRS was supposed to start ReShade is disabled as well.
The game starts regularly in pancake mode subsequently.
stl goes through several functions to automatically find the current window id
(and for later use also the game window name, to make starting SBS VR for the game faster)
This works mostly very good, but some games start own launchers before the actual game.
Then autodetecting the correct window is almost impossible, and the window name has to be set manually as GAMEWINDOW.
If autodetecting failed for whatever reason, it is still possible to pick the game window name again, by using the Tray Icon
The vr-video-player author was so kind to accept a little patch, to work better with stl. It is possible to live zoom in and out and the zoom state is written into a temporary file, which stl picks up. The value is stored in the internal SBS Tweak config (also when changed) and read from there from now on.
To make switching between game- and vr-video-player window easier (with hmd) there is also the option TOGGLEWINDOWS:
When enabled, all visible windows will minimize on game start, and will maximize back when game finishes
So switching between the windows is easily possible with Alt+Tab.
TOGGLEWINDOWS is also enabled by default in the VR Steam Categories (ReShadeVR,SBS-VR,vkVR.conf)
USEGAMEMODERUN: set to 1 to start game with gamemoderun (User Configuration overrides system-wide configuration)
Set NOTY to your notifier to draw some start/stop stl messages
MangoHud
Set MANGOHUD to 1 to enable mangohud (does nothing in stl itself, but just exports the upstream variable)
Nyrna
Set RUN_NYRNA to 1 to enable nyrna while game is running
(User Configuration overrides system-wide configuration)
ReplaySorcery
Set RUN_REPLAY to 1 to enable replay-sorcery while game is running
(User Configuration overrides system-wide configuration)
GameConqueror
Set RUN_GAMCON to 1 to automatically start GameConqueror when the game starts.
The game exe will be loaded into GC automatically,
but also can be overridden with GAMCONWAITEXE (f.e. for games starting a launcher).
When the game exits GameConqueror will be closed automatically as well.
As the gameconqueror startscript uses pkexec and asks for more permissions, the default
executable is set to GAMCON=/usr/share/gameconqueror/GameConqueror.py in the global config.
Enabling GameConqueror is also possible by simply adding the game to the "Cheat" [Steam Category.
Some games (afaik mostly multiplayer) are not cheat-safe and could lead to a ban, so be careful with cheating!
GameScope
Set USEGAMESCOPE to 1 to automatically start GameScope when the game starts, either per game or globally.
The commandline arguments used (GAMESCOPE_ARGS) can be configured both per game and globally as well.
minimize all open windows on game start and maximize them when game exited using wmctrl
TOGGLEWINDOWS: toggle visibility of all open windows on start/stop
If STRACERUN is set to 1 stl will write a strace log of the launched game
strace is launched with the commandline arguments found in STRACEOPTS.
When STRACERUN is enabled make sure
/proc/sys/kernel/yama/ptrace_scope is set to 0.
else your user will get access denied when trying to attach a process.
Either
echo 0 > /proc/sys/kernel/yama/ptrace_scope
as root or enable it persistent in sysctl.
Basic Network Traffic Monitor
NETMON: program to record game network-traffic with argumentsNETOPTS- used when enabled
If NETMON is set the basic network traffic of the selected game is monitored and written into NETMONDIR.
duplicate lines are unique sorted at the end.
ReShade
Set INSTALL_RESHADE to 1 to automatically install reshade into the selected game dir.
Set USERESHADE to 1 to start game with ReShade enabled
If DOWNLOAD_RESHADE is set to 1 all required files for ReShade are downloaded once into RESHADESRCDIR
of course you can install all files manually as well. make sure to rename all files correctly:
64bit d3dcompiler_47.dll: -> d3dcompiler_47_64.dll
32bit d3dcompiler_47.dll: -> d3dcompiler_47_32.dll
ReShade64.dll, ReShade32.dll: renaming not required as they will be placed in the gamedir under the required name
The required architecture is autodetected from the game.exe and the matching files are copied from RESHADESRCDIR into the selected game dir
both downloadfiles and basic configuration were taken from r/linux_gaming
If USERESHADE is disabled and the corresponding game is started, the previously installed ReShade dll will be renamed, so ReShade is disabled when the game starts.
When USERESHADE is re-enabled the renamed dll will be re-activated.
ENABLE_VKBASALT: setENABLE_VKBASALTto 1 to start the game with vkbasalt (does nothing in stl itself, but just exports the upstream variable)VKBASALT_CONFIG_FILE: the vkbasalt source config file - it points per default toSTLCFGDIR/vkBasalt.confand is autogenerated if not found The autogeneratedVKBASALT_CONFIG_FILEpoints to the files fromRESHADE_DEPTH3Dso it should have been at least checked out once withCLONE_DEPTH3D
Depth3D
Mostly useful in combination with SBS-VR.
Set RESHADE_DEPTH3D to 1 to install ReShade Depth3D Shader into gamedir
If CLONE_DEPTH3D is set to 1 the git repository will be automatically cloned/pulled (only when RESHADE_DEPTH3D=1) to DEPTH3DSRCDIR in Downloads
With RESHADE_DEPTH3D enabled Overwatch.fxh, SuperDepth3D.fx, SuperDepth3D_VR.fx from Depth3D are copied to the gamedir.
When the game started just create a initial profile by selecting the autodetected SuperDepth3D_VR.fx
Config files can optionally be opened with the texteditor STLEDITOR if desired, either by accepting a requester (for editing Tweakfiles) or by opening
Configfiles within the Editor Dialog started directly or as submenu of the Settings Menu.
If xdg-open is configured as STLEDITOR or if the configured editor is not found, stl tries to autoconfigure an installed texteditor.
(first trying to find it through 'xdg-mime query', then check binary availability in this order: geany, gedit, leafpad, kwrite)
Set OPENEDITORURL to 1 to additionally open the EDITORURL url for the game in your BROWSER when starting the editor from the Editor Dialog.
(by default the url $OPENEDITORURL/$SteamAppID is opened, if this doesn't work with the url you want to open just open an issue)
If EDITORURL contains "AID" it will be replaced by the current SteamAppID.
A little File selection requester allowing to choose which config files to open with the Editor.
The requester works with both USEGUI set to 'yad' and 'zenity'.
If USEGUI is set to "zenity" in the global config the Editor Dialog will open directly instead of the Settings Menu
when selected on Game Launch and also via Command Line.
Literally every env variable can be set in gameconfig $STLGAMECFG and system-wide configuration,
making it pretty easy to tinker with important ones (f.e PROTON , DXVK* , MANGOHUD, RADV_PERFTEST, WINE...)*
The Possibilities Are Endless...
stl has pretty much to check, but when everything is configured, several option-checks can be disabled (per game) to speed up the actual game start process. Here are some examples which improve the start notably (all settings can be configured in the Settings Menu)
- set
WAITEDITORto0on Game Launch - set
CHECKCATEGORIESto0if the Game has no Steam Category Tweak anyway - set
SAVESETSIZEto0when all windows have their optimal size