Fix many problems with run.sh #74

arrowmaster · 2025-07-09T03:42:41Z

Don't output to stdout when not about to exit because of an error.
Make BASEDIR usable earlier such as in the config section.
Update the SteamLaunch check with a check that actually works currently and will hopefully be resilient to future changes in Steam.
Preserve spaces in passed arguments so it will not break on games installed to a path with spaces.

arrowmaster · 2025-07-09T03:43:41Z

I can resubmit these as individual PRs if requested but I haven't tested that they would all merge cleanly if done that way.

ManlyMarco

As far as I can see this can be merged as is. I'll wait for someone that can verify it working on Linux first though.

Damglador · 2025-07-24T17:25:34Z

Well, that's weird (executable_name is also set executable_name="EtG.x86_64")

But it works from Steam

Edit: Had to cd in the game directory for it to work, Steam does that by default.

ManlyMarco · 2025-07-25T19:18:47Z

Edit: Had to cd in the game directory for it to work, Steam does that by default.

Is this a regression compared to the current version?

arrowmaster · 2025-07-25T21:28:11Z

Edit: Had to cd in the game directory for it to work, Steam does that by default.

Is this a regression compared to the current version?

I believe the check that produces this error message is probably in the wrong location, but this would not be a regression. It is a continuation of previously bad behavior. It shouldn't be fixed to work but should have a better error messages and be checked in better locations.

The script overwrites $executable_name with $1 if $1 is set. It then checks if $executable_name is set and that a file named $executable_name has execute permission, if this is a relative path its based on the current working directory. After this check it will look to see if $executable_name starts with a / and if not prepend $BASEDIR forcing it to either be an absolute path or a relative path from $BASEDIR. The order of these behaviors could be changed but trying to fix the inherent problem of potentially having the wrong working directory when launching $executable_name is not a problem to be solved. I think better behavior would be to check that $executable_name is set to a nonempty string earlier (before the SteamLaunch checks) and fail out. Then check that $executable_name is a file with the executable permission later after normalizing it to an absolute path. After all of this if somebody still runs the script while being in the wrong working directory, it should launch the executable but I would caution that the behavior of the executable running with the wrong working directory would be unknown and dependent on the executable.

I'll work on another patch to address this behavior.

Damglador · 2025-07-27T21:26:27Z

New patches fixed the issue.
But for me it is still not able to load BepInEx (with target_assembly="BepInEx/core/BepInEx.Preloader.dll" and BepInEx folder being in the game folder)

Log

└% '/home/Games/SteamLibrary/steamapps/common/Enter the Gungeon/run_new.sh' 
Found path: /home/Games/SteamLibrary/steamapps/common/Enter the Gungeon/EtG.x86_64
Could not load symbol mono_jit_init_version : /home/Games/SteamLibrary/steamapps/common/Enter the Gungeon/EtG_Data/Mono/x86_64/libmono.so: undefined symbol: mono_debug_enabled

 
(Filename:  Line: 200)

Mono path[0] = '/home/Games/SteamLibrary/steamapps/common/Enter the Gungeon/EtG_Data/Managed'
Mono config path = '/home/Games/SteamLibrary/steamapps/common/Enter the Gungeon/EtG_Data/Mono/etc'
Preloaded 'ScreenSelector.so'
Preloaded 'libAkFlanger.so'
Preloaded 'libAkGuitarDistortion.so'
Preloaded 'libAkHarmonizer.so'
Preloaded 'libAkSoundEngine.so'
Preloaded 'libAkStereoDelay.so'
Preloaded 'libAkTremolo.so'
Unable to preload the following plugins:
        ScreenSelector.so
        libAkFlanger.so
        libAkGuitarDistortion.so
        libAkHarmonizer.so
        libAkSoundEngine.so
        libAkStereoDelay.so
        libAkTremolo.so
Logging to /home/damglador/.config/unity3d/Dodge Roll/Enter the Gungeon/Player.log
Failed to hook dlsym, ignoring it. Error: no such function: dlsym
Failed to hook fclose, ignoring it. Error: no such function: fclose
Failed to hook dup2, ignoring it. Error: no such function: dup2
Failed to hook dlsym, ignoring it. Error: no such function: dlsym
Failed to hook fclose, ignoring it. Error: no such function: fclose
Failed to hook dup2, ignoring it. Error: no such function: dup2
 --id --release --
Failed to hook dlsym, ignoring it. Error: no such function: dlsym
Failed to hook dup2, ignoring it. Error: no such function: dup2
lsb_release
FSG  v2.0 prints certain LSB (Linux Standard Base) and
Distribution information.

Failed to hook dlsym, ignoring it. Error: no such function: dlsym
Failed to hook dup2, ignoring it. Error: no such function: dup2
lsb_release
Usage:  [OPTION]...
With no OPTION specified defaults to -v.

Options:
  -v, --version
    Display the version of the LSB specification against which the distribution is compliant.
  -i, --id
    Display the string id of the distributor.
  -d, --description
    Display the single line text description of the distribution.
  -r, --release
    Display the release number of the distribution.
  -c, --codename
    Display the codename according to the distribution release.
  -a, --all
    Display all of the above information.
  -s, --short
    Use short output format for information requested by other options (or version if none).
  -h, --help
    Display this message.
Failed to hook dlsym, ignoring it. Error: no such function: dlsym
Failed to hook fclose, ignoring it. Error: no such function: fclose
Failed to hook dup2, ignoring it. Error: no such function: dup2
Failed to hook dlsym, ignoring it. Error: no such function: dlsym
Failed to hook fclose, ignoring it. Error: no such function: fclose
Failed to hook dup2, ignoring it. Error: no such function: dup2
 --id --release --
Failed to hook dlsym, ignoring it. Error: no such function: dlsym
Failed to hook dup2, ignoring it. Error: no such function: dup2
lsb_release
FSG  v2.0 prints certain LSB (Linux Standard Base) and
Distribution information.

Failed to hook dlsym, ignoring it. Error: no such function: dlsym
Failed to hook dup2, ignoring it. Error: no such function: dup2
lsb_release
Usage:  [OPTION]...
With no OPTION specified defaults to -v.

Options:
  -v, --version
    Display the version of the LSB specification against which the distribution is compliant.
  -i, --id
    Display the string id of the distributor.
  -d, --description
    Display the single line text description of the distribution.
  -r, --release
    Display the release number of the distribution.
  -c, --codename
    Display the codename according to the distribution release.
  -a, --all
    Display all of the above information.
  -s, --short
    Use short output format for information requested by other options (or version if none).
  -h, --help
    Display this message.

Edit: looks like EtG requires the libdoorstop bundled with BepInEx on Thunderstore, but with that version of libdoorstop the script causes a coredump

ebkr · 2025-07-29T07:04:06Z

To run this via Steam it appears that I need to set executable_name before it'll work.

This does introduced a regression and is incompatible with the shared BepInEx package on Thunderstore because we can't set one executable name that works across all games. (EG: Valheim, Lethal League Blaze, etc)

I understand if this is required before we launch, but can we add a check for the first argument to see if it's something along the lines of --executable-name and pull it out from the following argument?

Immediately backing out when no executable name is defined in the script makes this entire part redundant:

# Handle first param being executable name
if [ -x "$1" ] ; then
    executable_name="$1"
    shift
fi

Unless it's fine to have any string in the executable name? Feels wrong though.

arrowmaster · 2025-07-29T08:52:48Z

Immediately backing out when no executable name is defined in the script makes this entire part redundant:

That section is checking if $1 is a file that exists and has the executable bit set in the filesystem permissions as per https://pubs.opengroup.org/onlinepubs/009604399/utilities/test.html. It is not checking that $1 has a value

To run this via Steam it appears that I need to set executable_name before it'll work.
Unless it's fine to have any string in the executable name? Feels wrong though.

Right now I rewrote it to use the executable_name set as the filename (ex game.x86_64) and either run that in the current directory, or use executable_name to determine which argument is the absolute path to the game executable as passed by Steam. It needs to know exactly which argument that is for the SteamLaunch section.

So yes this is a regression if there is a package out there that supports multiple games.

This does introduced a regression and is incompatible with the shared BepInEx package on Thunderstore because we can't set one executable name that works across all games. (EG: Valheim, Lethal League Blaze, etc)

Neither of these use a shared package. It looks like Lethal Company, Content Warning, REPO, Sailwind, Ultimate Chicken Horse and some others use a shared package that doesn't include the linux doorstop_libs or a launch script. But of those I've checked so far only Ultimate Chicken Horse has a native linux version on Steam. So I find it unlikely the regression would actually have any impact on linux native games that used to work.

ebkr · 2025-07-29T09:58:13Z

But of those I've checked so far only Ultimate Chicken Horse has a native linux version on Steam. So I find it unlikely the regression would actually have any impact on linux native games that used to work.

That's fair, although if the package is shared with any further communities then we'd need it to work, otherwise it becomes a generic BepInEx-BepInExPack package which only works for UCH on Linux. That then means subsequent games with native Linux support then end up requiring their own BepInEx package.

We can also end up with situations where a game later gets native Linux support, so a shared package then ends up requiring native Linux support.

Damglador · 2025-07-29T18:08:56Z

As an option, the script could try finding a file or an argument with pattern *.$(uname -m), this is what I use as the fallback, if the executable_name is not set it'll try to find *.$(uname -m) in the game directory, and then *.x86_64 and *.x86 just in case. This is from what I understand Unity's default executable naming convention, so it should work for most games, it definitely does for Enter the Gungeon, Valheim, Inscryption and UCH.

But this can be unreliable if a game has something like Editor.x86_64 in it's directory, but that's better than entirely relying on executable_name variable

arrowmaster · 2025-07-29T18:23:46Z

As an option, the script could try finding a file or an argument with pattern *.$(uname -m), this is what I use as the fallback, if the executable_name is not set it'll try to find *.$(uname -m) in the game directory, and then *.x86_64 and *.x86 just in case. This is from what I understand Unity's default executable naming convention, so it should work for most games, it definitely does for Enter the Gungeon, Valheim, Inscryption and UCH.

But this can be unreliable if a game has something like Editor.x86_64 in it's directory, but that's better than entirely relying on executable_name variable

I was thinking about this too. If I only used check for *.x86_64 and *.x86 in the SteamLaunch section to find the argument it could work most of the time. Executable names for every game can be checked on steamdb.info but I don't have a more exhaustive list of Unity games with native linux builds to check against.

The launch script has always required executable_name to be set if launching outside of Steam.

Damglador · 2025-07-29T19:26:24Z

It's better to check for *.$(uname -m) first, since the system can be x86 or x86_64, maybe even aarch64 in the future, and the *.x86_64 and *.x86 are there as fallbacks in case the system is aarch64 (or god forbit risk-v) and uses box64 or alike to run the game or the system is x86_64 and the game only has x86 build. I think this way it's more universal and future-proof and doesn't make it much more complicated.

arrowmaster · 2025-07-29T20:52:22Z

It's better to check for *.$(uname -m)

My thought here is not to try to find the executable on disk but only to find which argument passed by Steam is the executable. Let Steam figure out which executable to pick and so we don't need to handle edge cases like a game only having x86 binary running on x86_64 system. Or a possible future where Valve introduces a compatibility layer for running x86(_64) on aarch64.

The launch script previously needed either executable_name to be set or $1 to be a path to a binary file with the executable permission set. I'm very hesitant to introduce an attempt to locate the binary file on disk as it seems very outside the scope of the original intentions and needs of the launch script.

Sure it would be nice to do everything but if a user doing something more complicated than using Steam and a mod manager, they can probably read some instructions in the rare cases they might need to do some manual setup.

arrowmaster · 2025-08-01T00:38:18Z

I force pushed a new stack of commits so its cleaner to read. The SteamLaunch check now supports executable_name being empty and in that situation checks for *.x86_64 or *.x86.

Updated overview of changes.

Don't output to stdout when not about to exit because of an error.
-~~Make BASEDIR usable earlier such as in the config section.~~
+Resolve target_assembly to an absolute path if not already.
Update the SteamLaunch check with a check that actually works currently and will hopefully be resilient to future changes in Steam.
Preserve spaces in passed arguments so it will not break on games installed to a path with spaces.

Damglador · 2025-08-01T00:49:31Z

┌─[damglador@Parasite][~]
└% '/home/Games/SteamLibrary/steamapps/common/Enter the Gungeon/run.sh' EtG.x86_64 
Please set executable_name to a valid name in a text editor or as the first command line parameter

Did not touch executable_name

It's the same thing that was happening at the beginning, it wants executable in the working directory instead of near the script file

arrowmaster · 2025-08-01T00:55:23Z

┌─[damglador@Parasite][~]
└% '/home/Games/SteamLibrary/steamapps/common/Enter the Gungeon/run.sh' EtG.x86_64 
Please set executable_name to a valid name in a text editor or as the first command line parameter

Did not touch executable_name

You need to pass a path not just a filename, for example ./EtG.x86_64 should work. This has not changed from before.

Damglador · 2025-08-01T01:00:47Z

Nope

┌─[damglador@Parasite][~]
└% /home/Games/SteamLibrary/steamapps/common/Valheim/run.sh ./valheim.x86_64
Please set executable_name to a valid name in a text editor or as the first command line parameter

Also tried it with EtG before, didn't work. But it did even without ./ when it was fixed the first time (probably because I have PATH=. in my shell config)

arrowmaster · 2025-08-01T01:13:13Z

if [ -x "$1" ] ; then
    executable_name="$1"
    shift
fi

if [ -z "${executable_name}" ] || [ ! -x "${executable_name}" ]; then
    echo "Please set executable_name to a valid name in a text editor or as the first command line parameter"
    exit 1
fi

This checks if $1 is a path to a file that both exists and has the executable bit set. I believe if a relative path is used it is relative to $PWD. The next check tests if executable_name is zero length or if its not a path to a file that exists and has the executable bit set. None of this has been changed by this patchset (it was but I changed it back).

@Damglador Either your executable's don't have the executable bit or your attempts to run the script without changing into the directory first are causing the problems.

Damglador · 2025-08-01T01:16:03Z

From good news, I can confirm that it's working with the latest BepInEx release in Valheim in Steam.

And also I think it breaks out of Steam runtime. Steam wrappers are passed where %command% is, and the script basically discards them and calls just the game executable, just like my script does.

For context, arguments with

gamemoderun ~/.config/r2modmanPlus-local/doorstop.sh %command% "-applaunch" "311690" "--doorstop-enable" "true" "--doorstop-target" "/home/damglador/.local/share/com.kesomannen.gale/enter-the-gungeon/profiles/Default/BepInEx/core/BepInEx.Preloader.dll" > EtG.log

in Steam, from the script perspective look like this:

Arg 0 = the script itself
[doorstop.sh] Arg 1 = /home/damglador/.local/share/Steam/ubuntu12_32/steam-launch-wrapper
[doorstop.sh] Arg 2 = --
[doorstop.sh] Arg 3 = /home/damglador/.local/share/Steam/ubuntu12_32/reaper
[doorstop.sh] Arg 4 = SteamLaunch
[doorstop.sh] Arg 5 = AppId=311690
[doorstop.sh] Arg 6 = --
[doorstop.sh] Arg 7 = /home/Games/SteamLibrary/steamapps/common/SteamLinuxRuntime_soldier/_v2-entry-point
[doorstop.sh] Arg 8 = --verb=waitforexitandrun
[doorstop.sh] Arg 9 = --
[doorstop.sh] Arg 10 = /home/Games/SteamLibrary/steamapps/common/SteamLinuxRuntime/scout-on-soldier-entry-point-v2
[doorstop.sh] Arg 11 = --
[doorstop.sh] Arg 12 = /home/Games/SteamLibrary/steamapps/common/Enter the Gungeon/EtG.x86_64
[doorstop.sh] Arg 13 = -applaunch
[doorstop.sh] Arg 14 = 311690
[doorstop.sh] Arg 15 = --doorstop-enable
[doorstop.sh] Arg 16 = true
[doorstop.sh] Arg 17 = --doorstop-target
[doorstop.sh] Arg 18 = /home/damglador/.local/share/com.kesomannen.gale/enter-the-gungeon/profiles/Default/BepInEx/core/BepInEx.Preloader.dll

Damglador · 2025-08-01T01:23:11Z

@arrowmaster

if [ -x "$1" ] ; then
    executable_name="$1"
    shift
fi

On the first line you check if $1 is executable, but if $1 is a relative path, which it should be, it checks in the current working directory instead of $(dirname $0). So if I say EtG.x86_64, it checks in ~/EtG.x86_64 instead of /home/Games/SteamLibrary/steamapps/common/Enter the Gungeon/EtG.x86_64

~~So I think it should be~~

if [ -x "$(dirname $0)/$1" ] ; then
    executable_name="$(dirname $0)/$1"
    shift
fi

~~I think $BASEDIR is the equivalent of $(dirname $0) in the script~~

Looking in $PWD is desirable only in case of launching from Steam, because it sets $PWD to the game directory, and this also allows the script to be in the profile directory in r2modman instead of having to be in the game directory near the script.

~~Though this is also the way the old script does things, why not check both? First $PWD and then fallback to $BASEDIR~~

arrowmaster · 2025-08-01T01:45:36Z

And also I think it breaks out of Steam runtime. Steam wrappers are passed where %command% is, and the script basically discards them and calls just the game executable, just like my script does.

No, that should not be possible with the logic. I believe you are interpreting something incorrectly or seeing it the 2nd time the script is invoked later in the Steam Runtime and believing it has skipped the runtime. Set STEAM_LINUX_RUNTIME_VERBOSE=1 at the beginning of your Steam launch args and search the log for "Command to run:" and "Running:". Also if you use logsave instead of redirecting to a file you get the entire commandline with arguments at the beginning of the log.

For context, arguments with

gamemoderun ~/.config/r2modmanPlus-local/doorstop.sh %command% "-applaunch" "311690" "--doorstop-enable" "true" "--doorstop-target" "/home/damglador/.local/share/com.kesomannen.gale/enter-the-gungeon/profiles/Default/BepInEx/core/BepInEx.Preloader.dll" > EtG.log

in Steam, from the script perspective look like this:

Arg 0 = the script itself
[doorstop.sh] Arg 1 = /home/damglador/.local/share/Steam/ubuntu12_32/steam-launch-wrapper
[doorstop.sh] Arg 2 = --
[doorstop.sh] Arg 3 = /home/damglador/.local/share/Steam/ubuntu12_32/reaper
[doorstop.sh] Arg 4 = SteamLaunch
[doorstop.sh] Arg 5 = AppId=311690
[doorstop.sh] Arg 6 = --
[doorstop.sh] Arg 7 = /home/Games/SteamLibrary/steamapps/common/SteamLinuxRuntime_soldier/_v2-entry-point
[doorstop.sh] Arg 8 = --verb=waitforexitandrun
[doorstop.sh] Arg 9 = --
[doorstop.sh] Arg 10 = /home/Games/SteamLibrary/steamapps/common/SteamLinuxRuntime/scout-on-soldier-entry-point-v2
[doorstop.sh] Arg 11 = --
[doorstop.sh] Arg 12 = /home/Games/SteamLibrary/steamapps/common/Enter the Gungeon/EtG.x86_64
[doorstop.sh] Arg 13 = -applaunch
[doorstop.sh] Arg 14 = 311690
[doorstop.sh] Arg 15 = --doorstop-enable
[doorstop.sh] Arg 16 = true
[doorstop.sh] Arg 17 = --doorstop-target
[doorstop.sh] Arg 18 = /home/damglador/.local/share/com.kesomannen.gale/enter-the-gungeon/profiles/Default/BepInEx/core/BepInEx.Preloader.dll

This is extremely confusing as I don't know what doorstop.sh is or why you are passing an extra appid.

@arrowmaster
if [ -x "$1" ] ; then
    executable_name="$1"
    shift
fi
On the first line you check if $1 is executable, but if $1 is a relative path, which it should be, it checks in the current working directory instead of $(dirname $0). So if I say EtG.x86_64, it checks in ~/EtG.x86_64 instead of /home/Games/SteamLibrary/steamapps/common/Enter the Gungeon/EtG.x86_64

$1 should NOT be a relative path, Steam passes absolute paths. It just so happens to also work with a path relative to PWD. I did NOT make any changes this section.

So I think it should be
if [ -x "$(dirname $0)/$1" ] ; then
    executable_name="$(dirname $0)/$1"
    shift
fi
I think $BASEDIR is the equivalent of $(dirname $0) in the script

Absolutely incorrect. You are suggesting looking for the executable relative to the location of the script instead of the working directory. If you make this change you break storing mods in a separate directory with mod managers.

Looking in $PWD is desirable only in case of launching from Steam, because it sets $PWD to the game directory, and this also allows the script to be in the profile directory in r2modman instead of having to be in the game directory near the script

Again, Steam passed the executable as an absolute path. This is in your own log above as arg 12. Launching from r2modman invokes Steam which sets PWD to the game directory.

All of your problems are because you are trying to execute the script with the wrong PWD.

Damglador · 2025-08-01T02:13:39Z

I see, I was indeed wrong on the runtime, it does show Command to run: in logsave file. I wonder what are the wrappers for then.

This is extremely confusing as I don't know what doorstop.sh is or why you are passing an extra appid.

Dirty example. Here's a simple script that just shows what is passed in %command%:

#!/bin/sh
i=0
for arg in "$@"; do
    i=$((i + 1))
    echo "Arg $i = $arg" >> args.log
done

Added it to launch arguments for Valheim in Steam as ./getargs.sh %command% and got

Arg 1 = /home/damglador/.local/share/Steam/ubuntu12_32/steam-launch-wrapper
Arg 2 = --
Arg 3 = /home/damglador/.local/share/Steam/ubuntu12_32/reaper
Arg 4 = SteamLaunch
Arg 5 = AppId=892970
Arg 6 = --
Arg 7 = /home/Games/SteamLibrary/steamapps/common/SteamLinuxRuntime_soldier/_v2-entry-point
Arg 8 = --verb=waitforexitandrun
Arg 9 = --
Arg 10 = /home/Games/SteamLibrary/steamapps/common/SteamLinuxRuntime/scout-on-soldier-entry-point-v2
Arg 11 = --
Arg 12 = /home/Games/SteamLibrary/steamapps/common/Valheim/valheim.x86_64

I guess these wrappers are not important?

All of your problems are because you are trying to execute the script with the wrong PWD.

Yeah, it is. Sorry for that.

But there is one regression that caused my confusion. If I set executable_name="EtG.x86_64" in the script from Jul 26 it'll find the executable near it, but the latest version doesn't.

arrowmaster · 2025-08-01T02:45:52Z

I see, I was indeed wrong on the runtime, it does show Command to run: in logsave file. I wonder what are the wrappers for then.

This is extremely confusing as I don't know what doorstop.sh is or why you are passing an extra appid.

Dirty example. Here's a simple script that just shows what is passed in %command%:

The wrappers do two major things, the first is setup a baseline environment using the same shared libraries used by all users of Steam for Linux no matter what distro they are on. In the before times if a game dev compiled their game against the latest non LTS version of Ubuntu that had a new glibc, the game might not launch at all on other distros that had not yet upgraded to use that new version of glibc. Now game devs compile against the shared runtime and we all have it on our systems.

The second is to inject the libraries for the Steam Overlay and some other Steam specific features. This is actually what causes more trouble for us because we need to use the same method to get doorstop loaded but need to avoid stepping on each others toes. I'm using a SteamDeck so I very much don't want to risk breaking the menus or Steam Input.

But there is one regression that caused my confusion. If I set executable_name="EtG.x86_64" in the script from Jul 26 it'll find the executable near it, but the latest version doesn't.

Ah ha. So I actually introduced that new behavior in one patch by moving the checks and then reverted it by not including it in this patchset. If you go back to mainline version it should have the same behavior as my current patchset. So this is not a regression in the PR. I guess maybe the check could be moved lower until after the path has been resolved. I need to think about this.

arrowmaster · 2025-08-08T02:42:37Z

The latest releases of BepInExPack_Valheim are using UnityDoorstop 4.4.0 with a start_game_bepinex.sh script that includes the current changes from this PR.

A small handful of users on Linux have told me that they successfully used script to launch Valheim with mods. I have heard of zero problems so far related to the run script.

ebkr · 2025-08-13T14:45:47Z

I can also confirm that the latest BepInExPack_Valheim release has made things work without the user having to do any additional modification.

ManlyMarco approved these changes Jul 9, 2025

View reviewed changes

arrowmaster mentioned this pull request Jul 24, 2025

[BUG] - Linux native modding doesn't work ebkr/r2modmanPlus#1848

Open

arrowmaster force-pushed the nixscriptfixups branch from 0060443 to 991945d Compare July 25, 2025 22:16

ManlyMarco self-requested a review July 28, 2025 01:06

arrowmaster added 5 commits July 31, 2025 20:11

run.sh: formatting cleanup

2d09eae

run.sh: Don't output to stdout

431d8aa

run.sh: Preserve spaces in passed arguments

7b69019

run.sh: Resolve target_assembly to an absolute path

730400c

run.sh: Update SteamLaunch check with a more futureproof check

245ad5e

arrowmaster force-pushed the nixscriptfixups branch from 8d46b84 to 245ad5e Compare August 1, 2025 00:29

arrowmaster mentioned this pull request Aug 4, 2025

New-ish Steam update broke modded Valheim on Linux BepInEx/BepInEx#1032

Open

ManlyMarco approved these changes Aug 11, 2025

View reviewed changes

Fix many problems with run.sh #74

Are you sure you want to change the base?

Fix many problems with run.sh #74

Uh oh!

Conversation

arrowmaster commented Jul 9, 2025

Uh oh!

arrowmaster commented Jul 9, 2025

Uh oh!

ManlyMarco left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Damglador commented Jul 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ManlyMarco commented Jul 25, 2025

Uh oh!

arrowmaster commented Jul 25, 2025

Uh oh!

Damglador commented Jul 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ebkr commented Jul 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

arrowmaster commented Jul 29, 2025

Uh oh!

ebkr commented Jul 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Damglador commented Jul 29, 2025

Uh oh!

arrowmaster commented Jul 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Damglador commented Jul 29, 2025

Uh oh!

arrowmaster commented Jul 29, 2025

Uh oh!

arrowmaster commented Aug 1, 2025

Uh oh!

Damglador commented Aug 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

arrowmaster commented Aug 1, 2025

Uh oh!

Damglador commented Aug 1, 2025

Uh oh!

arrowmaster commented Aug 1, 2025

Uh oh!

Damglador commented Aug 1, 2025

Uh oh!

Damglador commented Aug 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

arrowmaster commented Aug 1, 2025

Uh oh!

Damglador commented Aug 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

arrowmaster commented Aug 1, 2025

Uh oh!

arrowmaster commented Aug 8, 2025

Uh oh!

ebkr commented Aug 13, 2025

Uh oh!

Uh oh!

ManlyMarco left a comment •

edited

Loading

Damglador commented Jul 24, 2025 •

edited

Loading

Damglador commented Jul 27, 2025 •

edited

Loading

ebkr commented Jul 29, 2025 •

edited

Loading

ebkr commented Jul 29, 2025 •

edited

Loading

arrowmaster commented Jul 29, 2025 •

edited

Loading

Damglador commented Aug 1, 2025 •

edited

Loading

Damglador commented Aug 1, 2025 •

edited

Loading

Damglador commented Aug 1, 2025 •

edited

Loading