How to proceed with version upgrade with fixes?

[xcoldfyrex]

This is mostly for @mmmaxwwwell or whoever else might know.

I've created a new image version, based on Debian Bullseye which introduces numerous bugfixes, stability improvements, and enhancements. Here is the tl;dr:

• Debian Bullseye
• Wine 7
• Numerous console warnings have been fixed
• Implemented support for different users
• Appears to be far fewer server crashes
• Mod downloads work out of the box, no .so or dll files to copy around

Is the the author still active on this project/wanting to merge these in(asking before I submit a PR) or shall I just proceed with a cloned fork on my own repo? I'm happy to do either.

[mmmaxwwwell]

I was, I kid you not, today, setting up my computers to update this thing. Its set up to autobuild using github actions and to publish to docker, so lets get the changes on a branch and then we'll figure out how to merge them to main.

[xcoldfyrex]

I don't appear to have permissions to push my branch

[mmmaxwwwell]

I created a v2 branch, can you make a PR to there?

[xcoldfyrex]

Negative, still lacking perms it seems

[xcoldfyrex]

It worked! https://github.com/mmmaxwwwell/space-engineers-dedicated-docker-linux/pull/59

[mmmaxwwwell]

Awesome, theres a few things I want to change about the container.

• Originally I wanted to use bind mounts to mount the appdata folder right into the container, but it looks like there is some kind of performance overhead using that instead of volume mounts. this also means the startup script will have to change.
• Same thing for port forwarding instead of using host ports, i think theres a performance impact.
• I think the dockerhub keys are probably expired, its been over a year since I built this, and theres probably a new pattern anyways.
• I want to provide a nice script for the not-tech-savvy users to upgrade.

[mmmaxwwwell]

i just bricked my build server, so i'll be reformatting that now

[xcoldfyrex]

Awesome, theres a few things I want to change about the container.

* Originally I wanted to use bind mounts to mount the appdata folder right into the container, but it looks like there is some kind of performance overhead using that instead of volume mounts. this also means the startup script will have to change.

* Same thing for port forwarding instead of using host ports, i think theres a performance impact.

* I think the dockerhub keys are probably expired, its been over a year since I built this, and theres probably a new pattern anyways.

* I want to provide a nice script for the not-tech-savvy users to upgrade.

How substantial are the performance impacts(will end users notice)?

[mmmaxwwwell]

I didn't benchmark anything so its all anecdotal, but I think it was pretty substantial

[mmmaxwwwell]

I got some time to look at this, and was trying to move the bind mounts to volume mounts. Check out the v2_volumes branch. I'm messing something up, and its causing steamcmd to fail when installing the DS, complaining about missing shared libs. I'm going to go back and implement the changes more slowly and see where the install starts to fail to troubleshoot.

We should have the config and bins stored in volume mounts instead of bind mounts. I think it will improve performance, and also resolve some issues around permissions and stability. You can see what I'm getting at if you look at the docker-compose.yml on that branch, specifically the mounts.

Just wanted to say that this isn't forgotten, and give you an update to where we're at.

[mmmaxwwwell]

It appears that I didn't introduce the issue, I'm getting the same thing before moving anything around.

Waiting for client config...OK
Waiting for user info...OK
"@sSteamCmdForcePlatformType" = "windows"
Success! App '298740' already up to date.
Starting Server..
/entrypoint-space_engineers.bash: line 4: cd: /appdata/space-engineers/SpaceEngineersDedicated/DedicatedServer64/: No such file or directory
wine: failed to open "/appdata/space-engineers/SpaceEngineersDedicated/DedicatedServer64/SpaceEngineersDedicated.exe": c0000135
Exiting Server Process..
WARNING: setlocale('en_US.UTF-8') failed, using locale: 'C'. International characters may not work.
Redirecting stderr to '/home/wine/Steam/logs/stderr.txt'
[  0%] Checking for available updates...
[----] Verifying installation...
Steam Console Client (c) Valve Corporation - version 1687387651
-- type 'quit' to exit --
Loading Steam API...dlmopen steamservice.so failed: steamservice.so: cannot open shared object file: No such file or directory
dlmopen libSDL3.so.0 failed: libSDL3.so.0: cannot open shared object file: No such file or directory
OK```

[xcoldfyrex]

It appears that I didn't introduce the issue, I'm getting the same thing before moving anything around.

Waiting for client config...OK
Waiting for user info...OK
"@sSteamCmdForcePlatformType" = "windows"
Success! App '298740' already up to date.
Starting Server..
/entrypoint-space_engineers.bash: line 4: cd: /appdata/space-engineers/SpaceEngineersDedicated/DedicatedServer64/: No such file or directory
wine: failed to open "/appdata/space-engineers/SpaceEngineersDedicated/DedicatedServer64/SpaceEngineersDedicated.exe": c0000135
Exiting Server Process..
WARNING: setlocale('en_US.UTF-8') failed, using locale: 'C'. International characters may not work.
Redirecting stderr to '/home/wine/Steam/logs/stderr.txt'
[  0%] Checking for available updates...
[----] Verifying installation...
Steam Console Client (c) Valve Corporation - version 1687387651
-- type 'quit' to exit --
Loading Steam API...dlmopen steamservice.so failed: steamservice.so: cannot open shared object file: No such file or directory
dlmopen libSDL3.so.0 failed: libSDL3.so.0: cannot open shared object file: No such file or directory
OK```

What OS are you testing this on? I have never seen this.

[mmmaxwwwell]

I'm running nixOS, looks like it was nothing, just a warning. I was waiting for output and my laptop just took a lot longer than expected.

[mmmaxwwwell]

I got the changes you made plus the changes I was thinking of on the v2 branch, but I had to rewrite the history, my bad. You'll have to delete the branch locally and re-pull it, I moved your changes to v2_xcoldfyrex.

[mmmaxwwwell]

Doing performance testing now, if you want to take a look at what I put in with the pack/unpack stuff I'd love that.

[mmmaxwwwell]

And heads up, the v2 branch is set to auto build to docker hub.

[xcoldfyrex]

Doing performance testing now, if you want to take a look at what I put in with the pack/unpack stuff I'd love that.

Sure, I'll peek more tomorrow and let you know.

[xcoldfyrex]

Before I start hacking at things, I want to raise this in the event you have code not checked in or your local env is different:

• Now I need sudo when running start due to permissions needed by podman(I did not drill down why)
• Upon running setup, followed by building and startup, startup fails with

  podman logs -f space-engineers-dedicated-docker-linux
  World folder does not exist, exiting
  World folder does not exist, exiting
  ...

  as entrypoint is still checking for /appdata/space-engineers/World/World, but nothing is creating appdata. Other than that, I like the layout of the volumes in the configuration that are defined, it looks much cleaner.

[mmmaxwwwell]

Your user needs to be in the podman or docker group, I think I messed up the loadworld replace command, I'll fix it today.

[mmmaxwwwell]

closing this, thank you for your contributions, they are pulled into the v2 branch and will make it to main when I get to it.