cross-posted from: https://lemm.ee/post/38676431
A while back I ended up getting tired of making hacks to get custom binaries to launch in Steam for Windows titles. Primarily for modding, I would find a way to simply launch custom EXE files through Steam to ensure the modding tools and the game were contained neatly in the same prefix. My first ventures with this were Skyrim and Fallout: New Vegas. With these titles, I overrode the gamebryo/creation engine launcher EXE with Mod Organizer 2 (renamed to be the launcher). While this worked, the solution doesn’t work for other games without a secondary launcher that is targeted through Steam.
I eventually came to the conclusion that one can override launch targets entirely in Steam, and that tools like SteamTinkerLaunch could take advantage of this. However, STL certainly does a lot and honestly, that is way more than I really desired just to launch games with a custom EXE. Thus I made a shell script that essentially allows for the user to write in their own custom target and have it launch right through Steam.
The usage for this is simple. Just copy the ‘shim’ file into the game directory, override the Steam launch arguments to include “
./shim %command%”, and all is good. Furthermore, environment variables (such as DRI_PRIME=1), additional launch wrappers (gamemoderun), and game launch arguments (-novid for Source Engine titles) all work. If one needed a combination of all of this, it would look something like “DRI_PRIME=1 gamemoderun ./shim %command% -novid”.The way target editing currently works is on first launch the shim file grabs the default game target and writes it as the contents of ‘target’, another file in the game directory. From there, one can simply edit the target location in the file and shim will launch the custom executable.
So far, I have used this to get things like RaftModLoader and BeamMP working (mod loader for Raft and multiplayer for BeamNG.Drive respectively). I see no issue with this being able to also work for Bethesda titles and others that need custom executables. As I understand as well, the actual game install directories on a Steam Deck with SteamOS are mutable, and with a bit of tinkering through desktop mode should help get a seamless experience for launching modded Steam games for Deck users as well.
I hope someone finds as much use and utility that I have for getting a lot of modding tools for Windows games working without needing to mangle the prefix using protontricks in some cases or install the absolute multi-tool that is SteamTinkerLaunch.
You must log in or # to comment.
Does this allow running multiple executables at the same time inside the game’s proton prefix? Like say, running the game and a widescreen memory patcher at the same time.
It doesn’t currently allow for concurrent execution of EXE files, but that’s a good idea. I’ll see about implementing it.
Thanks, I’ll look forward to it.
I just want an easy way to use WeMod. There’s this but it’s usage is very complicated.
Sounds like it does exactly that. Edit: it doesn’t, yet
I used a widescreen hack with FF7 to get a fullscreen aspect ratio on my steamdeck, and the way I got it working was to make steam launch both the patcher and game at the same time.
deleted by creator
Obviously not. I said it sounds like that’s what it can do.
And I obviously didn’t use this for my use case. That was ages ago.
deleted by creator
What?
deleted by creator
Kinda.
If you want the applications to work on the memory interaction level, they have to be children of the same process. If you start a game launcher in wine, and then start a game from it, it can “see” that game process, close it, join friends, whatever.
But if you start the game exe directly, then separately start the launcher while the game is already running, then it won’t be able to see that there’s already a running game process.
It’s not always enough for the processes to just be part of the same file system (same prefix). If all you need is some input interactions like with voiceattack or trackIR, that doesn’t matter. But for memory hacks it does.
Wine has an internal task manager and if you just start processes without making sure they are running together, they’ll all end up in their own separate wine instances, even though they are on same prefix.
