Skip to topic | Skip to bottom
Linux.DebSpringr1.1 - 29 Jul 2007 - 08:35 - TWikiGuest? [Zum Ende]

Start of topic | Direkt zum Menü

The DebSpring Project - TA Spring for Debian Etch+ and Ubuntu

This page is dedicated to Debian Packages I built and maintain for Total Annihilation Spring - a Game inspired by Total Annihilation. TA is a Realtime Strategy Game that was released ~ 1998. Background of the game ist a War between two extraterrestrical races - Arm and Core - but today mods provide different unit sets (representing the races), too.


  • Packages of the latest release (I'll try to build svn-versions on a regular basis soon)
  • FHS compliance, no /opt -installation, no mix of Code and data although spring usually works that way.
  • Packages for Debian GNU/Linux Sarge (stable), Sid (unstable) and Ubuntu Dapper Drake
  • Multiuser- and Multiinstance-ready: Multiple users (or a single one multiple times) may use the game with different mod/map/unit- addons on the same homedirectory/host without any interference.
  • Lots of gamedata in optional packages:
    • Maps: Multiple map collection packages ( spring-map-pack1 ... ).
      Warning: The map packages are usually 200MB+ .
    • Units: Units seperated from mods are no longer provided, sorry.
    • Mods: A lot of mod packages (different games using the Spring enging) are available. Name schema is spring-mod-[modshortcut] .
  • Ability to access and automatically download distributed content without any manual downloading necessary. Downloaded content is shared between all users of a given computer
  • Map path cost files are shared between all users of a computer to save precious cpu time and storage.
  • DebSpring provides a setup tool for complete configuration of spring. This includes:
    • Selecting the mod to be used
    • Changing video settings (Resolution,Fullscreen on/off)
    • Configuring audio settings which includes selecting the audio API and the device to be used.
    • Selecting maps to be used. This way you don't have always to scroll through endless lists every time you want to Just Play (tm) .
    • Debspring configuration is managed on a per user/host/X-display basis which enables
      • multiple users to play on a lan using the same networkwide user account
      • multiple users playing on a single machine (which is rather unlikely, but I'm pedantic :-) ) using either the same or different unix accounts.
  • Debspring minimizes intervention and tries to keep manual changes (e.g. on the .springrc file). Modification options not coverd by the interactive spring-setup will never be touched.
  • Different game types are configured by debspring at request - including...
    • Single player - A Game against arbitrary AI
    • Other side - A Game against arbitrary AI with sides swapped (You are Core, AI player is Arm)
    • Demo - For watching two computer players fight each other
    • Menu-driven - Debspring just configures/downloades the content, you define the type of game, the map + the actual mod inside a menu on spring's start.
  • Menu entries are created using the Debian-Menu-System which means, there'll be some fancy icons in KDE's K-Menu at Games/Strategy .

I just wanna play...

Add one of those lines (depending on your Debian-distri) to your /etc/apt/sources.list file:

Distribution down sources.list-Line
Debian Etch deb /
Debian Lenny deb /
Debian Sid deb /
Ubuntu Dapper Drake deb /

Update your package lists:

root@host > apt-get update

Install the main packages by typing:

root@host > apt-get install spring-release

Use the KDE/Gnome/whatever-menu to start the game. There should be a new menu entry ( Games/Strategy/Spring (Instant Fun) ) - that's it. If you want more control over your game (different mods, different maps) select Games/Strategy/Spring (Setup) instead.

I want to know a bit more...

Spring is incredibly flexible. It is possible to change the gameplay completely by replacing e.g. Units, Buildings, Weapons. It's possible to switch to different AIs (Artificial intelligences) to fight against and to play games against other players over LAN or the Internet. spring-setup is a little helper program that was created to make this flexibility partly accessible to users that just want to play . The options of spring-setup will be explained in this part of the documentation.

Whenever you exit spring-setup pushing the Save & Exit button or you run spring by selection start , all options of spring-setup ware written to disk.

You might want to start the game directly - without having to use spring-setup . This is possibly by typing spring .

The initial game setup

When you spring-setup it the first time, it will use some preconfigured options:

  • Gametype is Human vs. Computer . There are other gametypes - e.g. server to setup a server, other Spring users can connect to.
  • Chosen artificial intelligence is NTAI. There are more of them available with different behavior.
  • Mod is XTA Pimped Edition V5.5 which is the default gameplay. Other mods can be installed by selecting them. They will be downloaded from the internet automatically.
  • Selected map is Mars which is one of the three default maps. More maps can be downloaded from the internet.

Three ways to get content

Debspring offers three ways to use content (Maps and Mods):

  1. Installation of content packages via debian package system (e.g. Package spring-map-pack1 ). This is the clean debianish way.
  2. Accessing content in arbitrary local directories. If you manually downloaded maps/mods, this is way you want to go.
  3. Selection of content which resides on mirror server and will be automatically downloaded on selection. This is the most convenient way. Maps/mods are selected as if they are local and all necessary packages are downloaded at once when they are needed. Information about where to get the content is stored in a text file whose URL can be changed. It defaults to .

What packages are available?

Debspring consists of the spring package, containing binaries (AI, spring itself), the architecture independ spring-scripts packages handling mod dependencies and maintaing the per user/host/display workdirs and the spring-basedata package containing the default mod and some base datafiles (some maps, default unit textures, ...).

Mod packages

There are additional mod packages available (use default debian package tools for checking the release numbers):

Package Explaination
spring-mod-aa The Absolute Annihilation mod
spring-mod-ff Final Frontier mod - TA in a Space environment with all units being starships.
spring-mod-wd World domination mod - A mod with units one would expect in a war on earth.
spring-mod-xm Xect vs. Mynn mod - A mod containing two new races
spring-mod-gundam Gumdam Annihilation mod - Gundam is a science fiction universe. I never heard of it before spring... However - this mod puts you in this universe.
spring-mod-kuro KuroTA mod
spring-mod-uh Uberhack mod
spring-mod-hc Hoovercraft commander mod
spring-mod-nb Nanoblobs mod - Units are strange toys here.
spring-mod-sw Starwars mod - Play Spring with Units known from those famous movies.

All mod-packages can be installed at the same time. spring-setup will put .sdz / .sd7 archives in the right place, whenever you request a mod.

Map packages

I picked the most interesting maps from Fileuniverse's Spring-Maplist and put them into five debian packages:

  • spring-maps-pack1
  • spring-maps-pack2
  • spring-maps-pack3
  • spring-maps-pack4
  • spring-maps-pack5

If you think, i missed you favorite, most important, ... map - just send me a mail and I'll include it into a Debspring package. Soon there'll be functionality in spring-setup to include maps/mods in arbitrary locations in the filesystem.

AI packages

Debspring is prepared to include third-party-AIs when it's necessary. However, there are currently 4 AI-modules included in the main binary package itself:

  • JCAI
  • AAI
  • KAI 0.12 and KAI 0.22

KAI 0.22 will be chosen by default.

How to make own packages?

Additional map/unit/mod-packages?

There are some simple rules:

  • All maps go in /usr/share/spring/maps


If the package contains mod files:

  • All mods files go in /usr/share/spring/mods .
  • The packages have to depend on spring-scripts and should recommend spring .
  • Mods should be architecture independent ( Architecture: all in control-file )
  • The postinst and the postrm -scripts have to call spring-modupdate in the configure -target ( postinst ) and in the remove -target ( postrm ) .

Mod packages may provide an additional textual configuration file to provide/override information about the mod. This file should have a nama associated to the mod package (i.e. aa for spring-mod-aa which contains Absolute Annihilation) and must be placed in /usr/share/spring/modextinfo . Syntax is like this:

modalias=[Regex an archive must match]:[Alias]
modname=[Regex an archive must match]:[Name displayed in menu]

modalias tries to match archives ( .sdz or .sd7 -files which are mods in most cases ) and assigns them an additional name (alias). This is i.e. necessary because there's no version management system for those archives which means springdecals_v062.sdz = springdecals_v061.sdz . modalias provides an easy way of solving those problems for small amounts of archives. The special value base as Alias promises the archive-manager that all necessary data of matched archives' files is already in the base archives contained in the spring and spring-basedata -packages.

modname assigns a module a name to be displayed in spring-setup 's mod selection dialog.



modname=springWD5B65\.sdz:World Domination

How to recompile Spring for a different Debian'isch Distribution?

If you're using i.e. Debian Etch or an Ubuntu release which is not Dapper Drake, you can compile spring on your own. Here's the step-by-step-howto:

Make the source package repository known to apt which means putting the following lines into /etc/apt/sources.list :

deb /
deb-src /

... update the package list ...

root@host > apt-get update

... , install the general development packages ...

root@host > apt-get install dpkg-dev fakeroot

... and install the packages necessary especially for the spring-build-process ...

root@host > apt-get build-dep spring-release

Then switch back to a normal user account.

Find a usable directory with enough free space (1 GB should be sufficient). The following command is an example, any directory can be used. BTW xxx is some variable version number (release version of spring, debian version of the package) - you have to replace xxx by the according number.

user@host > mkdir -p /opt/spring;cd /opt/spring

Get the source package from the debspring-server ...

user@host > apt-get source spring-release

... , chdir into the spring-package-root ...

user@host > cd spring-release-xxx

... and build the package by typing ...

user@host > dpkg-buildpackage -rfakeroot

You'll get some warnings about non-existing gpg-keys. They can be safely ignored. After building the package, you'll find the .deb -file (in this example) in /opt/spring . Switch back to root:

user@host > sudo bash

... install the package ...

root@host > dpkg -i /opt/spring/spring-release_xxx_386.deb

... and satisfy the missing dependencies ...

root@host > apt-get -f install

Now refer to the I just wanna play section for the rest of the installation. If you have to choose a Distribution - sarge is what you want.

Technical details

This section covers the Question What does debspring do to make spring actually run?

Determining the workdir

Spring uses a single directory (incl. subdirectories) to get all it's gamedata, AI-binaries, configuration, ... .

All scripts contained in debspring are working inside this directory which is determined by three variables:

  • The current user. Remark: Actually, just the path to the user's homedirectory ( $HOME ) is used.
  • The local FQDN of the computer. Remark: FQDN means the name of the computer + the name of the domain. It's determined using the hostname -f command.
  • The current display name. Remark: The displayname is the address of your X-Server. It is usually :0.0 .

The workdir name is determined this way:

export WORKDIR="$HOME"/.springdir/`hostname -f``echo $DISPLAY | sed s/:/_/`



Linking content into the workdir

The workdir is mainly a big symlink-tree which means, it consists of directories and subdirectories, containing symbolic links to the real content and binaries. There are some reasons:

  • It's always good, to hve static data non-writable to the regular user. All data in debspring-package is installed root-writable-only.
  • The content is located in different locations to satisfy the debian policy (Seperating platform dependent and independent data)
  • You can safely remove the whole workdir without really deleting anything.

Static data

The static targets of those symbolic links reside in two directories which are populated by debian packages:

  • /usr/share/spring/workdir - Configuration files, platform independent binary data
  • /usr/lib/spring/workdir - Share object files (mainly AI)

Dynamic data

Every data which is conditionally linked into the workdir is called dynamic data here. This covers...

  • Maps
  • Mods

All these data are considered plattform independent and reside in multiple locations - depending on how they get to spring. Maps and Mods are located in static directories (Maps in debian packages) in /usr/share/spring/maps / usr/share/spring/mods . The user might select an additional location for Maps/Mods in spring-setup which Maps/Mods are chosen from and symlinks are created poiting to. The last valid location is /var/lib/spring/dl-maps and /var/lib/spring/dl-mods which contains Maps/Mods that were downloaded using the Debspring-Content-Downloader.

Other data

The directory $WORKDIR/maps/paths always points to /var/cache/spring/ to ...

  • share precalculated path data among all users of a given host
  • not fill the homedirectory with cache information (which would unneccesarry increase the volume of the backup, you're doing daily, right? :-) )

Configuration files

Everything you setup in spring-setup is written into $WORKDIR/.spring-debianrc as KEY=VALUE pairs. You might change those values safely using other programs or a text editor - it will effect games started by running the spring -wrapper directly.

When Spring is run using debspring, several configuration files are written which are important for Spring itself + some of the libraries it depends on:

Configuration file for Explaination
$WORKDIR/.springrc Spring This file is usually located in $HOME but Debspring uses a trick to make spring access it directly from the workdir.
$WORKDIR/.openalrc OpenAL The sound configuration file. It configures the openal-library, spring uses to output sound.
$WORKDIR/debspring-startscript Spring This is the Startscript defining the type of game spring will present you. It is used whenever you didn't choose gametype =menu

Bending the homedirectory

Spring and some of it's libraries are depending on configuration files which are located in the user's homedirectory. Debspring changes this behaviour to make those files being located relative to the $WORKDIR . This is how it's done:

# Demo wrapper to run spring inside it's workdir
#  by fbo
export WORKDIR="$HOME"/.springrc/`hostname -f``echo $DISPLAY|sed s/:/_/`

# We redefine the homedirectory and set it to the correct
# workdir. This won't affect other processes, just spring.
export HOME="$WORKDIR"


export HOME="$OLDDIR"


  • add dependency checks in spring-cindex
  • move oft used methods into perl libs
  • Add POD to spring-script
  • fix 'utime'-problem in spring-setup


[Zurück zum Start]

Aktuelle Wiki-Seite: Linux > DebSpring

[Zurück zum Start]