Game specification

This is a preliminary specification of how Spring will support mods and switching between them.

First, a new subdirectory will be created in the spring folder, called "mods". All mods should be placed here, either in the root of the folder or possibly in their own subfolders.

To present mods to switch between, Spring will search this folder and its subfolders for archive files containing a file called "modinfo.tdf". The general idea is that this file should be used as a manifest file to let spring know what to do with the archive it is found inside, so each archive file in the mods directory is supposed to have one or a default one might be used.

These info files will also be cached to avoid having to look inside files that haven't changed every time spring is started.

This is an example of what this file should look like:

// Description of the mod control file recognized by spring:

[MOD] {

  // The name is shown in the selection interface
  Name=XTA; 

  // These can be shown by the selection interface 
  Description=XTA 0.95 beta makes stuff balanced and cool; 
  URL=http://www.clan-sy.com/; 

  // What kind of mod this is 
  //  0 - Hidden (support mod that can't be selected, such as OTA_textures) 
  //  1 - Normal, only one can be selected at a time 
  //  2 - Addon, any number of these can be selected. Could be used 
  //      for single units for example. 
  //  others - perhaps mutators and addon races that can be 
  //           enabled in addition to xta for example? 
  ModType=1; 

  // Number of other archives this one depends on    
  NumDependencies=1; 
  Depend0=taenheter.sdz;

}

Listing the dependencies allows a mod to not load the OTA textures at all for example, if it only uses original textures. Only one mod of type 1 can be selected at one time. Also, if a mod of type 2 is depending on a type 1 mod, that mod has to be selected first.

Some examples on how this could be used:

• An OTA mod that restores balance to be more similar to OTA could use modtype=1 and depend on XTA. Since XTA is now in the dependency graph, type 2 mods that depend on XTA would now also be usable.
• A new total conversion with a few extra options (not sure what that could be.. but anyway) could use a hidden base package and provide several type 1 mods that are small files that depend on the base.

To support older spring and ta mods that do not have this file, Spring could use a default modinfo file for all the hpifiles that do not contain this file. The default would be a modname=the filename, modtype=1, and dependencies set up to match the original spring release (xta+ota_textures).

When playing, the files would be loaded in the order defined by the dependency graph. The files could also be checked with an MD5 checksum or similar to make sure all players have the same file.

If a player does not have a certain mod when trying to join a game, the info in description etc could be sent to allow the player to download it.. The filename could be sent as well, so that the client could try to download it automatically from a few predefined redirect servers (similar to the system unreal tournament uses).