Server Setup

This page will guide you through the process of setting up an ASSS server. It is assumed that you have already downloaded the appropriate release from the website. Before beginning you should read the userguide located in /docs or on the ASSS website. It's probably most important to read the "File Layout" section, which explains where the important files reside when you extract the ASSS package.

You also want to make sure that if you are not going to use MySQL or Python that you disable the appropriate modules. Or conversely, make sure that all the System Requirements are installed before proceeding any further.

Building Linux Version

• tar zxvf asss-1.x.y.tar.gz
• cd asss-1.x.y/src
• edit Makefile (in your favorite text editor)
• make

Configuring ASSS

You will probably want to take a look at the modules.conf file before running ASSS for the first time to check for dependency issues.

Note: A ';' preceeds a comment and all following characters before a newline are ignored.

Changing Zone Name and Description

The zone name and description are both defined in the /conf/global.conf file. Edit this file to set your zone's name and description. Set both Billing:ServerName and Directory:Name to your desired zone name, and set Directory:Description to the description you want listed on the directory server. You'll also want to set the current directory servers in Server1, Server2, etc. At this time the following directory servers work: sscentral.sscuservers.net and sscentral.subspacehq.com.

To have ASSS send its info to the directory servers, uncomment (remove the semicolon preceeding) the directory module in modules.conf:

directory
;billing

When you run ASSS you should see the following output on module load:

I <cmod> loading C module 'directory' from 'internal'
I <directory> server on port 5000 using name 'YOUR ZONE NAME HERE'
I <directory> using 'sscentral.sscuservers.net' at 62.65.37.101 as a directory server
I <directory> using 'sscentral.subspacehq.com' at 199.232.158.5 as a directory server

and the following during normal ASSS operation:

D <directory> sending information to directory servers

Changing Staff

Your staff is defined in /conf/staff.conf.

In order to give yourself sysop you would change it to:

[GroupPasswords]
; this section is just "group-name = password"
; groups that aren't listed can't be logged into by password.

; the rest of the sections in this file are named after arena groups

[(global)]
; these are "playername = group"
_YOURNAME_ = Sysop

You may also need to log in once using ?passwd <subspace login password> and rejoining the zone before commands work. This is to validate that only someone using your password is allowed to use sysop commands, in case the Billing server goes down or you don't use a biller.

Notice that you have given yourself access to group Sysop in (global). This means that you will have Sysop privilages in all arenas. To limit a player to have only access in a single arena, put the player in the section pertaining to that arena. For example, to only have sysop powers in arena basketball you would do:

[GroupPasswords]
; this section is just "group-name = password"
; groups that aren't listed can't be logged into by password.

; the rest of the sections in this file are named after arena groups

basketball:_YOURNAME_ = Sysop

[(global)]
; these are "playername = group"

Also note that Sysop is an arbitrary group that can have any number or privilages. You can make up your own groups, too, and limit their special abilities and commands. Say we wanted to add a group called SettingChanger, who could change the settings in a single arena (let's say basketball), but not use arena messages or spec other players. First we'll add the players (in this case, Priitk) to the appropriate group in staff.conf:

[GroupPasswords]
; this section is just "group-name = password"
; groups that aren't listed can't be logged into by password.

; the rest of the sections in this file are named after arena groups

basketball:Priitk = SettingChanger

[(global)]
; these are "playername = group"

Then, in groupdef.conf we'll add the group and it's privilages.

; conf/groupdef.conf
; don't edit this file, edit the ones in groupdef.dif

[SettingChanger]
#include groupdef.dir/default
cmd_quickfix
cmd_getsettings

changesettings

[default]
#include groupdef.dir/default
...

And now the Priitk should be able to change the settings by using ?getsettings or ?quickfix, but only in arena basketball. Editing groupdef.conf directly is not recommended, so it's much cleaner to do something like

; conf/groupdef.conf
; don't edit this file, edit the ones in groupdef.dif

[SettingChanger]
#include groupdef.dir/default
#include groupdef.dir/setchanger

[default]
#include groupdef.dir/default
...

and then create a file in groupdef.dir called setchanger which contains the privilages and commands:

cmd_quickfix
cmd_getsettings

changesettings

You've probably noticed that lines prefixed with cmd_ enable a player to use that command. Also, a line prefixed with privcmd_ allows a player to use a private command (one that can be messaged to a player). There are other capabilities, such as changesettings above, that a player needs in order to perform some actions, such as change the settings. Here's a complete list of the non-command capabilities (from grelminar's User Guide):

• seeprivarena controls whether private arena names are sent to a player for the ?arena command.
• seeprivfreq determines if a player sees private freqs in the freq listing.
• findinprivs is needed by a player running ?find for the server to report the names of private arenas. (Not implemented yet.)
• seeepd allows players to see other ship's energy and specials from spectator mode. (epd stands for extra position data.)
• seesysoplogall allows a player to see all important log messages in the zone.
• seesysoplogarena only allows a player to see only important log messages having to do with the arena he is currently in.
• seemodchat allows players to see the moderator chat.
• sendmodchat controls who can send moderator chat messages. Usually, these two capabilities would be given to the same people.
• uploadfile allows a player to upload files. Note that the player must also have the cmd_putfile to upload a file using that command.
• bypasslock allows players to switch ships even though the arena or themselves have been locked into a ship or into spectator mode by a staff member.
• bypasssecurity lets players use unauthorized clients, or prevents kicking off for security checksum failures.
• invisiblespectator makes players not show up on the list given when the person they are spectating uses the ?spec command.
• unlimitedchat allows a player (e.g., a bot) to bypass chat flooding checks.
• changesettings lets clients use the settings change packet (required for ?quickfix/?getsettings).
• isstaff makes players show up in ?listmod output.
• seeallstaff allows a player to see all non-default-group players, even if they lack isstaff.

Also see: http://sscx.net/asss/userguide.html#%_sec_4

Changing Map and Settings

To change the map you need to first put the map (.lvl file) you want to use into the /maps/ directory. Then you edit the settings in the arena you want your map to be in. Change General:Map to be the name of the .lvl file you want it to use.

To change what default arena (called public in Subgame) is using, edit /arenas/(default)/arena.conf. Note that this file may use data from other files using #include statements. To override certain settings without editing them from the original files, you can define them at the end of a file. For example, if you wanted svs settings, but the map to be "mymap.lvl" you could set your arena.conf to be:

; drop in all of svs settings here
#include conf/svs/svs.conf

[General]
Map = mymap.lvl

Changing Modules

You can change which modules your server uses. First make sure the compiled .dll file with your plugin is in the /dist/bin/ directory. Let's say our .dll file was called MyModules.dll and the module we were trying to use was called FreqWatcher. Now edit /conf/modules.conf and at the very end add:

MyModules:FreqWatcher

The order of the modules.conf file is important, as files that depend on other files must be listed after them (unless they take advantage of MM_POSTLOAD in their main module function). Usually when the server aborts while loading, the problem can be traced back to the modules.conf file (a module is missing, or in the wrong place).

Running ASSS

To run the windows version of ASSS, locate ASSS.bat and double click it. That's it! You now have your own zone up and running.

In Linux, just run ./scripts/run-asss, which handles ?shutdown -r. IMPORTANT: You will need to edit the ASSSHOME variable defined inside the script to point to the directory you extracted ASSS.