Devidian
Load World Path is Incorrect
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 <LoadWorld> 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
Hi, yeha it cant create an instance by itself. You have to upload a previously created instance.
You should copy your instances to /mnt/NAS2/Storage/servers/space-engineers/instances so in your case /mnt/NAS2/Storage/servers/space-engineers/instances/GamerPlace which content should look like
If you spin up the server the entrypoint.sh that will do all install and stuff will also replace the <LoadWorld> because the container cant run with the windows original path.
It takes the worldname from <WorldName> so if your path is wrong you have to edit <WorldName>
I hope that helps.
I wish it did, but alas I copied it correctly the first time. The way this container forces to look for:
<LoadWorld>Z:\appdata\space-engineers\instances\GamerPlace\Saves\ComeOnAndSlam\</LoadWorld>
instead of:
<LoadWorld>Z:\appdata\space-engineers\instances\GamerPlace\Saves\ComeOnAndSlam\Worlds\Sandbox.sbc</LoadWorld>
has made for a somewhat frustrating experience that prevents the game from loading.
I've never messed with an entrypoint.sh but I might just try and correct this issue.
Will \Worlds\Sandbox.sbc be added to the entrypoint.sh to support newer saves?
Sorry i was very busy, i will check out a new save and check what has to be done, as soon as i can spent some time!
No worries!
In the meantime I've found the work-around was to dump the contents of : /##InstanceName##/Worlds/
to just /##InstanceName##/
Then it'll finally load the Sandbox.sbc on it's own. This might only be applicable to PC or Scenario saves.