Navigation
Community
Configuring
Creating
FAQ - General
Info for Sauerbraten Users
Introduction
Known Issues
Main Page
Notes
Playing
Troubleshooting

Creating >

### Running a Local Server

It is sometimes useful to run a local server instance, that is, a server instance on the same machine you are running the game client on. Reasons you might want to do this include:

- Lets you change the map scripts without uploading them to a remote server. This is useful because you may need to edit the scripts quite a lot during debugging and so forth, and because uploads take time.
- You have more direct control and contact with the server - so you can see how much CPU it's using, stuff it logs to the console (like errors and warnings), and so forth.
- You don't need to find a free remote server instance.
- You can use some editing commands that require that you be the only client logged into the server, like heightmaps. However, you can also do this on a remote server, by selecting 'request private edit mode...' in the client menu.

There are some disadvantages, however:

- With the client and server on the same machine, you will not notice network delays, because communication is pretty much instant. This means that it is not possible to debug 'responsiveness' issues in your maps, that is, stuff that makes the game responsive even though some of the logic is on remote machines.
- You need to set up the server, perhaps telling your firewall to let it use the ports it needs, and so forth.

## How to do it

- Pick a 'home directory' for your server. This is the first parameter you pass to the server when you run it (with intensity_server.sh or intensity_server.bat). So, for example, running intensity_server.bat my_server will set the home directory to my_server\.

- If you don't specify the directory, it will use something under your user's home directory, this depends on what operating system you are using (on Windows XP, it would be under C:\Documents and Settings and then your user, in Vista it would be under C:\Users and then your user, in Linux it would be in ~/. Under the operating system's home directory, there will be a directory called intensityengine_server, or with a '.' before it on Linux.)

- After running the server for the first time, a settings.cfg file will appear in the home directory. There are several parameters of interest there (we list them as [Category] / Element):

- [Logging] / level: How much output to log to the console. Use DEBUG for more information, INFO for a lot more information.
- Versions 1.0.2 and earlier:

- [Activity] / force_map_asset_id: The UUID (identifier) of the map to run. To find it, you can view the map asset (not the activity) on the main website. The last part of the URL is the UUID, for example,
  http://www.syntensity.com:8888/tracker/asset/view/06c9b70b_14d7_4afc_bd63_56588670c1ef/
  (so, 06c9b70b_14d7_4afc_bd63_56588670c1ef in this case).
- [Activity] / force_activity_id: Setting this is optional; if set, the activity the server is running will be listed correctly on the master's list of server instances. If you do set it, this should be a UUID for the activity, which you can find like finding the UUID for the map asset (but when viewing the activity).
- Note: If there isn't an [Activity] section, simply add one.

- Versions 1.0.3, trunk, and later:

- [Activity] / force_activity_id: You can either place an actual activity ID (as described above), or simply paste the full URL to the activity, from the website. Such URLs look something like
  http://www.syntensity.com:8888/tracker/activity/view/afe3c7e1_caeb_4320_9116_6e2ae8ad6242/
  You can find the URL by clicking on the activity on the activities page.
- Note that you don't need to set force_map_asset_id, it will be discovered automatically based on the activity ID. (However, you can still define it, and not define force_activity_id, for backwards compatibility.)
- Note: If there isn't an [Activity] section, simply add one.

- After setting the activity information, run the server. Then run the client, log into the master, and select 'local connection...' to connect to your server.
- You should now be able to work on your map.

Notes:

- While the server is local, you are still logged in to the Syntensity master server. This means that if you do 'Upload map...' it will be uploaded to the master.

- Note that uploading the map will update it for everyone, as you are uploading it to the master server. The master server won't let you do that if you aren't the owner of the asset, in that case the upload will fail with an error.

- For smaller edits, you can do the following:

- Change the map files for both the client and the server, then run them.
- The client's map files are in the client's home directory, under packages/base/mapname/, and the server's are in the server's home directory, also under packages/base/mapname/, where 'mapname' is the name of the map.
- Any changes made to both those map directories will take effect when you work locally. This lets you be 'out of sync' with the remote master server, when you are testing local changes.
- Note that if you change just the client's files, or just the server's - or change both, but don't restart the server - then, with the client and server not running the same code, strange things may happen.
- Note also that if you change the server's map.js, and do 'upload map' from the client, then the client will upload the old version. After the upload to the master server, both client and server will get the latest version from the master, which will have the old map.js - overriding what you changed in the server's map.js.
- One helpful approach here is to use a symlink (on operating systems that support that), so that the client and server are really using the same /packages directory, even though they have different home directories.

Updated on Oct 27, 2009 by Alon Zakai (Version 14)