Monster Media 1994 #1

home *** CD-ROM | disk | FTP | other *** search

/ Monster Media 1994 #1 / monster.zip / monster / BBS_GAME / VP314.ZIP / VP314D2.EXE / PLANETS1.DOC < prev next >

Wrap

Text File | 1994-01-26 | 37KB | 885 lines

VGA Planets(tm) Version 3 PLANETS.EXE Version 3.00 HOST.EXE version 3.14 (0.00) TABLE OF CONTENTS PLANETS1.DOC (0.01) ABOUT VERSION NUMBERS (0.02) SYSTEM REQUIREMENTS (0.03) REGISTRATION (1.00) INTRODUCTION TO VGA PLANETS (1.01) THE SCENARIO (1.02) HELP! (1.03) GAME MAIL PACKETS (1.04) THE HOST.EXE PROGRAM (1.05) BBS HOST SYSOP (1.06) INDEPENDENT HOST (1.07) PLANETS ON ONE COMPUTER (1.08) PLANETS ON MANY COMPUTERS IN THE SAME BUILDING (1.09) PLAYING PLANETS FROM THE HOST DIR IN A MULTICOMPUTER GAME (1.10) PATHS (1.11) Xmodem and Ymodem (1.12) Windows (1.13) Program Crashes (2.0) PLANETARY ECONOMY (2.1) MINERALS (2.2) MINERAL MINES (2.3) FACTORIES (2.4) DEFENSE POSTS (2.5) SUPPLIES (2.6) TAXES AND POPULATIONS (2.7) METEOR IMPACTS _________________ PLANETS2.DOC (3.00) STARSHIPS (3.01) TECH LEVELS (3.02) NEW SHIPS (3.03) WEAPON BANKS AND FIGHTER BAYS (3.04) FIGHTERS (3.05) WEAPON KILLING/DESTRUCTIVE POWER (3.06) STARSHIP FIX / RECYCLE (3.07) FUEL (3.08) CARGO (3.09) PRIMARY ENEMY (3.10) SHIP MISSIONS (3.11) STARSHIP NAVIGATION (3.12) FUEL (3.13) REPAIRS IN SPACE (3.14) COLONIZE MISSION (3.15) ALCHEMY SHIPS (3.16) MINE FIELDS (3.17) ORDER OF COMBAT (3.18) COMBAT LAWS/RULES (4.0) STARBASES (4.1) DEFENSE AND FIGHTERS (4.2) A BASE'S ROLE IN SHIP BUILDING AND ARMING (4.3) STARBASE ORDERS (4.4) PLANETARY / STARSHIP FRIENDLY CODE (4.5) STARBASE SCANNER (4.6) STARBASE FIX COMMAND (5.0) THE STARCHART ----------------- PLANET3.DOC (6.0) VICTORY CONDITIONS (6.1) LIST OF STARSHIP TYPES (6.2) A REVIEW OF THE RACE FLEETS (6.3) PERSONALIZED RACE NAMES (6.4) RACE.NM AND THE HOST (6.5) RACE.NM AND THE REMOTE PLAYER (6.6) RACE.NM AND THE LOCAL GAME (6.7) RACE.NM AND BBS SYSOPS (7.0) STARTING THE GAME (7.1) STARTING IF YOU ARE NOT HOSTING THE GAME (7.2) THE GAME FILES ( A BRIEF LIST ) (7.3) LIST OF PLAYER FILES (7.4) LIST OF ALL THE HOST FILES (8.0) SUPPORT (8.1) REGISTRATION (9.0) NEW FEATURES IN VERSION 3 ----------------- PLANET4.DOC (10.0) RACE ADVANTAGES (10.01) PLAYER 1 ( The Solar Federation ) (10.02) PLAYER 2 ( The Lizards ) (10.03) PLAYER 3 ( The Bird Men ) (10.04) PLAYER 4 ( The Fascists ) (10.05) PLAYER 5 ( The Privateers ) (10.06) PLAYER 6 ( The Cyborgs ) (10.07) PLAYER 7 ( The Crystal People ) (10.08) PLAYER 8 ( The Evil Empire ) (10.09) PLAYER 9 ( The Robots ) (10.10) PLAYER 10 ( The Rebels ) (10.11) PLAYER 11 ( The Colonies ) (10.12) A QUICK OVERVIEW (11.0) NATIVE RACE ADVANTAGES (11.1) HUMANOID (11.2) BOVINOID (11.3) REPTILIAN (11.4) AVIAN (11.5) AMORPHOUS (11.6) INSECTOID (11.7) AMPHIBIAN (11.8) GHIPSOLDAL (11.9) SILICONOID (12.0) NATIVE GOVERNMENT SYSTEMS AND TAXES (12.1) COLLECTING TAXES FROM NATIVES (12.2) COLLECTING TAXES FROM COLONISTS (12.3) TAKING OVER PLANETS WITH COLONISTS (13.0) DEFENSE AND ATTACKS (13.1) PLANETARY DEFENSE (13.2) GROUND WAR (13.3) SHIP TO SHIP MATH (13.4) SHIP DAMAGE EFFECTING WEAPONS AND ENGINES (14.0) SHIP WEAPON AND ENGINE STATS (15.0) MOUSE DRIVER SCALING FACTORS (16.0) HCONFIG.EXE (16.1) CONFIGURE STARSHIP RECYCLE RATE (16.2) CONFIGURE METEOR IMPACT ODDS (16.3) CONFIGURE MINE FIELDS (16.4) CONFIGURE ALCHEMY SHIPS (17.0) ERROR MESSAGES ----------------- PLANET5.DOC Appendix A: Ship hull spec list. Covers: Federation, Lizards, BirdMen, Fascist and Privateer. ----------------- PLANET6.DOC Appendix A: Ship hull spec list. Covers: Cyborg, Crystalline, Evil Empire, Robots, Colonies and Rebels. ----------------- PLANET7.DOC Appendix B: HINTS AND TIPS FROM THE INTERNET ----------------- (0.01) ABOUT VERSION NUMBERS This is version 3.0 and will NOT work with all previous releases. I will continue to support version 2.1 & 2.2 as long as there are version 2 games being played. (0.02) SYSTEM REQUIREMENTS The game can be played on any IBM compatible with VGA graphics and a 286 or faster CPU with a hard drive. (0.03) REGISTRATION Please register the game. This will allow me to continue eating, paying the bills and PROGRAMING. Thanks! Registered players may play in the same game as unregistered players. Registered players will have a slight tech advantage. If a player decides to register the game they can switch over to the registered version of the game and have easier access to tech levels 7 through 10. The shareware ( unregistered ) version of the game also allows access to all tech levels, but it takes more work to do so. Players that give registered copies of the game away will be attacked in the game by the Tim Continuum. (0.04) WARNING!!!: VGA Planets is >>>EXPENSIVE<<< Each computer system must have it's own registered copy to buy tech levels 7 to 10. If the game is being played on 11 different computers your players will have to each buy a registered copy. Yes, this adds up to $165.00. Yes, that is alot of money. Yes, some people can not afford to buy a registered copy for themselves and 10 of their friends, tough cookies! Let them buy their own copy. Sysop's should not worry about buying registered copies for the players, leave that to them. BBS systems CAN NOT register the game. Only players can. The HOST.EXE, MASTER.EXE, CPLAYER.EXE, REF.EXE, RCONFIG.EXE and HCONFIG.EXE programs are all FREEWARE. You can download these all from my BBS at (209) 877-4921 free of charge. If the sysop is also a player then yes they need to register. (1.00) INTRODUCTION TO VGA PLANETS VGA Planets is a graphical multiplayer play by turn war game that simulates combat in space between galactic empires. The game emphasizes mining, colonization and the construction of starships. The players compete against each other economically and militarily on a galactic scale. Although there is an economic component to the game, it is mainly a tactical and strategic wargame. Although the player with the best economy usually has the best potential to win, it's not the purpose of the game -- and the scoring system reflects this. The game system allows players to construct their own starships by selecting various components and placing them on a given hull type. This game can handle from two to 11 players. The game is designed to be a BBS or Net game. This game can also be played on one computer alone. The game can be played on any BBS that supports file transfers, with or without the sysop's help. Many people are playing VGA Planets over the NET using Email and UUENCODE. To begin the game, you are given a planet, a starbase, and two ships. You have to manage your planet's population and resources wisely. You can create more ships and expand your domain through colonization or conquest of neighboring planets. Of course, the other players are attempting to do the same thing. The game can also be set up so that players start with just freighters and no homeworlds. VGA Planets can be compared to a 11-player chess game in which all players move all their pieces simultaneously, one turn at a time. (1.01) THE SCENARIO Ten years ago a small fleet of freighters left your home world in a quest to find new worlds to colonize. Half way through your journey you lost all contact with fleet command. You then begin to fear the worst, a full scale galactic war may have broken out and your small fleet may be the last of your race. You left home with four very special ships that were equipped with tech 17 Bussard Ramscoops which gather low grade matter from the interstellar medium and converts it to antimatter fuel. The tech 17 Bussard Ramscoop Fuel Ships served you well until you lost the last one a year ago when the final cobalt-lanthanide-boronite fractionator coil (CLBF coil) burnt out, your fleet was then forced to make the rest of the journey burning low grade neutronic fuel. Your fleet finally arrived at your goal, the small Echo open star cluster on the outer tip of third major arm of the Milky Way. This open cluster contains 500 planets that are all named after the stars from your home star sectors. The last fuel base you passed is over 7000 light years away and you are unable to build new CLBF coils. In fact, the only know source of CLBF coils is small super high tech research station ran by a group of Andromedians near the galactic core 30000 light years away. The coils are shipped to all the major homeworlds by Endoane traders. A shipment of supplies which included 20 new CLBF coils was following one year behind your fleet until it was lost to an unknown band of pirates. The highest tech level ever achieved by your race has been tech 10, so it is really very unlikely that you will ever be able to build any CLBF coils on your own. Unless you reestablish contact with your homeworld or a supply shipment shows up you can regard this as a one way mission. Upon arrival at the first world you came to all your starships were landed on the planet's surface to be converted into raw materials for the building of mines, factories and one low tech starbase. A small local system freighter and a small capital ship were built when your starbase was completed. You soon learn that you are not alone. Moving across your starcharts are enemy races that have followed you to this star cluster. You must now put every effort into building the most powerful fleet of war ships possible before you are attacked. Your best hope is to send small freighters in every direction to drop off colonists and supplies so that they can grow in numbers on new planets and extract the minerals that your starbase needs to build more ships. You need to act fast because your enemies will most likely be trying to expand also. Pay close attention to the starchart, because you can see your enemy's ships as they travel between planets. Good luck . . . (1.02) HELP! In the game you can press <H> on most screens to see a help screen that explains this part of the game to you. (1.03) GAME MAIL PACKETS Players upload their turn (TRN) files to the host BBS or Email account. The host runs the actual calculations involved, and produces a result (RST) files that are sent back to the players. The players run the local program to view their situation and set up their orders for the next turn. Players then run an UNPACK program that decodes and expands the game result file (RST) into several data files. Then the main program PLANETS is run to play the game. When you are playing the game you can order your starships around, build new starships, receive messages and do many other fascinating activities. When a player has completed their game turn they exit the PLANETS program and run a program MAKETURN that packs the new data into a TRN file that is sent back to the host computer. After the TRN files from all the players are gathered into one directory by the person hosting the game the program HOST is ran to decode all the TRN files at once. New RST files are generate by the HOST program. These new RST files are then sent back to all the players. NOTE: If any player miss out on a turn the game will continue just fine. Their ships and planets will continue performing their last order. Ships will continue the same coarse and speed and planets will continue to mine minerals and produce supplies. A missed turn can't be made up! The host cannot use old TRN files. They are meaningless to the host. (1.04) THE HOST.EXE PROGRAM All the TRN files of the players from all the players who are taking part in the current turn must be in the game data directory when you run HOST. You can only run HOST once per game turn. Running HOST outside the directory that contains the game universe data files DOES NOTHING! TRN files from other games are rejected by HOST and erased. A person hosting a game called me up and told me about the following problem: Nine people are currently playing a game. One person somehow lost their RST file. So they had the person hosting the game run HOST again. The player with the missing file then put the new RST file on floppy and went home. They next day everyone puts all ten of their TRN files in the host directory and HOST is run. Everyone notices none of their new commands are recognized and the HOST says all but one file is stale. What went wrong? Answer: When HOST was run the second time all old TRN files and RST files became stale files from last turn. Only the player that lost the RST has a fresh file after they grabbed the new RST file after the HOST program ran. All ten of the other players missed TWO turns because of this. The last turn because they had not turned in their TRN files yet and the current turn because the files that they did turn in were stale and had to be rejected. ONLY RUN HOST ONCE PER TURN. You may wish to make a backup directory to store all the current RST files after you run HOST, just in case someone loses their RST file. Don't let anyone talk you into running HOST before the players have turned in their current TRN files. HOST needs all the TRN files all the players who are going to be in on the current game turn, because all the action and interaction between players TAKES PLACE AT ONCE, when HOST is run. Stale File: A RST or TRN from a previous game turn. The HOST program rejects all stale TRN files. The player with the stale file will miss a turn. If you unpack a stale RST file, all your data files will be stale and you will end up producing a stale TRN file when you run MAKETURN. Fresh File: A RST or TRN from the current game turn. When a person misses a game turn, they MUST get a fresh RST file from the host computer. Or they will end up making a stale TRN file. (1.05) BBS HOST SYSOP Just how many turns there are per day are completely up to the person hosting the game. You may wish to have only one game turn per day. If you are a sysop you may wish to just put in a little batch file that is run every day at clean up time that has your machine copy all the PLAYER TRN files into the proper directory, perform a game turn ( run HOST ) and copy the PLAYER RST files into a directory from which the players can then download their file. If the host crashes while running it will log the error to the error log file and exit to dos. When you have 250K or more of free memory you can run HOST from a DOS shell. The game administrator has the option when first starting the game to give each race their own password, so that even if a player downloads another player's RST file that player will be unable to open it without the real player's password. Players can change their password during their turn, but the change does not take effect until the next turn. Players can also turn off the password check by changing the password to "NOPASSWORD". I strongly advise the sysop set up the BBS so that the TRN files can only be uploaded by the proper players, unless you feel that you can trust your players. For example: I am player 2 ( The Lizard Player ). The file that I upload to the BBS host computer is "PLAYER2.TRN". The file that I download from the BBS host is "PLAYER2.RST". Nobody else should be able to upload a file named "PLAYER2.TRN" and mess up my turn. There are not several very good door programs that makes setting up BBS games very easy. Many sysops compress the PLAYER RST files using PKZIP, ARJ or LHA to make RST download times faster. The PLAYER TRN files are so small that there is really no point in compressing them. (1.06) INDEPENDENT HOST An independent host is a BBS user ( or a Net user ) that is hosting a VGA Planets game on their own computer. The independent host uses the BBS only for a means of transferring the RST and TRN files to and from all the players in the game. One easy way of moving the files around is to attach the files to Email. Once a day the person acting as the independent host downloads all the TRN files sent to him from all the players in the game. The files are moved into the planets data directory and HOST is run. The result files (RST) are then mailed back to all the players. The independent host should be sure to tell all the players what time the TRN files have to be in by, when then next turn will take place and when they can log back onto the BBS to pick up their new RST file. (1.07) PLANETS ON ONE COMPUTER A group of people can set up a game on one computer and take turns playing out their turn. After everyone has had their chance to play out their turn the game administrator will then exit the PLANETS program, run MAKETURN, HOST and finally UNPACK. All this will perform the math and file data file building for the next turn. Players can then again take turns playing out their turn. All the files remain in one directory on the computer. You may use the TURN.BAT file to run all the above files in the correct order and return to the planets game automatically. (1.08) PLANETS ON MANY COMPUTERS IN THE SAME BUILDING All the computers must have the planets player files installed in a directory. One computer must act as host and have the host files installed. You can use a network to transfer RST and TRN file back and forth or you can use a pair of floppies. Using a pair of floppies: .................................................................... Label floppy one "RST result files". Place the "RST result files" floppy into the host computer and copy all the RST files from the Planets directory onto it. Pass the floppy around to each player so that they can copy the file that belongs to them into their Planets directory. _______________________ AN EXAMPLE: Player 2, the Lizard player, has the game installed in directory c:\PLANETS The Lizard places the "RST result files" floppy into drive a: copy a:\player2.rst c:\planets The Lizard player then passes the floppy along to the next player who hasn't yet gotten their RST file yet. _______________________ Players must run UNPACK to decode the RST into data files. The players may then run PLANETS and play the game. After finishing their turn they exit the game and run MAKETURN that generates a new TRN file. Label floppy two "TRN the players turns". Pass "TRN the players turns" around to each player that has finished their game turn and ran MAKETURN already. The players then copy the TRN file in their game directory onto the floppy and pass the floppy along to the next player. _______________________ AN EXAMPLE: Player 1, the federation player, has the game installed in the directory c:\PLANETS The fed player places the floppy "TRN the player turns" in drive a: copy c:\planets\player1.trn a: The fed player then passes the floppy along to the next player. _______________________ After all the TRN files are gathered, they are all copied into the host's data directory from the floppy "TRN the players turns". The game administrator will then run HOST. This will decode all the TRN files and generation brand new RST files. The whole cycle repeats . . . .................................................................... (1.09) PLAYING PLANETS FROM THE HOST DIR IN A MULTICOMPUTER GAME You ready shouldn't play planets from the host directory if you are hosting a game where files (TRN) and (RST) are being transferred back and forth over modem or net. Set up another directory to play the game. The danger in playing from the HOST directory is you may clobber the in coming TRN files by mistake when you run MAKETURN and the RST files when you run UNPACK. This will cause all the game turns, except yours, to become stale and their commands will be thrown away. It is best to make a sub directory and play out your turn there. (SEE PATHS 1.10) NEVER run TURN.BAT in a multicomputer game! TURN.BAT is for local games (one computer, one game directory). (1.10) PATHS NEW for version 3 is the ability to specify a path to where the data files for the game are stored. All VGA Planets programs will accept a path. If you do not specify a path the programs will look for the data in the current directory. master dirname Where "dirname" is the name of the directory where this VGA Planets game's data files are to reside. If "dirname" does not exist, MASTER.EXE will create it if it can. It is recommended that an empty directory be used for new games of VGA Planets. In case you are hosting more than one game of VGA Planets, you should know that the data files for each game MUST be kept in separate directories! If you run MASTER.EXE and specify a directory containing a VGA Planets game-in-progress, the game- in-progress will be lost, overwritten by the newly started game. MASTER.EXE allows the host to control several key game parameters: - which races will be participating? - whether or not each race will have a starting password. - whether friendly codes on planets will be randomized. - range of starting distances between homeworlds. - mineral richness of all homeworlds. - the starting population of the planet - starting engine tech level for all homeworlds' starbases. These parameters cannot be changed without destroying the game and starting over. You don't really need to use the path option unless you are running more the one game. By using the path option you can have many games running at once on your machine and use very little extra disk space. When you run MASTER with a path all the data important to a game will be moved to the game data directory. You can zip up all the files in the game data directory and move them to another computer, if you should ever need to move a game to another computer. All the EXE programs will look for game data at the path given and they will also look for the static data files in the current directory. The static data files are installed on your hard drive when you install the game. Example: ( INSTALLING THREE GAMES ) You have installed the game on your hard drive at C:\PLANETS c: cd \planets mkdir game1 <- you make the directory for the game master game1 <- make the game universe host game1 <- make the first set of RST files ---------------------- < Time out while you play your turn > copy \planets\game1\player1.rst \temp unpack \temp <- unpack the RST files planets \temp <- play! maketurn \temp <- make the TRN file copy \temp\player1.trn \planets\game1 ----------------------- < START A SECOND GAME > mkdir game2 master game2 host game2 < START A THIRD GAME > mkdir game3 master game3 host game3 < you now have three games going > ____ game1 | c:\planets\-+---- game2 | ---- game3 Example: ( MOVING GAME ONE TO ANOTHER MACHINE ) cd \planets\game1 pkzip game1.zip *.* give game1.zip to the other sysop (1.11) Xmodem and Ymodem Xmodem and Ymodem transfer protocols should not be used to transfer TRN and RST files. Xmodem and Ymodem may cause data transmission errors. Use Zmodem if possible. (1.12) Windows Planets sometimes works under MS Windows as a DOS Session. (1.13) Program Crashes If any of the programs crash run the MS-DOS command CHKDSK /F to make sure your hard drive is free of errors. DR-DOS users use the command CHKDSK /M/F MS DOS now has a great new tool called SCANDISK that works far better CHKDSK. ------------------------------------------------------------------------------ (2.0) PLANETARY ECONOMY The planetary economy is based on mining, factory production, taxes and population. (2.1) MINERALS There are 4 types of minerals: Neutronium is the super dense mineral used for fuel on starships. It is far too unstable for use in building ship components. Duranium is a very strong mineral used to build the frame work of starship components and the armor skin of starbases and fighters. Tritanium is a mineral that can withstand very high pressures and temperatures. It is used widely in starship construction. Molybdenum is used mainly in high power energy wave guides. It is important for weapon construction and engine construction. High tech components tend to use greater amounts of molybdenum then lower tech components. All unexplored planets will have some minerals sitting on the planet's surface along with minerals buried in the planet's core that can be mined. (2.2) MINERAL MINES Mines extract minerals from the planet's core as long as one of the four minerals are present. If no minerals are present, mines are completely useless. The cost of building a mine is 4 megacredits and a supply unit. The maximum number of mines that can be constructed on a planet is limited by the size of your colonist population. Mines only remove minerals from the ground, they DO NOT produce minerals out of thin air, they will stop giving you minerals when the planet runs out of minerals. When a planet runs out of minerals all the mines on the surface become useless junk that cannot be recycled. Mines are permanent scars on the planet's surface and will add to the planet population's discontent. Starships and colonists can take a mining survey of the planet that will show you a graph of the amounts of minerals remaining unmined in the planets core and a listing of the amounts of ore that have been mined so far and are ready for use. The survey will also tell you the number of mines present on the planet. The rate that your mines can extract ore out of the ground depends on the concentration of the ore. There are five grades of mineral concentration. 1. very scattered ( ten mines can extract a KT per turn ) 2. scattered 3. dispersed ( three mines can extract a KT per turn ) 4. concentrated 5. large masses ( one mine can extract a KT per turn ) The amount of minerals in a planet is rated at five different grades. 1. none ( 0 KT ) 2. very rare ( 0 to 99 KT ) 3. rare ( 100 to 599 KT ) 4. common ( 600 to 1199 KT ) 5. very common ( 1200 to 4999 KT ) 6. abundant ( 5000+ KT ) Most planets can be mined clean in just a few turns, but planets with abundant minerals will produce minerals for a very long time. If you build a great number of mineral mines the population on the planet will unhappy and you will be forced to drop the tax rate to keep them happy or else face the risk of riots and war. Mineral mines and factories risk showing up on enemy sensors unless the planet has a planetside defense of more than 100. (2.3) FACTORIES Factories produce one supply unit each turn. The cost of building a factory is 3 megacredits and one supply unit. The maximum number of factories that you can build on a planet is limited by the size of your colonist population. When a planet becomes over populated (at somewhere around 11,000,000 on your homeworld) the colonists will be forced to eat and use supplies to keep from starving. Some planets can reach a state of over population at around 1,000,000 colonists if they have an arctic or desert climate. If you notice that your supply production has stopped or slowed then you are having an over population problem. There are a few desert and arctic planets were the climate is so bad that 1 clan is considered over populated. (2.4) DEFENSE POSTS Defense posts protect the planet from attacking starships. Cost of building a defense post is 10 megacredits and one supply unit. The maximum number of defense posts you can build on a planet is limited by the size of your colonist population. Defense posts will screen the planet's industrial activity from long range sensor sweeps by enemy ships. The odds of detection are (100 - NUMBER OF DEFENSE POSTS )%. The number of fighters that a planet can launch to defend the planet from enemy ship attacks equals SQR( NUMBER OF DEFENSE POSTS ). Fighters from a planet are regenerated after each attack. (2.5) SUPPLIES The supplies produced by your factories can be carried by starship to new planets to be used to build new factories, mines and defense posts. You can also sale supply units for one megacredit each. Alchemy ships can use supplies to make minerals and fuel. (2.6) TAXES AND POPULATIONS By taxing the colonist and native populations you can generate megacredits for building mines, factories, defense posts, a starbase and starship components. The populations will become upset with you if the tax rate is too high or if there is over population. They may become upset if there are too many mines, factories, or defense posts due to environmentalist movements begins within the population. Over several turns the populations of a planet may become very unhappy. If they ever become too unhappy they will start a riot or even a civil war. If this happens they will kill each other and destroy your mines, factories and defense posts. If a riot starts the tax rate will be instantly set to 0% to prevent a civil war. A high tax rate slows the birth rate. You can use this factor to prevent over population. Keep in mind that a population with a tax rate of 0 will cause the population to expand at the maximum rate. A planet's climate will also affect the maximum population and the birth rate. Temperate warm planets provide the best possible conditions for all lifeforms. Desert and arctic planets are the worst possible conditions for life. If the population is ever greater than the population that the planet's climate can sustain, the colonists will consume supplies to survive. If the climate is too harsh you may have to make regular freighter runs of supplies to the planet to keep the colonists alive. (2.7) METEOR IMPACTS The Host person can set the odds of ONE very large meteor crashing into a planet by using the HCONFIG program. When a meteor strikes a planet, massive amounts of new minerals and fuel ore will be buried deep in to planet's core. That planet will then become a mineral rich world and a very good place to build mineral mines. Many bad things happen to a planet that is hit by a meteor. A great number of the population will be killed. Many mines, factories, and defense outposts will be destroyed and the planet may be plunged into a civil war. Your starbase and all ships in orbit will be safe from the effects of the meteor. When a meteor hits the resulting explosion is so large that all the races will know which planet was hit (everyone will receive a message). This could trigger a "mineral rush" to get to that planet first and setup a colony there first. The impacted planet should have enough minerals buried in it to build a starbase and many new ships. That makes the planet impacted a real prize. ------------------------------------------------------------------------------ [ Continued . . . SEE PLANETS2.DOC ]