Server Hosting

Hosting a server can be complicated and dangerous if it is done wrong! People could hijack your server and ruin your whole system (especially when you are using insecure passwords or scripts)! DO IT AT YOUR OWN RISK!

General Info

Some important things & facts you should know

What does it take to host a CS2D Server?

Listen Or Dedicated Server?

Both servers do the same thing! They host a CS2D game and they save it in the serverlist - at least if you do everything correctly! If you want to host a game and play yourself we recommend to use the listen server (CS2D). If you want to host a server permanently and want it to be online 24/7 you should use the dedicated server (cs2d_dedicated).

Listen Server (CS2D Client, CS2D)

The listen server is the easiest way to host a server. To start a listen server you start the CS2D client (CS2D) and use the 'New Game' option. It has many advantages:

So whenever you want to host and play at the same time and at the same PC: Use the listen server!

Dedicated Server (cs2d_dedicated)

The dedicated Server is more complicated to use than a listen server. It's a separate program (cs2d_dedicated) which can only be used for server hosting and which has no video output. Advantages:

Huge disadvantage: You can't control the server directly. You have to use RCon (remote control) or custom Lua scripts to do so. Use the dedicated server if you want to host a CS2D game on a real server machine (a root- or v-server) without GPU and if you want the server to be online 24/7.

How To Host

Host Listen Server

Host Dedicated Server

Important Server Files

sys/server.cfg

This file contains nearly all server settings.

sys/config.cfg and sys/more.cfg

Some additional settings. However most of these settings are for the client and do not affect the server.

sys/bans.lst

A list of all players which are banned from your server.

sys/mapcycle.cfg

A list of maps which will run on your server. The server will automatically cycle through these maps (if settings allow it). You can also add commands which will be executed when a certain map is loaded. Check the comments in this file for details. Only maps in this file can be voted by players!

sys/serverinfo.txt

A welcome message. It will be displayed to everyone who joins your server! You can remove this file (or its contents) if you do not want to have a welcome message.

sys/servertransfer.lst

A list of files which will be sent to all clients which join the server (and which accept these files). Read the comments in this file for details.

sys/logs folder

Contains log files (if logging is enabled). Read them if your server does not work properly. You can delete log files if you do not need them anymore. They do not influence the server.

sys/stats folder

Contains files which are used to save the server stats and player rankings. Simply delete these files to reset the stats/rankings (stop the server while doing this).

sys/core folder

Some (internal) core files (nothing you need to edit or care about).

sys/lua/server.lua

This file will be executed by the CS2D Lua parser whenever you start your server. It allows you to include Lua scripts. This can be done by editting this file with a text editor. Read the comments in this file for details.

sys/lua/wrapper.lua

A wrapper which makes it easier to use CS2D commands in your Lua scripts. Used by many Lua scripts.

sys/usgn.dat

Masterserver connection info. Essential for servers. Otherwise they will not be able to communicate with the U.S.G.N. masterserver (no serverlist entry, no account login).

bots/Standard AI.lua

This file will be executed by the CS2D Lua parser whenever you start your server. It contains the Lua scripts for bots. It is unimportant if you are not using any bots.

Automated Health Checks

In some scenarios CS2D servers can crash or start to malfunction. This can be caused by bad Lua scripts or attacks. One known attack is sending empty or corrupted UDP packets which can kill the UDP connectivity of your server (the process will keep running normally though). See the security page to learn how to block this attack!.

Pinging The Server

Because of the UDP connectivity issue mentioned above, it's not sufficient to check if the CS2D server process is still running. The recommended health check is therefore to ping the CS2D server. This can be done by sending a simple UDP packet to the IP and port of the server (you can use the IP 127.0.0.1 if the script is running on the same machine).

Ping Packet Structure (request and response are equal)

The timestamp must be a 32 bit integer (4 bytes). CS2D will respond with exactly the same timestamp value. This allows measuring the ping (by comparing the timestamp in the packet with the current timestamp). If you just want to check if the server responds (and not how quickly it does) the timestamp value does not matter. You have to include it anyway though. Otherwise the message is incomplete and CS2D won't respond. Commonly the system uptime or application uptime in milliseconds is used as timestamp value.

You should send this message periodically (e.g. every 5 seconds) and wait for a response. The response data will look exactly like the request. If the server does not respond anymore for multiple requests you should kill the server process (if still running) and restart it.

Note that UDP is unreliable and subject to packet loss. It is possible that you don't get a response for every single ping request you send even though the server is still alive. Therefore it is recommended to only restart after sending multiple ping requests without response.