Game specification: Difference between revisions

From Spring
Jump to navigationJump to search
Fnordia (talk | contribs)
0 edits
No edit summary
 
Flozi (talk | contribs)
0 edits
tag for delete, adds nothing to info in modinfo.lua page
 
(32 intermediate revisions by 18 users not shown)
Line 1: Line 1:
This is a preliminary specification of how Spring will support mods and switching between them.
{{delete}}
===Overview===


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.  
This is a specification of how Spring will support mods and switching between them.  


To present mods to switch between, Spring will search this folder and its subfolders for files called modinfo.tdf. It will look inside the hpi files as well. The general idea is that this file should be used as a manifest file to let spring know what to do with the hpi archive it is found inside, so each hpi file in the mods directory is supposed to have one or a default one might be used.
Spring looks for games in the folders "maps", "base" and "mods" and "games", and all their subfolders. It is recommended to put your game in a subfolder of /games.  Spring supports multiple subfolders within /games:  '''/games/my_nifty_game/game.sdd''' and '''/games/my_nifty_game/game_support.sdz''' are both correct.


These info files could also be cached to avoid having to look inside files that haven't changed every time spring is started.
On startup, Spring will search these folders and their subfolders for files called [[Modinfo.lua]]. This file declares all ''dependencies'' of this game, such as additional graphics, sounds and the like.


This is an example of what this file could look like:
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. Archive files that do not contain this file are ignored, and aren't available to Spring's Virtual File System.


<tt>
===Modinfo.lua===
// Description of the mod control file recognized by spring:
See [[Modinfo.lua]]


[MOD]
===Replacements===
{
'''When releasing new versions of a game or map it is recommended that a new unique filename is used.''' In this manner it would be possible for the lobby to download archives from a fast webserver based on the filename.  
  // The name and version is used to identify the mod.  
  // Version should be a number (to be used in comparisons)
  Name=XTA;
  Version=0.95;


  // These can be shown by the selection interface
But if a new name is used for a support archive with content for example, it would break other mods that depend on the archive. To avoid this, replacements can be used.
  Description=XTA 0.95 beta makes stuff balanced and cool;
  URL=http://www.clan-sy.com/;


  // What kind of mod this is
Replacements simply specifies which other archives this one replaces. So if a new archive specifies that it replaces old_archive.sdz, any other mod that depends on old_archive.sdz would now use the new one instead.
  //  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 mods this one depends on   
It is probably not always a good idea to use this for new versions of a mod however, since if you hide the old version people would not be able to switch between the old and the new version. So only use replacements when you are sure that it is what you want.
  NumDependencies=1;


  [DEPEND0]
===Distribution===
  {
      Name=OTA_Textures;
      MinVersion=1;
  }


  //[DEPEND1]
If a player does not have a certain game's files when trying to join a game online, the Lobbies are designed to let them know that they don't have the game. If you have uploaded your game to the [[Dev:LobbyDownloadSystems|various services]] that are supported by the Lobby applications, players can automatically download the game. Also, SpringDownloader allows players to share the game's file with others easily. Modinfo.lua lets both the Lobby application and Spring know what your game is, and whether it "knows" where it can be downloaded from.
  //{
  //  Name=OTA_Scripts;
  //  MinVersion=1;
  //}
}
</tt>
 
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:
 
* Single extra units that has
* 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).

Latest revision as of 14:44, 24 August 2013

Deletion! This page is marked for deletion! If you think it does not belong deleted, please remove this template, and state your reasoning in the edit summary, or on the talk page.


Overview

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

Spring looks for games in the folders "maps", "base" and "mods" and "games", and all their subfolders. It is recommended to put your game in a subfolder of /games. Spring supports multiple subfolders within /games: /games/my_nifty_game/game.sdd and /games/my_nifty_game/game_support.sdz are both correct.

On startup, Spring will search these folders and their subfolders for files called Modinfo.lua. This file declares all dependencies of this game, such as additional graphics, sounds and the like.

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. Archive files that do not contain this file are ignored, and aren't available to Spring's Virtual File System.

Modinfo.lua

See Modinfo.lua

Replacements

When releasing new versions of a game or map it is recommended that a new unique filename is used. In this manner it would be possible for the lobby to download archives from a fast webserver based on the filename.

But if a new name is used for a support archive with content for example, it would break other mods that depend on the archive. To avoid this, replacements can be used.

Replacements simply specifies which other archives this one replaces. So if a new archive specifies that it replaces old_archive.sdz, any other mod that depends on old_archive.sdz would now use the new one instead.

It is probably not always a good idea to use this for new versions of a mod however, since if you hide the old version people would not be able to switch between the old and the new version. So only use replacements when you are sure that it is what you want.

Distribution

If a player does not have a certain game's files when trying to join a game online, the Lobbies are designed to let them know that they don't have the game. If you have uploaded your game to the various services that are supported by the Lobby applications, players can automatically download the game. Also, SpringDownloader allows players to share the game's file with others easily. Modinfo.lua lets both the Lobby application and Spring know what your game is, and whether it "knows" where it can be downloaded from.

Retrieved from "https://springrts-wiki.p2004a.com/mediawiki/index.php?title=Game_specification&oldid=8117"