Troubleshooting

Start with the Log

Every server writes to logs/ beside itself, and to the console. Almost every question below is answered in the first twenty lines of a start-up log, which report the port it bound, the database it opened and how much content data it loaded.

If you are going to ask for help, have that. “It does not work” and the first twenty lines of the log are very different questions.

The Server Exits Immediately

Something else is on the port. The log says so. Either stop the other thing or change SERVICE_PORT. On Windows this is often a previous copy of the same server that did not exit.

It cannot write where it is. If you extracted into Program Files or another protected directory, the database and log files fail to open. Move the whole directory somewhere you own.

The Server Starts but Reports Zero Monsters

The content data did not import. The server keeps running because an empty world is still a world, but nothing will spawn.

On a first run this usually means the archive was extracted incompletely, or extracted with a tool that skipped the large data file. Re-extract the whole archive.

If you switched to MySQL, check that the content database name in settings.cfg matches the one the schema created. A mismatch is not an error: the server opens a database that exists and is empty, and there is nothing for it to complain about.

Players Cannot Connect from Outside

Work through these in order, because each one makes the next testable.

1. From the server machine itself. If the client cannot connect to 127.0.0.1, nothing else matters and the problem is the server or the client version.
2. From another machine on the same network, using the server’s local address. Failing here means the machine’s firewall. Check the protocol: the GTH games are UDP and the RF games are TCP, and a rule for the wrong one looks exactly like a rule that is not there.
3. From outside, using your public address. Failing only here means port forwarding.

Test from a phone on mobile data rather than from your own network. A router that reflects traffic back to itself will make step three appear to pass when it has not.

The Client Connects and Then Drops

Almost always a version mismatch: a client for one version of the game talking to a server for another. The server logs the version it expects. The two RF Episode 2 releases in particular look similar and are not interchangeable.

The second cause is stale client files. If you have patched your client/ directory, a player running the old files may get far enough to connect and then fail on the first message that changed shape.

The Launcher Says the Server Is Offline

The launcher asks the server directly, so this is a real answer rather than a guess. Either the server is not running, or the launcher is pointed somewhere else.

Check launcher.ini beside the launcher: it holds the address and it is the file to edit if you changed the port. A launcher that says offline against a server you can see running is nearly always pointed at the wrong host.

The Website Shows the Game Offline While the Game Is Up

The website reads a status channel on the loopback address of the machine it is running on. If the website and the game server are on different machines, it cannot reach it, and reporting offline is the correct answer to the question it can actually ask.

Run both on the same machine, which is what the archive assumes.

Accounts Do Not Work Between the Launcher and the Website

They share one database, so this means they are not looking at the same one. Check that both are started from the same directory, or that both point at the same DATABASE_PATH or MySQL host. A relative database path resolves against the directory a program was started in, so launching one of them by double-clicking from somewhere else can silently open a second, empty database.

Where to Ask

Discord. Bring the version you are running, which we stamp into every archive name and print in the server log, and the first twenty lines of that log.