Game specification - Revision history

Flozi: tag for delete, adds nothing to info in modinfo.lua page

2013-08-24T13:44:48Z

tag for delete, adds nothing to info in modinfo.lua page

← Older revision		Revision as of 14:44, 24 August 2013
Line 1:		Line 1:
			{{delete}}
	===Overview===		===Overview===

Line 24:		Line 25:

	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.		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.

	~~[[Category:Game Dev]]~~

Flozi: Game development -> Game Dev

2013-03-25T20:14:20Z

Game development -> Game Dev

← Older revision		Revision as of 21:14, 25 March 2013
Line 25:		Line 25:
	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.		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.

	[[Category:Game ~~development~~]]		[[Category:Game Dev]]

Knorke at 00:52, 30 December 2011

2011-12-30T00:52:43Z

← Older revision		Revision as of 01:52, 30 December 2011
Line 3:		Line 3:
	This is a specification of how Spring will support mods and switching between them.		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 /~~mods~~. Spring supports multiple subfolders within /~~mods~~: '''/~~mods~~/my_nifty_game/game.sdd''' and '''/~~mods~~/my_nifty_game/game_support.sdz''' are both correct.		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.		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.		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.
Line 13:		Line 13:

	===Replacements===		===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.
	When releasing new versions of a ~~mod~~ 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.		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.
Line 24:		Line 23:
	===Distribution===		===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.		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.

	[[Category:Game development]]		[[Category:Game development]]

Knorke: /* Overview */ and games

2011-04-30T08:30:59Z

Overview: and games

← Older revision		Revision as of 09:30, 30 April 2011
Line 3:		Line 3:
	This is a specification of how Spring will support mods and switching between them.		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 all their subfolders. It is recommended to put your game in a subfolder of /mods. Spring supports multiple subfolders within /mods: '''/mods/my_nifty_game/game.sdd''' and '''/mods/my_nifty_game/game_support.sdz''' are both correct.		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 /mods. Spring supports multiple subfolders within /mods: '''/mods/my_nifty_game/game.sdd''' and '''/mods/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.		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.

Knorke: /* Modinfo.lua Example */ see Modinfo.lua

2011-04-30T08:30:01Z

Modinfo.lua Example: see Modinfo.lua

@@ Line 9: / Line 9: @@
 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 Example===
+===Modinfo.lua===
-Modinfo.lua, like any Lua language file, can contain active code, should you want it to.  But it is mainly just designed to refer Spring's Virtual File System (VFS) to the correct game files and any dependencies of your project.
+See [[Modinfo.lua]]
 ===Replacements===

Abma: /* Distribution */

2010-12-05T01:06:56Z

Distribution

← Older revision		Revision as of 02:06, 5 December 2010
Line 52:		Line 52:
	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.		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.

	[[Category:~~Mod~~ development]]		[[Category:Game development]]

Abma: moved Mod specification to Game specification

2010-12-05T00:53:20Z

moved Mod specification to Game specification

← Older revision	Revision as of 01:53, 5 December 2010
(No difference)

Braindamage: use unitsync names, not filenames!

2010-08-23T11:52:40Z

use unitsync names, not filenames!

← Older revision		Revision as of 12:52, 23 August 2010
Line 25:		Line 25:
	modtype=1,		modtype=1,
	depend= {		depend= {
	~~depend01.sdd~~,		"Content 1",
	~~depend02.sdd~~,		"Content 2",
			--do not used filenames, use the internal name, or downloader programs will fail to download the dependencies automatically
	},		},
	}</pre>		}</pre>

Argh at 10:20, 25 February 2010

2010-02-25T10:20:31Z

← Older revision		Revision as of 11:20, 25 February 2010
Line 37:		Line 37:
	'''Modtype''' determines whether Spring's archive system sees the game as a game, or as an "invisible" file that can only be called as a Dependency. If set to any number except for 1, it will not be visible to end-users as a "game", but you can still refer to it in the depend table.		'''Modtype''' determines whether Spring's archive system sees the game as a game, or as an "invisible" file that can only be called as a Dependency. If set to any number except for 1, it will not be visible to end-users as a "game", but you can still refer to it in the depend table.

	===~~Dependencies~~===		===Replacements===

	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.

	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~~.		When releasing new versions of a mod 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.

	~~===Replacements===~~

	When releasing new versions of a mod 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 ~~depends~~ on the archive. To avoid this, replacements can be used.		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.		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.
Line 56:		Line 47:
	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.		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.

	===~~Final words~~===		===Distribution===

	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)~~.		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.

	[[Category:Mod development]]		[[Category:Mod development]]

Argh: /* Modinfo.lua Example */

2010-02-25T10:14:19Z

Modinfo.lua Example

← Older revision		Revision as of 11:14, 25 February 2010
Line 32:		Line 32:

	'''Dependencies''' are files that your game depends on to operate. This may be anything- a map, another game, a folder named "my_nifty_sounds.sdd" that has a bunch of sounds in it and a modinfo.lua file to identify it as a valid file archive to Spring- basically anything goes, so long as it, like your game, is identified as a usable archive by having a modinfo.lua file in it.		'''Dependencies''' are files that your game depends on to operate. This may be anything- a map, another game, a folder named "my_nifty_sounds.sdd" that has a bunch of sounds in it and a modinfo.lua file to identify it as a valid file archive to Spring- basically anything goes, so long as it, like your game, is identified as a usable archive by having a modinfo.lua file in it.

			These files are loaded in the order listed. So if depend02.sdd contains a file with the same name as depend01.sdd, it will <u>overwrite that file</u>.

	'''Modtype''' determines whether Spring's archive system sees the game as a game, or as an "invisible" file that can only be called as a Dependency. If set to any number except for 1, it will not be visible to end-users as a "game", but you can still refer to it in the depend table.		'''Modtype''' determines whether Spring's archive system sees the game as a game, or as an "invisible" file that can only be called as a Dependency. If set to any number except for 1, it will not be visible to end-users as a "game", but you can still refer to it in the depend table.