This guide was created in response to the demand to know information about dedicated server running in a linux / WINE environment. It has been extensively tested in this environement. During the stress test, several servers were linux or BSD. If you want to run an "official" server, you should probably first follow the Step-By-Step Dedicated Server Guide to register its IP address. Otherwise, you can still run public unofficial servers without registering them.

Performance Note

Although ThreadSpace: Hyperbol makes extensive use of the D3DX math libraries, the dedicated server requires no rendering of graphics or sound and other things which tend to be slow under WINE. The performance ends up being about the same as native performance on windows machines, if not faster due to a leaner kernel.

What you'll need

First, you'll need the dedicated server itself.

You can either copy the dedicated server from your steam folder on a machine that has it (by using the url steam://install/2740 ) ... or by running steam inside linux using WINE... or by using the hldsupdate tool, which is the recommended way.

Option 1: Obtaining Files by copying them from someone elses (or your own) Steam

Simply 'run' the url 'steam://install/2740'. The most reliable way to do this is to do so on a windows machine with steam installed. This is why we don't recommend this way of doing it. Then, whenever we update the server, you'll have to re-copy. But if you want to do it this way, the files will end in <steam install location>/steamapps/common/tshb Copying that folder to your linux machine or partition will basically be copying the dedicated server.

Option 2: Using the linux-friendly steam tool (Recommended!)

Download the "hldsupdatetool" from valve.http://storefront.steampowered.com/download/hldsupdatetool.bin

That is a linux x86 executable for Valve's HLDSUPDATETOOL. It presents an EULA and unzips itself to a binary called "steam". With that binary you can not only automatically update to the latest version, but you can also automatically verify that all your files are uncorrupted and okay. Its the recommended way of doing it. Especially since you can automate things with bash scripts, thanks to STDOUT support in hyperbol.

Using the HLDS Update tool, once you have installed it and it has become the binary called "steam", telling it to install the entire dedicated server is pretty easy:

./steam -command update -game "tshb" -dir ~/tshb_server

You can of course replace dir with where you want to put the files.

The final gotcha: The D3DX9_31.dll file

You'll also need to obtain D3DX9_31.dll - We can't distribute this except as part of theDirectX9redist. We do include the redist as part of the Hyperbol install (including the demo). You could probably use the linux utility "cabextract" (ubuntu: apt-get install cabextract) to extract it from the redist.

• If you installedThreadSpace: Hyperbol on any windows machine, it will be in your windows system folder. There are other ways to obtain it. We can't advise you on how to obtain or copy this dll around, since we can only distribute it as part of theDirectX9redist, but once you have it, copying it into your hyperbol folder alongside the executables will make the game (And the server) work in WINE. Future versions of WINE may even incorporate this DLL so by the time of writing it may not even be necessary. You'll have to manually place that file in your tshb folder, because we can't distribute it without permission.

So now you have the files and DLL necessary - What next?

At this point we assume the following:

• You have the dedicated server on your linux / BSD machine, with WINE installed and the DLLs necessary in place.
• If you want the server to be official, you've registered the server and thus obtained a hostoptions.cfg file (or many, one for each server) from Starport (using the Dedicated Server Guide). If you dont want it to be official, you hand crafted the hostoptions using a text editor, or using the game's GUI to graphically craft your desired custom ruleset. Either way, the hostoptions.cfg goes in the data folder.

So at this point you're ready to run the server. You can either run it in graphical mode, if you want to have buttons and stuff (using Xorg or X11/Wine)... or you can run it in pure console text mode, which is compatible with STDIN/STDOUT redirection and works great with the 'screen' command. (Recommended).

Running in graphical mode

Simply use the command

wine hbds.exe

Running in console mode (Compatible with 'screen')

wineconsole hbds.exe -console

Notice that we are using wineconsole instead of wine. Failure to use wineconsole will cause it to be impossible to 'talk' to the dedicated server via STDIN. You really need to use wineconsole instead of wine.

Some users have had problems getting it to run without first using

export DISPLAY="" 

Other useful command line options besides -console

-norelocate

If you need to place the executables away from the data, you can do that too, using the '-norelocate' command line option. By default, hbds.exe relocates the working folder to the location of its executable, and expects there to be a 'data' subfolder there. If you instead want to keep the executables elsewhere, simply ensure that the working current working directory has the 'data' subfolder in it, and then execute the same command but with -norelocate as an extra command line option.

-serverip <dotted ip address>

If you have multiple network cards bound to different IP addresses, you can use -serverip to select which ip address the server presents itself on. You must own this ip address or it will output an error. Note that all traffic is routed from that source IP - that includes master server heartbeats, auth requests, etc.

-configfile <filename>

This tells the server instance to load a specfic config file instead of hostoptions.cfg in the data folder. Note, it looks in the data folder specifically. So telling it -configfile hello.cfg would look specifically inside the data folder for hello.cfg

-tcpconsoleport nnnn

This tells the server to listen on port nnnn on localhost (non routable) for telnet or IRC-DCC connections. Its basically a TCP interface into the server's console. It is suggested that you SCREEN+TELNET to that port. Only one connection will be allowed. Only localhost can connect. If you do not specify this option, no console port will be used. Its mainly intended for people who write server administration / monitor tools. For example, you can use python in linux (natively) to speak to the console of the dedicated server via this interface, since its just TELNET protocol (raw).

Other notes

See the dedicated server guide mentioned at the top of this doc for useful command line options and other administrative notes.