Heh, we called it in Discord. Glad to hear you figured it out.
It may be the case that your previous server was on a DMZ (unfiltered) port or your setup somehow enabled uPnP.
Heh, we called it in Discord. Glad to hear you figured it out.
It may be the case that your previous server was on a DMZ (unfiltered) port or your setup somehow enabled uPnP.
Pistakilla Thank you for that as well but I'm still seeing the same behavior.
Absent on launch, present on the second rotation.
(I've verified the script is present and the variable isn't otherwise set in my server.cfg or launch command arguments)
Pistakilla Thank you for this.
I can confirm that option works without the previous GSC script being present in my container images. However, it does NOT work at first if the first map on the server is kino.
Much like the screen shots above show, the first time a server boots (starting at kino) there won't be mule kick. But if the server rotates BACK to kino the mule kick is present.
So it almost seems that this dvar isn't being read/processed on server initialization but is when a server is switching maps.
To provide additional context: These screenshots are taken 2 days apart on different instances using the same base docker image with a "Activate_Mulekick" gsc script embedded.
Edit 2: So it turns out even with the above script Mule Kick will still fail to show up every time.
I've currently got 7 BO1 instances with 4 of them featuring Kino in their map rotations.
Last night I noticed it working on one but this morning on that same instance (since restarted) it's gone.
My severs are docker images so they're all using the same base with the above script embedded. Mule kick on kino is just buggy.
Never mind. I just noticed it was active on one of my instances. Thank you!
CodWawer I'm not sure if this is your exact issue as I got my game files from steam and my folder structure is different but in order to get t4sp working in my plutonium server Docker image I did have to rename localized_common_mp.ff to localized_common.ff.
After making this change my t4sp servers run as expected. I have not tested anything other than zombies, however.
JordanTheDev Were you able to get this to work? As written it doesn't for me.
I figured this out with the help of this post.
In essence T6 servers need to read the configuration out of <game_root>/main/, a directory that doesn't exist by default (but did/does for t5).
Making that directory and adding my .cfg files there allows my Docker image to run t6 servers.
I've updated the repo with this solution as well. (mkdir -p /home/pu/games/pluto_t6_dedicated_server_full/main)
Hello,
I've been working on my own plutonium-in-docker solution because I wanted an image that could be used generically rather than requiring pterodactyl or other such tool and have thus far only been able to get t5sp (BO1 zombies) working.
No matter what argument I try, the working directory I start in, nor which version of T6 I build into the image (pluto_t6_full_game, pluto_t6_dedicated_server_full) attempting to start t6zm always returns the error "config file %s not found" without any reflection of the path I gave it. (T5 will fail and tell you it can't find the configuration file in /home/pu/pluto_t5_full_game/main for example)
This is the repo: https://git.bodybychipotle.com/bodybychipotle.com/plutonium-server-docker
This is the helper script that actually launches the servers:
(Another reason I built my own images. The script will kill the server if the logs indicate it's in a bad state - EXE_ERROR_MODIFYING_SESSION, thus auto-restarting the server)
The launch command: /usr/bin/xvfb-run -a wine bin/plutonium-bootstrapper-win32.exe t6zm/home/pu/games/pluto_t6_dedicated_server_full -dedicated +set key X7X6S +set fs_game '' +set net_port 28969 +start_map_rotate +set sv_config t6zm.cfg
As stated this works for T5, just not T6 yet. (edited)