RE:NODE

Guides12 min read

OpenTTD server: openttd.cfg, network, AI

Run an OpenTTD dedicated server: openttd -D, the network settings in openttd.cfg, invite codes, ports 3979 and 3977, rcon, AI companies, NewGRFs and autosaves.

0 readers

An OpenTTD dedicated server is the normal game binary started with -D: openttd -D runs a headless server that loads or generates a map and waits for players. Everything else is openttd.cfg - map size and economy in the game sections, and the server's name, slots, visibility and ports in [network] - with passwords kept in a separate secrets.cfg in current versions. The server listens on port 3979 (TCP and UDP) for players and optionally 3977 (TCP) for admin tools. It is tiny: a few hundred megabytes of memory and one core run a normal map for a dozen players. What takes thought is the rest - how companies are protected, when old ones are cleaned up, which AIs and NewGRFs to load, and how often to save.

How OpenTTD multiplayer works#

OpenTTD multiplayer is a lockstep simulation. Every client runs the full game and the server keeps them in agreement by distributing player commands; the server is the authority on the order of those commands and the source of the save that new players download when they join. Some consequences:

  • Joining downloads the whole map. A new player receives the current savegame from the server. On a big, mature map that is a noticeable wait.
  • Clients must have the same NewGRFs and game scripts. The server tells the client what it needs, and the client fetches anything available from the online content service before joining.
  • Every client simulates everything. A map that runs slowly on a player's PC is slow for them in multiplayer too, whatever the server's hardware.
  • Desyncs - a client whose simulation drifts from the server's - are disconnected. They are rare in current versions and usually point to mismatched content or a buggy script.

Players are grouped into companies. Several players can share one company, each company has its own money and network, and spectators can watch without a company. A server usually allows up to 15 companies and more clients than companies, so friends can co-operate in one company or compete in several.

Co-op, competitive or goal servers

OpenTTD servers tend to fall into three styles, and the settings follow from the style rather than the other way round.

A co-op server puts a group of friends into one company, building a single network together. It needs few slots, generous money settings, breakdowns to taste, and a large enough map for the network to grow into over weeks. The main risk is two people rebuilding the same junction at once, which is a conversation rather than a setting.

A competitive server gives each player or team their own company on a shared map, racing for the best routes and the highest company value. It needs a map sized to the player count - big enough that companies are not boxed in on day one, small enough that they meet and compete - clear rules on blocking other companies' tracks, and a reset policy so a runaway leader does not end the fun for everyone else.

A goal server uses a game script to set shared or competing targets - deliver a certain amount of cargo, grow a town to a certain size - and resets when someone wins. Goal servers are the easiest to keep populated as public servers, because every round has a clear ending and new players can join at the start of the next one.

Whichever you run, write the rules down and put a link in the server name or description. Most arguments on OpenTTD servers are about track blocking and station spreading, and both are much easier to settle with a rule written before the game began.

Requirements and resource usage#

OpenTTD is one of the cheapest servers you can run. Map size and the number of vehicles set the cost; players barely do.

MapRAMCPUNotes
256x256, up to 8 players256-512 MB1 coreSmall casual game
512x512 or 1024x512, up to 16512 MB-1 GB1 fast coreTypical community server
1024x1024, many vehicles1-2 GB1 fast coreLarge network games
2048+ maps, thousands of vehicles2 GB+1 very fast coreClients struggle before the server does
  • CPU: the simulation is essentially single-threaded. Clock speed is everything. Because every client runs the same simulation, the practical ceiling is the slowest player's PC, not the server.
  • Disk: negligible - the game and a few saves fit in under a gigabyte, plus whatever NewGRF and AI content you download.
  • Network: light during play, heavier when a player joins and downloads the map.

Large maps are where most servers go wrong. A 4096x4096 map sounds generous, but it takes a long time to send to joining players, autosaves take longer, and late in the game clients with weaker PCs lag behind.

Starting a dedicated server#

On Linux, install OpenTTD from the official downloads or your distribution, together with a base graphics set - OpenGFX is the free one, and depending on version the game may refuse to start without a base set even as a dedicated server. Then:

bash
$ openttd -D$ openttd -D 0.0.0.0:3979$ openttd -D -g mysave.sav

The useful command-line options:

OptionWhat it does
-D [host][:port]Run as a dedicated server, optionally binding an address and port
-g [savegame]Load a savegame, or start a new game if none is given
-c <file>Use a specific config file
-G <seed>Generate the map with this seed
-xDo not save configuration changes on exit
-d [level]Debug output, useful for diagnosing desyncs and script errors

Without -g, the server generates a new map from the settings in openttd.cfg. With -g, it loads a save - which is also how you move a single-player game onto a server.

On first start, OpenTTD writes its config to the user configuration folder. On Linux that is ~/.config/openttd/ in current versions, with saves and downloaded content under ~/.local/share/openttd/; older versions used ~/.openttd/ for both. On a game panel, these all live in the server's own folder. Stop the server before editing - OpenTTD writes its settings back on exit, unless you started it with -x.

openttd.cfg: the network section#

openttd.cfg is an ini file with dozens of sections. For a server, [network] is the one that matters:

openttd.cfg
[network]server_name = Northern Rail Co-opserver_game_type = publicserver_port = 3979server_admin_port = 3977max_clients = 25max_companies = 15autoclean_companies = trueautoclean_protected = 12autoclean_unprotected = 2min_active_clients = 0pause_on_join = truerestart_game_year = 0
SettingWhat it does
server_nameName in the server list
server_game_typelocal, invite-only or public
server_portGame port, TCP and UDP, default 3979
server_admin_portAdmin port for tools, TCP, default 3977
max_clientsConnected players including spectators
max_companiesCompanies allowed at once (up to 15)
autoclean_companiesRemove abandoned companies automatically
autoclean_protectedMonths before an abandoned protected company is reset
autoclean_unprotectedMonths before an abandoned open company is removed
min_active_clientsPause the game until this many players are on
pause_on_joinPause briefly while a player downloads the map
restart_game_yearStart a new game automatically in this year; 0 never

Since version 12, passwords and other secrets are kept out of openttd.cfg, in a separate secrets.cfg next to it - server_password, rcon_password and admin_password go there - and a private.cfg holds personal values. That split means you can share openttd.cfg without leaking credentials. Older guides that put passwords in [network] are describing older versions.

server_game_type and invite codes

Version 12 also replaced the old LAN and internet advertising settings with server_game_type:

  • `public`: listed in the in-game server list and joinable by anyone (with the server password, if set).
  • `invite-only`: not listed, but reachable with an invite code the server prints at start and players type in the multiplayer menu.
  • `local`: not advertised outside the local network.

Invite codes work through OpenTTD's coordinator service, which can help players connect even when direct connections are awkward. On a hosted server with open ports, direct connections work too; the invite code is simply a convenient, shareable way to get a private group in.

Game settings worth deciding first

The rest of the config holds the game rules. Several are worth agreeing before the first train runs: map size and terrain, vehicle_breakdowns, the economy type, infrastructure_maintenance, station spread, train length limits and whether road_side is left or right. Most game settings can be changed in a running game by an admin through the console with set, but map size, climate and terrain are fixed once the map exists.

Ports and connecting#

PortProtocolPurpose
3979TCPGame connection
3979UDPServer discovery and queries
3977TCPAdmin port, only for admin tools

Players connect through Multiplayer: pick the server from the list (public servers), enter an invite code (invite-only), or add the server by address and port. The admin port is for external tools such as bots and statistics collectors; leave it closed to the internet unless you run one, and set admin_password if you do. Game server ports explained covers why admin ports should not face the world, and using rcon safely applies to OpenTTD's rcon as much as to any other game.

Console commands and rcon#

A dedicated server's console accepts the same commands as the in-game console. Remotely, a player with the rcon password runs them as rcon <password> "<command>" from their own console.

CommandEffect
clientsLists connected clients with IDs
companiesLists companies with IDs
kick <client-id>Disconnects a client
ban <client-id>Bans a client's address
unban <address or number>Removes a ban
reset_company <company-id>Deletes a company
move <client-id> <company-id>Moves a client to a company or spectators
pause / unpausePauses or resumes the game
save <name>Saves the game
newgameStarts a new map with current settings
set <setting> <value>Changes a setting
say "<text>"Sends a chat message
exec <script>Runs a script of console commands

help lists the full set. OpenTTD also runs console scripts automatically at certain events - files such as on_dedicated.scr (when the dedicated server starts) and game_start.scr (when a game starts) in the scripts folder - which is the clean place to set things you want applied every time.

Company protection has changed in recent versions: older releases used a per-company password, while newer ones replace it with lists of allowed clients per company. Check how your version handles it before promising players their company is safe from strangers.

AI companies and game scripts#

OpenTTD has no built-in AI; AIs are scripts downloaded from the online content service, BaNaNaS, and so are game scripts - scripts that set goals, cargo targets or story events for the whole game.

On a dedicated server with no GUI, content is managed with the content console commands:

code
content updatecontent statecontent select <content-id>content download

content update fetches the catalogue, content state shows what is available and installed, content select marks an item (by its ID from the listing), and content download installs the selection. You can also copy AI and game script folders into the server's ai and game folders by hand.

Then allow AIs in multiplayer and set which ones start:

openttd.cfg
[ai]ai_in_multiplayer = true

AI players are configured in the [ai_players] section, and game scripts in [game_scripts]; the console commands list_ai, start_ai, stop_ai, reload_ai and rescan_ai manage them in a running game. A few things to know before inviting AIs to a multiplayer map:

  • AIs take company slots. Each counts against max_companies.
  • Some AIs are expensive. A sophisticated AI planning a large network uses a lot of script time, and every client runs it too.
  • AIs compete for the same towns and industries as players. On a co-op server, a couple of AIs add life; on a competitive one, they can crowd out players.

Game scripts are often more interesting for servers than AIs. Goal-based scripts give a whole server a shared objective, which helps keep a community map going for months.

NewGRFs, saves and resets#

NewGRFs - new vehicles, industries, stations and graphics - are part of the game state. The server's NewGRF configuration is fixed when a map is created, and joining clients download any NewGRFs they lack from BaNaNaS automatically, as long as the NewGRF is published there. A NewGRF you added from elsewhere has to be given to players by hand, so stick to BaNaNaS content on public servers.

Saves:

  • Autosave: the server saves on a timer; the interval setting is in real minutes in current versions (older versions saved per game month or year). Autosaves rotate through a numbered set in the autosave folder.
  • Manual saves: save <name> before anything risky - loading new scripts, resetting companies, changing settings.
  • Off the machine: the save folder is small, so there is no excuse not to copy it elsewhere on a schedule. Backups that actually restore explains why one restore test is worth a dozen untested copies.

Resets are part of OpenTTD community life. Some servers run a map to a fixed year with restart_game_year and start again automatically; others reset by goal or by vote. Announce the policy in the server name or your community channel so nobody spends three weeks on a network that disappears tomorrow.

On RE:NODE every game server gets SFTP, a file editor for configs, a Schedules tab that can send console commands and run backups, and off-machine backup slots. OpenTTD itself is not in the catalogue.

Troubleshooting#

Players see the server but cannot connect. The TCP game port is closed - discovery uses UDP and connection uses TCP. Open both.

Joining takes forever on a big map. The whole savegame is sent on join. Smaller maps, or pause_on_join so the game waits, help.

A client keeps desyncing. Mismatched content or a script issue. Check that their NewGRFs and scripts match the server, and run the server with -d debugging to see where it happens.

Settings revert after restarting. You edited openttd.cfg while the server was running; it wrote its own copy on exit.

Passwords in openttd.cfg do nothing. Current versions read them from secrets.cfg.

The game crawls late on a large map. Vehicle count and pathfinding on one core, multiplied across every client. See CPU vs RAM for game servers - more memory will not help.

FAQ#

How many players can an OpenTTD server hold?

Up to 15 companies and more clients than that, since several players can share a company and others can spectate. The real limit is map size and the clients' own PCs.

Do players need to install NewGRFs before joining?

Usually not. Clients download missing NewGRFs, AIs and game scripts from the online content service when they join, as long as the content is published there.

What is the difference between public and invite-only?

Public servers appear in the in-game list. Invite-only servers are hidden, and players join with the invite code the server prints at start or by address.

Can AI companies play on a multiplayer server?

Yes, with ai_in_multiplayer enabled and AI scripts installed. They use company slots and some are CPU-heavy, so add them deliberately.

Can I move a single-player game onto a server?

Yes. Upload the .sav file and start the server with -g pointing at it. The map, companies and settings come with it.


Comments

Completely anonymous: no account, no email, no cookie. We store the name you type, the text and the time - nothing else. Links are limited and markup is not rendered.

0/2000