// This is a sample ModManager Mod Definition file

// It will not actually be recognized by ModManager
// because its name is not of the format *_ModDef.txt
// Any files in the [CTP2 directory]\Mods directory
// whose names are of that format will be recognized
// and read in (so long no errors occur whilst that
// is being done).

// For example:
// APOL_ModDef.txt

// As you may have guessed, // starts a comment,
// which continues to the end of the line.

// You can seperate things in this file either
// with new lines or with tabs.

// Everything *IS* case-sensitive except the
// references to directories/files.

// The order in which things appear, or even
// whether they appear at all is not very important.
// The only required fields are the Key and Name
// fields.

// We start with the mod's Key - this key must be
// unique.  If two mods have the same key then they
// will not both be read, and other strange things
// could happen.

// I recommend that you use as the Key the initial
// part of the definition file name, so in the
// above example that would be APOL.  If everyone
// sticks to this convention then conflicts are
// impossible since only one file of that name
// can exist in the mods directory at any time.

Key	MOD // The key for this sample is MOD

// Next we have the longer name of the mod as it
// appears in the list of options

Name	The Really Wonderful Mod

// You can specify a long description for the mod.
// This should explain prerequisites and any
// other peculiarities of the mod.

// To allow for new lines in the description
// you must specify its end with an @

Description
This really is a wonderful mod!
It requires the Apolyton Pack to be used.
@

// There is the option to give your mod a version
// This means that when someone installs a new
// version ModManager will notice and perform
// a restoration and reinitialization to ensure
// that everything is back to normal.

// The version can be any string, and version
// 1 is considered different from version 1.0, etc.

// If you fail to provide a version, then it will
// be considered version 0.

Version	1

// Later I demonstrate how to specify compatibility
// with other mods - it is possible to give
// the default behaviour for mods which are not
// listed explicity.

// The default value of this default behaviour
// is No - i.e. incompatible by default.

CompatibleByDefault Yes

// If this is primarily intended to be a stand-alone
// mod then ModManager can create a setup consisting
// of this mod alone when it first encounters it.
// You can specify whether you wish this to happen
// as follows.  The default is Yes.

CreateSetup No

// Lastly we have several different possible sections
// Each is begun with a keyword, contains a list
// of items, and is ended with an @ symbol
// (or the end of the file)

// Each section can appear more than once, or
// not at all, and they can be in any order.


// You can list other mods which must be part of
// a setup before this one can be included
// under the Prerequisites heading.
// Mods should be identified by their key.

Prerequisites
APOL // Here I specify that the Apolyton Pack
@    // must be in place before this mod can be

// You can list mods with which this one
// is compatible, but does not specifically
// require (i.e. the two mods can both be
// installed and coexist happily).
// Anything listed under Prerequisites is
// also automatically considered compatible,
// and there is no need to list them again
// here.

Compatible
LOTR // So this mod claims to be compatible
@    // with the Lord of the Rings mod
     // which is rather silly, since it
     // requires the Apolyton pack.

// Conversely, you can specify mods with which
// this is certainly incompatible, so that
// they cannot both be used in the same setup

// If (for some strange reason) you list the
// same mod as being both compatible and
// incompatible then incompatibility takes
// priority.  If you make a mod incompatible
// with one of its prerequisites then it
// will be unusable.

Incompatible
@ // Here I have listed nothing at all.
  // This has the same effect as if I
  // had not bothered to put this list in.


// Now we (finally!) get to the bit where
// you actually specify what files are involved
// in the mod.

// This consists of specifications of file
// transfers.  The following comments apply
// to all such transfers:

// For each transfer you must list a source file
// and a destination file.  The locations
// should be specified as from the main CTP2
// directory, with no leading backslashes.

// All transfers are file copies - files never
// get moved.

// There is no guarantee as to what order the
// transfers will be performed, except that
// all the initialization ones will be done
// before all the others.

// You can access the users chosen language
// directory with the %l escape - this will be
// replaced with ctp2_data\[language].
// You can also use %d as a shortcut for
// ctp2_data\default.

// Paths should not include .. (to reach
// parent directory) - ModManager will generate
// an error if it encounters such paths
// (otherwise you could use this feature to
// fiddle with files anywhere on the users PC).

// Modmanager will also check the extension
// of the files being copied so that you
// don't overwrite ctp2.exe or anything similar.

// Lastly, I made it impossible to use
// any filename starting with orig_, since
// this is the prefix used by ModManager to
// preserve original files.


// Firstly we list initialization file transfers.
// These are files which will be copied
// whenever the mod is initialized
// (this will probably only occur when it
// is first noticed by ModManager, or when
// a new version is installed).

// Example uses of this feature:
// Copying some of the default sprites from the
//  original sprite folder into your mods sprite
//  folder so that you need not include those
//  sprites in the zip
// Copying files in the language-specific
//  portion of the gamefile structure into
//  the language path for this user.

// IMPORTANT:
// !!These transfers should NOT overwrite original
// gamedata files.  ModManager will NOT make
// backups of files overwritten in this way!!

Initialization
ctp2_data\english\gamedata\MOD_info_str.txt	ctp2_data\%l\gamedata\MOD_info_str.txt
@ // In this example I copy the info_str for this
  // mod into the appropriate language
  // directory so that the game will
  // find it.

// The other type of file transfers are
// application file transfers.  These are
// performed each time a mod is applied, and
// backups of overwritten files are made so that
// they can be restored later.

// This is primarily intended for replacing
// original game files, but you could also
// use it to replace files from other mods.

// For example:  You wish to make a small
// alteration to the Apolyton Pack scripts,
// and use this to replace APOL_script.slc
// with your own version.  ModManager will
// preserve a copy of the old APOL_script.slc
// under the name orig_APOL_script.slc,
// which will be restored when your mod is
// removed.
// Unfortunately, there is a problem with this
// method: if the user then installs a new
// version of the Apolyton pack with a new
// APOL_script.slc, then under the right
// conditions this new one could be replaced by
// the old one under the pretense of
// 'restoring the original'.  This is
// because all orig_* files are considered
// sacrosanct and never altered by
// ModManager when they already exist.
// To get round this problem you should
// instead list such file transfers under
// Substitution, rather than Application.
// The difference here is that the backup
// will be called subst_APOL_script.slc,
// and it will be *deleted* after it is
// copied out to restore the original
// as your mod is removed.
// That way, the problem only arises if
// the user installs a new version of the
// Apolyton Pack whist both the Apolyton Pack
// and your mod are applied.  I will try to
// warn users not to do this.

Application
%d\gamedata\MOD_gamefile.txt	%d\gamedata\gamefile.txt
ctp2_data\english\gamedata\MOD_Great_Library.txt	%l\gamedata\Great_Library.txt
@

Substitution
%d\gamedata\MOD_APOL_script.slc	%d\gamedata
@

// The last type of list is changes to be made
// to userprofile.txt.  Be careful with these
// because the user can prevent them working
// by selecting an appropriate option, and also
// they will not be removed when the mod is
// (since ModManager doesn't know what to reset
// them to).

// Remember that these are case sensitive!

UserProfile
DebugSlic	Yes
@