Old SchoolOps

Configuration

What each setting in settings.cfg does, which port your game uses, and how to open a server to the outside world.

For Every Game Updated 2026-08-23

The File

settings.cfg sits at the root of the archive on the RF releases, and in server/ on Gate to Heavens and Gate to Heavens Classic. It is grouped into sections in square brackets, one setting per line, name and value separated by whitespace. Anything after // is a comment.

[gameserver]
SERVICE_IP      0.0.0.0
SERVICE_PORT    27800
MAX_SESSIONS    500

[database]
DATABASE_PROVIDER   sqlite
DATABASE_PATH       ./db

The server reads it once at start. Change something, restart.

The Settings You Will Actually Touch

SERVICE_IP

Which network address to accept connections on.

  • 0.0.0.0 (the default) means every address on the machine, which is what you want for a server other people connect to.
  • 127.0.0.1 means only this machine. Useful while you are testing, because nothing outside can reach it even if your firewall is open.

Do not put your public IP here unless you know why you are doing it. 0.0.0.0 already covers it, and a hardcoded address breaks the moment your ISP changes it.

SERVICE_PORT

The port players connect to. It has a per-game default that matches what the original client expects, and you should leave it alone unless you are running more than one game on one machine.

GamePortTransport
Gate to Heavens36000 login, 36001 gameUDP
Gate to Heavens Classic26000 login, 26001 gameUDP
RF Online 1.0527770TCP
RF Online (Giga 4 Part 2)27780TCP
RF Online: Red Army27790TCP
RF Online: Secret of Holystone27795TCP
RF Online: Golden Age27800TCP

Changing it means telling your players, and for RF it means editing the launcher’s own launcher.ini so it points at the right place.

MAX_SESSIONS (the RF releases only)

How many players may be connected at once. 0 means unlimited. The default of 500 is far above what a home connection will do anyway; it exists so a runaway loop cannot exhaust the machine.

The two Gate to Heavens servers have no session cap setting today. The key is not in their settings.cfg and putting it there does nothing.

The Database Section

Covered in full on the database page. The short version: leave it alone and you get a file-based database that needs nothing installed.

SUPER_PASSWORD (the RF releases only)

The one setting you do not write. The website writes it, under [webserver], and only while this game has no Super Administrator account:

[webserver]
SUPER_PASSWORD  7Rk9fQ2mTxb4Vn6PjWs3Zhc5

It is a one-time bootstrap password. Sign in on your own site with any email address and this value in place of the password, and that account becomes staff. The line is blanked the moment it is used, and a new one is generated on the next start if nobody was promoted. An empty value signs nobody in.

The server writes the value itself, twenty-four characters from an alphabet with no lookalikes in it, so nothing in it can be mistaken for something else when you retype it. A value shorter than twenty characters is ignored without being compared, which means a hand-written one is very likely to sign nobody in at all. There is no reason to write your own.

The two Gate to Heavens releases have no such key. Their website carries no control panel, so it never writes one, and their first grant is made with the tool instead.

If you find a value here on a server that already has staff, or you need the whole flow, read GM accounts.

Opening the Server to Other People

Three things have to be true, and they fail in this order.

  1. The server is listening. SERVICE_IP is 0.0.0.0, and the log says it is listening on your port.
  2. The machine’s firewall allows it. On Windows this is an inbound rule for the port, for the right protocol. Getting TCP and UDP the wrong way round is the single most common mistake, and the table above says which each game uses.
  3. Your router forwards it. Port forwarding to the machine’s local address, same port, same protocol.

Test from outside your own network, not from the same machine. A server that works locally and fails from outside has passed step one and failed two or three, and testing locally cannot tell you which.

Running More Than One Game on One Machine

Every game has its own port, its own database and its own directory, so they coexist without any special configuration. Extract each archive somewhere separate and start each one.

Pointing two different games at the same DATABASE_PATH is fine, and it is worth doing. The directory holds one file per database, and the names are what keep them apart: each game keeps its own gommo_<game> and its content database to itself, while the accounts database is called gommo_accounts in every game. Share the directory and the two servers share that one file, so a player registers once and logs into both, and the staff tool can see the grants for both. Keep the directories apart and each game gets a private accounts file, which is the thing that surprises people: the same email address becomes two unrelated accounts.

The caution worth keeping is the other one. Do not point two copies of the same game at one DATABASE_PATH. Two servers writing one game database is not something the game expects.