When spinning up this docker file, I found it quite simple until it was unable to make it's own empty save.
Easy enough, download the 1~ish gb dedicated server and make a new save. I find nothing talking about what I should copy to the instance folder, just that I should copy "the instance directory" over. So I copy over the entire instance, sweet. Ready to go, spin up the docker image, I see the settings take, and it immediately quits after saying it's unable to load checkpoints.
After looking at this readout of the configuration I notice the save path definitely does not look like:
Z:\appdata\space-engineers\instances\GamerPlace\Saves\ComeOnAndSlam, so I chalk that up to a wine-ism. I move onto the debug.
I look over the debug log, it shows me nothing really except that the checkpoints failed. I guess I don't have some sort of logging enabled. Log file for reference:
SpaceEngineersDedicated_20240920_141604794.log
I start comparing the two configuration files and notice has been updated to reflect the Z: Drive:
<LoadWorld>Z:\appdata\space-engineers\instances\GamerPlace\Saves\ComeOnAndSlam\</LoadWorld>
But when compared to the original one from my local machine, it's missing an additional directory and file now.
<LoadWorld>C:\Users\Binary\AppData\Roaming\SpaceEngineersDedicated\Saves\ComeOnAndSlam\Worlds\Sandbox.sbc</LoadWorld>
Trying to add the \Worlds\Sandbox.sbc to the configuration in the docker binds causes it to be constantly reset to the incorrect path.
I can take away the permissions to edit this file but that seems somewhat hacky, is this the intended experience?
se-server:
image: devidian/spaceengineers:winestaging
container_name: se-ds-docker
restart: unless-stopped
volumes:
# left side: your docker-host machine
# right side: the paths in the image (!!do not change!!)
- /mnt/NAS2/Storage/servers/space-engineers/plugins:/appdata/space-engineers/plugins
- /mnt/NAS2/Storage/servers/space-engineers/instances:/appdata/space-engineers/instances
- /mnt/NAS2/Storage/servers/space-engineers/SpaceEngineersDedicated:/appdata/space-engineers/SpaceEngineersDedicated
- /mnt/NAS2/Storage/servers/space-engineers/steamcmd:/root/.steam
ports:
- target: 27016
published: 27016
protocol: udp
mode: host
environment:
- WINEDEBUG=-all
- INSTANCE_NAME=GamerPlace
- PUBLIC_IP=1.2.3.4
# public ip required for healthcheck
When spinning up this docker file, I found it quite simple until it was unable to make it's own empty save.
Easy enough, download the 1~ish gb dedicated server and make a new save. I find nothing talking about what I should copy to the instance folder, just that I should copy "the instance directory" over. So I copy over the entire instance, sweet. Ready to go, spin up the docker image, I see the settings take, and it immediately quits after saying it's unable to load checkpoints.
After looking at this readout of the configuration I notice the save path definitely does not look like:
Z:\appdata\space-engineers\instances\GamerPlace\Saves\ComeOnAndSlam, so I chalk that up to a wine-ism. I move onto the debug.
I look over the debug log, it shows me nothing really except that the checkpoints failed. I guess I don't have some sort of logging enabled. Log file for reference:
SpaceEngineersDedicated_20240920_141604794.log
I start comparing the two configuration files and notice has been updated to reflect the Z: Drive:
<LoadWorld>Z:\appdata\space-engineers\instances\GamerPlace\Saves\ComeOnAndSlam\</LoadWorld>But when compared to the original one from my local machine, it's missing an additional directory and file now.
<LoadWorld>C:\Users\Binary\AppData\Roaming\SpaceEngineersDedicated\Saves\ComeOnAndSlam\Worlds\Sandbox.sbc</LoadWorld>Trying to add the \Worlds\Sandbox.sbc to the configuration in the docker binds causes it to be constantly reset to the incorrect path.
I can take away the permissions to edit this file but that seems somewhat hacky, is this the intended experience?