Fix for multiple containers on a single host

[merriry]

Once 1.0.1.1 was released and the server container started to work, I quickly found that getting more than one server to run did not work. Using:

http://api.steampowered.com/ISteamApps/GetServersAtAddress/v0001/?format=json&addr=IP_HERE

Along with a couple dedicated servers on a windows box helped me to understand that steamworks uses the configured port in server.cfg to report which port the server is running, as well as which port it is using to communicate with steamworks. I tried using configs that looked similar to this on the windows box:

sv_port 27015; steam_server_query_port 26990; steam_server_steam_port 26991;

and this on the second:

sv_port 27015; steam_server_query_port 26992; steam_server_steam_port 26993;

after they started up you could see both servers in the browser, however when you tried to connect it would crash the game. Example of the response I got for my server with this configuration:

{"response":{"success":true,"servers":[{"addr":"XXX.XXX.XXX.XXX:26990","gmsindex":65534,"appid":632360,"gamedir":"Risk of Rain 2","region":-1,"secure":true,"lan":false,"gameport":27015,"specport":0},{"addr":"65.49.84.186:26992","gmsindex":65534,"appid":632360,"gamedir":"Risk of Rain 2","region":-1,"secure":true,"lan":false,"gameport":27015,"specport":0}]}}

I then tried it with the configs looking like this:

sv_port 26901; steam_server_query_port 26911; steam_server_steam_port 0;

and

sv_port 26902; steam_server_query_port 26912; steam_server_steam_port 0;

and got:

{"response":{"success":true,"servers":[{"addr":"XXX.XXX.XXX.XXX:26911","gmsindex":65534,"appid":632360,"gamedir":"Risk of Rain 2","region":-1,"secure":true,"lan":false,"gameport":26901,"specport":0},{"addr":"65.49.84.186:26912","gmsindex":65534,"appid":632360,"gamedir":"Risk of Rain 2","region":-1,"secure":true,"lan":false,"gameport":26902,"specport":0}]}}

I was also able to connect and play on both of them.

I then edited the dockerfile and the default_config with some additional env variables to make it possible to set the sv port and query port and then started up containers with:

docker run -d -p 26901:26901/udp -p 26911:26911/udp -p 26911:26911/tcp --name ror2server -e R2_HOSTNAME="Cool Server" -e R2_HEARTBEAT=1 -e R2_PLAYERS=8 -e R2_SV_PORT=26901 -e R2_QUERY_PORT=26911 ror2serverry:latest and docker run -d -p 26902:26902/udp -p 26912:26912/udp -p 26912:26912/tcp --name ror2server -e R2_HOSTNAME="Cool Server 2" -e R2_HEARTBEAT=1 -e R2_PLAYERS=8 -e R2_SV_PORT=26901 -e R2_QUERY_PORT=26911 ror2serverry:latest

(ror2serverry was a local image build after the edits) and was able to connect and play on both of them. I then spun up 10 and all 10 worked as well.

I know this is not how Docker is supposed to work, but the server doesn't seem to like the Docker way at all.

[avivace]

Oh hey, great explanation!

First of all: if you are on Windows, you probably don't want to use this Docker image, as it sets up Wine a virtual framebuffer to run the server on Linux. If you're on Windows, it's probably more performant to not use Wine and directly run the Windows executables. Maybe we can think about providing another Docker image based on Windows without Wine.

About supporting multiple instances of the server on the same IP: exposing the Query port and SV variables makes sense, but I don't want this niche use case to make things harder and commands longer for everyone else.

This doesn't seem the case, as you will want to specify the SV port only when setting a non-default one, but I'll wait for some feedback from the other mantainers.

Last thing: you seem to have forked from an old commit, and the README.md changes are conflicting with a recent rewrite I did. Are you willing to add the changes on the last commit?

Thanks for your useful (documented) troubleshooting and your contribution!

[merriry]

I am running it on Linux, I was just using windows to figure out what was going on since I could get the DS downloaded from Steam to work with multiple copies on windows. I forked your code yesterday evening, You had to go and commit it today?! ;) I put defaults for all the values in the ENV variables, so if you just want to run one, or run one that doesn't talk to steam on some random port using -p 25000:27015/udp it still works great. As far as usability goes:

docker run -p 25000:27015/udp avivace/ror2server:latest still works docker run -p 27015:27015/udp avivace/ror2server:latest still works docker run -p 27015:27015/udp -p 27016:27016 -e R2_HEARTBEAT=1 -e R2_HOSTNAME="Hostname" avivace/ror2server:latest still works docker run -p 25000:27015/udp -p 27016:27016 -e R2_HEARTBEAT=1 -e R2_HOSTNAME="Hostname" avivace/ror2server:latest does not work and will not work with how the container is now docker run -p 27015:27015/udp -p 25001:27016 -e R2_HEARTBEAT=1 -e R2_HOSTNAME="Hostname" avivace/ror2server:latest does not work and will not work with how the container is now docker run -p 25000:27015/udp -p 25001:27016 -e R2_HEARTBEAT=1 -e R2_HOSTNAME="Hostname" avivace/ror2server:latest does not work and will not work with how the container is now

The only time you actually need to use the new env variables is if you want to change the steam and game ports to non-standard ports and have it still show up in the server browser. Because steamworks uses the configured ports in server.cfg for advertisement, you can't -p 25000:27015 on any container and have it work in the server browser. It still definitely works with connect "IP:PORT" in the game console.

The docker command EXPOSE is optional and just tells us which ports it is expecting to be mapped, it doesn't actually map them, so I expose the env variables to remind me what the mapped ports should be. I cannot think of a better way to get the steamworks services working properly on a non-standard port or multiple instances of the container. Personally I would love to only change exposed ports and have it be happy... but we can't do that.

[merriry]

I recommited readme. Your rewrite today is very well done, so I just took it and inserted the additional env variables, and rewrote my explanations. I found another typo in it too. your example mods docker command still had R2_ENABLE_MODS=true in it.

[InfernalPlacebo]

I was able to test fork on a server of mine and got it working as intended with the instructions from merriry.