==================================================== Advanced Civilization: Call to Power Scenario Design ==================================================== By John Bytheway v0.7 (beta) Last Updated 2001/08/10 Please, please send in any corrections or additions. Your contribution is welcome. ---------- 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 Reference 10 About the Author 11 Version History 12 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 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: 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: 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. If any such modification is to take place, I would recommend that the data instead replace the default entirely. In is not difficult to make a backup copy of the ctp_data directory or even to make a whole new copy of CivCTP for the new files. 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_SETTLER 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.) 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. 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). 4. 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. 5. You tried to load a game which dates from some older version of the rules - start a new one instead. 6. 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. 7. 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\) 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 i 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 needs 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. 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 cannot select units or cities by clicking on them, you must 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. Marine redundancy - Any unit can amphibious assault, not just ones with the appropriate flag. 4. 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: e.g. SLAVE_RAIDS 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 range [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). 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 Specifies the icon to be used by the advance. (c.f. advanceicon.txt). ADVANCE_DEFAULT_BRANCH 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 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 *This is obsolete in units.txt - probably also here. ADVANCE_COST 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 Change advance makes to pollution due to city size. ADVANCE_POLLUTION_PRODUCTION_MODIFIER 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 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. You MUST have a UNIT_SETTLER, since this will be the unit given to the player at the beginning of the game. However, you can of course change gl_str.txt and/or the sprite, so that it does not appear as a 'Settler'. 4.3.3 Compulsory data values SHIELD_COST Cost to build in shields (Cogs?). POWER_POINTS Obsolete. MAX_HP Hit points (at war - less if stood down or on alert (unless IS_SPECIAL_FORCES - q.v.)). ATTACK Attack strength (10 times that which you see in-game). DEFENSE Defense strength (10 times that which you see in game). FIREPOWER Firepower (Enemy hit points removed per hit). ZB_RANGE_ATTACK Bombard strength (Also strength when in second row of battlefield, and for active defense). BATTLEFIELD_RANGE BATTLEFIELD_RADIUS *These are related to the positioning on the battlefield and the distance the unit can shoot on it. *They appear to always be the same for combat units, but diffenrent for non-combat ones. VISION_RANGE Vision range (In squares - don't forget that it's circular-ish). ACTIVE_DEFENSE_RANGE Range of active defense. ELECTRONIC_COMBAT_FACTOR Obsolete. MAX_MOVEMENT Movement (1 turn) (100ths of squares). FUEL Fuel (100ths of squares). Units will only die when out of fuel with the NO_FUEL_THEN_CRASH flag. SHIELD_HUNGER Upkeep (shield/turn) (affected by alert status and IS_SPECIAL_FORCES). FOOD_HUNGER **Upkeep (food/turn). Never used - possibly no effect. DEFAULT_SPRITE Sprite (c.f. SpriteID.txt). Also determines picture in Cheat Mode's Unit maker. DEFAULT_ICON 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 Obsolete (c.f. junk_str.txt). SOUND_SELECT1 SOUND_SELECT2 SOUND_MOVE SOUND_ACKNOWLEDGE SOUND_CANTMOVE SOUND_ATTACK SOUND_WORK SOUND_VICTORY SOUND_DEATH These determine the sound made by the unit under the gived conditions (c.f. sounds.txt). ENABLING_ADVANCE Advance required to build the unit (c.f. advance.txt). NULL for none. OBSOLETE_ADVANCE 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 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 Fraction of normal growth rate at which this city grows (applies only to cities). BONUS_FOOD 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 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 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 *Adds this much to pollution counter when unit dies. **Possibly negative to promote eco-units? LAUNCH_DESTROYS_OZONE *Adds this much to pollution counter when unit launches to space. GOVERNMENT_TYPE 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 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 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 Reformation ability (undoes conversion of city & causes unhappiness). SLAVE_RAIDS 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 Slaving settlers ability. This always succeeds. TRANSPORT_CAPACITY Units capacity & sounds for load/unload for a transporting unit. Use in conjunction with CAN_CARRY_ flags (q.v.) ESTABLISH_EMBASSY Establish embassy ability (as diplomat). INVESTIGATE_CITY Investigate city aility. Floats are probabilities of success and capture. **Integer possibly related to wariness? CAUSE_UNHAPPINESS 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 Soothsay ability (as cleric/televangelist). **Should follow CAUSE_UNHAPPINESS. INDULGENCE_SALES Indulgence sales ability (inc. happiness & divert gold, as cleric). CONVERT_CITIES Convert population ability (diverts gold). Reversed by reformation ability. *Floats are probabilities of success and capture. INJUNCTIONS Injunction ability (stops production for turn in target city, as lawyer). SLAVE_UPRISING Cause slave uprising ability (as abolitionist) UNDERGROUND_RAILWAY Free slaves ability (as abolitionist). *Floats are probabiity of success and capture. STEAL_TECHNOLOGY Steal technology ability (as spy). *Floats are probability of success, capture and of spy becoming veteran. INCITE_REVOLUTION Incite revolution ability (as spy). *Floats are probability of success, capture and of spy becoming veteran. PLANT_NUKE 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 Attack causes nuclear explosion (as nuke). CREATE_FRANCHISE Create franchise ability (diverts production) (as corporate branch). **Float is probability of success. CONDUCT_HITS Conduct hits ability (temporary unhappiness, as ecoterrorist). **Should follow CAUSE_UNHAPPINESS entry. NANO_TERROR Nano terror ability (destroys improvements & spreads (c.f. Const.txt for prob. of success), as ecoterrorist). **Float is probability of success. BIO_TERROR Bio terror ability (temporary unhappiness & spreads (c.f. Const.txt for prob. of success), as infector). **Float is probability of success. CREATE_PARKS 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_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 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 - Stealth 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. *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. 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. 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 Cost to build in shields. IMPROVEMENT_UPKEEP Cost to upkeep in gold/turn. IMPROVE_DEFAULT_ICON Improvement icon (c.f. improveicon.txt). IMPROVE_DESCRIPTION Obsolete (c.f. junk_str.txt). ENABLING_ADVANCE Advance required to build. OBSOLETE_ADVANCE 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 Type of production (valid production references are: PRODUCTION_TYPE_KNOWLEDGE, PRODUCTION_TYPE_PRODUCTION and PRODUCTION_TYPE_GOLD) and increase (%). IMPROVEMENT_FLAG_SILO 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 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 *Chance of preventing conversion (%). Or possibly reduction in the chance of success of conversion. IMPROVEMENT_FLAG_HAPPY_INC Increase in happiness (possibly argument is actually a float). IMPROVEMENT_FLAG_HAPPY_INC_SWITCH {} Increase in happiness (variable by government), for example (Taken from cathedral): IMPROVEMENT_FLAG_HAPPY_INC_SWITCH 3 { GOVERNMENT_COMMUNISM 1 GOVERNMENT_THEOCRACY 5 } IMPROVEMENT_FLAG_LOWER_CRIME Fraction by which crime reduced. IMPROVEMENT_FLAG_SCIENCE_PER_POP IMPROVEMENT_FLAG_GOLD_PER_CITIZEN Provides this much science or gold for each population of city. IMPROVEMENT_FLAG_LOWER_OVERCROWDING Increases overcrowding by this much (Use negative number for decrease). IMPROVEMENT_FLAG_POLLUTION_BONUS Increases pollution by this fraction. IMPROVEMENT_FLAG_LOWER_PEACE_MOVEMENT Increases unhappiness due to war by this fraction. IMPROVEMENT_FLAG_MOVEMENT_TYPE_IS_REFUELED **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 Cost in shields. WONDER_DEFAULT_ICON Icon (c.f. wondericon.txt). WONDER_MOVIE Movie (c.f. wondermovie.txt). WONDER_DESCRIPTION Obsolete (c.f. junk_str.txt). ENABLING_ADVANCE Advance required to build. OBSOLETE_ADVANCE Advance which cancels effect (when any civ discovers it). 4.4.4 Optional data values WONDER_FLAG_INCREASE_FOOD_ALL_CITIES Increases food production by this % in all cities. WONDER_FLAG_REDUCE_READINESS_COST Reduces military upkeep costs by this %. WONDER_FLAG_INC_HAPPINESS_EMPIRE Increases happiness in all cities by this. Possibly a float. WONDER_FLAG_DEC_CRIME_PERCENT Decreases crime by this % in all cities. WONDER_FLAG_DEC_EMPIRE_SIZE Decreases unhappiness due to distance from capitol by this %. WONDER_FLAG_INCREASE_REGARD Increases opponents regard by this (Possibly a %). Only relevant to AI players. WONDER_FLAG_INC_CONVERTED_CITIES_FEE_PERCENT Increases income from converted cities by this %. WONDER_FLAG_INCREASE_CATHEDRALS Increases happiness from buildings with CATHEDRAL (or possibly RELIGIOUS, or possibly both - c.f. improve.txt) flag by this %. WONDER_FLAG_INC_KNOWLEDGE_PERCENT Increases science by this % in every city. WONDER_FLAG_GOLD_PER_WATER_TRADE_ROUTE Provides this much gold for every foreign trade route through a water square. Possibly a float. WONDER_FLAG_INCREASE_BOAT_MOVEMENT 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 Increases output of scientists (or possibly all science) in host city by this %. WONDER_FLAG_INCREASE_SPECIALISTS 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 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 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 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 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 Increases each units (maximum) hitpoints by this much. WONDER_FLAG_INCREASE_PRODUCTION Increases all production by this %. WONDER_FLAG_GOLD_PER_INTERNATIONAL_TRADE_ROUTE Provides this much gold for every trade route between opponent civs. WONDER_FLAG_MULTIPLY_TRADE_ROUTES 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 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 Regardless of the number, this will remove all world pollution. WONDER_FLAG_BREAK_DOWN_CHANCE 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 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 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. I can't find those references in any other file. 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 will not attempt to upstage that here. 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 fully exploited. 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 the rest are either very obvious or hopelessly obscure. 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 TRANSFORM_ADD 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. ENV_MATERIALS Don't know. Possibly determines route taken by caravans. PROBABILITY *Somehow related to the relative probabilities of the different goods. GOOD_INDEX *Connection to goods.txt. At present there is no way to edit the .til files to change what the terrain looks like, but that may change soon. See the Apolyton site forums for details (if you can find the relevant thread...). 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_xxxx 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). 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). 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 tose 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 scenario uses 'ma'). You can include quasi-hyper-links in the text files to other great library entries using the following notation: [Link text] For example, here is an extract from preqg001.txt, regarding one of the goods: LOCATED: Mountain Volcano 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 stage. 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 indexes 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 and possibly the . 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 detail here but refer you to the documentation (readme.doc) with v1.2 and the various files on the Apolyton site. ----------- 9 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. 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. ------------------- 10 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' scenario - 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 . ------------------ 11 Version history ------------------ v0.7beta (2001/08/18) --------------------- Added an explanation of q.v. and c.f. to the notes, and added more cross-references. 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!