Closed 3zet closed 4 months ago
well the XML-RPC interface works just fine, your configs just changed so it doesn't authenticate anymore ? no ?
I'm afraid no, it shows that error after even changing things like server name and/or server description in dedicated_cfg.txt. Hard to say but it may be the issue of text coding? I'm not technical enough so I can only guess.
Just for explanation - For finding this I left default SuperAdmin password, which was simply SuperAdmin.
I'm afraid no, it shows that error after even changing things like server name and/or server description in dedicated_cfg.txt. Hard to say but it may be the issue of text coding? I'm not technical enough so I can only guess.
Just for explanation - For finding this I left default SuperAdmin password, which was simply SuperAdmin.
A couple things this could be caused by:
Hypothesis 1: You're running the game and the server on the same PC and haven't modified the XMLRPC port from the default port 5000. The game exposes its own XMLRPC interface on port 5000, meaning if you start the game before you start the server, the port is already occupied and the server will use port 5001.
Hypothesis 2: Another program is already occupying your defined xmlrpc port.
If neither of those are the culprit, then make sure the server is actually running after you're making those changes to the dedicated_cfg.txt
config file.
Changes to the file require killing/stopping the server and starting it again.
Also, if you're not using the /nodaemon command line argument when starting the dedicated server, make sure you're also stopping/killing all other threads that the dedicated server spawns before you start it again.
Hypothesis 3: If you're running both minicontrol and the dedicated server in a container each, the IP you defined under XMLRPC_HOST
in the .env
file of minicontrol might no longer be the valid IP for the container of the server.
If you're using docker-compose to start both the server and minicontrol in a stack, it's better to use the hostname of the dedicated server container as XMLRPC_HOST
, e.g. tmufserver
.
If all else fails: Double and triple check that the XMLRPC port and the SuperAdmin user and password are the exact same in both the dedicated_cfg.txt and the minicontrol .env file.
I finally found the issue. I always edited config files under linux but for some reason no matter which text editor I used it was doing something to the config files the minicontrol was not able to connect to the server? Is it really a text coding issue?
When I was out of ideas right now I just edited the file using a windows built-in notepad. That helped.
The question is why? I think it should be working despite the OS.
To be honest, troubleshooting this took a way too much time.
I finally found the issue. I always edited config files under linux but for some reason no matter which text editor I used it was doing something to the config files the minicontrol was not able to connect to the server? Is it really a text coding issue?
When I was out of ideas right now I just edited the file using a windows built-in notepad. That helped.
The question is why? I think it should be working despite the OS.
To be honest, troubleshooting this took a way too much time.
Different operating systems use different (combinations of) line ending characters. CR-LF on Windows, LF on Linux, CR on Mac
It must be something else, because it works only when I edit the file on the windows machine and drop it on the server directly, it does not work even when file is replaced (???), only when a new config file is put into directory.
Alright, I finally found what is wrong with minicontrol and I can replicate it.
I tested it on 5 different machines, both native and containers, all of them are behaving the same. OS was different too - I was running servers on Windows 10 and few different Linux distros (Debian 12, Mint 21, Arch) and modifying ANY of the config files ends up with that error.