Closed clarkent86 closed 6 months ago
Oh and I forgot to mention, you can see in my logs that some of the env vars are getting set as program arguments, but not certain ones like SERVER_NAME
. The ones that aren't, like SERVER_NAME
, are getting default values in the .ini and not the values I have set in the environment vars. There just seems to be a disconnect in k3s sourcing the env vars correctly for .ini, but the program arguments are working fine. I am able to connect directly with the set password via environment variables.
When I was looking at the startup scripts, every server control from env vars was startup args. There was no sed
-fu on the .ini
file.
https://github.com/thijsvanloef/palworld-server-docker/blob/main/scripts/start.sh#L25-L26
^ This is how server name is done.
I think I see the issue, the server startup command isn't in quotes, so spaces wouldn't be supported. I'm going to submit a pull request to encapsulate those in quotes. I'll test it first though.
Yup, that was exactly it. For some reason, it's not showing up in Community servers, but it shows up in Recent Servers. When I had spaces it shows as "Them"
Unfortunately it looks like my issue persists. I assumed it was consistent across deployments, but this looks to be a k8s issue vs. docker, specifically k3s running on TrueNAS. There must be some subtle difference in bash versions in how they are handling start.sh and the STARTCMD
. I'll continue to debug.
As an FYI, I have published my personal repo image to docker hub so I can verify directly against what's ran in TrueNAS vs. docker compose...which is what I should've done in the first place. Apologies for my laziness along the way here.
I'm sure this has been fixed by now. His deployment sounds a little different, but I've been running this server on an iX Systems custom docker image on TrueNAS since week 1 of Palworld release and I have no issues. It runs k3s in the background. It sounds like this deployment may be directly k3s instead of via docker, and I imagine there was some misconfiguring or simply the bug has already been fixed.
Update: This comment is based on an outdated image/perhaps previously to iX updating libraries to execute the start script in an updated fashion, or a bug fix that was not communicated back to this issue.
@xHyperElectric If you're going to claim that, please provide evidence, or how you're able to use spaces?
The server runs fine, but it does not allow for spaces in configuration values which should allow them, like the server name or password.
See my above comment that explicitly shows this in the output from the startup script:
2024-01-25 19:40:06.258260-06:00./PalServer.sh -port=10826 -players=16 EpicApp=PalServer -publicip=24.152.167.16 -publicport=8221 -servername=Them Bucky Boys -serverpassword=**** -adminpassword=**** -queryport=27015 -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS
Closing this as @xHyperElectric was correct, spaces are now honored in environment variables.
It's totally possible that iX systems updated their libraries that execute the start script and this was entirely unrelated to any changes here.
For what it's worth, I have also been running this since week 1 of palworld and this was an issue long after. Thanks for bringing it back to my attention to check if the issue persisted, as it does not for one reason or another!
Describe the bug
As directed in the readme, I've updated the environment variables, but/Pal/Saved/Config/LinuxServer/PalWorldSettings.ini continues to show default values.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
I expect the env. var values like SERVER_NAME to populate in PalWorldSettings.ini, but it remains default:
Screenshots
n/a
Desktop (please complete the following information)
docker-compose.yml contents
Container/Host Logs
Additional context
the blank values in the PalWorldSettings.ini were not intentionally removed, that is the state of the file after deleting and rebooting or powering off, deleting, and booting