====================================================
Advanced Civilization: Call to Power Scenario Design
====================================================

By John Bytheway <jjb48@cam.ac.uk>
v0.81 (beta) Last Updated 2001/09/05
Please, please send in any corrections or additions.  Your contribution is welcome.
THIS MATERIAL IS NOT MADE OR SUPPORTED BY ACTIVISION

----------
0 Contents
----------

0  Contents
1  Introduction
 1.1  Notes (read this!)
2  General Concepts
 2.1  Scenarios
 2.2  The Data File Structure
3  Suggested Approach
 3.1  Step by Step Design
 3.2  Bug Fixing
 3.3  Bug Avoidance
 3.4  Designing a Tech Tree
 3.5  Tips & Tricks
 3.6  Known Bugs & Problems with CTP
4  Modification of the Rules Files
 4.1  File Structure
 4.2  Advance.txt
 4.3  Units.txt
 4.4  Improve.txt
 4.5  Wonder.txt
 4.6  Installation.txt
 4.7  Govern.txt
 4.8  Age.txt
 4.9  DiffDB.txt
 4.10 Terrain.txt
 4.11 Pop.txt
 4.12 Const.txt
 4.13 Other text files
 4.14 Obsolete Items
5  Icons and the Great Library
 5.1  Icon File Structure
 5.2  Great Library Entries
6  Strings
 6.1  gl_str.txt
 6.2  add_str.txt, cht_str.txt
 6.3  civ_str.txt
 6.4  dip_str.txt
 6.5  err_str.txt
 6.6  exp_str.txt
 6.7  help_str.txt
 6.8  info_str.txt
 6.9  junk_str.txt
 6.10 ldl_str.txt
 6.11 scen_str.txt
 6.12 Strings.txt
 6.13 tut_str.txt
7  Sprites
8  SLIC
9  AI
10 Reference
11 About the Author
12 Version History
13 The End

--------------
1 Introduction
--------------

This file is intended to give some insight into some of the more advanced methods of CivCTP scenario design.  I am open to corrections, comments & suggestions at the address above - everything from spelling corrections to high-level restructuring suggestions.  The information will tend towards low-level discussion of the nuts and bolts of scenario design, rather than more sweeping, high-level concerns.  I apologise for any inconsistencies or variable writing style.

Let me stress once more, the fastest way for this file to improve is by suggestions from you.  If you have any clarifications, confirmations, cancellations, corrections, contributions or comments then send them to me.

1.1 Notes (read this!)
----------------------

Asterisks before a statement or topic indicate tentativity.  The more asterisks, the less sure I am of the fact involved.

I assume that you are using the English version of the game.  Otherwise, simply substitute the appropriate language directory name wherever 'english' is mentioned.

Before you begin, it is vital to download the official patch to version 1.2 and the unofficial hack to version 1.21 which can be found at the official CivCTP and Apolyton sites respectively.  Without the hack, it is impossible to save a scenario game which has already been saved and loaded.

It is also highly recommended to donload EasyMod (also from Apolyton), which allows visual editing of the most relevant files.

See the references section (9) for the Apolyton address and other sources.

All dates are in the yyyy/mm/dd format.

The abbreviation c.f. and q.v. are often used here, both of which effectively mean 'see also' except that c.f. is used before the reference, while q.v. is more of an afterthought (a more literal translation is 'which you should also take a look at' - actually it just stands for 'which see' in Latin).

------------------
2 General Concepts
------------------

There are a great many aspects to scenario or modpack creation in CivCTP.  The game data is contained within the ctp_data directory, although it may also (to some extent) be placed within the scenario directories.

2.1 Scenarios
-------------

In v1.2, a scenarios directory is created within the CivCTP directory which may contain scenarios which will then be recognized by the game, and selected from.  This useful feature allows for scenarios to be managed easily and cleanly (to a certain extent)

2.1.1 Implementing scenarios

Such scenarios should follow this structure:

Each scenario pack has one directory within the scenarios directory, which may have any name.

Each scenario has one directory within the scenario pack directory which has a name of the form 'scenxxxx', where xxxx is a number.  The numbers must begin with 0000 and count upwards - this allows for 10000 scenarios within each pack.  There must be at least one scenario in each pack.

In the scenario pack directory there must be a file called 'packlist.txt' with the following three lines:

<Scenario pack name>
<Scenario pack description>
<Number of scenarios in pack>

There may also be a 115x90 16-bit Targa image called packicon.tga for the scenario pack icon.

In each scenario directory there must be a file called scenario.txt with the following two lines:

<Scenario name>
<Scenario description>

There may also be a 115x90 16-bit Targa image called scenicon.tga for the scenario icon.

Unlike Civ2, there is no provision for an extended description of the scenario.

If the scenario is to include a predefined map, this must be created using the Cheat Mode dialog in the game.  When you choose to save the scenario you will be prompted for the name of the scenario, and this must be EXACTLY the same as that which was entered in scenario.txt - the map should then be saved as 'savegame.csg' and placed in the appropriate scenario directory (NOT the scenario pack directory).

(Saved games can be found in ctp_program\ctp\save)

Modifications to the game rules can be added to a scenario by placing the appropriate files either in the scenario pack directory or the scenario directory, following the same directory structure as within ctp_data (i.e. you create 'default' and 'english' directories within the scenario or scenario pack directories.  The files withing the scenario pack directories override the default rules, and the files within the scenario directories override both the default rules and the scenario pack rules.

2.1.2 Advantages of scenarios

The advantages to implementing scenarios in this way are clear:

They allow users to easily install scenarios and keep them separate from the default rules.  They can be kept distinct, managed and deleted easily.

They allow for simple modification of the data files without fear of changing default settings or permanently damaging the game.

2.1.3 Disadvantages of scenarios

Unfortunately, as usually seems to be the case, there are flaws in the system which passed the game designers by unnoticed.  Luckily, the most important of these (that a scenario game, if saved, loaded, saved and loaded will crash the game) is fixed with the v1.21 hack.  Of course, any player who has not applied the hack will not be able to properly use the scenario.  However, there are other problems.

Primarily, not all the data files will be read from the scenario, but will always be read from the default location (Most notably const.txt and the great library text files, but there may be others).  This means that the designers of scenarios must either avoid modifications to these files (almost impossible in any major modification) or modify the default ones, which will inevitably cause problems since the scenario data is now divided between two locations.

This problem can be avoided to a certain extent for the great library files by giving them a new naming convention and putting them into the same directory as the existing GL files without overwriting.

Lastly, changes to the available civilizations will not appear since you choose your civ before (well, at the same time as) your scenario.

ModPicker, available from http://members.home.nl/paulvdb/modpick.htm addresses some of these problems.

You can instead replace the default data, since it is not particularly difficult to back up , but of course, this also has its downside, since it is now not possible to include a map easily.

2.2 The Data File Structure
---------------------------

Since CivCTP was designed to be as easy as possible to extend to different languages, the data is divided into two sections.  The language-independant section is in the 'default' directory, the language-dependant data is in the 'english' (or 'german', etc.) directory.

All the game rules, pictures and videos are in the 'default' directory (strangely, this includes the wonder videos, which include english text) which refer to other files in the language-dependant section whenever they must communicate with the player textually.

2.2.1 Further subdivisions

Within the 'default' and 'english' directory are a host of others, described briefly here:

aidata:    Contains much data on how the AI works (not for the faint-hearted)

gamedata:  default\gamedata contains most of the rules such as details on the units, wonders, terrain, etc.  english\gamedata contains al of the hard-coded strings and textual great library entries.

graphics:  Contains most of the games flat images (as 16-bit Targas (.tga) or compressed into .zfs files), the terrain (as mysterious .til files) and the sprites (.spr files).

scenarios: No known purpose - presumably a leftover from when scenarios were to be put here.

sound:     All compressed, so no way to know for sure.  Presumably non-language specific sounds (also much in english\sound).

uidata:    User interface data.

videos:    Videos both for the great library and wonders.

--------------------
3 Suggested Approach
--------------------

How you approach the task of modification depends upon the magnitude of the modification.  If you intend only to make small additions or subtractions to the rules, your task is fairly simple - it is relatively easy to add first the advances, then the improvements / units / wonders / governments and finally their assosiated great library entries, descriptions and sprites, testing at each stage.

On the other hand, if you intend to make a major modification, remodelling the entire game, including removing large chunks of any of the major files, but especially advance.txt, you have a much harder task.  Because of the interlocked nature of the files, it is very difficult to change only one, and test the changes since the game will not run until all the others which are connected are also changed, by which time it is difficult or impossible to determine the cause of any problems.

3.1 Step by Step Design
-----------------------

I recommend the following course of action to allow the most frequent testing, and hence easiest bug-finding & fixing.  Don't forget to always keep a backup of the 'last known good' setup, and to test as frequently as you can without becoming bored out of your mind.

1. Go through all files with reference to advances and remove such references.  This involves:

a) In govern.txt wonder.txt, units.txt, improve.txt, installastion.txt, terrain.txt, endgame.txt set all ENABLING_ADVANCE and OBSOLETE_ADVANCE entries to NULL.

b) In age.txt set all AGE_NUM_ADVANCES to 0 and remove all AGE_ENABLING_ADVANCE entries (remember the format to know how to put it back together).

c) In DiffDB.txt look for the ADVANCE_CHANCES section.  This determines the probability that various advances are known initially.  I'm not sure whether this can be left empty - to be safe it's probably best to leave at least one entry refering to the most lowly advance in your tech tree followed by 100 100 (i.e. certain to get it) in each difficulty setting.

2. Design your tech tree (see notes below).

3. Put back your changes in DiffDB.txt, installation.txt, terrain.txt, endgame.txt & age.txt to reflect the new tree.

4. Design your units (units.txt) (remember to include a unit with the ability to settle land so that there's a unit to start the game with, and make sure it can build a city).  Don't bother with special sprites at the moment, just use the best-fitting existing sprite.

5. Design your governments (govern.txt).

6. Design your improvements (improve.txt) and population options (pop.txt) in parallel.

7. Design your wonders (wonder.txt) (Don't forget to include a wormhole-detecting wonder if you want to allow the alien-life project)

8. Do any other minor rule-modifications in files like terrain.txt and const.txt as required.

9. Do thorough bug-testing before you invest hours in the sprites & great library.  First play against yourself and then get your freinds to come and play hotseat to test it out (Especially the combat system - are there any units which always win/lose, etc.).  If you can it's a good idea to do internet multiplay since that's somewhat simpler to avoid seeing what the other players do than in hotseat.

10. Do the sprites (using internet-downloaded ones or make your own with the tool available on the official CivCTP site) and icons.

11. If you ever want computer players, do the AI (based on playtesting above).  Alternatively, ensure that it is clear this scenario is for human players only, and edit const.txt to remove ruins (and hence chance of barbarians) and always play Ruins Only.

12. Do the great library entries and construction summaries.

13. If you're feeling especially artistic, make movies for the wonders and great library entries.

3.2 Bug Fixing
--------------

If you get a crash whilst the game is on the 'Loading...' dialog but no error message (Look carefully, sometimes the error messages are minimised or behind other open windows) then look into these, some of the more common causes:

1. You just crashed CivCTP previously, and it's confused.  Restart the computer and try again.

2. The number at the top of a file does not agree with the number of entries in it.  CAREFULLY count the entries in each recently modified file (possibly write a program for the purpose) and check against the number at the top.  This really really is the most common cause of unerrored crashes, it's astonishing how easy it is to forget to change the number at the top.

3. You don't have the v1.21 hack installed, or it's not installed properly (see how to install in section 3.3, below) - install it.

4. You tried to load a game which dates from some older version of the rules - start a new one instead.

5. The game is being loaded under default rules instead of the scenario rules - start a new game under the correct scenario rules, then choose options > new game and load the game in question.  This tells the game what rules you want to be using.

6. Check the below sections on individual files for common problems.

If you get a crash in mid-game with no error message then consider the following:

1. A computer player is trying to do something instructed in its AI which is impossible due to rule changes (This can be caused even by a single barbarian unit wandering around) - play humans only hotseat, Ruins Only and don't touch those ruins.

2. You are trying to load a queue when there's a queue from a different set of rules present - delete the offending queue (It's in ...\ctp_program\ctp\save\queues\)

3. You tried to open the ranking screen.  Sometimes this crashes the game (cause unknown - probably somehthing to do with wonders, possibly having more than 64).

If none of that helps, go back to the 'last known good' rules (ALWAYS keep a copy of the rules that you KNOW works) and do the changes in smaller increments to localise the problem.

If you're still stumped, try asking for help on the newsgroup or Apolyton forums.

3.3 Bug Avoidance
-----------------

Follow this simple advice to avoid bugs as much as possible.  Some may appear simple-minded, but need to be said nonetheless:

1. Keep a copy of the rules which you KNOW works at all times (I can't say this too often).

2. Stick to naming conventions as much as possible (not as easy as it may sound).

3. Change things as little as possible before testing.  But, on the other hand, don't test too often or you'll get bored out of your mind.

4. Don't open too many files at once.

5. Remeber to save all your open documents before testing the new rules (or the game won't know :)).

6. Don't open two copies of the same file at once.  Be especially careful of this if you're working on two computers at once (Something I often do).

7. Don't get confused between the scenarios rules files and the default rules files (or you'll get in REAL trouble).

8. Don't use words which you know you can't spell reliably if you can help it (you wouldn't believe the nightmares I had due to spelling satellite incorrectly in certain places).

9. Plan on paper (or other text files) first.

10. Use assistant programs such as EasyMod.

11. Know what you're doing before you do it.

12. Unless you are specifically experimenting or trying out some novel idea (which IS something you should be doing) stick to what you know - don't make illogical choices for data values (remember those flying submarines in Civ2?).

13. Install properly.  This is taken from a post by Don Blevens:

"Patches require specific exe files AS WELL AS the game to have been played to work properly. The reason is certain files are created or modified ONLY after the game has been played. Since I do a lot of Mod Work/Testing, I have screwed my CtP installation up quite a few times. During the re-install from scratch, I have hit about every concievable 'patch doesn't work' error. The following is guaranteed to work: 

1) Uninstall CtP and delete all directories related to it.
2) Reboot your computer
3) Do a Maximum/Full CtP install
4) Reboot
5) Start/save a game
6) Install CtP v1.2 Patch
7) Reboot
8) Start/save a game
9) Install V1.21 Hack
10) Reboot
11) Start/save a game
(Steps 12, 13 and 14 are only necessary if you want to use the No_CD Hack)
12) Install V1.2(5) No_Cd Hack
13) Reboot
14) Start/save a game
15) You are off and running"

14. Keep a copy of the rules which you KNOW works at all times (I REALLY can't say this too often).

3.4 Designing a Tech Tree
-------------------------

There are of course many ways to approach this problem, but I outline mine below, in the hope that it may be useful.

3.4.1 Bare bones

Begin by ignoring the technologies themselves but considering the things which you wish to be permitted.  Start with units, and consider the various categories (Defensive ground, slow offensive ground, fast offensive ground, bombarding ground, active defense ground, naval transport, naval subs, naval anti-subs, naval aircraft carriers, naval active defense, airborne fighters, airborne bombers, space fighters, space bombers, settlers, diplomatic / spying units, religious units, varied special units (e.g., lawyer, corporate branch, nuclear missile, eco-ranger, etc.), settling units, trade units).  Choose which categories are to exist in your scenario and map out their progression through the game (e.g. Defensive ground might go Warrior - Phalanx - Musketeer - Rifleman - Machine Gunner), and invent a technology for each one.  You should also consider city improvements in much the same way, and governments, terrain improvements & terraforming.

3.4.2 Skeleton

To connect the bones together, try to invent ways to connect the technologies together so that the tech for the more advanced unit (or improvement, etc.) requires that of the less advanced unit (e.g. Conscription (for Rifleman) requires Gunpowder (for Musketeer)).  This will give you a whole lot of tech-lines.  You will probably already have a great many ideas for links.

3.4.3 Fleshing it out

Now just let your imagination run free and link up the techs and tech-lines.  Try (insofar as it is possible) to prevent players getting too far ahead in one field compared to one which is closely related (e.g. defensive & agressive war techs), but at the same time give them as much freedom as possible in distant ones (e.g. aggressive war and cultural).  They should always have at least four techs to choose between (unless they have single-mindedly avoided an important one for a long time).  Getting this balance right is very hard.

Personally, I don't like end-of-the-line techs that don't go anywhere (Like Espionage in Civ2, Tank warfare in CivCTP), and I make sure that you need everything for the future techs at some point.  This provides another source of inspiration (not only "What advances would you need to discover this?" but also "Where does this lead?").

When you actually implement the tree in advance.txt make all the ADVANCE_COST entries small.

3.4.4 Common Bugs

(I have a program which will do all of this for me - it was simple to write, I would advise using QBASIC or Visual BASIC)

1. Non-existant prerequisites

Check you haven't got any misspellings or inconsistencies in your names that mean the prerequisite advances don't exist.  This bug isn't too serious since the game will alert you with an error message.

2. Tech loops

If you have tech A needing tech B needing tech A again (or some larger version of the same) you are in serious trouble.  In Civ2, this caused a really nasty crash, and it probably does the same in CivCTP, but I don't know since I've avoided it so far.  Just Don't Do It.

3. Unnecessary prerequisites

Not a bug as such, but if you have tech A needing techs B and C, but tech B needs tech C anyway then this is a little superfluous.  It can be useful to stop people jumping techs by finding them in ruins or swapping, but it can also be confusing to players.

3.4.4 Test

Now play a game and research all your techs in order from most primitive onwards.  Write them all down in this order on a piece of paper or in a text file.  You'll probably want to rearrange them in advance.txt into this order too.  On your list go through and decide upon points to start each of the ages, and number the advances' ADVANCE_AGE_INDEX accordingly.  Also choose the advances to affect pollution levels, roads, etc. (See section below on advance.txt)

3.4.5 Consolidation

When you have implemented all your units, improvements, etc. but before you do the wonders get your list of advances and put a mark next to each one for each thing which it allows (be it unit, improvement, government, tile improvement, installation, terrain terraforming or X-lab component).  You'll probably find that some of the advances allow many things and many allow nothing at all.  Now's your chance to rearrange these things to even out the distribution.  This can be done by:

1. Splitting advances up into smaller steps.

2. Merging advances together.

3. Moving things the advance allows to other, related advances.

4. Removing some of the things an advance allows.

5. Inventing new things for an advance to allow (Wonders are especially good for this).

Now you understand why I advised that you leave the wonder design till last.

3.4.6 Finishing touches

All that remains is to allocate each advance an ADVANCE_COST, and possibly an ADVANCE_DEFAULT_BRANCH.  (There's also the icons, but that's another matter entirely).
These are things best left to personal preference.

3.5 Tips & Tricks
-----------------

Here are some useful tricks I have found whilst editing and playtesting:

If the 'go to space layer' button is not there you can still toggle space by pressing Shift+S.

If you need to reach cheat mode in a multiplayer game you must do this by using the 'Launch editor' button where you would normally use the 'Launch' button.  Beware - once you close the cheat window you cannot get it open again.  Whilst the cheat window is open you might have difficulties selecting units or cities by clicking on them, don't forget you can use the 'next city' and 'next unit' buttons.

3.6 Known Bugs & Problems with CTP
----------------------------------

There are a number of known bugs & problems in CTP, AFAIK, they are as follows:

1. Production penalty evasion - You can evade the penalty for changing your production between different types of construction by inserting the new item after the first in the queue and then removing the first item, instead of changing through the 'Build' button.

2. Spy nukes / nanite defuser - A wonder with the nanite defuser flag doesn't stop spys nuking.

3. Expulsion in enemy cities - You can expel units in enemy cities!

5. There are some others related in the text detailing the specific rules files below.

---------------------------------
4 Modification of the Rules Files
---------------------------------

Now we proceed to detailed discussion of the various rules files (mostly from default\gamedata).

Each file will be taken in turn, in a rough order of importance.  A general discussion of each followed by notes about the individual data values and flags.  The order in which these values and flags are taken is meant to group related items.

4.1 File Structure
------------------

By and large, the files all follow a similar structure:

The first line contains the number of entries in the file

Each entry consists of a name, followed by various properties enclosed in braces (i.e. {})

The properties are either data values, followed by one or more data or flags, which have no associated data.  The data values can be either compulsory or optional, obviously flags are always optional.

Tab charachters or new lines separate entries.

Comments are preceded by a # and ended by a new line.

Literal strings are enclosed in quotes.

The description of a data value will take the following form:

<Data value name> <list of arguments>
<Description of effect & other pertinent details>

e.g.

SLAVE_RAIDS <float> <float> <integer> <integer> <sound reference> <special effect reference>
Slaving ability.  *The two floats are the probabilities of success and of being captured.  **The integers determine the amount of unhappiness caused by the raids and the number of turns the unhappiness persists.

Here, the list of arguments is the sequence of phrases in angle brackets.  A float is any number, often a probability (and hence limited to the interval [0,1]).  An integer is a whole number.  Other types of argument usually refer to the names of entries in other (or the same) files.

The arguments are seperated by spaces in this file, but in the actual data file they must be seperated by tabs.

Floats must have a '0' before their decimal point (i.e. '0.5' is OK, '.5' is not).

If you want to put a whole number where a float is possible it is advisable to add .0 to the end to remind yourself and anyone else that fractions are possible.

Some of those classified as integers may in fact be floats, but probably not vice versa.

4.2 Advance.txt
---------------

Advances are the basis of Civilization, and its defining charachteristic.  It is vital to have a well-structured tech tree, and this is what constitutes the major strategy element of most games - choosing which direction to explore the tree.

4.2.1 Repercussions

There are BIG repercussions to modifications of this file.  As well as gl_str.txt for the advance names, the following files reference advances for enabling and obsoleting purposes:

govern.txt wonder.txt, units.txt, improve.txt, installastion.txt, terrain.txt, endgame.txt

There is also age.txt, which defines the progression between ages in terms of advances required.

Lastly, DiffDB.txt contains lists of advances which may be given to players at the start of the game.

advanceicon.txt is also closely connected to advance.txt, but you can avoid the necessity of editing that temporarily by giving all the advances the same icon (e.g. ICON_ADVANCE_DOMESTICATION).

4.2.2 Limitations

There is no known limit to the number of advances - 230 works fine but beware of exceeding 256.

It is advisable to have at least one advance with each flag if you ever want the thing in question to be available.  Many of the things referenced in the advance flags are also referenced elsewhere (e.g. you have an advance with ALLOWS_ROADS, but terrain.txt also gives the advance required for roads on each terrain type).  I have no idea what will happen if these disagree.

ADVANCE_COST MUST come after all the other data values or you will get mysterious error messages.

If you ever want pollution then don't forget to specify it here.

4.2.3 Compulsory data values

ADVANCE_DEFAULT_ICON <icon reference>
Specifies the icon to be used by the advance.  (c.f. advanceicon.txt).

ADVANCE_DEFAULT_BRANCH <branch reference>
Specifies the branch in which the advance is found (c.f. BranchID.txt).  Determines the order in which the choices appear on the advance choice dialog and the pictures which appear next to the advances on the science screen.

ADVANCE_AGE_INDEX <age index (integer)>
Specifies the age in which the advance is found (c.f. Age.txt).  *DOES NOT determine progression from one age to another, but only the picture, but only the picture in the science screen.

POWER_POINTS <integer>
*This is obsolete in units.txt - probably also here.

ADVANCE_COST <integer>
Cost, in 'lightbulbs' (or gold, if you prefer) to research.  *This is not the only factor which determines this, since the game also makes advances harder to research as the player progresses (As in Civ2).  Depending on the rate at which you intend the game to progress and how easy it is to get science (Depends on terrain, improvements, wonders, governments, wages), you should probably use values similar to those in the default rules.  There is no need to have large chunks of advances with the same cost - you can have a gradual progression from cheap to expensive (In one scenario I had each advance 5% more expensive than the last) or the costs randomly jumping about however you wish.  ADVANCE_COST MUST come after all other data values (including optional ones).

4.2.4 Optional data values

ADVANCE_POLLUTION_SIZE_MODIFIER <integer>
Change advance makes to pollution due to city size.

ADVANCE_POLLUTION_PRODUCTION_MODIFIER <integer>
Change advance makes to pollution due to production.

4.2.5 Flags

ALLOWS_ROADS
Roads can be built once researched.

ALLOWS_RAILROADS
Railroads can be built once researched.

ALLOWS_MAGLEV
Maglevs can be built once researched.

ALLOWS_TUNNELS
Undersea tunnels can be built once researched.

(I don't think any of the above four flags actually do anything, I think they are overridden by terrain.txt)

ALLOWS_TRANSFORM
Transformation can be done once researched.

ALLOWS_INFRASTRUCTURE
Infrastructure can be built once researched.

ALLOWS_CAPITALIZATION
Capitalization can be built once researched.

ALLOWS_DEEP_OCEAN
Deep ocean can be seen once researched.

ALLOWS_NUKE
*Allows spies and related units to nuke cities.

ALLOWS_ALIEN_LIFE
*Can build xenolab.

NO_INDEX
No entry in the great library

4.3 Units.txt
-------------

Units.txt is the most complex file by far, and much of it's contents is obscure, obsolete or inconsistent.  When making your own units, it is vital to carefully consider as much as you can of what follows, so as to avoid strange problems such as transport which have holes but nothing that will fit in them.

It is usually best to begin with a working unit and make changes to it - there are certainly a wide variety to choose from in the default rules, and if you want more, look at scenarios available online.

4.3.1 Repercussions

There are few repercussions to modification of units.txt, but you must alter gl_str.txt and take note of uniticon.txt and SpriteID.txt.

The costs and some other information about the various special abilities are contained in order.txt.

4.3.2 Limitations

There is no known limit to the number of units.  It can exceed 128, but beware of exceeding 256.  Unfortunately, there IS a limit of a little less than 199 sprites for units (there are 199 slots but some of them have unreferenced files in them - replace them at your own risk), so if you intend to exceed this many units, they will have to share sprites.

*The unit given to the player at the start of the game is the first unit on the list with the ability to settle land - so you should certainly have one such unit.  If you wish the plyer to first have a sea or space settler then you will have to use a SLIC trigger to create the new settler and kill the old one (make sure you do it in that order).

4.3.3 Compulsory data values

SHIELD_COST <integer>
Cost to build in shields (Cogs?).

POWER_POINTS <integer>
Obsolete.

MAX_HP <integer>
Hit points (at war - less if stood down or on alert (unless IS_SPECIAL_FORCES - q.v.)).

ATTACK <integer>
Attack strength (10 times that which you see in-game).

DEFENSE <integer>
Defense strength (10 times that which you see in game).

FIREPOWER <integer>
Firepower (Enemy hit points removed per 'hit').

ZB_RANGE_ATTACK <integer>
Bombard strength (Also strength when in second row of battlefield, and for active defense).

BATTLEFIELD_RANGE <integer>
BATTLEFIELD_RADIUS <integer>
*These are related to the positioning on the battlefield and the distance the unit can shoot on it.  *The two values appear to always be the same for combat units, but diffenrent for non-combat ones.

VISION_RANGE <integer>
Vision range (In squares - don't forget that it's circular-ish).

ACTIVE_DEFENSE_RANGE <integer>
Range of active defense (In squares - I don't know whether this is circular or square).

ELECTRONIC_COMBAT_FACTOR <integer>
Obsolete.

MAX_MOVEMENT <integer>
Movement (1 turn) (100ths of squares).

FUEL <integer>
Fuel (100ths of squares).  Units will only die when out of fuel with the NO_FUEL_THEN_CRASH flag.

SHIELD_HUNGER <integer>
Upkeep (shield/turn) (affected by alert status and IS_SPECIAL_FORCES).

FOOD_HUNGER <integer>
**Upkeep (food/turn).  Never used - possibly no effect.

DEFAULT_SPRITE <sprite reference>
Sprite (c.f. SpriteID.txt).  Also determines picture in Cheat Mode's Unit maker.

DEFAULT_ICON <icon reference>
Icon (c.f. uniticon.txt).  Determines picture in units tab, and on construction options list, short description on construction options list and great library entry.

DESCRIPTION <description reference>
Obsolete (c.f. junk_str.txt).

SOUND_SELECT1 <sound reference>
SOUND_SELECT2 <sound reference>
SOUND_MOVE <sound reference>
SOUND_ACKNOWLEDGE <sound reference>
SOUND_CANTMOVE <sound reference>
SOUND_ATTACK <sound reference>
SOUND_WORK <sound reference>
SOUND_VICTORY <sound reference>
SOUND_DEATH <sound reference>
These determine the sound made by the unit under the gived conditions (c.f. sounds.txt).

ENABLING_ADVANCE <advance reference>
Advance required to build the unit (c.f. advance.txt).  NULL for none.

OBSOLETE_ADVANCE <advance reference>
Advance which makes unit obselete (c.f. advance.txt).  NULL for never obsolete.
This data value may be repeated to allow for more than one obsoleting advance, but this results in messages saying a unit is obsolete more than once.

CHEAT_INDEX <integer>
Determines which tab on the cheat/unit screen this unit is placed under:
1 - Army
2 - Navy
3 - Air Force
4 - Space
5 - Special
6 - Not present (e.g. caravans, etc.)

4.3.4 Optional data values

CITY_GROWTH_MODIFIER <float>
Fraction of normal growth rate at which this city grows (applies only to cities).

BONUS_FOOD <integer>
Extra food that is obtained from square occupied by unit.  Only one unit can have this effect on each square, addition of further units will not add more food.  **May work negative - thus dissuading players from having the given unit sitting around in their city radius or to deplete enemy food stocks?

BOMBARD_ROUNDS <integer>
Number of potential hits per bombard.  Note that bombardment is always at firepower 1, so the number here is the most hit points that can ever be removed by bombardment.

DEFEND_AGAINST_SPIES <fraction>
Makes spies less successful either BY this fraction or TO this fraction (i.e. does 0.25 make spies three-quarters as effective or one-quarter as effective or does it decrease chance of success by 25%?).

DEATH_INCREASES_GLOBAL_WARMING <integer>
*Adds this much to pollution counter when unit dies.  **Possibly negative to promote eco-units?

LAUNCH_DESTROYS_OZONE <integer>
*Adds this much to pollution counter when unit launches to space.

GOVERNMENT_TYPE <government reference>
Available only in this government.  This data value may be repeated to allow for more than one government which can build this unit.  If this value is omitted, all governments can build the unit.  You can use GOVERNMENT_ANARCHY.

SETTLE_CITY_TYPE <unit reference>
City created when unit builds.  **Possibly can build more than one type of city (allowing for land/sea engineers etc. **Possibly can 'build' into a non-city unit (e.g. deploying a catapult which has been brought dissasembled to an enemy city).  c.f. SETTLE_... flags.

REVOLUTION <sound reference> <special effect reference>
Revolution ability - This is an ability which CITIES have (not to be confused with spies INCITE_REVOLUTION ability).  I have no idea what would happen if you had a city without this.

CAN_REFORM <sound reference> <special effect reference>
Reformation ability (undoes conversion of city & causes unhappiness).

SLAVE_RAIDS <float> <float> <integer> <integer> <sound reference> <special effect reference>
Slaving ability.  The two floats are the probabilities of success and of being captured.  **The integers determine the amount of unhappiness caused by the raids and the number of turns the unhappiness persists.

SETTLER_SLAVE_RAIDS <sound reference> <special effect reference>
Slaving settlers ability.  This always succeeds.

TRANSPORT_CAPACITY <integer> <sound reference> <special effect reference>
Units capacity & sounds for load/unload for a transporting unit.  Use in conjunction with CAN_CARRY_ flags (q.v.)

ESTABLISH_EMBASSY <sound reference> <special effect reference>
Establish embassy ability (as diplomat).

INVESTIGATE_CITY <float> <float> <integer>
Investigate city aility.  Floats are probabilities of success and capture.  **Integer possibly related to wariness?

CAUSE_UNHAPPINESS <?> <integer> <integer> <sound reference> <special effect reference>
Cause unhappiness ability.  First parameter is always 1 - meaning unknown (possibly probability of success).  *Integers are amount of unhappiness and turns it pesists.  **This is somehow related to the CAN_SOOTHSAY and CONDUCT_HITS abilities, which follow it (in cleric, televangelist & ecoterrorist but not in subneural ads) and are the abilities displayed to the player.

CAN_SOOTHSAY <sound reference> <special effect reference>
Soothsay ability (as cleric/televangelist).  **Should follow CAUSE_UNHAPPINESS.

INDULGENCE_SALES <sound reference> <special effect reference>
Indulgence sales ability (inc. happiness & divert gold, as cleric).

CONVERT_CITIES <float> <float> <sound reference> <special effect reference>
Convert population ability (diverts gold).  Reversed by reformation ability.  *Floats are probabilities of success and capture.

INJUNCTIONS <sound reference> <special effect reference>
Injunction ability (stops production for turn in target city, as lawyer).

SLAVE_UPRISING <sound reference> <special effect reference>
Cause slave uprising ability (as abolitionist)

UNDERGROUND_RAILWAY <float> <float> <sound reference> <special effect reference>
Free slaves ability (as abolitionist).  *Floats are probabiity of success and capture.

STEAL_TECHNOLOGY <float> <float> <float> <sound reference> <special effect reference>
Steal technology ability (as spy).  *Floats are probability of success, capture and of spy becoming veteran.

INCITE_REVOLUTION <float> <float> <float> <sound reference> <special effect reference>
Incite revolution ability (as spy).  *Floats are probability of success, capture and of spy becoming veteran.

PLANT_NUKE <float> <float> <sound reference> <special effect reference>
Plant nuke in city ability (as spy).  *Floats are probability of success and capture (need no veteran probability since spy dies if successful.

NUCLEAR_ATTACK <sound reference> <special effect reference>
Attack causes nuclear explosion (as nuke).

CREATE_FRANCHISE <float> <sound reference> <special effect reference>
Create franchise ability (diverts production) (as corporate branch).  **Float is probability of success.

CONDUCT_HITS <sound reference> <special effect reference>
Conduct hits ability (temporary unhappiness, as ecoterrorist).  **Should follow CAUSE_UNHAPPINESS entry.

NANO_TERROR <float> <sound reference> <special effect reference>
Nano terror ability (destroys improvements & spreads (c.f. Const.txt for prob. of success), as ecoterrorist).  **Float is probability of success.

BIO_TERROR <float> <sound reference> <special effect reference>
Bio terror ability (temporary unhappiness & spreads (c.f. Const.txt for prob. of success), as infector).  **Float is probability of success.

CREATE_PARKS <sound reference> <special effect reference>
Create parks ability (destroy target city and all tile improvements & units within city radius, as eco-ranger).  **Units with this ability cannot be built until a wonder with ENABLE_PARK_RANGERS flag has been built.

4.3.5 Flags

LAND_CITY_CAN_BUILD
SEA_CITY_CAN_BUILD
SPACE_CITY_CAN_BUILD
*Usually units can be built in cities that match their movement class, or coastal cities which can build sea units.  To allow extra types of cities to build a unit use these flags.  Don't give LAND_CITY_CAN_BUILD to sea units unless you want them to end up trapped.

BUILDING_REMOVES_A_POP
Building this unit will decrease the parent city's population by one (as settler).

ONLY_BUILD_ONE
Units without this flag will be built indefinately if at the end of a build queue.  If given the flag, when they are built (if at the end of a queue), the queue will be declared empty.

SIZE_SMALL
SIZE_MED
SIZE_LARGE
These determine whether the unit will fit into various transports (c.f. CAN_CARRY_...).  You should give one to each unit.  **Presumably, a unit with none of the above flags would be untransportable, and one with more than one could be transported by any transport which could carry either.

MOVEMENT_TYPE_LAND
MOVEMENT_TYPE_MOUNTAIN
MOVEMENT_TYPE_WATER
MOVEMENT_TYPE_SHALLOW_WATER
MOVEMENT_TYPE_AIR
MOVEMENT_TYPE_SPACE
These determine the regions in which the unit can move.  **Beware MOVEMENT_TYPE_SHALLOW_WATER because if the appropriate wonder is active, units with this flag can move in deep water too (c.f. wonder.txt).

LOSS_MOVE_TO_DMG_NONE
*Normally units lose movement as they are damaged.  This flag means that they do not, i.e. they are always at full movement capacity.

VISIBILITY_CLASS_0
VISIBILITY_CLASS_1
VISIBILITY_CLASS_2
VISIBILITY_CLASS_3
VISIBILITY_CLASS_4
VISIBILITY_CLASS_5
VISIBILITY_CLASS_6
VISIBILITY_CLASS_7
VISIBILITY_CLASS_8
VISIBILITY_CAN_SEE_0
VISIBILITY_CAN_SEE_1
VISIBILITY_CAN_SEE_2
VISIBILITY_CAN_SEE_3
VISIBILITY_CAN_SEE_4
VISIBILITY_CAN_SEE_5
VISIBILITY_CAN_SEE_6
VISIBILITY_CAN_SEE_7
VISIBILITY_CAN_SEE_8
Between them, these sets determine what can see what.  They are fairly self-explanatory.  If you want to stick to the conventions in the default rules, the classes are:
0 - Normal units,
1 - Underwater (e.g. submarine),
2 - Extra-stealthy underwater (e.g. crawler, stealth sub),
3 - Trade units (e.g. corporate branch),
4 - Hide-in-plain-sight units (e.g. cleric, slaver),
5 - Covert ops (e.g. spy, ecoterrorist).
6, 7, 8 - Unused in normal rules
But there is no reason to keep the units sorted like this except convention.
Don't forget that any unit is visible if you try to move into its square, and that units can be located by their ZOC.
I have no idea why there are 9 classes - that seems a very peculiar number.
*A unit with no VISIBILITY_CLASS is always invisible.
**A unit with more than one VISIBILITY_CLASS can be seen by any unit which can see ANY of the classes.
*A unit with no VISIBILITY_CAN_SEEs is blind (perhaps an underground APC?)

IS_STEALTHY
Don't know - only the phantom has this flag by default, probably obsolete but give it to cloaking units to be safe.

CAN_CLOAK
Allows the unit to cloak and thus become harder (impossible?) to see.

CAN_CARRY_SMALL_LAND
CAN_CARRY_MED_LAND
CAN_CARRY_LARGE_LAND
CAN_CARRY_SMALL_AIR
CAN_CARRY_MED_AIR
CAN_CARRY_LARGE_AIR
CAN_CARRY_SMALL_SPACE
CAN_CARRY_MED_SPACE
CAN_CARRY_LARGE_SPACE
Determines the types and sizes of units which can be carried.  It is strongly advised that you only allow units to transport things smaller than themselves.  **The type of a unit (LAND / SEA / AIR) is determined by it's MOVEMENT_CLASS - presumably their is some kind of priority for units with more than one MOVEMENT_CLASS, probably LAND over SEA and SPACE over AIR.  It appears to be impossible to transport sea units.  c.f. SIZE_... flags and TRANSPORT_CAPACITY data value.

CAN_BOMBARD_LAND
CAN_BOMBARD_MOUNTAIN
CAN_BOMBARD_WATER
CAN_BOMBARD_SPACE
Allows a unt to bombard the given regions.

CAN_COUNTER_BOMBARD
Not sure - I've never seen it happen in a game.  Only interceptors and space fighters have this by default.

CAN_BEACH_ASSAULT
*Without this a unit cannot attack a land square from a beach square or assault an underwater city (**or a space city? - c.f. ATTACK_FROM_SPACESHIP).  Don't forget to give this to all your aircraft.

ATTACK_FROM_SPACESHIP
**Without this a unit cannot attack a space city from a space transport.  You might need CAN_BEACH_ASSAULT too.  You do NOT need to give this to spacecraft, only to units attacking from within transport.

LAND_ATTACK
MOUNTAIN_ATTACK
SEA_ATTACK
SHALLOW_WATER_ATTACK
UNDERWATER_ATTACK
AIR_ATTACK
SPACE_ATTACK
Most of the time a unit can attack that which is logical.  I'm not sure about the exact rules.  If you find that a unit cannot attack when you think it should be able to, add one of these flags.  Check default rules for guidance.

ACTIVE_DEFENSE_ONLY_WHEN_CARRYING_ENABLERS
ENABLES_CARRIER_ACTIVE_DEFENSE
These two together supply conditional active defense.  The unit with ACTIVE_DEFENSE_ONLY_WHEN_CARRYING_ENABLERS will have active defense only when it contains a unit with ENABLES_CARRIER_ACTIVE_DEFENSE.

NO_LAND_ATTACK
NO_MOUNTAIN_ATTACK
NO_SEA_ATTACK
NO_SHALLOW_WATER_ATTACK
NO_AIR_ATTACK
NO_SPACE_ATTACK
Use these to stop units attacking when they are able to but shouldn't be, e.g. bombers should have NO_AIR_ATTACK.

DEFEND_AIR
DEFEND_SPACE
These determine the regions covered by a unit's active defense.  Use DEFEND_SPACE with extreme caution, since it can really surprise people with units flying about up there.

SETTLE_LAND
SETTLE_MOUNTAINS
SETTLE_WATER
SETTLE_SPACE
These determine the regions settleable by a unit with SETTLE_CITY_TYPE (q.v.).

HAS_POP_AND_CAN_BUILD
This makes a unit a city - it has a population and can build stuff.

EXERTS_MARTIAL_LAW
This causes a unit to increase happiness in appropriate governments.

CAN_EXPEL_POP
Pretty much all units have this.  Don't know what effect it has.

CAN_PILLAGE
Allows a unit to pilliage tile improvements.

CAN_EXPEL
Allows a unit to expel others with CAN_BE_EXPELLED (q.v.).

CAN_PIRATE
Allows a unit to pirate trade routes.

CAN_SUE
Allows a unit to sue others with CAN_BE_SUED (q.v.)

IGNORE_ZOC
Allows a unit to move regardless of enemy ZOCs.

VICTORY_ENSLAVEMENT
**Enslaves when victorious in combat?

CANT_CAPTURE_CITY
Can't be used to capture an enemy city.

CANT_ENTRENCH
Can't fortify.

CANT_PATROL
*Can't sentry/sleep.

CAN_BE_SUED
Can be sued by others with CAN_SUE (q.v.).

CAN_BE_RUSTLED
Obsolete.

CAN_BE_EXPELLED
Can be expelled by others with CAN_EXPELL (q.v.).

HAS_NO_ZOC
Exerts no ZOC and thus affects enemy movement less.

DEATH_EFFECTS_HAPPY
*The death of the unit will affect the happiness of the citezens in your empire (depending upon government).

IS_SPECIAL_FORCES
Regardless of alert status, this unit is aways at full hit points and requires full support.

IS_TELEVANGELIST
This flag causes the unit to become more effective in its conversion against a city when that city includes an improvement with the DOUBLES_EFFECT_OF_TELEVANGELISTS flag (q.v.).  Check const.txt for more conversion information.

IS_SPACE_LANDER
IS_SPACE_LAUNCHER
These allow the unit to move between ground and space of it's own accord (c.f. LAUNCH_DESTROYS_OZONE).  Rail launchers can launch any unit which will fit into a CARGO_POD (c.f. IS_CARGO_POD) and the star ladder effect can move any unit in or out of space.

IS_CARGO_POD
The unit with this flag will be used to transport any non-space unit mving around in space.  **You may be able to have more than one unit like this, affected by ENABLING_ADVANCE & OBSOLETE_ADVANCE, possibly getting larger (in terms of size of units it can contain, not their number) as the game progresses.

IS_TRADER
A unit with this flag will not appear on the map when built, but can be used to make trade routes.  Having more than one trader is useful only if their production cost changes (and possibly their upkeep?)

NEEDS_NO_SUPPORT
**Doesn't appear on the units screen?  Only cities have this by default.

NO_INDEX
No entry in the great library.

CANT_BUILD
Can't be built in a city (e.g. cities, cargo pods)

NO_SLAVES
*Can't be built if either the empire or the city has slaves (not sure which).

NO_FUEL_THEN_CRASH
Crashes if it runs out of fuel.

SINGLE_USE
Dies when used to attack (e.g. missile) after combat is over.

PARATROOPER
Can paradrop (c.f. const.txt, PARATROOPER_TRANSPORT).

ASSISTED_DROPS
**Can drop form space onto a city.

PARATROOPER_TRANSPORT
A unit with this is created temporarily to transport paratroopers to their destination whenever a paradrop order is issued.  Having more than one is probably pointless unless they are affected by ENABLING_ADVANCE and OBSOLETE_ADVANCE but I don't think they are.

ADVERTISES
Don't know.  Possibly related to CAUSE_UNHAPPINESS (q.v.).

WORMHOLE_PROBE
When a unit with this enters the same square as the wormhole it will dissapear and the player may begin the X-Lab.

4.3.6 Units.txt commentary

There is an awful lot to assimalate about the units.txt file, and it's easy to become confused.  Here I present a summary of the information collected into categories:

Combat

Initiated combat takes place when a deliberate assault is made.  The outcome is determined by the AATACK, ZB_RANGE_ATTACK, DEFENSE, HIT_POINTS, and FIREPOWER values of the units and their BATTLEFIELD_RANGE and BATTLEFIELD_RADIUS.  The ELECTRONIC_COMBAT_FACTOR does nothing - ignore it.  The likelyhood of population decrease improvement destruction on assault in set in const.txt.

Bombarding is determined by the bombarding units ZB_RANGE_ATTACK, BOMBARD_ROUNDS and has nothing to do with FIREPOWER (bombarding always at firepower 1).  If appropriate units are present, there may be a COUNTER_BOMBARDment  The likelyhood of population decrease and improvement destruction on bombardment in set in const.txt.

ACTIVE_DEFENSE takes effect when an enemy unit passes within the ACTIVE_DEFENSE_RANGE of a unit with DEFEND_AIR or DEFEND_SPACE.  The strength of the attack is dependant upon ZB_RANGE_ATTACK and possiby BOMBARD_ROUNDS and FIREPOWER.

Movement

Units can move within the regions defined by their MOVEMENT_TYPE_... flags.  Their maximum movement in a single turn is set by MAX_MOVEMENT, and the amount of movement used up by various types of movement are defined in terrain.txt.  Their FUEL is decreased at the same rate, and reset to full if they end their turn in a freindly city or airbase.  If the fuel runs out and they have the NO_FUEL_THEN_CRASH flag then they will die.  If they end their turn (with space bar) all remaining movement and the same amount of fuel is used up.

Units with IS_SPACE_LAUNCHER and IS_SPACE_LANDER can move between air and space, but their LAUNCH_DESTROYS_OZONE.

If the unit is a PARATROOPER, it can paradrop a distance defined in const.txt, carried by a PARATROOPER_TRANSPORT.  There is a chance of a miss to a neighbouring square (c.f. const.txt).

If a unit CAN_BEACH_ASSAULT, then it can attack land squares from sea transports and underwater cities from crawlers and the like.  If the unit can ATTACK_FROM_SPACESHIP, it can assault space cities from a space transport.  In fact, I am told that all units can make amphibious assaults, but I don't know about space-city assaults).

Abilities

There are a whole plethora of unit abilities.  It's generally best to simply copy them from existing units.  If you plan to fiddle with the numbers, remember to playtest the unit in question to ensure its effectiveness is as desired.  The cost of abilities and the movement they use up are defined in order.txt.

4.4 Improve.txt
---------------

Improve.txt is fairly simple, and you chouldn't have any trouble working out what's going on.  The most important thing to keep track of is which of the values take integers and use them as a percentage increase/decrease and which take floats and use them as a fraction increase/decrease.

4.4.1 Repercussions

As well as gl_str.txt, it is important to consider pop.txt, since the population requirements are in terms of improvements.  Improveicon.txt is less closely dependant upon improve.txt.

4.4.2 Limitations

There is no known limit to the number of improvements.  43 works fine.  Since their is a limit of 64 wonders, there may be a similar one for improvements.

*Possibly you need an improvement called IMPROVEMENT_CAPITOL to be placed free in your first city - but it may determine this from flags.

4.4.3 Compulsory data values

IMPROVEMENT_PRODUCTION_COST <integer>
Cost to build in shields.

IMPROVEMENT_UPKEEP <integer>
Cost to upkeep in gold/turn.

IMPROVE_DEFAULT_ICON <icon reference>
Improvement icon (c.f. improveicon.txt).

IMPROVE_DESCRIPTION <description reference>
Obsolete (c.f. junk_str.txt).

ENABLING_ADVANCE <advance reference>
Advance required to build.

OBSOLETE_ADVANCE <advance reference>
Never used in the default rules, but a powerful tool.  When the advance in question is discovered the relevant improvement is removed from all cities in that civilization, and it can no longer be built.  Because this never normally occurs, there is no notification message, and one should be added in SLIC.

4.4.4 Optional data values

IMPROVEMENT_FLAG_PRODUCTION_PERCENT <production type reference> <integer>
Type of production (valid production type references are: PRODUCTION_TYPE_KNOWLEDGE, PRODUCTION_TYPE_FOOD, PRODUCTION_TYPE_PRODUCTION and PRODUCTION_TYPE_GOLD) and increase (%).

IMPROVEMENT_FLAG_SILO <integer>
Reduction in storage required for growth (%).  *I think this works by reducing the amount of food required to grow in population.

IMPROVEMENT_FLAG_DEFENDERS_BONUS <integer>
Increase in defense of units within.  This is NOT a percentage, it is an amount of increse in 10ths of the values you read in the game.

IMPROVEMENT_FLAG_PREVENT_CONVERSION <integer>
*Chance of preventing conversion (%).  Or possibly reduction in the chance of success of conversion.

IMPROVEMENT_FLAG_HAPPY_INC <integer>
Increase in happiness (possibly argument is actually a float).

IMPROVEMENT_FLAG_HAPPY_INC_SWITCH <integer> {<list of govt. mods.>}
Increase in happiness (variable by government), for example (Taken from cathedral):
IMPROVEMENT_FLAG_HAPPY_INC_SWITCH	3
{
GOVERNMENT_COMMUNISM	1
GOVERNMENT_THEOCRACY	5
}
There is a lot more to this flag than it might appear at first sight, consider the following which might be added to some capitalist institution:
IMPROVEMENT_FLAG_HAPPY_INC_SWITCH	0
{
GOVERNMENT_COMMUNISM	-5
}

IMPROVEMENT_FLAG_LOWER_CRIME <float>
Fraction by which crime reduced.

IMPROVEMENT_FLAG_SCIENCE_PER_POP <float>
IMPROVEMENT_FLAG_GOLD_PER_CITIZEN <float>
Provides this much science or gold for each population of city.

IMPROVEMENT_FLAG_LOWER_OVERCROWDING <integer>
Increases overcrowding by this much (Use negative number for decrease).

IMPROVEMENT_FLAG_POLLUTION_BONUS <float>
Increases pollution by this fraction.

IMPROVEMENT_FLAG_LOWER_PEACE_MOVEMENT <float>
Increases unhappiness due to war by this fraction.

IMPROVEMENT_FLAG_MOVEMENT_TYPE_IS_REFUELED <movement type reference>
**Refuels units of this movement type.  Don't understand this, since units are always refuelled upon ending turn in city.  Possibly refuels units which just pass through and don't stop.  Possibly obsolete.

IMPROVEMENT_FLAG_FOOD_VAT <?>
Prevents starvation (dunno what number does - it's not the pollution per food, which is set in const.txt).

4.4.5 Flags

IMPROVEMENT_FLAG_CANT_BUILD_ON_LAND
IMPROVEMENT_FLAG_CANT_BUILD_IN_SPACE
IMPROVEMENT_FLAG_CANT_BUILD_IN_SEA
Prevents construction of the improvement in cities of the given type.

IMPROVEMENT_FLAG_CAPITOL
Acts as empire-centre for calculations of empire-distance unhappiness.  Prevents coexistance of more than one such improvement.  Possibly also gives you this building in your first city free.

IMPROVEMENT_FLAG_PREVENT_SLAVERY
Population of city cannot be enslaved.

IMPROVEMENT_FLAG_IS_RELIGIOUS
IMPROVEMENT_FLAG_CATHEDRAL
One of these determines the Hagia Sophia effect of improving certain happiness buildings (c.f. wonder.txt).  This question was raised in the Activision FAQ, but the answer was not helpful:

* What is the difference between IMPROVEMENT_FLAG_IS_RELIGIOUS and IMPROVEMENT_FLAG_CATHEDRAL used by both the Temple and Cathedral?

Wonders can be set to have an effect on buildings with the RELIGIOUS flag set and with buildings with the CATHEDRAL flag set. They don't have any direct effect on the building they're attached to. 

- Joe Rumsey, CTP programmer

Whether the slight difference in the choice of words ('ON buildings' vs. 'WITH buildings') is important, I don't know.

IMPROVEMENT_FLAG_ALLOW_GRUNTS
*Allow factory workers.  I think that references in pop.txt take priority over this, so probably obsolete.

IMPROVEMENT_FLAG_AIRPORT
Don't know.  Possibly obsolete.

IMPROVEMENT_FLAG_DOUBLE_TELEVANGELISTS
Doubles effect of conversions by units with IS_TELEVANGELIST (c.f. units.txt, const.txt).

IMPROVEMENT_FLAG_TELEVISION
*Probably related to the Hollywood effect (x gold per television in other civ.).

IMPROVEMENT_FLAG_PROTECT_FROM_NUKES
Protects city (But not the surrounds?) from nukes.

IMPROVEMENT_FLAG_PROTECT_FROM_BIO_AGENTS
Protects city from bio attacks.

IMPROVEMENT_FLAG_PROTECT_FROM_NANO_VIRUS
Protects city from nano terror.

IMPROVEMENT_FLAG_SPACE_LAUNCH
Can launch units to space (but only those which will fit in a cargo pod).

IMPROVEMENT_FLAG_NO_UNHAPPY_PEOPLE
Cancels all unhappiness and happiness.  Sets happiness at 75 regardless.

IMPROVEMENT_FLAG_NO_RUSH_BUY_PENALTY
Makes rush buys cheaper (just 1 gold/shield).

IMPROVEMENT_FLAG_FORCE_FIELD
Puts a forcefield picture round the city (Does NOT affect defense).

CITY_WALLS
Puts a city walls picture round the city (Does NOT affect defense).
Note that this is the only improvement flag with a name which does not begin IMPROVEMENT_FLAG_.  That's not a typo. 

4.5 Wonder.txt
--------------

This file is basically very similar to improve.txt.  Again, be aware of the difference between fraction/floats and percentage/integers.

4.4.1 Repercussions

Just gl_str.txt and, to a lesser extent, wondericon.txt and wondermovie.txt.  Editing this is very benign.

4.4.2 Limitations

THERE IS A LIMIT OF 64 WONDERS!
This extremely frustrating fact must be kept in mind when editing this file.
Any wonders past the 64th appear on the construction list, and can be apparently built, BUT they never actually appear in the city.  You do get some of the instant effects, but not the long term ones.  This can be put to use if used carefully, for instance if your 65th wonder is a generic space elevator, it can be built as many times as a player wishes in each of his cities, and he will recieve a free space city above each one.  This might be a viable alternative to Space Engineers if priced carefully.  However, none of these cities will recieve free transport to and from space.

Having large numbers of wonders has also been linked (not conclusively) to a crash caused by looking at the ranking screen.

4.4.3 Compulsory data values

SHIELD_COST <integer>
Cost in shields.

WONDER_DEFAULT_ICON <icon reference>
Icon (c.f. wondericon.txt).

WONDER_MOVIE <movie reference>
Movie (c.f. wondermovie.txt).

WONDER_DESCRIPTION <description reference>
Obsolete (c.f. junk_str.txt).

ENABLING_ADVANCE <advance reference>
Advance required to build.

OBSOLETE_ADVANCE <advance reference>
Advance which cancels effect (when any civ discovers it).

4.4.4 Optional data values

WONDER_FLAG_INCREASE_FOOD_ALL_CITIES <integer>
Increases food production by this % in all cities.

WONDER_FLAG_REDUCE_READINESS_COST <integer>
Reduces military upkeep costs by this %.

WONDER_FLAG_INC_HAPPINESS_EMPIRE <integer>
Increases happiness in all cities by this.  Possibly a float.

WONDER_FLAG_DEC_CRIME_PERCENT <integer>
Decreases crime by this % in all cities.

WONDER_FLAG_DEC_EMPIRE_SIZE <integer>
Decreases unhappiness due to distance from capitol by this %.

WONDER_FLAG_INCREASE_REGARD <integer>
Increases opponents regard by this (Possibly a %).  Only relevant to AI players.

WONDER_FLAG_INC_CONVERTED_CITIES_FEE_PERCENT <integer>
Increases income from converted cities by this %.

WONDER_FLAG_INCREASE_CATHEDRALS <integer>
Increases happiness from buildings with CATHEDRAL (or possibly RELIGIOUS, or possibly both - c.f. improve.txt) flag by this %.

WONDER_FLAG_INC_KNOWLEDGE_PERCENT <integer>
Increases science by this % in every city.

WONDER_FLAG_GOLD_PER_WATER_TRADE_ROUTE <integer>
Provides this much gold for every foreign trade route through a water square.  Possibly a float.

WONDER_FLAG_INCREASE_BOAT_MOVEMENT <integer>
Increases movement of all ships (MOVEMENT_TYPE_WATER / MOVEMENT_TYPE_SHALLOW_WATER?  Does this affect fusion tanks?) by this much (100ths of sqs).

WONDER_FLAG_INCREASE_SCIENTISTS <integer>
Increases output of scientists (or possibly all science) in host city by this %.

WONDER_FLAG_INCREASE_SPECIALISTS <integer>
Increases output of specialists in every city by this %.  Beware this, it has a very big effect in late-game empires, and can completely unbalance the game.

WONDER_FLAG_DECREASE_MAINTENANCE <integer>
Free maintainance for all buildings which cost this much gold or less.  Beware this, it can have a very big effect in early- to middle-game empires if the number is big, and can unbalance the game.

WONDER_FLAG_RANDOM_ADVANCE_CHANCE <integer>
Provides roughly this many advances per age.  In fact this is translated somehow into a probability per turn, it has nothing at all to do with the length of the ages.

WONDER_FLAG_OTHER_CIV_RANDOM_ADVANCE_CHANCE <integer>
Provides troughly this many advances per age that someone else has.  In fact this is translated somehow into a probability per turn, it has nothing at all to do with the length of the ages.

WONDER_FLAG_GOLD_PER_TELEVISION <integer>
Provides this gold for each opponents city with improvement with TELEVISION flag (or possibly for each opponent improvement with TELEVISION flag). Possibly a float.

WONDER_FLAG_INCREASE_HP <integer>
Increases each units (maximum) hitpoints by this much.

WONDER_FLAG_INCREASE_PRODUCTION <integer>
Increases all production by this %.

WONDER_FLAG_GOLD_PER_INTERNATIONAL_TRADE_ROUTE <integer>
Provides this much gold for every trade route between opponent civs.

WONDER_FLAG_MULTIPLY_TRADE_ROUTES <integer>
Multiplies income from trade to/from host city by this %.  Note this is MULTIPLICATION, not addition.  This could result in insanely high incomes for cities with more than one wonder with this effect.

WONDER_FLAG_POLLUTERS_TO_PARKS <integer>
Destroys this many of the most polluting cities, together with all units and tile improvements in their respective city radii.

WONDER_FLAG_REDUCE_WORLD_POLLUTION <integer>
Regardless of the number, this will remove all world pollution.

WONDER_FLAG_BREAK_DOWN_CHANCE <float> <integer>
There is the float chance of empire division each turn.  The integer could limit the number of turns for which such division could occur.

WONDER_FLAG_TEMPORARY_FULL_HAPPINESS <integer>
Celebration in every city for this many turns.  Handle with care, this can triple or quadruple a civ's effectiveness during the celebration period, especially in the late-game.

WONDER_FLAG_OVERCROWDING_REDUCTION <integer>
Increases overcrowding in every city by this much.

4.4.5 Flags

WONDER_FLAG_FREE_TRADE_ROUTES
Trade routes without trde units.  The routes will dissapear when the wonder is made obsolete.  Beware this if the wonder is available early or for a long time.

WONDER_FLAG_CLOSE_EMBASSIES
Close embassies with all others & prevents war declarations on owner.

WONDER_FLAG_EMBASSIES_EVERYWHERE
Embassies with all opponents except those at war with.

WONDER_FLAG_EMBASSIES_EVERYWHERE_EVEN_AT_WAR
Embassies with all opponents.

WONDER_FLAG_SPIES_EVERYWHERE
25% protection from spy attacks in all cities.

WONDER_FLAG_REFORM_CITIES
*Reform all converted cities upon construction.

WONDER_FLAG_PREVENT_CONVERSION
*Prevent conversion of more cities (existing conversions remain).

WONDER_FLAG_ALL_BOATS_DEEP_WATER
*Any unit with MOVEMENT_TYPE_SHALLOW_WATER gets MOVEMENT_TYPE_WATER too.

WONDER_FLAG_FREE_SLAVES
Frees all slaves worldwide.

WONDER_FLAG_GLOBAL_RADAR
Gives sight coverage of whole map.

WONDER_FLAG_FREE_SPACE_TRANSPORT
Provides space city above with unlimited pollution-free transport between the two.  The city won't die when the wonder is made obsolete.

WONDER_FLAG_ENABLE_PARK_RANGERS
Allows construction of units with CREATE_PARKS ability.

WONDER_FLAG_ALL_CITIZENS_CONTENT
No riots or revolts regardless of happiness (city's happiness set to 75).

WONDER_FLAG_REVOLTING_CITIES_JOIN_PLAYER
All opponent revolting cities will join player.

WONDER_FLAG_NO_POLLUTION_UNHAPPINESS
Eliminates unhappiness due to pollution.

WONDER_FLAG_ELIMINATE_NUKES
Destroys all nukes & prevents their construction.

WONDER_FLAG_FORCEFIELD_EVERYWHERE
Gives a forcefield in every city.  Possibly requires an improvement called IMPROVEMENT_FORCEFIELD, possibly checks flags for an improvement with the FORCEFIELD flag.

WONDER_FLAG_PROTECT_FROM_BIOLOGICAL_WARFARE
Prevents nano- and bio-terror attacks on all cities.

WONDER_FLAG_WORMHOLE_DETECTOR
Makes wormhole visible to you this turn & opponents next turn (or possibly later - c.f. const.txt).

4.6 Installation.txt
--------------------

This is all fairly simple and self-explanatory.  It shares much with units.txt.

I don't know why they have ATTACK and FIREPOWER values, but they should probably be left at 0.

I don't know where the sprite refences lead to.  The sprites themselves are stored in the *.til files in ...\gamedata\graphics\tiles\ but I can't find those SPRITE_... references in any other file to tell you which number is associated with which name, and this precludes addition of new installations (though probably it would be impossible anyway.

I suspect that the INSTALLATION_LAND, INSTALLATION_WATER flags determine both the tab upon which they are available under PW and upon which squares they can by built.

I suspect that the IS_LISTENING_POST, etc. flags determine the location of the button on the tab, or they might be related to the AI.  Only the airfield does not specify it's effect within the other entries, so presumably IS_AIRFIELD allows refuelling of aircraft.  Does anybody fancy making a seaplane platform to do the same thing in the ocean?

4.7 Govern.txt
--------------

This file is explained in detail in gov_explanations.doc, available from the Apolyton site.  I recommend that you read this work also.
Just take note that there are a great many possibilities which are not exploited in the default rules, and could lead to an explosion of government types if they were.

However, instead of the usual term-by-term explanantion here is a list of a number of things which it is wise to consider when designing governments:

The expectations on their own are totally irrelevant - the only important thing is their sum, since they can be adjusted relative to one another to maximise any one of the three sliders.  This sum can be from -6 to +6, but it is probably best to limit it to the -3 to +3 range as in CTP normally so as to always allow a certain degree of freedom. This same effect means that you can never accurately predict the the position of any one slider - it will depend on who is leading and their priorities.

The wages slider, as it stands in CTP is almost a non-entity.  Unless you change the order of magnitude of the various quantities involved, wages will never be as important as maintainance, and most players will push the slider to full at all times.  You could of course change this in a number of ways - increasing the effect of wages (through const.txt) or decreasing both maintainance and income.  Note that you can also vary the wages paid to members of the population (c.f. pop.txt) so that a labourer is paid more than a merchant, for instance.

Gold is science.  In other words, since most science comes from gold, the effective science income of a civilization (unless it employs many scientists/science improvements) is rougly proportional to the product of the gold coefficient, the science coefficient and the max science rate.  This is of course not true if wages and maintainance are a significant fraction of gold income - if this is the case then the gold coefficient is much more important than the other values.

Gold is production.  Choosing what to rush buy distinguishes the experienced player from the master, and it is this which unbalances Corporate Republic in CTP - it has so much gold that it can afford to out-produce Technocracy.  This especially true if you have improvements with the nanite factory effect (c.f. improve.txt).  Note also the rush buy modifiers for each government, which have an additional effect upon the efficacy and utility of rush buying.

Pollution depends on production.  The pollution coefficient applies after the production coefficient, so the amount of pollution is proportional to the product of the two (also, don't forget the effect of the workday).

Pollution unhappiness does NOT depend on the pollution coefficient.  This unhappiness is calculated before the government pollution coefficient is taken into account (but after the production coefficient and workday).

Possibly the single most important number for any government is the city limit.  This is a very important property, and should be carefully considered.  It is a great shame that it cannot vary by map size.  Note also the associated coefficient for unhappiness per additional city.  Personally, I have varied this number from 0.1 up to 2.

Capitol distance unhappiness is not especially relevant in CTP as it stands, but with a little increase to its effects, it becomes a powerful incentive to build roads, and not to overextend oneself.

Note that as well as an enabling advance, governments have an obsolete advance.  If you are going to have a great many governments, it might be wise to utilise this so as not to confuse the player, and also it might be an incentive to avoid certain research which would precipitate the loss of a valuable government option.

Lastly, each government can vary the number of trade routes permitted per city, and the efficiency of capitalization and infrastructure - altering these three options might make an otherwise unattractive government extremely useful under the correct circumstances.

4.8 Age.txt
-----------

This is also fairly simple.  There are only a few options:

You can set here the advances required to progress to the age in question.  It is this, and not the age indexes of the advances that matters.

You can change the way the city sprites are distributed amongst population.

There is the curious STARTING_ROUND value at the bottom of each entry - I think this might be related to the CheatAge= line in userprofile.txt (c.f. Userprofile.txt editing FAQ).

And remember - there's no reason to stick to just 5 ages!

4.9 DiffDB.txt
--------------

This file has a great many options.  It is here that the distribution of turns over years is set.  (to set the finishing year, edit Const.txt).

There is fairly good commenting on the first few entries, and of the rest my best guesses are as follows:

..._FACTOR
*Affect the contribution of the various elements of the civ score.

AI_START_...
These are obvious

HUMAN_START_LOCATION <integer>
*This chooses which of the start locations is given to the player.  0 is the best, 1 the next best and so on.  Beware of going beyond 2 since the game engine might generate only as many start locations as there are civs and there might only be 3 civs.

AI_INTELLIGENCE_FACTOR <?>
Don't know.  I assume that increasing this will not magically make the AI more intelligent, but decreasing it may well make it stupider.

AI_GANG_UP_FACTOR <?>
It's fairly obvious what this should do in general, but I don't know the details.

DISTANCE_FROM_CAPITOL_ADJUSTMENT <?>
AI_DISTANCE_FROM_CAPITOL_ADJUSTMENT <?>
Possibly affect capitol distance unhappiness?

POLLUTION_ADJUST <?>
Don't know.

AI_TECHNOLOGY_COST <float> <float> <float> <float> <float>
AI_PRODUCTION_COST_ADJUSTMENT <float> <float> <float> <float> <float>
AI_GOLD_ADJUSTMENT <float> <float> <float> <float> <float>

Multiply the relevant quantities by the given fraction.  *I think the five numbers refer to the five ages, but one mod which increased the number of ages to 7 left only 5 numbers here.

MAX_HUMAN_ADVANCES <integer>
MAX_AI_ADVANCES <integer>

*The maximum number of advances given initially

HUMAN_SCIENCE_BONUS <float>
HUMAN_FOOD_BONUS <float>

These numbers increase through negative values from -0.4 to 0.0 as difficulty goes from easy to hard.  I can't see exactly what they do but the general intent is obvious.

EXTRA_SETTLER_CHANCE <integer>

The chance that a human player gets an extra settler (AI initial settlers set by AI_START_UNITS), but I don't know the exact relation between the numbers and probabilities.  See default rules for guidance.

Note the ADVANCE_CHANCES section, which sets the probabilities of having various advances initially as a percentage.  I'm not sure why there are two numbers - possibly referring to human and AI players.

This file is closely linked to Const.txt.

4.10 Terrain.txt
----------------

A relatively unimportant file for most purposes, but you will have to change an AWFUL lot of advance references in here if you want to alter the tech tree.  Some of the less obvious things are:

The terrain is defined as a series of blocks, the default terrain properties followed by properties under various other conditions.  Some of the properties (food, gold, etc.) are additive, others (movement, etc.) are not.

TRANSFORM_REMOVE <integer> <integer>
TRANSFORM_ADD <integer> <integer>
These determine the time taken and cost in PW for terraforming from and to this terrain.  *These values are added to the converse ones for the other terrain in question to obtain the cost and time required.

TERRAIN_CAN_DIE
GOOD_CAN_DIE
*These alows a terrain to become a dead square as a result of nukes or pollution.

ENV_BASE
This block has the default terrain data.

ENV_CITY_BONUS
*This block has the data for this terrain with a city on it.

ENV_RIVER_CUR
*This block has the data for the terrain with a river on it.

ENV_SCORE
Don't know.

ENV_FREIGHT
Don't know.  Possibly determines route taken by caravans or capitol distance unhappiness.

ENV_MATERIALS
Don't know.  Possibly determines route taken by caravans or capitol distance unhappiness.

PROBABILITY
*Somehow related to the relative probabilities of the different goods.

GOOD_INDEX
*Connection to goods.txt.

It is now possible to edit the appearance of the terrain - see http://mbv.dk/uk/civ_ctp.html.

4.11 Pop.txt
------------

This is all fairly clear.  I have no idea what it is that determines which category the populations appear in on the labour screen.  *Possibly connected to their names in gl_str.txt.
More, better (or worse) versions of any of the population types which CAN_WORK_CITY is simple.  Just make a copy of the existing population of the given type, so that the better ones are below the worse ones, change the name, BONUS_... value and IMPROVEMENT as appropriate (Don't forget to edit gl_str.txt too).  I haven't tried populations which provide bonuses in more than one category.  You might also (if you're asking for trouble) apply bonuses to CAN_WORK_FIELDS types.  Perhaps have more than one type of outside worker, with later versions allowed by appropriate improvements which give you bonuses.  Also note MIN_SIZE and MAX_SIZE, which are never put to use in the default rules, but offer many interesting ideas.  This file allows many more possibilities than it suggests at first, and any serious scenario designer should give it its due attention.

4.12 Const.txt
--------------

This file has all of the global rules and bits and pieces that didn't fit anywhere else.  The most important thing to remember about this file is that it will NOT be read from a scenario directory, but must be in the ctp_data directory.  Unlike the great library files, there is no way to avoid overwriting the existing file here.  There are many useful things to be found in here, but the file is heavily commented, so I won't cover them in detail, just go over a few of the more useful features:

The first chunk is all about how the map is generated.  This could be useful if you intend to do a scenario based on some alien planet (or Earth in the grip of a nuclear winter) but I will give no details.

REVOLUTION_LEVEL 60
RIOT_LEVEL 73
VERY_HAPPY_THRESHOLD 85
These let you make cities more or less likely to celebrate, riot, revolt.

UNIT_WORKDAY 0.25 # slider to work
BASE_WORKDAY 1.0 # work per person when slider is zero
UNIT_WAGES 1.0 # what does 1 notch mean
BASE_WAGES 4.0 # gold per person when slider is zero
UNIT_RATIONS 0.25 # what does 1 notch mean
BASE_RATIONS 1.0 # food per person time POP_HUNGER when slider is zero
These let you change the effects of the sliders (handle with EXTREME caution).

CHANGE_CURRENTLY_BUILDING_ITEM_PENALTY 25 # what percent of the sheild store is lost it the current item is changed
This is in fact not particularly useful since players can get around it by changing their production by removing the first item in the queue.  If you do so, then you lose no production.  This applies only to changes through the BUILD button, not the QUEUE button.

PARADROP_DISTANCE 20 # how far away can paratroopers drop?
PARADROP_SUCCESS_PERCENT 100 # a miss results in a drop to a neighboring square
Could be fun...

BIO_INFECTION_TURNS 5
NANO_INFECTION_TURNS 5
BIO_INFECTION_SPREAD_CHANCE 0.60
NANO_INFECTION_SPREAD_CHANCE 0.40
BIO_TERROR_KILL_PERCENTAGE 0.20
Changing these could seriously affect the attractiveness of such unconventional warfare.  Consider upping the probabilities to 0.9 or even 1 :).

NUKE_POPULATION_PERCENTAGE 0.75
Change this to 1, and using nukes is suddenly a whole different ballgame.

RUINS_CHANCE_PER_BOX 0.0
If you want to rid yourself of barbarians and their associated crashes, change this probability to 0 as shown here.  Also see risks.txt for other ruins and barbarian info.

UNIT_RUSH_MODIFIER 3
IMPROVEMENT_RUSH_MODIFIER 1
WONDER_RUSH_MODIFIER 5
Here you can vastly affect how likely players are to buy various things.  But, beware - using the change-production-through-queue-manipulation technique described above they can avoid production losses due to changes in production and buy expensive units by first buying cheap improvements.

GOLD_FROM_PIRACY 30
Fancy promoting piracy?  Beware of raising this too high and promoting self-pirating.

FOOD_TO_POLLUTION_COEF 1.0			# pollution to food ratio produced by food vats
Fed up with players having huge cities in the mountains with food vats?  Just increase this number and pollution will run rampant.  (Although its not so bad in the mountains, since they can't die, and it's irrelevant if there's a gaia controller style wonder).

ADVANCE_CHOICES_MIN 4
ADVANCE_CHOICES_MAX 6
If you've a very loose or restrictive tech tree, you'll probably want to change these so the players have a larger or smaller list to choose from on the science screen.

MAP_SIZE_SMALL	24	48	2
MAP_SIZE_MEDIUM	48	96	2
MAP_SIZE_LARGE	64	128	2
MAP_SIZE_GIGANTIC	70	140	2
What do you suppose is the outside limit for map sizes?  256x256, or 32768x32768?  If you know the up-to-32-players trick, or want to play REALLY long games, larger maps could be useful.  Increasing the '2' at the end has no effect as far as I can tell, but I haven't tried decreasing it.

INCITE_REVOLUTION_GOLD_COEFFICIENT 100.0
INCITE_REVOLUTION_CAPITOL_PENALTY  5000.0
Inciting revolts was never as easy in CTP as Civ2.  Now you can fix that.

NANO_INFECTION_TERRORIST_DEATH_CHANCE 0.25
BIO_INFECTION_TERRORIST_DEATH_CHANCE 0.25
Strange, I thought these probabilities would be in units.txt.

FLOOD_CHANGES_COAST_TO_WATER_CHANCE 0.5
Eliminate global warming flooding in one easy step.  Or, make it far, far worse.  See also gw.txt.

4.13 Other Text Files
---------------------

Here's a passing reference to the other text files, if you're advanced enough to be editing these you shouldn't need any details.  OTOH, if anyone has anything interesting to say about these, please tell me.  See below for the *icon.txt except messageicon.txt and the *id.txt files,

(in alphabetical order)
branchID.txt - Determines the order in which advances appear on the science choice list.
civilisation.txt - The pictures, names, personalities and cities of the varios civs.
colors00.txt - Sets the player colours and the colors of the terrains on the minimap in RGB format.
concept.txt - Just a list of all the concepts with their icons.  You can add new concepts if you wish.
endgame.txt - Everything to do with the X-lab, lots of possibilities here.  Probably don't change NUM_STAGES though.
gamefile.txt - This lists all the other files to include.  Perhaps by changing this you could avoid the const.txt overwriting problem.
goods.txt - You can add new goods, or change their value for trade (not all goods need have equal value)
gw.txt - Determines what happens when global warming occurs.  What terrains change to what, etc.
hscore.txt - Don't know.
map.txt - The map sizes are here as well as in const.txt.  Don't know which has priority.  Also many details about the generation of maps of these sizes.
messageicon.txt - The references to those pictures that are displayed when you receive messages, to be reffered to in turn from SLIC code.
order,txt - You can change the cost in gold and movement of the various unit orders.  I'm not sure that the movement value does anything - there's another in const.txt.
ozone.txt - Not sure, related to global warming somehow.  There's much confusion due to the amalgamation of global warming and ozone depletion.
playlist.txt - The way songs are played from the CD.
pollution.txt - The amount of pollution to trigger the various events on each map size.
profile.txt - Roughly the same as userprofile.txt in ctp_program\ctp\, and probably superceded by that.
risks.txt - Determines hut-related things and the probability of non-hut barbarians on each risk setting.
sounds.txt - A big list of sound IDs and their file names.
throne.txt - All about the 'throneroom' which is of course the monument screen.
tileimp.txt - Just a list of the farms, etc.  Not sure what determines their sprites, but most tile improvement data is in terrain.txt.
units_historic.txt - A variation on the units rules, don't bother - it's absurd.
victorymovie.txt - References to the movies you get with each kind of victory / defeat (VICTORY_LOST_OVERRUN_BY_SMURFS, even) and the intro movie.
wondermovie.txt - References to the wonder movie files.

4.14 Obsolete Items
-------------------

The following is taken from the Activision FAQ:

//Begin quote
Which of the unused functions would still work and are bug free? How can I revive them? I have noticed the following in CTP's files: 

RUSTLE
DEFUSE_MINES
NULLIFY_WALLS
ASSASSINATE
BOMB_CABINET
INVESTIGATE_READINESS
THROW_PARTY
AIRLIFT
HEAR_GOSSIP
PATROL
TERROR_HACK

Unfortunately, while the code is still in there for most of them, there's no way to actually do them from the interface. The buttons and keyboard shortcuts were removed from the code. But SLIC (our scripting language) is just slightly shy of being able to activate them, so there's a chance some of them will be possible to use via slic messages after the patch. 
HEAR_GOSSIP may actually still do something as is, but we stopped tesing it long ago. DEFUSE_MINES is totally gone. PATROL is totally gone. TERROR_HACK is gone. The rest are action we may look into reviving in the future. 

- Joe Rumsey, CTP programmer 
//End quote

Keep in mind that there is much in these rule files that does nothing at all.  This is not the complete list of obsolete things, for example ELECTRONIC_COMBAT_FACTOR and POWER_POINTS also do nothing.  If you find some value which appears to do nothing, it probably does just that.

-----------------------------
5 Icons and the Great Library
-----------------------------

Many of the other text files give reference to icons, each has its own icon file.  They are:

advanceicon.txt, concepticon.txt, endgameicon.txt, goodsicon.txt, governicon.txt, improveicon.txt, messageicon.txt, terrainicon.txt, tileimpicon.txt, uniticon.txt, wondericon.txt

Except messageicon.txt (which is an anomaly - it references those pictures which appear down the left hand side of the screen at the beginning of each turn) and uniticon.txt (because the game designers were inconsistent in naming units.txt - it should have been unit.txt) you can find out the file which references the icons by removing the 'icon' from the filename (e.g. endgameicon.txt is referenced in endgame.txt).

5.1 Icon File Structure
-----------------------

Except messageicon.txt, all these files follow a similar structure.

The first line contains the number of entries in the file, and each subsequent line contains an icon reference (used to reference this icon in other files) and a series of filenames in quotes.

In most of the files there are 6 filenames:
(In what follows ? is any letter, # is any number)

C?###F.tga
This is the picture that appears at the centre of the great library screen under the entry for this item when great library movies are off (**or when the movie in the next entry is "Null").

C?###A.avi
This is the movie that appears at the centre of the great library screen under the entry for this item when great library movies are on.

GAME?###.txt
This file contains the information which appears at the bottom of the great library screen under the gameplay tab.

HIST?###.txt
This file contains the information which appears at the bottom of the great library screen under the historical tab.

PREQ?###.txt
This file contains the information which appears in the left 'prerequisites' box of the great library screen.

VARI?###.txt
This file contains the information which appears in the right 'consequences' box of the great library screen.

However, if the item in question is something that can be constructed (units, improvements, wonders, endgame, some concepts) then there are two additional files:

UP?###.tga
The is the picture that appears when the item is under construction on the production tab and (in the case of units) appears as the unit picture on the unit tab.  In fact, this slot in the uniticon.txt file is instead filled with files of the form UPUA##.tga, since the UPU###.tga files are related to the sprites (q.v.).

STAT?###.txt
This file contains the text to display in the little summary box on the construction options screen.

The '?' in the files above is determined by the class of item:
C - concepts (inc. governments, exc. unit ability concepts)
G - goods
M - improvements (inc. endgame items)
U - units
W - wonders
X - unit ability concepts

Unfortunately, there is some inconsistency in the system (e.g. Capitalization and Infrastructure are concepts in some places, improvements in others).

The ### number is simply a way to distinguish between the many files.  Unfortunately, the numbers do not simply begin at 1 and count up, so it quickly becomes difficult to know what numbers are available and what refer to what.

Sometimes the filenames are replaced by "Null" when they are not applicable.

5.2 Great Library Entries
-------------------------

The entries in the great library are defined by these files.

Images should be 160x120 16-bit Targas placed in the default\graphics\pictures directory.
Movies should be 160x120 15fps Indeo 5.10 compression for best results and placed in the default\videos directory.
Text files should be placed in the english\gamedata\gl directory.

N.B.  Activision advised 160x120, but lower resolutions work fine (although they look bitty, because they're scaled up).

Great Library tect files will NOT be read from scenario directories, they must be in the ctp_data directory.  Luckily, most such files are compressed into .zfs archives, so they can be safely overridden by 'real' files outside the archive without overwritng anything.  To avoid conflict with other scenarios, however, it's a good idea to change the naming scheme for your great library text files by replacing the third and fourth charachters in the filename with something relevant to your scenario (The MedMod used 'mm', my Mars mod uses 'ma').

You can include quasi-hyper-links in the text files to other great library entries using the following notation:

<l:#,#>[Link text]<e>

For example, here is an extract from preqg001.txt, regarding one of the goods:

LOCATED:
<l:5,8>Mountain<e>
<l:5,12>Volcano<e>

The two numbers refer to the section and entry in the great library.  The first being:

1 - Units
2 - Improvements
3 - Wonders
4 - Advances
5 - Terrain
6 - Concepts
7 - Governments
8 - Tile improvements

And the second number is the number of the item in some list or other.  I am not sure how this second number works.  For instance, returning to the example above, if you open terrainicon.txt, you will find that ICON_TERRAIN_MOUNTAIN is the 10th entry, and ICON_TERRAIN_VOLCANO is the 14th.  Their file indexes are 9 and 13 respectively. On the other hand, if we consult terrain.txt they are the 9th and 19th entries.  None of these numbers match up.

EasyMod allows you to put in these links easily, so there must be some method by which to determine the appropriate number.

---------
6 Strings
---------

As well as the rules files, you will certainly have to modify the strings files in english\gamedata.  These are covered briefly below.

6.1 gl_str.txt
--------------

This is by far the most important of the files.  Although its name suggests that it is for the great library, and it is, it also determines the names of everything in virtually every occurence of a message or piece of text in-game.

All of the contents are fairly obvious, and shouldn't need explanation.  Just remember to modify this every time you add a new unit, wonder, etc.  If you forget, though, you should get an error message, so it's not a big deal.

6.2 add_str.txt, cht_str.txt
----------------------------

These files are mostly concerned with the user interface.  You'll only need to modify them if you're going for an extreme alteration of the game, or you want to change some obscure aspect.

6.3 civ_str.txt
---------------

The strings related to the various civilizations.  Leader pronouns and so forth.  Also references to leader picture files.

6.4 dip_str.txt
---------------

Diplomacy strings.  Of minimal utilty.

6.5 err_str.txt
---------------

Error messages - as it says in the file, don't mess with these too much.

6.6 exp_str.txt
---------------

Strings used in the city tab / happiness section as well as in the civ score summary.  Could be useful in a major mod.

6.7 help_str.txt
----------------

This one is very important.  It includes the popups which occur when you hold your mouse over a tech in the science screen and the ones you get when you right-click on items in the construction list.  These strings do not work alone, however, you must edit script.slc also.

6.8 info_str.txt
----------------

All sorts of general messages that occur all the time during the game.  A couple caght my eye, like:
RESEARCH_TRADE " I recommend that you research Trade."
Which would have to be changed if the tech tree was modified.

6.9 junk_str.txt
----------------

Remember all those description references in the data files?  This is where they all lead - to junk.  Presumably it was decided to include descriptions with icons at some late stage, and this was a hangover from the previous implementation.

6.10 ldl_str.txt
----------------

A strange assortment of various strings.  I have no idea what 'ldl' means.  Again, just a few things that might have to be changed if you changed the names of various things.

6.11 scen_str.txt
-----------------

This file is left blank so that you can replace it in your scenario directory and add more strings without overwriting others.

6.12 Strings.txt
----------------

This file includes all the others.  Note that add_str.txt was supposed to have been removed before release.  You can add more of your own files to this list if you wish.

6.13 tut_str.txt
----------------

Strings for the tutorial.  Unless your scenario is complicated enough to warrant its own tutorial, you shouldn't care about this.

---------
7 Sprites
---------

Sprites have a .spr extension and can be found in default\graphics\sprites.  The only way to make sprites is to use Activision's SpriteTool (available from the official CivCTP site).  I strongly reccomend that you also aqcuire HOW TO MAKE CTP UNIT GRAPHICS WITHOUT ANIMATIONS by Harlan Thompson from the Apolyton site.  I will only consider the referencing of sprites from the point of view of the data files.

The sprites all have names of the form g?##.spr (or g?###.spr for sprites with indicies greater than 99).  ? is a letter specifying the type of sprite - U is certainly for units and I assume that C, G and X are for cities, goods and special effects.  The sprites, unlike the other files, are referenced not by their entire file name but just by their sprite ID, which (if necessary extended to two characters with a leading zero) gives the ## or ### in the filename.  Sprite IDs above 199 are not recognised.  Since you cannot have a 00 ID (it just uses the 01 one instead) this limits the sprites to 199 of each category.

The unit sprites are referenced in SpriteID.txt, the city sprites in CityID.txt, the special effects in projectileID.txt, projectileendid.txt and speceffectid.txt and the goods sprites (incuding the wormhole! - A space good?) in GoodsID.txt.  I can find nowhere that the references for the time improvement sprites are - the string SPRITE_LISTENING_POST in installations.txt occurs nowhere else in any other data file.  If you try to create a unit with the sprite of an installation, the game crashes.

There are some sprites, e.g. gu91.spr which are never referenced by the *ID.txt files.  Whether these can be safely replaced or what they are, I do not know.

The SpriteTool will create sprites for units, cities, goods and effects, though only unit creation is well documented.

------
8 SLIC
------

You can create many effects using the SLIC language associated with CivCTP.  I shall not go into much detail here but refer you to the documentation (readme.doc) with v1.2 and the various files on the Apolyton site.

My experiences with SLIC have been varied, sometimes it sems to work flawlessly, but at other times there are untraceable bugs.  In particular the terraforming function is unreliable.  A good text editor will of course help, and at least one (though I cannot find the source of this information to know which) has had SLIC syntax highlighting written for it which can be obtained from somewhere.

Here are some things it may be useful to know:

1. To kill a city use AddPops() with a large negative number
2. To implement militia units which are supplied free to the players cities, copy and modify the appropriate triggers from the MedMod.
3. A special effect is just a pretty picture.  Appliying a speceffect_nuclear_attack will make a mushroom cloud, but not kill units, population or tiles.

----
9 AI
----

The AI is a bugbear to the scenario author who wishes to change the rules, since inevitably the question of how new units etc. will be used by computer players.  If the AI files disagree with the other game data files then crashes will ensue with incresing frequency.  I will not go into detailed discussion of the AI files here, but instead give advice on removing the worry of AI from your games.

If you wish to exclude AI players, there are four sources you must consider:

1. Starting players
These can be stopped by simply not choosing any, and also by having a SLIC trigger which kills them off.

2. Random barbarians
These can be prevented by reducing the probabilities in risks.txt to 0, or by playing huts only

3. Barbarians from huts
These can be prevented by reducing the probabilities in risks.txt to 0, or by removing huts altogether (c.f. const.txt)

4. New civilizations/barbarians from revolts
You could remove revolts altogether (c.f. const.txt).  If you wish to avoid such drastic measures, you can reduce the effects of revolts by making more wonders with the effect of causing revolting cities to join the owner civilization (though it's probably a bad idea to have two such which can exist simultaneously - that is untested).  However, you cannot ensure that the wonder is built, and cities in that empire which revolt will still go to the AI.  The only way to prevent this is to have a SLIC trigger to kill off such cities on their first turn.  Don't forget that AI-entity style wonders also cause revolts.

------------
10 Reference
------------

Firstly, don't forget the great library and your lowly CTP manual - both of which are packed with interesting material detailing the game rules.

Two of the most useful Internet sites are:
The official CivCTP site - http://www.activision.com/games/civilization/
The Apolyton Civilization site - http://apolyton.net/
Follow other links on these pages to further sites since they will be kept much more up to date than this file.

The Apolyton site has a great many useful references on CTP modification and some sprites for you to use.  It also has scenarios and modpacks written by others for your inspiration.

For a .til file editor (to change terrain appearance) go to:
http://mbv.dk/uk/civ_ctp.html

A useful utility is ModPicker, available from:
http://members.home.nl/paulvdb/modpick.htm

Other docs to look out for follow.  I used information from many of these in writing this document, and thanks to all the authors.  Most of the files are either distributed with v1.2 or are available on the Apolyton site:

Civilization: Call to Power, version 1.2 (readme.doc)
The v1.2 readme includes a tutorial on scenario creating, and touches on SLIC.

Civilization: Call to Power, editor readme, version 1.2 (editor_readme.doc)
The v1.2 editor readme details how to use the cheat mode / scenario map editor, including known problems and things to avoid.

GOVERN.TXT Readme (gov_explanations.doc)
This explains the various numbers in govern.txt and how they affect the game.

gov_sheet.xls
This provides the government details in spreadsheet form for easy comparison.

CTP Modification: Activision FAQ (Parts 1 & 2 - activ-1.shtml, activ-2.shtml)
Some useful information direct from the horses mouth.

Userprofile.txt editing FAQ (profile_faq.shtml) By David Williams, aka Non-Descript, dr.funk@pdq.net
Pretty much the only resource describing this handy little file.

SLIC Scripting Language (slic.shtml) By Joe Rumsey, a.k.a. Mr Ogre
CTP Modification: SLIC Functions (slicfunc.htm) With the above
CTP Modification: SLIC Variables (slicbuiltin.htm) With the above
Between them, these three documents tell you all there is to know about SLIC coding.

-------------------
11 About the Author
-------------------

Just a sucker for a stupidly hard task.  With enough time to get it done.
I don't actually play CivCTP very much, but I've always loved modification & customization.
Watch out for my CivCTP 'Colonization of Mars' mod - if it ever gets released (at time of writing (2001/08/11) it still needs quite a bit of the graphics, sprites and great library entries doing).
I have also written scenarios for Civilization II, Doom II and Starcraft.
Contact me at <jjb48@cam.ac.uk>.

------------------
12 Version history
------------------

v0.81beta (2002/03/18)
----------------------
Fixed typos
Updated info about VISIBILITY_CLASSes
Added TileEdit info

v0.8beta (2001/09/05)
---------------------
Added much additional information to the section on govern.txt
Added information about the AI
Expanded the SLIC section

v0.71beta (2001/08/18)
----------------------
Removed the Marine bug from the bug list since it does not exist.
Added PRODUCTION_TYPE_FOOD to list of valid production references.

v0.7beta (2001/08/18)
---------------------
Added an explanation of q.v. and c.f. to the notes, and added more cross-references and 'About the Author'.

v0.6beta (2001/08/11)
---------------------
Corrected many errors and added the tips & tricks and bugs sections.

v0.5beta (2001/07/16)
---------------------
Fleshed out, added strings section.

v0.1alpha (2001/07/14)
----------------------
Initial Ramblings.  Most of the structure in place, together with an assortment of detail.

----------
12 The End
----------

Thanks for reading, and remember:  If you've anything to contribute, please do so!

THIS MATERIAL IS NOT MADE OR SUPPORTED BY ACTIVISION
