NOTE: SOME OF THE SETTINGS DESCRIBED ARE INTRODUCED IN THE UNOFFICAL PUBLIC BETA PATCH FOR THE GAME RELEASED BY TALDREN, so those might change or others might be altered when the patch (or even an official beta) is released. This includes the sections on forfeit penalties, the section on officer skill advancement, and the section on offering alternative "hail" missions, plus possibly some others I've forgotten :)

Please let me know if you can supply corrections or additions! (NuclearWessels@hotmail.com)

Much of the information contained in this document has come from a wide range of players and server admins for SFC2 and SFC3, Nomad, CptCastrin, Poland, MaxTorps, carrie, SkullnBonez, Rook, Articfires, BBJones, kosh2000, Mog, Magnumman, a whole slew of folks I've forgotten to list, and of course the good folks at Taldren - a big thanks to all of them! Any mistakes or omissions in the document are my own fault, apologies for that! Dave (Nuclear) Wessels

I have no objections to people using any of my material as long as it is not for profit (though I'd certainly appreciate due credit) but you must respect the rights of the game developers, owners, and publishers.

• 1. An introduction to D3 servers
  • 1.1 D3 single-player campaigns
  • 1.2 D3 online campaigns

• 2. Initial setup
  • 2.1 What do you need to customize a campaign?
  • 2.2 Setup and file location: single player campaigns
  • 2.3 Server kits and setup: online campaigns
  • 2.4 Misc. setup notes

• 3. Selecting and customizing the map
  • 3.1 Selecting which map a campaign will use
  • 3.2 Customizing the map itself
  • 3.3 Controlling movement on the map

• 4. Controlling alliances and political tensions
  • 4.1 Setting starting alliances
  • 4.2 Changing alliances over time

• 5. Controlling ship pricing and availability
  • 5.1 Prices: ships, supplies, repairs, trade-ins
  • 5.2 Ship production, time, and the economy
  • 5.3 Starting ships for players and the AI

• 6. Controlling AI populations and behaviour
  • 6.1 AI populations
  • 6.2 AI goals
  • 6.3 Fleets - composition and behaviour
  • 6.4 AI-only battles and results

• 7. Controlling mission availability
  • 7.1 Selecting missions for a campaign
  • 7.2 Controlling mission offerings
  • 7.3 Controlling opposition strength
  • 7.4 Controlling special mission offerings (storyline campaigns)
  • 7.5 Controlling base placement and impact

• 8. Customizing names (ships, officers, planets, etc)
  • 8.1 Customizing officer names
  • 8.2 Customizing ship names
  • 8.3 Customizing planet names
  • 8.4 Customizing rank names
  • 8.5 Customizing race/empire names
  • 8.6 Customizing other text

• 9. Controlling officers
  • 9.1 Officer availability
  • 9.2 Officer advancement

• 10. Controlling the flow of time and campaign duration
  • 10.1 Establishing turn duration and turns/year
  • 10.2 Interaction of time with economy and AI behaviour
  • 10.3 Establishing automated campaign victory conditions

• 11. Controlling news and reporting
  • 11.1 Frequency and volume of news reports

• 12. Saving and restoring campaigns
  • 12.1 Controlling when saves take place
  • 12.2 Shutting down and restarting campaigns

• 13. Controlling mission results and impact
  • 13.1 Player results from missions
  • 13.2 Mission impact on hex defensive values
  • 13.3 Mission impact on political tensions
  • 13.4 Controlling frequency and impact of AI-vs-AI missions
  • 13.5 Player and AI "glicko" ratings
  • 13.6 Player rank and advancement

• 14. Modifying game technology
  • 14.1 Changing Weapon Stats
  • 14.2 Changing Bridge Component Stats
  • 14.3 Changing Hull Component Stats
  • 14.4 Changing Engine Stats
  • 14.5 Changing Shield Stats

• 15. Modifying ships
  • 15.1 Modifications to DefaultLoadout.txt
  • 15.2 Modifications to DefaultCore.txt
  • 15.3 Models

• 16. Databases: Flatfile and SQL (maybe someday)
  • 16.1 Modifying a campaign on-the-fly: editing the flatfile DB
  • 16.2 SQL campaign databases

---

• 1. An introduction to D3 servers
  This guide should give you most of the information you need to customize your single player campaign as much as you like. For the most part, the settings in single player campaigns and online servers function identically, so I'll just try to include notes where an item is relevant for one form only.

  • 1.1 D3 single-player campaigns There is remarkably little difference between a single-player campaign and an online campaign: in a sense for the single-player campaign their PC is acting both to play the game and also as a "just for you" server.

    If you ignore the parts about "connecting to the server" below, you'll find the description comes very close to covering single-player campaigns.

  • 1.2 D3 online campaigns
    Here we'll take a stab at describing what role your PC and the assorted servers play during the different parts of an online dynaverse campaign. (Again, for single player all the relevant parts are taken care of by your own machine.)

    This is all pretty much guesswork, so if anyone has corrections feel free to pass them along!

    The pieces of an online campaign

    There are three key components involved in an online campaign:

    • The central directory server that keeps track of which campaign servers are currently up and running,

    • The campaign servers themselves (e.g. the GFL server(s), the Triangle server, the Activision servers, etc etc)

    • The individual players' PCs

    (Note that servers are just computers running appropriate software to provide options to collections of other users - the software needed to use an ordinary PC as a D3 server is provided as part of the D3 server kit described elsewhere.)

    How all these components work together is described below.

    What happens when you connect to a server?

    1. When you fire up the game and go to multiplayer/dynaverse/login, your PC establishes a communication connection to the central directory server.

       This is done automatically, and works fine as long as your connection is ok, you aren't running a firewall (or have performed any necessary technical voodoo to prevent it from interfering with SFC3), and Activision's central server is actually up and running.

    2. The central directory server is also in communication with all the different D3 servers that are currently up and running, and acts like a matchmaker - it passes the server descriptions, player loads etc on to you, and you tell the central server which campaign server you wish to connect with.

    3. When you pick a server, a link is established between you and the server (that lag time while you're waiting to get on the server, impatiently tapping your fingers and hoping you get through).

    4. Once the connection is established, the central directory server bows out, leaving you in communication with the server.

       Before
       ======
       One D3 Server
       	\
       	CentralDirectoryServer-----Your PC
       	/                      
       Another D3 Server
       
       After
       =====
       Player 1's PC
       	\
       	Selected D3 Server-----Your PC
       	/
       Player 2's PC
       

    5. Each D3 campaign server keeps track of all its universe details - where all the ships in the galaxy are, what the map looks like, what the state of the economy is, what ships are in the shipyards, and which ships are currently involved in missions

       The first time you connect to the server you are asked to choose a race, and when you do so it creates a character for you (name, starting ship, prestige, etc) and adds all that stuff to the list of things it has to keep track of.

       After that (and every subsequent time you connect to the server) the server takes a few moments to tell your PC everything it needs to know about the current state of the universe. This includes the list of players currently logged on and an up-to-date copy of the map. The delay you experience waiting for the map to appear is part of this process - at first the server has to tell your PC a lot about the universe. Once that's done it only needs to let you know when things change.

       From that point on, as long as you aren't actually in a mission, the D3 server and your machine are constantly keeping each other informed about what's going on:

       • when players log on or off, or go into or come out of missions, the server passes word along to your PC so it can update the player list
       • when players move into or out of the hexes immediately around your ship, the server passes word along so the ship symbol appears/disappears on your map
       • when a hex flips, or its value changes, the server passes word along so your PC can update its map
       • when people type something in chat the server passes word along, etc etc

       The most interesting (and most complicated) set of circumstances comes about when you move from one hex into another, so we'll start a separate step to look at that.

    What happens when you accept a mission online?

    When you move from one hex to another, it causes a whole chain of events to occur:

    1. First, your PC sends word to the D3 server that you want to move from your current hex to a target hex.

       You then sit around and wait until the D3 server acknowledges that yes, it knows your moving and your move is ok.

       You get delays here for two reasons, (i) the server admin can specify how much to deliberately slow people down when moving, (ii) if the server is busy it can take a few seconds before it gets around to acknowledging you

    2. When you move from one hex to another the server has to decide what kind of an impact that has on mission offerings, so (as far as I can tell) the following things take place:

       • The server looks at the hex you've moved into and looks at every type of mission on the server, and decides which mission(s) to offer you (if any).

         To do this, the factors it considers are:

         • the type of terrain (asteroids, shipping lane, etc)
         • the presence or absence of planets and bases
         • who owns the hex
         • which other ships are in draft radius, and the size and race of each of those ships

         The server compares those factors to the set of recommendations the mission script contains, and decides which missions you should be offered.

       • The server displays a set of available missions to you, and shows you who else is in the hex and whether or not they are in battle. You may or may not choose one of the missions, or you may choose to attack or defend someone else in the hex. (Or, you may get attacked by someone before you get the chance.)

       • When you select a mission, the server has to go through another sequence of steps:
         • Pick what kind of map you'll be using,
         • Grab your chosen fleetmates and opponents from the dynaverse,
         • Inform all the players of their role in the mission, and give them time to accept or forfeit
         • Generate AI ships to fill in certain specialty teams in some missions.

         • GET ALL THE INVOLVED PLAYERS' PCS TO HOOK UP WITH EACH OTHER TO RUN THE MISSION

           This is important, in that at this point the D3 server steps out of the loop for awhile.

           The player who initiated the mission starts off as the mission "host" - it is that player's PC that directs the running of the mission and keeps the other players' PCs informed about what's going on.

           Communication problems between the players' PCs cause the infamous lag and drop problems.

           If communication between the host and another player is broken, you get the "host left" message, and one of the remaining players' PCs takes on the duties of hosting the mission.

           Once the mission completes, everyone hooks back up with the D3 server, and the host PC informs the server what the results were.

           This is what explains many of the weird things that happen when players drop. If the communication link between two players is broken, then both may see it as if the other player dropped, both players' PCs start acting as host, and both communicate results to the D3 server. Since both players may have finished their missions against AI opponents, their reported results may be very different.

           This is also the reason that you can complete a mission long after the server has actually gone down - you don't find out the server is down until the mission is over and your PC tries to re-establish its connection to tell the server what the results were.

    Players and the AI: what ships are out there?

    Ships in the dynaverse come in three flavours:

    1. Ships that belong to players, and as such are a permanent part of the dynaverse (well, permanent until they're destroyed or traded in)

    2. Ships that are controlled by the AI but are a permanent part of the dynaverse - the number of these, the way they move through the dynaverse, and the way they take on missions in the dynaverse are all controlled or influenced through configuration files maintained by the administrators of the D3 server.

    3. Ships that are generated and eliminated on a mission-by-mission basis. Some missions have specific roles, or teams, that are created out of thin air at the start of the mission and evaporate again at the end of the mission.

  ---

• 2. Initial setup

  • 2.1 What do you need to customize a campaign?
    For the single player campaign all you need is to have the game installed. Most of the settings can be altered using simple text editors, e.g. Notepad. This will be sufficient for editing all the .gf files and all the .mct files discussed below.

    If you want to edit the campaign maps, you'll need to obtain a copy of the Artifex editor, directions on using it are covered later in this document.

    If you want to edit the shiplists (also discussed later) you'll probably need a copy of Microsoft Excel (though the free Excel viewer may suffice).

    To run an online server you need to have the server kit installed, but you do NOT need to have SFC3 installed on the same machine. (Which is just as well, since it takes a pretty ace machine to run a server AND let you play on it at the same time without processing headaches.)

    The server kit is freely available, this link is from the downloads section of sfcx.org.

    For file editing, the requirements are the same as those listed for the single-player campaign.

  • 2.2 Setup and file location: single player campaigns
    For the single player campaign all one has to do is start the game and choose to start the appropriate type of campaign, so the biggest trick for customization is knowing which values to modify in which files.

    Sections 3 through 15 of this guide cover the specifics of customization, but first we'll outline the key file locations.

    Most of the files of interest are clustered in seven areas within the SFC3 folder:

    • the MetaAssets folder contains the campaign maps (.mvm files)
    • the MetaAssets\ServerProfiles\SinglePlayer folder contains a large number of .gf files used to control most of the campaign settings. Each of these files can be edited with Notepad or any other simple text editor.
    • the Assets\Scripts folder contains all the mission scripts (.scr files). If new missions become available they can simply be copied to this location. (Actually creating new mission scripts requires the use of the scripting API (not yet released) and Microsoft's Visual C++ (6.0 or higher I believe).)
    • the Assets\Scripts\Campaigns folder contains a number of .mct files which are used to set up the basic framework for a campaign. These files can also be edited using Notepad or other text editors.
    • the Assets\CommonSettings folder contains a number of .gf files, these ones dictating settings related to types of ship system, rank, officer names, etc. Once again, these can be modified with any text editor.
    • the Assets\Specs folder contains the DefaultCore.txt and DefaultLoadout.txt files, which describe ship configurations. These files are best edited using Excel.
    • The Assets\Strings folder contains the shipnames.txt and strings.txt files, which are also best edited using Excel.

  • 2.3 Server kits and setup: online campaigns

    Assuming you have obtained and unzipped the server kit to a folder of your choice, some of the file locations are slightly different for servers:

    • the campaign maps are located in the Assets\Maps folder
    • the server profile .gf files are located in Assets\ServerProfiles
    • there is an extra Assets\ValidatedClientFiles folder: here you place copies of the DefaultCore.txt, mission scripts, and other files you want to ensure exactly match those of the players. This folder is designed to prevent players from logging on to your server with "unfair" modifications.

    Since servers are run independently of the game itself, we'll need to go through the basics of setting up and starting your server:

    1. For the server to communicate properly with the players and with the Activision directory servers you need to ensure the following ports are free:

       	tcp 26100 - 26110 
       	udp 2302 - 2400
       	tcp 27100 - 27110
       	udp 27100 - 27110
       	tcp 8085 and 6073
       	udp 8085 and 6073
       

    2. The following quote is from the file distributed with the kit:

        A future addition to the server kit will require .NET, you might want to install it now.
          The requirement is for the 1.0 .NET Framework Redistributable with SP2. There is a number of ways you can get it.
       
       	A. Most people will have it as an option if they use Windows Update.
       
       	B. You can also go to http://msdn.microsoft.com/netframework/downloads/default.asp and follow the links to get the version you want.
       
       	C. Or the direct links are as follows
       
       	Microsoft .NET Framework Redistributable  1.0
       
       	http://msdn.microsoft.com/downloads/default.asp?url=/downloads/sample.asp?url=/msdn-files/027/001/829/msdncompositedoc.xml
       
       	Microsoft .NET Framework SP2
       
       	http://msdn.microsoft.com/netframework/downloads/updates/sp/download.asp
       
       	I think you need to get both the Redistributable and the SP2, I’m not sure if MS bundled it.
       

    3. You'll need to give your campaign a name and description - this is what the players will see describing your campaign on the main list of servers.
       Use Notepad (or whatever) to open the Assets\Scripts\Campaigns\Campaign 1.mct file, and set the Name="xxx" and Description="yyy" fields to describe your campaign.
    4. Go through whatever setting changes you would like to make (see sections 3-15 below) (for your first server you might initially try it without any other changes, just to make sure you can get the default one up and running first).
    5. Run the ServerPlatform.exe program in the server kit folder
    6. Choose option 1 to start the server
    7. If you wish to stop the server later, simply hit enter to bring up the options menu, then choose shutdown.
    8. To restart the campaign at a later date, run the .exe and choose 1 again.

    Mailing list: for more information, or to discuss matters with the other admins out there, a mailing list exists for dynaverse server admins:

    http://groups.yahoo.com/group/DynaverseAdministrators/join
    

    Note: as a courtesy to those admins who do put in a lot of effort on this, if you aren't serious about running servers please don't join the group.

    LogViewer: to examine the log files detailing server action, a viewer has been provided (in the LogViewer folder). Here is a quote on using the viewer:

    Notes on using the new LogViewer:
    1. There is a simple filter system:
    
    	If you click View | Set Filter an edit box will come up. 
          You can enter any RegEx (Regular Expression) in there and it will filter the output. 
          It’s still rather crude and untested; 
               if you enter an expression that is not a RegEx then it will crash (just found that out myself).  
               However, I thought it would be fun to play with. 
               To clear the filter just enter an empty string or “.*”
    
    2. It will only display 1000 elements. 
             That was a last minute fix for a performance issue. 
             It might be able to do much more then that, but I didn’t want to take a chance.
    
    3. A log file is always created, it is given the date the log file was created, 
         and it is placed in the same directory LogViewer.exe is run from.
    
    4. If you didn’t use the default Debug.gf that came with the new kit, 
         then you should make sure your [Log] section looks like this:
    
    [Log]
    LogToLogViewer            = 1                                           // (1)
    LogViewerName             = "LogViewer"    // "LogViewer"
    LogToConsole              = 0                                           // (0)
    LogToDebugOutput          = 0                                           // (0)
    LogToEventViewer          = 0                                           // (0)
    EventViewer               = ""                               // Machine Name ("meta1")
    LogToFile                 = 0                                           // (0)
    LogFileName               = "logfile.log"
    
    
    You only really want the LogViewer on. 
         If you turn on the other logging systems the server’s performance will be negatively affected
    

  • 2.4 Misc. setup notes

    .mct files A campaign .mct file is used to select a map, difficulty level, time era, race, and mission list for a campaign. For single player "storyline" campaigns it is also used to determine what the first specialty mission is, and how much prestige a player must currently have before the first specialty mission is offered.

    Below we show an extract from a conquest campaign with 10 playable missions. These are in addition to the usual ability to attack or be attacked by other players, bases, shipyards, planets, and convoys.

    There are three possible eras each campaign can begin in: early (0), middle (1), and late(2), and you can specify a different starting map depending on which era the campaign is started in. The specific stardates the different eras correspond to are set in the Time.gf file (discussed later).

    Note that we can insert comments (notes to ourselves) within the file, by preceding them with //. I've added a number of comments below to explain the file contents.

    EarlyMapName="TNGMap.mvm" 	// if the campaign begins in Early era, we decided to use use this map
    MidMapName="Single.mvm" 	// if the campaign begins in Mid era, we decided to use this map
    LateMapName="Multi.mvm"		// if the campaign begins in Late era, we decided to use this map
    DifficultyLevel=2			// 0 = easy, 1 = average, 2 = harder
    Era=0					// 0 = early era, 1 = mid era, 2 = late era
    TriggerMission=""			// This is not a storyline campaign, so no special mission listed
    TriggerPrestige=0			// No special mission to start the campaign, so might as well leave at 0
    
    [Missions]
    1="Meta_Scan.scr"
    2="Meta_DistressCall.scr"
    3="Meta_SupriseR.scr"
    4="Meta_Delivery.scr"
    5="Meta_Escort.scr"
    6="Meta_SunMission.scr"
    7="Meta_Monster.scr"
    8="Meta_Casino.scr"
    9="Meta_Derelict.scr"
    10="Meta_Rescue.scr"
    
    // Below we list the races which can be selected and played for this campaign
    [Races]
    0=0	// List the Federation as choice 0 in the selection list
    1=1   // List the Klingons as choice 1
    2=2   // List the Romulans as choice 2
    3=3   // List the Borg as choice 3
    

    For a single-player (storyline) campaign, we might want the player to amass 2000 prestige before beginning the storyline. An example of this is shown below for the Klingon campaign

    Name="Klingon"
    Description="Play the General Campaign as a member of the Klingon Empire."
    
    EarlyMapName="Single.mvm"
    MidMapName="Single.mvm"
    LateMapName="Single.mvm"
    DifficultyLevel=2
    Era=0
    TriggerMission="Kli_Brotherhood"
    TriggerPrestige=2000
    		
    [Missions]
    0="Kli_Brotherhood.scr"
    1="Kli_AVastYeScurvyTargs.scr"
    2="Kli_TooFar.scr"
    3="Kli_Treachery.scr"
    4="Kli_WindsOChange.scr"
    5="Kli_AnviloPeace.scr"
    6="Kli_TurningTables.scr"
    7="Kli_FishBarrel.scr"
    8="Kli_Obedience.scr"
    9="Kli_EDuty.scr"
    10="Kli_Barking.scr"
    11="Kli_FDay.scr"
    12="Kli_FriendOrFoe.scr"
    13="Kli_Recall.scr"
    14="Kli_Blood.scr"
    15="Meta_Scan.scr"
    16="Meta_DistressCall.scr"
    
    [Races] 
    // only the klingon race is playable this time
    0=1
    

    Controlling the player population

    In the Character.gf file we can set limits on the total number of players a server can keep track of, the number of players that can be logged on at any given time, and how long to keep track of a player between sessions before we erase their account.

    PlayersMax	= 5000	// maximum number of human characters in the campaign
    PlayersLoggedOnMax	= 128	// maximum number of players logged on simultaneously
    PlayerMaximumInactivity	= 30	// number of days between log-ons before a player's character is deleted
    

    Security

    If the player's files don't match the server files, then in the Assets.gf file we can generate an appropriate error message:

    SecurityCheckFailureMessage	="This server has detected that one or more of the necessary files required to connect are either missing or incompatible.  List of offending files: "
    

    Game Speed, difficulty, and time settings

    The MissionMatching.gf file allows us to set a number of key variables with regard to speed and time on our server:

    [Game]
    GameSpeed	=9 	// default game speed for the server
    
    // Time to wait for missions selection in milliseconds,
    // the countdowns you see before a mission
    [SetupProtocol]
    ResponseWait	=15000 // wait 15 seconds for a response
    ReadyWait		=15000 // wait 15 seconds before launching
    
    [EngagementTimers]
    EngagementServerTickRate	= 1000	// time in ms
    WaitForBattleStart		= 45000	// time in ms before battle starts and no one else will join (battle is resolved to play/or not at that point)
    WaitForMissionReception		= 25000	// time in ms allowing players to acknowledge receipt of mission, ready to start
    WaitForBattleResults		= 480		// time in minutes before Engagement server assumes all players failed to report battle and are forfeited.
    WaitForRemainingBattleResults	= 480000	// time in ms for remaining battle results to be reported after first was reported
    
    // Adjust the strength of AI opposition based on the server difficulty setting
    [Diff]
    CaptainDiff	=0.85
    CommodoreDiff	=1.0
    AdmiralDiff	=1.15
    

    Allowing/disallowing mixed-race technology

    Generally speaking, servers try to prevent players from making modifications which allow them to put (for example) Borg armour on a Federation ship. However, some servers may run campaigns which specifically allow this ability. By default the ability is NOT allowed, but if you wish to change that then go to file ItemRules.gf and edit the MixRacialTech setting

    [Mixing]
    MixRacialTech = 0	// 0 does NOT allow mixed-race technology, 1 permits it
    

  ---

• 3. Selecting and customizing the map

  • 3.1 Selecting which map a campaign will use
    In the campaign .mct file (as noted above) you can specify which map is to be used in a campaign. It is assumed that a map with the matching name has been created and stored in the appropriate folder (MetaAssets for single player, Assets\Maps for servers).

    EarlyMapName="TNGMap.mvm"
    MidMapName="TNGMap.mvm"
    LateMapName="TNGMap.mvm"
    

    There are a number of different maps supplied with the game, check out the MetaAssets or Assets\Maps folder for a look at these. Here's a quick description:
    • TNGMap: 16 x 16 hexes, all four main races
    • SingleTNGMap: 34 x 19 hexes, all four main races
    • Single: 34 x 19 hexes, no Borg territory
    • Multi: 51 x 34 hexes, all four main races

  • 3.2 Customizing the map itself
    You can edit an existing map, or create a new map, using the Artifex program (the download location is given in section 2.1 above).

    If you want to use Artifex to edit an existing map, simply start Artifex, select "Open" and browse your way to the appropriate map.

    Click on the hexagon on the toolbar, and that will enable two list boxes that allow you to set the property of any map hex (e.g. select "Economic" and "10" then click hex (2,6) and the economic value of that hex will be changed to 10).

    If you wish to create a new map, you can edit the Artifex Definitions.txt file to specify the types of regions, races, etc which may be included in the new map. A part of the default definitions file is shown below:

    [Classes/Regions]
    type="string"
    range="array"
    0="Neutral"
    1="Federation"
    2="Klingon"
    3="Romulan"
    4="Borg"
    5="Cardassian"
    [Classes/Regions/UI/Color]
    0=0xdcdcdc
    1=0x0066f5
    2=0xcf3300
    3=0x40ff60
    4=0xa06612
    

    And an example showing the addition of various races to the map editor is as follows (only showing the relevant section of the file):

    [Classes/Regions]
    type="string"
    range="array"
    0="Neutral"
    1="Federation"
    2="Klingon"
    3="Romulan"
    4="Borg"
    5="Cardassian"
    6="Rakellian"
    7="Ferengi"
    8="Pirate"
    

  • 3.3 Controlling movement on the map
    There are several settings in file MetaMap.gf that control the speed of movement on the map:

    CauseTurnBreakOnMove 	= 0	// (0) This is set to 1 to cause the player to create a turn break by moving.  (This setting must be 0 on server side!)
     
    [Movement]
    MovementDelayInMilliseconds	= 15000	// This is how long it take to move 1 space on the map in milliseconds (multiplied by impedence of hex)
    CarryingStarbaseDelay	= 45000	// This is how long it take to move 1 space on the map in milliseconds if you are carrying a starbase! (multiplied by impedence of hex)
    

    There is another setting in MetaMap.gf that determines how quickly one gets "walked" from a current hex to a goal hex.

    [Walk]
    WalkRate	= 2000	// (ms)  Delay between each move when walking a character somewhere (goal for human)
    

  ---

• 4. Controlling alliances and political tensions

  Of course, one of the key characteristics of any campaign is the choice of political relationships between the empires. There are 10 groups we can set tensions between: the Federation, Klingons, Romulans, Borg, Species8472, the Cardassians, the Ferengi, the Rakellians, Pirates, and Neutral. (There are some neutral ships in the game, but they aren't an empire in the sense of the other groups.)

  • 4.1 Setting starting alliances

    For each race, we must describe how it feels (politically) about each of the other groups on a scale from 0 (best buddies) to 1000 (hated enemies). Note that the settings don't have to be the same in both directions (e.g. you could decide the Federation loved the Klingons but the Klingons hated the Federation) but you have to be really careful about things like that, or you wind up with some rather odd missions taking place.

    The starting tensions are set in the MetaMap.gf file

    [PoliticalTension/StartingTensions/Federation]
    Federation=0 // i.e. Feds love Feds
    Klingon=100  // i.e. Feds are allies of the Klingons
    Romulan=800  // i.e. Feds are enemies of the Romulans
    Borg=1000
    Species8472=1000
    Cardassian=800
    Ferengi=200
    Rakellian=1000
    Pirate=1000
    Neutral=800
    
    [PoliticalTension/StartingTensions/Klingon]
    Federation=200 // i.e. Klingons are allies of the Feds, but not quite as sure about it
    Klingon=0
    Romulan=800
    Borg=1000
    Species8472=1000
    Cardassian=800
    Ferengi=200
    Rakellian=1000
    Pirate=1000
    Neutral=800
    
    [PoliticalTension/StartingTensions/Romulan]
    ...
    

  • 4.2 Changing alliances over time

    It is possible, though frequently inadvisable, to set the political tensions up so that they can change over time ... each battle between two groups might increase tension, while long periods without fighting might decrease tension.

    It's a nice idea, but if the AI starts doing funky things this quickly leads to campaigns that are out of the control of the admin.

    We control the tensions by deciding how much a battle adds to tension, and how quickly tensions fade. This is done in the MetaMap.gf file. If you don't want the alliances changing during a campaign then set all these values to 0.

    [PoliticalTensionInc]
    // This is the numbered added every time a battle is fought
    // Some races like the Federation are slower to anger
    Federation=0			// 5
    Klingon=0				// 20
    Romulan=0				// 10
    Borg=0					// 15
    Species8472=0			// 10
    Cardassian=0			// 10
    Ferengi=0				// 15
    Rakellian=0				// ?
    Pirate=0				// ?
    Neutral=0				// 25
    
    
    [PoliticalTensionDec]
    // This is the number subtracted when political tension is asked to be decreased.
    // The federation is more likely to forgive than other races
    Federation=0			// 75
    Klingon=0				// 15
    Romulan=0				// 30
    Borg=0					// 30
    Species8472=0			// 10
    Cardassian=0			// 45
    Ferengi=0				// 30
    Rakellian=0				// ?
    Pirate=0				// ?
    Neutral=0				// 10
    
    [Politics]
    NumCycleUpTensions	= 10		// This will add up the increase in tension level every x number of turns
    AllyRatio			= 0.25 		// This number determines what percentage of races are allies. Calculated vs most hated enemy
    NeutralRatio		= 0.5 		// This number determines what percentage of races are nuetral. Calculated vs most hated enemy
    DistanceWeight		= 1.0
    TensionWeight		= 1.5
    

  ---

• 5. Controlling ship pricing and availability

  Other key characteristics for server flavour are the prices set for ships and supplies, and the frequency with which different ship types appear for sale in the shipyards.

  These settings are largely controlled in the Economy.gf file, and are discussed at some length below.

  • 5.1 Prices: ships, supplies, repairs, trade-ins

    The price for a ship is determined by the price of its hull and assorted components, all multiplied by a number of factors from the Economy.gf file:

    • the server difficulty setting can be used to scale prices up or down (i.e. making ships more expensive on harder difficulty settings)
    • each different class of ship (frigates, destroyers, etc) can have its own seperate factor, so you can have large ships go up in price more quickly than small ones
    • the MinimumBidFactor can scale up or down the minimum amount a player can bid, based on the price of the ship

    The segment below shows the relevant settings from the economy file:

    
    [Auction/Ship]
    MinimumBidFactor	= 1.0	// The multiplier for the minimum bid for a ship, currently based on BPV
    				// note that MinimumBidFactor is similar to TradeIn
    
    CanBenefitFromDowngradingShip		= 1	// (1)  1=If player gains a ship that required less prestige than their current ship, they will get the difference as well, 0=Do not award the difference
    
    
    
    // The cost multiplier for each difficulty setting
    [Cost/Difficulty]
    0	= 0.75
    1	= 1.0
    2	= 1.25
    
    // This is the cost of supplies in spacedock.
    // note that MinimumBidFactor is similar to TradeIn
    [Cost/Ship/SupplyDock]
    Repair		= 1.0
    TradeIn		= 0.85	// When a player trades in an old ship they get back 85% of its cost
    Missiles	= 1.0
    Fighters	= 1.0
    Shuttles	= 4.0
    Marines	= 4.0
    Mines		= 4.0
    SpareParts	= 1.0
    
    // This is a modifier per  for the price of a ship
    // the order must match 
    // all types are included here, but not necessarily used
    [Cost/Ship/ClassType]
    SHUTTLE					= 1.0
    FREIGHTER				= 1.0
    FREIGHTER				= 1.0
    FRIGATE					= 0.85
    DESTROYER				= 0.9
    LIGHT_CRUISER			= 0.95
    HEAVY_CRUISER			= 1.0
    HEAVY_BATTLECRUISER		= 1.5
    DREADNOUGHT				= 2.0
    BATTLESHIP				= 4.0
    LISTENING_POST			= 1.0
    SHIPYARD				= 1.25
    BASE_STATION			= 1.5
    BATTLE_STATION			= 2.0
    STARBASE				= 2.5
    MONSTER					= 1.0
    PLANET					= 1.0
    SPECIAL					= 1.0
    
    

  • 5.2 Ship production, time, and the economy

    The Economy.gf file also specifies how frequently ships are built, and how long they are available for purchase once constructed.

    A "TurnFrequency" variable specifies how frequently the economy is run (e.g. 5 means the economy is run once every 5 server turns). Each time the economy is run the total current economic value of a race's territory is computed and ships can be built until the race runs out of cash.

    Which specific ships are built is a bit of a lottery: for each ship type there is a fraction which is (more or less) inversely proportional to the likelihood of building a ship of that type. Ships are build from smallest type to largest type, so a race can run out of cash before it gets around to building some of the larger types.

    An example is shown below, where the probability of producing a larger ship is significantly smaller than the chance of producing a small ship:

    TurnFrequency  = 5	// (5) This is how often the economy gets run. 10 = 10 turns
    
    // This is the basic chance that a ship will be made by the empire
    [Cost/Ship/Build]
    Shuttle				= 0.01
    Freighter			= 0.03
    Frigate				= 0.20
    Destroyer			= 0.25
    LightCruiser		= 0.35
    HeavyCruiser		= 0.50
    HeavyBattlecruiser	= 0.75
    Dreadnought			= 0.90
    Battleship			= 0.99
    ListeningPost		= 0.20
    Shipyard			= 0.40
    BaseStation			= 0.70
    BattleStation		= 0.85
    StarBase			= 0.95
    
    PlayerModifierStep	= 20	// For every [x] players online when the economy is processed, we increase the budget for production.  It's actually a ratio, so if 10 people are on, production is up 50%.
    

    There are some catches to this ... if you use Excel (or an Excel viewer) to open the file Assets/specs/DefaultLoadout.txt and look under column F (Special) you'll see many ships have a notation of either AI or NS. AI characters can fly AI ships, but these ships will NOT appear in the shipyard. NS ships are specialty ships for the tutorials and storyline missions, and will not appear at all in conquest-style campaigns. If you change these entries to blank then you'll find the ships start appearing in the shipyards. So, for example, if you want the Scimitar to be a playable ship in your campaign then find its entry in DefaultLoadout.txt (search columns C or D for scimitar) and change column F from NS to empty.

    We can also control how long (how many turns) a player has to wait for a ship once they've won a bid on it, and how long a ship can be available for purchase once it has been produced

    TurnsUntilClose	= 3	// Number of turns before a bid on a ship is closed
    				// zero means "no wait" (used for single-player)
    
    MaximumAge	= 25		// This is the number of turns before a ship is scrapped
    MaximumInReviewByEmpire	= 40	// Currently this is the maximum ships allowed to be available for bid for an empire, regardless of strength/budget.
    

    Big ships (BBs) and bases have special production rules - an empire can only produce them if it is large enough (economically), and can only produce them periodically.

    For the thresholds I believe they are ratings between 0 and 10, designating an economic strength relative to the strongest race. E.g. with a threshold of 1 any race whose economy is at least 10% the size of the leading race can still try to build big ships or bases, with a setting of 2 they need to be at least 20% as large as the leaders, etc.

    The settings controlling these factors are also set in Economy.gf

    BuildBaseEconomicThreshold	= 0	// Economy has to be above this threshold before bases are built.
    BuildBaseFrequency		= 4	// How often bases try to get built
    BuildBigShipEconomicThreshold	= 1	// How healthy an empire has to be to try to build a big ship
    BuildBigShipFrequency		= 3	// how often the computer tries to build big ships DN, BB, CV
    NormalBuildTriesBeforeGiveUp	= 10	// Number of times the AI will try to be placed in a home hex before being placed randomly
    

  • 5.3 Starting ships for players and the AI

    Finally, we can select how large a ship a player starts out in, and what the distribution of AI ships looks like.

    We specify the starting ship for each playabe race, and we can set different ships for different server difficulty settings (0=easy,1=average,2=harder).

    This is all carried out in Character.gf:

    // Starting ships for players (sorted by RACE)
    [StartingShips/0]
    0	= "Norway"	// On easy difficulty, Feds start out in Norways
    1	= "K'Vort"	// and Klingons start out in K'Vorts, etc
    2	= "Falcon"
    3	= "Diamond"
    
    // Here for completeness ONLY, to account for extra races?
    4	= "NO SHIP"
    5	= "NO SHIP"
    6	= "NO SHIP"
    7	= "NO SHIP"
    8	= "NO SHIP"
    9	= "NO SHIP"
    
    // Starting ships for players (sorted by RACE)
    [StartingShips/1]
    // startin ship selections for Average server difficulty setting
    ...
    
    // Starting ships for players (sorted by RACE)
    [StartingShips/2]
    // starting ship selections for Hard server difficulty setting
    ...
    

    Also in Character.gf we can set the player's starting prestige, based on server difficulty setting. (Note that the actual starting prestige will be this amount plus 100.)

    // This is a character's starting prestige
    [Create/0]
    StartingPrestige	= 2400
    
    [Create/1]
    StartingPrestige	= 900
    
    [Create/2]
    StartingPrestige	= 400
    

    Finally, in AI.gf, we can determine (for each difficulty setting) what the relative frequency of each size of AI ship will be:

    [CreateShipClassOdds/0]
    Freighter	= 25		// (25)		Odds (out of total) to start a given AI in this ship
    Frigate	= 20		// (20)
    Destroyer	= 15		// (15)
    LightCruiser	= 10		// (10)
    HeavyCruiser	= 5			// (5)
    HeavyBattlecruiser	= 2			// (2)
    Dreadnought		= 2			// (2)
    Battleship		= 1			// (1)
    
    [CreateShipClassOdds/1]
    ...
    
    [CreateShipClassOdds/2]
    ...
    

  ---

• 6. Controlling AI populations and behaviour
  In addition to any human players, each dynaverse has an ever-changing population of AI characters - each with their own ships, skills, and mission goals.

  In this section we look at how the size of the AI population is controlled, what kind of ship distribution the AI population has, and how mission goals are determined for each AI character in a race.

  • 6.1 AI populations
    The AI.gf file contains the variables which dictate the target number of AI characters on the map. This is determined by computing the total economic value of each race (i.e. the sum of the economic values of each of their hexes on the map) and multiplying by a target ratio (see below). If the total economy for a race is 1000 and the ratio is set at 0.05 then the server will try to adjust the number of AI ships for that race to 1000 * 0.05 == 50 ships.

    You can limit the number of AIs to add/delete per turn, to control how quickly populations can grow or shrink due to fluctuating economies, and you can put an upper limit on the number of ships any race can have - regardless of how big their economy gets.

    [General]
    TurnFrequency = 4			
    // This is how often the AI server gets updated 4=4 times a turn,
    // i.e. every quarter turn the server will adjust the AI population
    
    // This section handles the creation of AI ships
    [Census]
    TargetPopulationToEconomicRatio	= 0.09	//  This is the ratio of AI ships to current economy of an empire
    
    MaxAIsToCreatePerTurn	= 50		// How many AIs to try to create before giving up
    CreateAIFrequency		= 1		// How many AIs to create a second, until goal level reached
    KillAIFrequency		= 2		// How many AIs to kill a second, until goal level reached (this only applies to mission generated AIs)
    CreateOfficerFrequency	= 1		// How many officers to create a second, until goal level reached
    MaxAIsPerEmpire		= 200		// Create a fixed number of AIs per empire. 
    	// A setting of -1 means not to use a fixed number, i.e. no upper limit
    
    [Rating]
    // The typical AI character is assumed to begin with a "glicko" skill rating in the range 700-1700
    // (as opposed to humans, who are all assumed to begin with a rating of 1500)
    StartingAIRating					= 1200
    StartingAIRatingRange				= 500
    

    
    Each AI character has to start somewhere, so the MetaMap.gf file controls their "birthplace"

    [AIBirthPlace]
    AIBornOnlyOnBases		= 0	// (0) 0=born either on base, or within a hex of base (random)
    AIBornOnBaseOddsDelta	= 4	// (4) Will randomly choose from a list that includes the 6 hexes around a random base and this many occurences of the base hex itself.
    					// In other words, 4 would be a 40% chance that the AI would be born on the base itself (4 out of (4+6)).  
    					// 6 would be 50% (6 out of (6+6)), 12 would be 66% (12 out of (12+6)), and so on...
    

  • 6.2 AI goals
    Having created an AI population, they need to be given some tasks. These are set as relative probabilities, and are determined in the Goal.gf file. I assume that once given a task the AI sticks with it until either it succeeds, is badly damaged or destroyed, or is assigned a new task.

    We can determine how often the server reassigns goals to AI characters, how much of that activity is recorded, what kind of damage levels force an AI to abandon its goals, and what the likelihood of different kind of goals are.

    For the goals themselves we give a set of relative weightings in the ScenarioOdds section below. If we said the weight of goal X is 300, goal Y is 200, and goal Z is 100, then there is a 50% chance goal X would be selected (300 / 600), 33.3% for goal Y, and 16.7% for goal Z. These odds can be set differently for each race, so (for example) you could make Federation AI primarily defensive and Klingon AI primarily offensive.

    In addition to the goals, we can decide how likely it is that an AI will take specific actions this turn (e.g. attack a character in the hex, fleet up with someone, etc). These settings are under the GeneralActionOdds section below.

    The specific settings are illustrated below.

    [General]
    TurnFrequency	= 4	// This is how often the goal server gets run. 4 = once every 4 turns
    
    [Monitor]
    ViewGoalActivity	= 2	// 2=view all goal activity, 1=view main activity, 0=view activity not logged
    ReportInterval	= 10	// (100)	Will report every n simulated characters (monitoring simulation)
    
    [Simulation]
    SystemRepairPercentage	= 25	// Percentage of total system damage required before AIs will stop their goal and return to base to be repaired.
    HullRepairPercentage	= 25	// Percentage of total hull damage required before AIs will stop their goal and return to base to be repaired.
    
    [GeneralActionOdds]
    // These are current actions, possibly taken in spite of an AI's current goals
    OddsAttack					= 50	// 0...100 chance that AI will attack an enemy in hex
    OddsAttackPlanet				= 01	// 0...100 chance that AI will attack an enemy planet in hex
    OddsAttackStarbase			= 02	// 0...100 chance that AI will attack an enemy starbase in hex
    OddsAttackHuman				= 80	// 0...100 chance that AI will attack a human enemy in hex
    OddsAttackButGoalDisagrees		= 10	// 0...100 chance that AI will attack an enemy in hex, considering that the goal disagrees with attack
    OddsAttackHumanButGoalDisagrees	= 30	// 0...100 chance that AI will attack a human enemy in hex, considering that the goal disagrees with attack
    OddsForfeitIfAttacked			= 30	// 0...100 chance that AI will forfeit when attacked
    OddsForfeitIfAttackedByHuman		= 40	// 0...100 chance that AI will forfeit when attacked by a human
    OddsAcceptDefenders			= 90	// 0...100 chance that AI will allow someone else to help defend
    OddsAcceptHumanDefenders		= 95	// 0...100 chance that AI will allow a human to help defend
    OddsJoinFleet				=  5	// 0...100 chance that AI will wish to join a fleet
    OddsJoinHumanFleet			= 50	// 0...100 chance that AI will wish to join a human fleet
    OddsLeaveFleet				=  1	// 0...100 chance that AI will leave a fleet during the turn
    OddsLeaveHumanFleet			=  0	// 0...100 chance that AI will leave a human fleet during the turn
    OddsApproveNewFleetMember		= 80	// 0...100 chance that AI will approve someone joining their fleet
    OddsApproveNewHumanFleetMember	= 90	// 0...100 chance that AI will approve a human joining their fleet
    
    //	Scenarios (Overall goals or tasks currently assigned to the AI)
    //		"NoScenario"			Nothing given to character
    //		"InternalPatrol"			Will patrol within allied territory
    //		"BorderPatrolDefense"		Will patrol on allied side of border
    //		"BorderPatrolOffense"		Will patrol on enemy side of border
    //		"Offense"				Will march into enemy territory and wander
    //		"OffensePlanet"			Will pick enemy planet to march to and attack
    //		"OffenseStarbase"			Will pick enemy starbase to march to and attack
    //		"DefendPlanet"			Will head to allied planet and remain for a period of time defending
    //		"DefendStarbase"			Will head to allied starbase and remain for a period of time defending
    //		"DefendBorder"			Will head to allied side of border and remain for a period of time defending
    //		"ExpandTerritory"			Will head to neutral territory and remain for a period of time
    //		"DeliverStarbase"			Will take Starbase to available allied hex and deliver (only possible if empire has strength and hex remains allied)
    //		"DeliverBattleStation"		Will take BattleStation to available allied hex and deliver (only possible if empire has strength and hex remains allied)
    //		"DeliverBaseStation"		Will take BaseStation to available allied hex and deliver (only possible if empire has strength and hex remains allied)
    //		"DeliverWeaponsPlatform"	Will take Weapons Platform to available allied hex and deliver (only possible if empire has strength and hex remains allied)
    //		"DeliverListeningPost"		Will take Listening Post to available allied hex and deliver (only possible if empire has strength and hex remains allied)
    //		"HuntEnemy"				Will choose a random enemy and begin hunting
    
    
    // NOTE:
    // The ScenarioOdds array for a given empire is totalled and each item's # is the odds ratio against that total.  Therefore
    // one scenario will be chosen and it's chance is based on the ratio of it's Odds vs the total of all odds for the empire.
    // (this, of course, includes "NoScenario")
    
    [ScenarioOdds/Federation]
    "NoScenario"		 =  600
    "InternalPatrol"		 =  300
    "BorderPatrolDefense"	 =  200
    "BorderPatrolOffense"	 =  100
    "Offense"			 =  070
    "OffensePlanet"		 =  010
    "OffenseStarbase"		 =  030
    "DefendPlanet"		 =  200
    "DefendStarbase"		 =  150
    "DefendBorder"		 =  200
    "ExpandTerritory"		 =  100
    "DeliverStarbase"		 =  002
    "DeliverBattleStation"	 =  001
    "DeliverBaseStation"	 =  002
    "DeliverWeaponsPlatform" =  003
    "DeliverListeningPost"	 =  005
    "HuntEnemy"			 =  020
    
    [ScenarioOdds/Klingon]
    "NoScenario"		 =  400
    "InternalPatrol"		 =  200
    "BorderPatrolDefense"	 =  250
    "BorderPatrolOffense"	 =  350
    ...
    

  • 6.3 Fleets - composition and behaviour
    We can, through settings in the MissionMatching.gf file, limit the composition of fleets to a certain degree. We can specify (if desired) that the fleet leader has to be the largest ship in the fleet, and we can specify an upper limit (1-3) on the number of ships of any size class in the fleet. For example, we could say that a fleet can have at most 1 battleship, 1 dreadnought, 2 cruisers, etc.

    [Fleet]
    LeaderCannotBeLowerClassThanMember	= 1		// 1=This prevents a member from joining a fleet if they have a higher ship class than the leader.  IGNORES freighters as leaders., 0=no check
    
    [Fleet/Maximum]
    Freighter		= 1		// (1)  Maximum of this ship class in a fleet (freighters cannot join anyway, so they're always 1)
    Frigate		= 3		// (3)
    Destroyer		= 3		// (3)
    LightCruiser	= 3		// (3)
    HeavyCruiser	= 2		// (2)
    HeavyBattlecruiser	= 1	// (1)
    Dreadnought		= 1		// (1)
    Battleship		= 1		// (1)
    

  • 6.4 AI-only battles and results
    Finally, we can decide what kind of results to expect if two AIs meet in combat. This is established in file MissionMatching.gf

    Essentially we specify the odds for the case where two opponents are equally matched, and what kind of "home ice advantage" is to be given to attackers/defenders when they are in their own territory.

    When a stronger opponent meets a weaker one these odds are scaled by the relative strengths of the two sides to determine what the probable results are.

    For each kind of result, we also have to make recommendations for what kind of battle damage should result -- basically how many battle passes we assume took place, and how much damage is assessed per battle pass.

    Finally, we have to specify how much prestige should be awarded to each combatant, and how long (in real time) the simulated battle should take.

    [PureAIBattle]
    OddsAstoundingVictory		= 5	// 0..100 Odds that one side of pure AI battle will get Astounding Victory
    OddsVictory				= 20	// 0..100 Odds that one side of pure AI battle will get Victory
    OddsDefeat				= 20	// 0..100 Odds that one side of pure AI battle will get Defeat
    OddsDevastatingDefeat		= 5	// 0..100 Odds that one side of pure AI battle will get Devastating Defeat
    DefenderHomeHexAdvantage	= 2	// Bonus to odds for defender if battle is within friendly hex
    AttackerHomeHexAdvantage	= 0	// Bonus to odds for attacker if battle is within friendly hex
    
    												
    // Battle formula (calculated for defender):
    // ratio = defender's total BPV / attacker's total BPV
    // 
    // if ( defender is battling on home territory )
    // {
    //      OddsVictory += DefenderHomeHexAdvantage
    // }
    // 
    // if ( attacker is battling on home territory 
    // {
    //      OddsDefeat += AttackerHomeHexAdvantage
    // }
    // 
    // OddsAstoundingVictory *= ratio
    // OddsVictory           *= ratio
    // OddsDefeat            *= 1/ratio
    // OddsDevastatingDefeat *= 1/ratio
    // 
    // OddsDraw				 = ( 100 - OddsAstoundingVictory - OddsVictory - OddsDefeat - OddsDevastatingDefeat )
    // if ( OddsDraw < 0 )
    // {
    //      OddsDraw = 0
    //      Remaining odds are normalized
    // }
    
    // Specify how likely it is that a defeated AI is killed
    OddsDeathOnDevastatingDefeat	= 95	// 0..100 Odds that AI will die as a result of devastating defeat
    OddsDeathOnDefeat			= 65	// 0..100 Odds that AI will die as a result of defeat
    
    // Specify the amount of damage resulting from battle
    DamageRange					= 80	// 0..100 Percentage damage on single system in one random damage pass
    OddsShipSystemDamage			= 50	// 0..100 Odds that random ship damage is system damage
    DamagePassesOnDevastatingDefeat	= 20	// Number of passes of random damage on ship as a result of devastating defeat (assuming they weren't killed)
    DamagePassesOnDefeat			= 10	// Number of passes of random damage on ship as a result of defeat
    DamagePassesOnDraw			= 5	// Number of passes of random damage on ship as a result of a draw
    DamagePassesOnVictory			= 2	// Number of passes of random damage on ship as a result of victory
    DamagePassesOnAstoundingVictory	= 0	// Number of passes of random damage on ship as a result of astounding victory
    
    // Specify the prestige reward/penalty for the AI-vs-AI battle
    PrestigeForAstoundingVictory	= 350		// Prestige for AI astounding victory
    PrestigeForVictory		= 250		// Prestige for AI victory
    PrestigeForDraw			= 0		// Prestige for AI draw
    PrestigeForDefeat			= -250	// Prestige for AI defeat
    PrestigeForDevastatingDefeat	= -350	// Prestige for AI devastating defeat
    
    // Specify how long (real time) the simulated AI battle should take
    AIBattlesSimulateTime		= 1	// 1=Simulate time delay before resolution of pure AI battle, 0=resolve results immediately
    AIBattlesTimeRange		= 8	// Time in minutes or seconds that pure AI battle might take (random)
    AIBattlesTimeInMinutes		= 1	// 1=AIBattlesTimeRange is in minutes, 0=AIBattlesTimeRange is in seconds
    
    

  ---

• 7. Controlling mission availability
  OK, there are several aspects to cover here in terms of how the server decides which mission(s), if any, should be made available to a player, how difficulty the missions should be, and how the mission results should be handled.

  • 7.1 Selecting missions for a campaign
    The campaign .mct file provides a list of missions which are available to be played in the campaign, and each time a player moves into a new hex that list is matched against current conditions (see section 7.2) to determine which of those missions should be offered. These missions may generate temporary AI for the player to combat, instead of the persistent characters moving around the dynaverse. These missions include the storyline missions, scan, distress call, etc.

    In addition, there is a list of missions specified in MissionMatching.gf which allows combat between AI characters on the map - we'll consider those in section 7.2.

    The mission list in the .mct file will be a sequentially-numbered list of mission scripts. The following example is taken from the Klingon single-player campaign:

    [Missions]
    0="Kli_Brotherhood.scr"
    1="Kli_AVastYeScurvyTargs.scr"
    2="Kli_TooFar.scr"
    3="Kli_Treachery.scr"
    4="Kli_WindsOChange.scr"
    5="Kli_AnviloPeace.scr"
    6="Kli_TurningTables.scr"
    7="Kli_FishBarrel.scr"
    8="Kli_Obedience.scr"
    9="Kli_EDuty.scr"
    10="Kli_Barking.scr"
    11="Kli_FDay.scr"
    12="Kli_FriendOrFoe.scr"
    13="Kli_Recall.scr"
    14="Kli_Blood.scr"
    15="Meta_Scan.scr"
    16="Meta_DistressCall.scr"
    

  • 7.2 Controlling mission offerings
    There are two aspects we need to consider: the chance of getting a scripted mission (from the list in the .mct file), and which "combatant" missions should be offered (i.e. what persistent AI/players are in the hex that you could attack or that could attack you?).

    Chance of getting a scripted mission
    The chances of getting a scripted mission are based on how appropriate the player/AI ships are for the mission script in the areas of strength and politics, and the appropriateness of the map hex for the mission in terms of terrain and ownership.

    The importance of these different factors is set in the MissionMatching.gf file, though the exact formula seems to be a form of voodoo ;-). I'll do my best to supply guesses for the relevant factors below.

    [ScreenForMatch]
    // determine how much of the matching info to log
    MatchDetail		= 1	// 0=no detail, 1=minimum detail, 2=max detail in log file/screen
    
    // establish a weighting to determine how likely it is a mission will be offered,
    // here you can establish a base chance for missions on eachmove, and
    // increase or decrease the likelihood based on enemy/neutral terrain
    // and the availability of other players/AI in the hex  
    BonusForNearbyForeignCharacters	=100
    EnemyHexBonus				=100	// bonus for a mission in enemy territory
    NeutralHexBonus				=50		// bonus chance in neutral hexes for a mission
    ChanceMove					=30		// (30) base chance for a mission on move (increase for more missions in home territory)
    
    // here you can weight the probability of mission offerings based
    // on how closely the hex matches the mission's expected terrain type(s)
    [TerrainScoring]
    PlanetTypeScoreForMatching		=5000  
    BaseTypeScoreForMatching		=2500
    TerrainTypeScoreForMatching		=100
    
    // here you can weight the probability of mission offerings based
    // on how closely the politics of the player matches the politics of the hex
    // e.g. "LookingForOwnHexInOwn" gives the likelihood for offering a mission
    //    if the mission expects to offer the mission to a player in their own territory,
    //       and the player actually IS in their own territory
    // Meanwhile "LookingForOwnHexInAlly" gives the likelihood for offering the same
    //    mission to a player who is currently in allied territory instead of their own
    // Essentially these give you the opportunity to enforce/ignore the mission's 
    //    preferences in terms of politics
    [PoliticsScoring]
    BonusForExactPoliticalMatch	=1000
    LookingForOwnHexInOwn		=1000
    LookingForOwnHexInAlly		=500
    LookingForOwnHexInNeutral	=0
    LookingForOwnHexInEnemy		=-1000
    LookingForEnemyHexInOwn		=-1000
    LookingForEnemyHexInAlly	=-1000
    LookingForEnemyHexInNeutral	=0
    LookingForEnemyHexInEnemy	=1000
    LookingForAllyHexInOwn		=0
    LookingForAllyHexInAlly		=1000
    LookingForAllyHexInNeutral	=0
    LookingForAllyHexInEnemy	=-10
    
    // here you can weight the probability of mission offerings based
    // on how closely the strength of the player matches the strength
    // the mission script thinks the player should have to take the mission
    [FleetScoring]
    GoodBPVScore		=1000
    TooWeakBPVScore		=300
    TooStrongBPV		=0
    GoodShipCountScore	=0
    TooFewShipCountScore	=0
    TooManyShipCountScore	=0
    PlaceBaseMissionScore	=50000
    BaseScoreBonus		=10000
    
    // here you can rate the relative importance of the different categories,
    // i.e. should we consider politics more than terrain, etc
    [ScoringWeights]
    WeightMissionsLastPlayed	=0.2
    WeightPoliticsScore		=10.0
    WeightTerrainScore		=1.0
    WeightFleetScore			=0.01
    
    // here we can weight the probability of mission offerings based
    // on the relationship between the player and their opposition
    // e.g. what should be done if the mission needs two enemies, 
    // but the two races in this case really aren't all that hostile to each other
    [RelationshipScoring]
    MaxRelationShipScore		=1000
    PoorEnemyOfScore			=100
    PoorAllyOfScore			=200
    DecentWorstEnemyScore		=300
    DecentAllyOfScore			=200
    
    // how important a role should the pirates play in a player's own territory,
    // neutral territory, and enemy territory
    OrionDomesticWeight		=0.7
    OrionNeutralWeight		=0.3
    OrionEnemyWeight			=0.2			 
    
    // here we can weight how many missions to keep track of,
    // and how important the recent mission results are
    [RecentlyPlayedScoring]
    MaxLastPlayedScore					=1000
    NumMissionsTracked					=5
    
    // here, I think, we set relative weights for the different terrain features:
    // i.e. type (or absence) of planet, type (or absence) of base, and
    //    type (or none) of terrain
    [MapScoring]
    PlanetScore							=20
    TerrainScore						=10
    BaseScore							=30
    

    Which specific mission will get offered
    The computations above determine if any of the specialty missions should be offered, but we also need to decide which missions should be available for combat between the player and AI characters in the hex. This is also carried out in file MissionMatching.gf, and we can have one or more missions to select from in each of eight different categories: ship-ship combat, convoy assaults, base/bats/starbase assaults, planet/homeworld/shipyard assaults.

    If appropriate persistent characters are in the hex then A mission of the appropriate type will be offered, but we can add variants on each type. The choice would be made randomly between the acceptable variants.

    
    // Add to these if you have special versions of these missions.  
    // They will be equally random, so be careful.  
    // You could always adjust this by having duplicate entries
    // of those that should be more common.  
    // (For example, if you had an extra Meta_Hail called Meta_Hail_StarIsGoingNova 
    // and wanted it 10% of the time, have it once and Meta_Hail appear 9 times...)
    
    [HailMissions/HailMissionTitles]
    0="Meta_Hail"	// Title of Hail mission (special)
    
    [HailMissions/HailConvoyMissionTitles]
    0="Meta_Hail_Convoy"	// Used when player attacks a AI Convoy
    
    [HailMissions/HailBaseStationMissionTitles]
    0="Meta_Hail_Base"	// Used when player attacks a Base Station AI
    
    [HailMissions/HailBattleStationMissionTitles]
    0="Meta_Hail_Base"	// Used when player attacks a Battle Station AI
    
    [HailMissions/HailStarBaseMissionTitles]
    0="Meta_Hail_Base"	// Used when player attacks a Starbase AI
    
    [HailMissions/HailPlanetMissionTitles]
    0="Meta_Hail_Planet"	// Used when player attacks a Planet AI
    
    [HailMissions/HailHomePlanetMissionTitles]
    0="Meta_Hail_Homeworld"	// Used when player attacks a Home Planet AI
    
    [HailMissions/HailShipYardMissionTitles]
    0="Meta_Hail_ShipYard"	// Used when player attacks a Ship Yard AI
    

    I'm assuming those need to be numbered sequentially, so if we added the variant Meta_Hail mission with a 20% chance of selection it might look something like:

    [HailMissions/HailMissionTitles]
    0="Meta_Hail"	// Title of Hail mission (special)
    1="Meta_Hail"	
    2="Meta_Hail"	
    3="Meta_Hail"	
    4="Meta_Hail_StarIsGoingNova "	// Title of alternate Hail mission
    

    
    Mission names and mandatory status
    We have some additional control available in MissionMatching.gf that allow us to determine which mission name is displayed (every mission has a true unique name and a cover name or display name).

    [MissionProfiles]
    ShowMission		=0		// (0) shows the team's mission title, 1 show's the true mission title
    

    And we have controls to determine if the .mct missions offered will be mandatory or not. Each mission script makes recommendations about whether or not a mission should be mandatory, but we can choose to turn off mandatory settings, or we can choose to turn on mandatory settings but restrict them to hostile territory.

    HasMustPlayMissions	=1	// Mandatory missions can occur if this is set to 1, but not if it is set to 0 
    MustPlayOnlyOnEnemyHex	=0	// If both this setting and the one above it are set to 1 then
    					// mandatory missions will be offered, but only in hostile territory
    

  • 7.3 Controlling opposition strength
    For the .mct missons, we can control how much the mission difficulty is scaled based on the server difficulty setting. (Remember the difficulty setting is in the campaign .mct file.) The strength adjustment based on difficulty is set in the MissionMatching.gf file.

    //modifier based difficulty setting
    [Diff]
    CaptainDiff		=0.85
    CommodoreDiff	=1.0
    AdmiralDiff		=1.15
    

  • 7.4 Controlling special mission offerings (storyline campaigns)
    For the storyline missions, you get told where to go and are given a time limit to get there. The message, the hex, and the time limit are set in the MissionGoals.gf file.

    I think the "Time Wait" field determines how many turns you are given before you must reach the target hex. The example below is for one of the Klingon storyline missions.

    [Kli_FriendOrFoe]
    GoalDescription="General Mi'Qogh has asked you to travel to sector 10,15 with great haste."
    
    [Kli_FriendOrFoe/Goals]
    0="Time Wait 15 OR"
    1="Location Move Hex 10 15 Wander 1"
    2="Location Move Hex 10 15 Wander 0"
    3="Package Deliver Mission Kli_FriendOrFoe"
    

    
    If you don't reach the goal in time, then you are walked from your current hex to the target hex. The speed (in milliseconds) with which you are moved is set in MetaMap.gf.

    [Walk]
    WalkRate	= 2000	// (ms)  Delay between each move when walking a character somewhere (goal for human)
    

  • 7.5 Controlling base placement and impact
    Finally, we'll consider the placing of bases and the impact this has on nearby hexes.

    We can determine whether or not multiple bases can be placed in a hex, and we can specify that a base cannot be placed in a hex unless friendly races control a certain number of adjacent hexes (to prevent players from wandering deep into enemy space, flipping one hex, then planting a starbase there). This is determined in MetaMap.gf.

    [StarbasePlacement]
    UnlimitedBasesInHex	= 0	// 0=can only have one base in a hex, 1=unlimited # of bases in hex.
    MinNearbySameRaceHexes	= 2	// There are 6 possible surrounding hexes.  At least this many must be of the same race as the current hex (which must match player's race)
    

    
    When a base is placed, it can increase the defensive strength of the hex it is placed in and (to a lesser degree) the strength of adjacent hexes. The amount of the increase is determined in file Score.gf.

    [Base/Transition]
    MinimumVictoryPoints	= 1	// The minimum number of victory points a hex will have after a base transition
    
    [StarBase/Transition/VictoryPoints]
    Primary		= 20	// 20 points added if the a StarBase is added or 20 points removed if StarBase is removed.  For the hex the StarBase is placed on
    Secondary		= 7	// 7 "" "" but for "secondary" hexes.  Like the one right next to the primary hex
    
    [BattleStation/Transition/VictoryPoints]
    Primary		= 14
    Secondary		= 4
    
    [BaseStation/Transition/VictoryPoints]
    Primary		= 10
    Secondary		= 2
    
    [ListeningPost/Transition/VictoryPoints]
    Primary		= 2
    Secondary		= 0
    
    [WeaponsPlatform/Transition/VictoryPoints]
    Primary		= 5
    Secondary		= 0
    
    [ShipYard/Transition/VictoryPoints]
    Primary		= 4
    Secondary		= 0
    

  ---

• 8. Customizing names (ships, officers, planets, etc)
  If desired, you can customize a great many of the text items in the game: the names of different captains, officers, ships, planets, empires, ranks for each empire, and many different text descriptions from the shipyards, quick tips, race descriptions, etc.

  • 8.1 Customizing captain and officer names
    We can set the names of AI captains for each race in the Character.gf file. These settings are used to randomly determine the name of each captain encountered.

    // These are the names of Federation AI's
    [Create/Federation]
    0="Kleiman"
    1="Nope"
    2="Kelbrim"
    ...
    
    //These are the names of Klingon AI's
    [Create/Klingon]
    0="Kros"
    1="Kann"
    ...
    

    
    In a similar manner, we can set the names of any officers available for each race. This is done through the OfficerNames.gf in the CommonSettings folder.

    [Federation]
    0="KLEIMAN"
    1="NOPE"
    2="KELBRIM"
    3="BOWEN"
    ...
    

  • 8.2 Customizing ship names
    Ship names for all the different races are handled in the Assets\Strings\shipnames.txt file, which is best edited using Excel or a similar tool (open as a tab-delimited text file).

  • 8.3 Customizing planet names
    As with the AI captain names, each race's planet names are established in the Character.gf file

    // These are the names of Federation Planet's
    [CreatePlanet/Federation]
    0="Earth"
    1="Alpheratz II"
    ...
    
    //These are the names of Klingon Planet's
    [CreatePlanet/Klingon]
    0="Qo'noS"
    1="Mirach VII"
    ...
    

  • 8.4 Customizing rank names
    We can alter the title associated with each military rank for each race, in the Rank.gf file in the CommonSettings folder.

    [RankNames]
    // Federation
    0	= "Lieutenant"
    1	= "Lieutenant Commander"
    2	= "Commander"
    3	= "Captain"
    4	= "Admiral"
    // Klingon
    5	= "Lieutenant"
    6	= "Lieutenant Commander"
    7	= "Commander"
    8	= "Captain"
    9	= "Admiral"
    // Romulan
    10	= "Ante-Tribune"
    11	= "Tribune"
    12	= "Sub-Commander"
    13	= "Commander"
    14	= "Admiral"
    // Borg
    15	= "Drone"
    16	= "Drone"
    17	= "Adjunct"
    18	= "Tertiary Adjunct"
    19	= "Primary Adjunct"
    

  • 8.5 Customizing race/empire names
    If you wish to change the name of a race, this can be done in the RaceNames.gf file in the CommonSettings folder.

    // These are used whenever race names are needed.  They are the ONLY place you must change these names.
    // They MUST match the order of the races.  Modders, this one's for you.
    
    [FullEmpireNames]
    0	= "United Federation of Planets"
    1	= "Klingon Empire"
    2	= "Romulan Star Empire"
    3	= "Borg Collective"
    
    4	= "Species 8472"
    5	= "Cardassian Union"
    6	= "Ferengi Alliance"
    7	= "Rakellians"
    8	= "Pirates"
    9	= "Contested Sector"
    
    10	= "All Races"
    
    
    [ShortEmpireNames]
    0	= "Federation"
    1	= "Klingon"
    2	= "Romulan"
    3	= "Borg"
    
    4	= "Species8472"
    5	= "Cardassian"
    6	= "Ferengi"
    7	= "Rakellian"
    8	= "Pirate"
    9	= "Neutral"
    
    10	= "All"
    

  • 8.6 Customizing other text
    Finally there is a wide variety of game text (descriptions, quicktips, etc etc) that can be altered by using Excel to edit one of the tab-delimited text files in folder Assets\Strings. This includes the shipnames.txt file, the quicktips.txt file, and the strings.txt file. The strings.txt file is a very large catch-all beastie for much of the in-game text, and the best bet is to peruse it a bit to get a feel for what's in there. (And remember to make backups before you change things!!!)

  ---

• 9. Controlling officers
  For ship's officers in the game we can control how many officers are available, and how quickly those officers tend to improve their skills from battle to battle.

  • 9.1 Officer availability
    In the AI.gf file we can set the number of officers a race has, expressed as a multiple of how many player/AI characters that race currently has.

    At the same time, we can roughly control the distribution of officers across different types of base and planet: expressing the minimum, average, and maximum number of offers we might find available.

    Finally, we can limit the number of officers the player can review at any given instant, and limit the amount of time a player has to make decisions about swapping officers during a review.

    // Officers
    [Officers]
    MaxInReviewByClient		= 8		// (8)	This is the most a human player can view in the officer screen (marked as in review and made available to client for a period of time)
    MaxInReviewTime			= 10		// (10)	# of minutes the client has to review officers before D3 asks for them back
    OfficerPopulationRatio		= 30.0	// (30.0)	Multiplied by the # of characters of a race to determine # of officers for that race
    
    [Officers/MinAtBase]
    ListeningPost			= 2		// (2)	Regardless of population, bases of this type will have at least this # of officers
    Shipyard				= 4		// (4)
    BaseStation				= 10		// (10)
    BattleStation			= 12		// (12)
    StarBase				= 16		// (16)
    Planet				= 20		// (20)
    
    [Officers/AvgAtBase] 
    // similar settings allow you to set the average number of officers at each base type
    ...
    
    [Officers/MaxAtBase]
    // and similar settings allow you to establish upper limits on the number of officers at each base type
    ...
    

  • 9.2 Officer advancement
    The Score.gf file contains the settings that dictate how likely it is than an officer's skill levels will increase following a successful mission.

    These probabilities can be set seperately for each level of officer - e.g. making it easy for an officer to advance from Trained to Skilled, but very hard for an officer to advance from Veteran to Expert.

    Furthermore, we can set the probabilities differently for the officer's "main area" than for the others - i.e. we can set it up so that an engineer finds it much easier to advance in engineering areas than in, say, medical expertise.

    [LevelUp]										
    // The odds that an officer will level-up in a skill out of his area of expertise after a mission is completed.
    Basic			= 0.02
    Trained		= 0.02
    Skilled		= 0.02
    Veteran		= 0.01
    Expert		= 0.01
    
    [SpecializedLevelUp]							
    // The odds that an officer will level-up in a skill in his area after a mission is completed.
    Basic			= 0.16
    Trained		= 0.08
    Skilled		= 0.04
    Veteran		= 0.02
    Expert		= 0.01
    

  ---

• 10. Controlling the flow of time and campaign duration
  There are many aspects of time we can control.
  • There are three different eras a campaign can start in, and we can specify how many game years each era lasts. In SFC2 this was important because different technology became important in different years, but in SFC3 this feature seems relatively unimportant.
  • We can control how long (in real time) each dynaverse "turn" lasts, and we can determine how many turns there are in a game year.
  • For most of the major game areas (economy, AI movement and goals, etc) we can establish how frequently they are updated. This generally breaks down into either (a) how many times updates occur in a single turn, or (b) how many turns elapse between updates.

  • 10.1 Establishing turn duration, turns/year, and years/era
    In the Time.gf file we establish how long, in real time, a dynaverse turn lasts. (As with most time measurements in the game, this is expressed in milliseconds.) We can also specify how many turns take place in each year.

    [Clock]
    // Here each turn will last 2 minutes, and thus 720 turns per year
    //    will result in each game year taking 24 hours of real time
    TurnsPerYear			= 720		// (1 day/year)
    MilliSecondsPerTurn		= 120000	// (120 seconds)
    

    In this same file we can set the "base year" for our campaign, and specify the start date of each of three eras (early, middle, late) relative to this base year. Again, for SFC3 at the moment this doesn't have a great deal of relevance.

    [Clock/StartingDate]
    BaseYear	= 56200    // measures all dates from 56200
    0			= 0  // early era starts at an offset of 0 from BaseYear
    1			= 10 // mid era starts at an offset of 10 from BaseYear
    2			= 20 // late era starts at an offset of 20 from BaseYear
    

  • 10.2 Interaction of time with economy and AI behaviour
    As mentioned, we can control how often different aspects of the dynaverse are updated. Below we cover a number of the different aspects.

    In AI.gf we specify how often the AI population is adjusted.

    [General]
    TurnFrequency	= 4	// This is how often the AI server gets updated 4=4 times per turn
    

    
    In Economy.gf we determine how often the economy is updated and ship production takes place.

    [General]
    TurnFrequency  = 5	// This is how often the economy gets run. 10 = once every 10 turns
     
    TurnsUntilClose	= 3	// Number of turns before a bid on a ship is closed
    				// zero means "no wait", i.e. the player gets the purchased ship instantly
    
    MaximumAge	= 25	// This is the number of turns before a ship is scrapped
    
    BuildBaseFrequency	= 10	// How often bases try to get built, e.g. 10 means once every 10 turns
    BuildBigShipFrequency	= 20	// how often the computer tries to build big ships DN, BB, CV
    

    
    In Goal.gf we specify how frequently we'll update goals for the AI characters on the map

    [General]
    TurnFrequency	= 2	// This is how often the goal server gets run. 4 = once every 4 turns
    

    
    In MetaMap.gf we determine how many times per turn the map is refreshed, and we can also specify how long it takes players to move from hex to hex on the map.

    [General]
    TurnFrequency	= 3			// This is how often the map gets updated 1=1 time a turn
    CauseTurnBreakOnMove 	= 0	// This is set to 1 to cause the player to create a turn break every time they move.  
    // (This setting must be 0 on server side, or it would try to end a turn every time anyone moved from hex to hex!)
    
    MovementDelayInMilliseconds	= 15000	// Milliseconds needed to move 1 hex on the map (Note: this time gets multiplied by the impedence level of the hex)
    CarryingStarbaseDelay		= 45000	// Time to move 1 hex on the map if you are carrying a starbase (also multiplied by impedence of hex)
    

    
    In MissionMatching.gf we determine the default game speed for battles, and we determine how long different wait times are for battles, how long simulated battles take, and how long the server will wait for mission results to be reported before it assumes a mission crashed.

    AIBattlesSimulateTime	= 1	// setting this to 1=Simulate a time delay for pure AI battles, setting this to 0=resolve results immediately
    AIBattlesTimeRange	= 8	// Time in minutes or seconds that pure AI battle might take (random)
    AIBattlesTimeInMinutes	= 1	// 1=AIBattlesTimeRange is measured in minutes, 0=AIBattlesTimeRange is in seconds
    
    [Game]
    GameSpeed	=9 	//default meta game speed
    
    // Time to wait for missions selection in milliseconds
    [SetupProtocol]
    ResponseWait	=15000 // wait 15 seconds for a response
    ReadyWait		=15000 // wait 15 seconds in ready state
    
    [EngagementTimers]
    EngagementServerTickRate	= 1000	// length of each tick in the countdown process leading into a mission
    WaitForBattleStart		= 45000	// time in ms before battle starts and no one else can join (battle is resolved to play/or not at that point)
    WaitForMissionReception		= 25000	// time in ms allowing players to acknowledge receipt of mission, ready to start
    WaitForBattleResults		= 480		// time in *minutes* before server assumes an all-out mission crash, and forfeit options (if any) are applied
    WaitForRemainingBattleResults	= 480000	// time in ms for remaining battle results to be reported after first was reported
    
    

  • 10.3 Establishing automated campaign victory conditions
    Finally, we can set automatic victory conditions for the server - effectively limiting how long play on the server will go on. This is done in MetaMap.gf, and involves specifying how big an empire has to be relative to its opponents before the campaign ends.

    You can also set warning levels, this will display messages when an empire is getting "close" to meeting the victory conditions.

    [WinConditions]
    NumCumulativeOpponentsToWin	= 3	// Number of cumulative oppenent points to overcome to win.
    	// Since there are 4 races, setting this to 3 means a race wins when it has a large economy than
    	// the other three races combined multiplied by the coefficient set below.
    NumCumulativeOpponentsToWarn	= 2	// Here a warning is issued when one empire is larger than two of its opponents combined
    CumulativeCoefficient	= 1.5		// How much bigger an empire has to be than it's opponents: 
    	// here we specify it has to be 1.5 times the size of all three enemy empires combined
    

  ---

• 11. Controlling news and reporting
  I'll expand this section when I get around to it, essentially you can customize the colours for different types of news item (see the News.gf file) and the frequency with which economic reports are generated.

  It is also possible to limit the volume of "spurious" news items, and the frequency with which it is cleaned out of the news.

  • 11.1 Frequency and volume of news reports
    In News.gf we can limit the volume of news and the frequency with which it is cleaned up.

    [General]
    TurnFrequency		= 1	// Currently controls how often old news gets removed from the database
    MaximumItemsAtOnce	= 30 	// The maximum number of news items to send a client when it connects for the first time per second
    

    
    In MetaMap.gf we can control how often the economic reports (summaries of the empires' economic status) appear in the news.

    [EconomicReport]
    Interval	= 10		// Every "Interval" years the report is produced in the news
    

  ---

• 12. Saving and restoring campaigns

  • 12.1 Controlling when saves take place
    In the Database.gf file we can determine how frequently an autosave takes place, how frequently autosaves should be backed up into special time-stamped folders, and whether or not an autosave should take place on exit.

    AutoSaveFrequency	= 5	// (5) How many turns will pass before auto-saving (default: every 10 minutes)
    AutoSaveOnExit	= 1	// (1) Should an autosave be done on exit
    AutoSaveDateTimeStampedRate	= 6		// (6) Every X times an autosave is done, create as "YYYY-MM-DD_HHMM".  
    							// 0=Do not use this feature.
    

  • 12.2 Shutting down and restarting campaigns

    For single player obviously we can save/exit/load/delete campaigns as desired.

    To shut down online servers simply hit enter to obtain the server menu and select shutdown. Running the ServerPlatform.exe and selecting 1 will restart the campaign from the most recent save.

  ---

• 13. Controlling mission results and impact
  One of the most important areas in setting up a campaign is determining what impact should a successful (or unsuccessful) mission have on the dynaverse. This includes analyzing the impact on the defensive value of the hex and the impact on a player's ship and reputation.

  The relevant settings are covered in a multitude of files, considered in the sections below.

  • 13.1 Player results from missions
    In the Character.gf file we determine how much of a player's prestige to take away after a mission to pay back any disrepute they have build up, and we determine if a player should be forcibly moved to a different hex if they lost a mission.

    DisreputePaybackRate	= 1.0	// This is the percent of new prestige awarded to pay back disrepute (1.0 = 100%).  
    // This must be between 0.1 and 10.0, i.e. at least 10% and at most 1000% of the prestige from a mission can be
    // taken away to pay back any disrepute they have built up.
    
    VictoryLevelToShiftAHexAfterBattle	= 3	// How badly a player has to lose before they get removed from a hex
    	// If a player survives a battle and receives this victory condition or below, they will move one hex out of the battle hex.													
    	// 3= Draw, Defeat, Devastating Defeat will move them
    	// 2= Defeat, Devastating Defeat will move them
    	// 1= Devastating Defeat will move them
    	// 0= Do not move the character no matter how bad a loss is
    

    
    In Score.gf we determine how much (if anything) a player is charged for a replacement ship if they lose their ship in combat.

    We also specify how much repair and resupply a character is automatically given at bases.

    [Misc]
    MissionCompletePrestige		= 5	// This is the min level of prestige a player can get if they drop into a tactical game
    CombatDamageBonus			= 15	// This is the bonus players get if they come into space dock with zero prestige
    ChargeForReplacementShip	= 1	// If the setting is 1 then if the player loses their ship due to forfeit or battle death
    	//  they will be charged the cost of their new ship, if the setting is 0 the player is not charged for the replacement
    ChargeToDisreputeRate		= 80	// Percent describing the breakdown between disrepute charges and prestige
    
    [Base]
    PostBattleMinimumRepair		= 1
    PostBattleRepairRatio		= 0.25 // Maximum percentage of remaining damage to repair on a base after a battle - PostBattleMinimumRepair
    PostBattleMinimumResupply	= 1
    PostBattleResupplyRatio		= 0.60 // Maximum percentage of missing stores to resupply a base after a battle - PostBattleMinimumResupply
    
    

    The "ChargeToDisreputeRate" needs some more explanation - this was cut and pasted from Dave Ferrell's explanation in the fixes thread:

    This controls how much to charge to a player's disrepute if they are charged for a new ship when they die. 
    The algorithm is a bit complex, so bear with me. 
    Its primary purpose is to lessen the sting of dying in battle, 
    but prevent cheating by stripping a ship and then purposefully dying in battle. 
    When a player dies and the server is set to charge them for their replacement ship 
    (Score.gf:[Misc]/ChargeForReplacementShip), the server calculates the trade-in value of their new replacement ship. 
    This amount is to be charged to the player. 
    ChargeToDisreputeRate is the percentage to charge to disrepute instead of prestige. 
    The remainder is charged to prestige. 
    If the player has disrepute already, the system will charge disrepute only up to the amount 
    that was to be charged to disrepute and the remainder will then go to prestige. An example:
    a) Player dies and is charged 10000 prestige for their new ship.
    b) ChargeToDisreputeRate is set to 80%, so 8000 goes to disrepute and 2000 to prestige.
    c) Player already has 5000 disrepute. So they are charged 3000 more disrepute, with the extra 5000 going back to prestige.
    d) Player is then charged 7000 prestige. If they did not have disrepute already, 
    it would have been 8000 to disrepute and 2000 charged to prestige.
    

    In MissionMatching.gf we set the penalties (if any) to be applied when a player fails to complete a mission due to forfeits, and penalties (if any) to be applied if the player drops due to a crash, lost connection, or Alt-F4.

    [ForfeitModifiers]
    ForfeitPercentageLossOfPrestige	= 25		// On a forfeit, the player will lose this percentage of their total prestige.
    ForfeitPrestigeThreshold		= 5000	// At or below this prestige level, the player will instead lose their ship on a forfeit.
    ForfeitLoseShipIfBelowPrestigeThreshold	= 0	// Turn ship loss on forfeit on/off.  1= Lose ship if forfeit and below prestige threshold, 0= No ship loss, just additional prestige loss
    ForfeitIfFailedToJoin	= 0	// 1= Treat drops, crashes, and Alt-F4's as if they were a forfeit, 0=Ignore this option
    DeathIfFailedToJoin	= 1	// 1= Treat drops, crashes, and Alt-F4's as if the player was killed in the battle, 0=Ignore this option
    
    [EngagementMisc]
    MaxPlayersInEngagement	= 6	// Max # of players that can engage each other at one time (to me this seems to be unstable beyond 6, and even 6 is dicey)
    DefenderFledAttackerBonus	= 125		// Prestige bonus given to attackers if a battle did not start because the primary defender forfeited
    

  • 13.2 Mission impact on hex defensive values
    In MetaMap.gf we determine how much the defensive value of a hex is changed due to a successful mission, and we determine what defensive level causes the hex to "flip" and what level it flips to. Both of these levels are determines as fractions of the original/maximum hex value.

    [Battle]
    MinVictoryPointsForPlayerVictory	= 0.2 // A player flips a hex when it is reduced to 20% of its original strength
    MinVictoryPointsForAIVictory		= 0.1 // An AI flips a hex when it is reduced to 10% of its original strength
    HexHealthResetRatio			= 0.5 // When a hex is flipped it switches to 50% of its original (maximum) strength
    
    [VictoryPointModifier]
    Easy	= 10	// on easy difficulty setting, each successful mission drops the hex strength by 10
    Med	= 5	// on medium difficulty setting, each successful mission drops the hex strength by 5
    Hard	= 1	// on hard difficulty setting, each successful mission drops the hex strength by 1
    PureAI	= 0.05	// each successful AI mission drops the strength of the hex by 0.05 
    	// (I'm not entirely sure if that's absolute or a fraction of the maxium)
    

  • 13.3 Mission impact on political tensions
    If your campaign is set up to allow changing political tensions over time (not recommended) then in MetaMap.gf you can determine how much each successful/unsuccessful mission impacts the tensions.

    [TensionBumps]
    Draw				= 0.5
    SuccessWin			= 0.33
    FailedWin			= 0.66
    SuccessDefend		= 0.5
    FailDefend			= 1.0
    

  • 13.4 Controlling frequency and impact of AI-vs-AI missions
    In MissionMatching.gf we determine the outcome of battles between AI opponents: who wins and how severely, how much damage is done to each combatant, how much prestige each combatant is awarded or penalized, and how long the simulated battle takes.

    First we set the odds for each different level of success or failure based on the assumption that the two sides are equally strong. These percentages will in fact be automatically scaled to reflect the relative strength of the two sides.

    [PureAIBattle]
    // First
    OddsAstoundingVictory	= 5		// 0..100 Odds that one side of pure AI battle will get Astounding Victory
    OddsVictory			= 20		// 0..100 Odds that one side of pure AI battle will get Victory
    OddsDefeat			= 20		// 0..100 Odds that one side of pure AI battle will get Defeat
    OddsDevastatingDefeat	= 5		// 0..100 Odds that one side of pure AI battle will get Devastating Defeat
    DefenderHomeHexAdvantage	= 2	// Bonus to odds for defender if battle is within friendly hex
    AttackerHomeHexAdvantage	= 0	// Bonus to odds for attacker if battle is within friendly hex
    
    // Battle formula (calculated for defender):
    // ratio = defender's total BPV / attacker's total BPV
    // 
    // if ( defender is battling on home territory )
    // {
    //      OddsVictory += DefenderHomeHexAdvantage
    // }											
    // 												
    // if ( attacker is battling on home territory )											
    // {												
    //      OddsDefeat += AttackerHomeHexAdvantage											
    // }												
    // 												
    // OddsAstoundingVictory *= ratio												
    // OddsVictory           *= ratio												
    // OddsDefeat            *= 1/ratio												
    // OddsDevastatingDefeat *= 1/ratio												
    // 
    // OddsDraw				 = ( 100 - OddsAstoundingVictory - OddsVictory - OddsDefeat - OddsDevastatingDefeat )								
    // if ( OddsDraw < 0 )											
    // {												
    //      OddsDraw = 0												
    //      Remaining odds are normalized												
    // }
    
    // given the level of victory has been decided,
    // determine if the loser got killed
    OddsDeathOnDevastatingDefeat	= 95	// 0..100 Odds that AI will die as a result of devastating defeat
    OddsDeathOnDefeat		= 65		// 0..100 Odds that AI will die as a result of defeat
    
    // now determine the amount of damage done to each ship,
    // based on the level of victory/defeat
    DamageRange	= 80	// 0..100 Percentage damage on single system in one random damage pass
    OddsShipSystemDamage	= 50	// 0..100 Odds that random ship damage is system damage
    DamagePassesOnDevastatingDefeat	= 20	// Number of passes of random damage on ship as a result of devastating defeat (assuming they weren't killed)
    DamagePassesOnDefeat	= 10	// Number of passes of random damage on ship as a result of defeat
    DamagePassesOnDraw	= 5	// Number of passes of random damage on ship as a result of a draw
    DamagePassesOnVictory	= 2	// Number of passes of random damage on ship as a result of victory
    DamagePassesOnAstoundingVictory	= 0	// Number of passes of random damage on ship as a result of astounding victory
    
    // determine how much prestige each combatant should receive
    PrestigeForAstoundingVictory	= 350		// Prestige for AI astounding victory
    PrestigeForVictory	= 250		// Prestige for AI victory
    PrestigeForDraw		= 0		// Prestige for AI draw
    PrestigeForDefeat		= -250	// Prestige for AI defeat
    PrestigeForDevastatingDefeat	= -350	// Prestige for AI devastating defeat
    
    // determine how long the combatants should be "in battle"
    AIBattlesSimulateTime	= 1	// 1=Simulate time delay before resolution of pure AI battle, 0=resolve results immediately
    AIBattlesTimeRange	= 8	// Time in minutes or seconds that pure AI battle might take (random)
    AIBattlesTimeInMinutes	= 1	// 1=AIBattlesTimeRange is in minutes, 0=AIBattlesTimeRange is in seconds
    

  • 13.5 Player and AI "glicko" ratings
    Each player and AI in the dynaverse has a skill, or glicko, rating. We determine the starting rating for each players and AI, thereafter the ratings go up or down based on how well (or how poorly) you do against the opponents you encounter and what their ratings were. For players, we determine the starting ratings in Score.gf, along with the kind of impact victory levels have on changes to the ratings.

    [Rating]
    FermiTemp			= 1.0	 // variable used in controlling how quickly ratings adapt
    StartingHumanRating	= 1500 // starting human rating
    MaximumGain			= 32   // amount a rating can change by in a single mission
    
    [VictoryLevels]
    AstoundingVictory		= 1.0	// Ast. Vic. is treated as a 100% win for computation of rating changes
    Victory			= 0.8	// Victory is treated as an 80% win for computation of rating changes
    Draw				= 0.5	// Draw is treated as a 50% win for computation of rating changes
    Defeat			= 0.2	// Defeat is treated as a 20% win for computation of rating changes
    DevastatingDefeat		= 0.0	// Dev. Defeat is treated as a 0% win for computation of rating changes
    
    [Hex]
    WinThreshold		= 0.5 // The threshold between won/lost is 0.5
    

    
    Meanwhile, in AI.gf we determine the range of starting ratings that a new AI can have.

    [Rating]
    StartingAIRating					= 1200
    StartingAIRatingRange				= 500
    

  • 13.6 Player rank and advancement
    As players complete missions and earn prestige they will gradually increase in rank. We can control the levels at which they are promoted, and what kind of prestige bonuses they receive on promotion, through the Rank.gf file in the CommonSettings folder.

    Note that we can also specify what the title associated with each rank is, as described in section 8.4.

    // This file contains settings for determining and naming a character's rank.
    // You can change the Rank Cost, Promotion Bonus and even the names of the Ranks
    // but you cannot change the number of ranks.
    
    [RankCost]
    //Total lifetime prestige needed to gain rank
    Lieutenant			= 0
    LieutenantCommander	= 2000
    Commander			= 10000
    Captain			= 40000
    Admiral			= 80000
    
    [PromotionBonus]
    // Bonus prestige awarded upon reaching a new rank
    Rank1			= 0
    Rank2			= 500
    Rank3			= 1000
    Rank4			= 2000
    Rank5			= 4000
    

  ---

• 14. Modifying game technology
  By adjusting various settings in the CommonSettings folder we can modify the mass, cost, health, efficiency, etc of various items of technology for the various races.

  Generally this is done by finding and editing the description of the specific racial item, as shown in the sections below.

  NOTE THAT THESE FILES MUST MATCH ON THE PLAYER MACHINE AND THE SERVER - i.e. if you run a server using modified versions of these files then so must the players, and if as a player you modify these files you will not be able to play on servers which use the stock files, SO MAKE BACKUPS BEFORE YOU DO THIS.

  As an aside, there are certain items (e.g. starbase power plants) that are not intended to be available for players to purchase in the refit screen. There is a general purpose tag used to indicate such refit items:

  UnavailableForRefit = 1
  

  • 14.1 Changing Weapon Stats
    In WeaponItems.gf (in the CommonSettings folder) we can alter the description, cost, and mass of various weapons for each of the different races. We can also change how much damage the items can absorb (health), how much warp energy they draw, and the baseline damage level they deliver.

    Examples are shown below for both a primary weapon and a heavy weapon.

    //Federation Primary Weapons//
    
    [PrimaryItems\PHASER IXS]
    Description = "PHASER IXS"
    Cost = 550
    Mass = 50
    Health = 15
    Energy = 2.0
    Damage = 4.0
    Race = "F"
    
    //Klingon Heavy Weapons//
    [HeavyItems\K-PHOTON TORPEDO]
    Description = "K-PHOTON TORP"
    Cost = 900
    Mass = 200
    Health = 20
    Energy = 6.0
    Damage = 6.0
    Race = "K"
    

  • 14.2 Changing Bridge Component Stats
    Similarly we can modify the characteristics of cloaking devices and computers in the BridgeItems.gf file in the CommonSettings folder.

    For computers we can determine whether or not they can detect cloaked ships and (if they can detect cloaked ships) how effective they are at the task using the AntiCloak and AntiCloakRating variables.

    Each computer also has a range index and lockon bonus, but I am not sure how effectively these are supported. (Anyone investigated this?)

    For cloaking devices the cloak rating determines how effective they are, while the cloak cost determines how much energy they draw.

    [ComputerItems\F-COMPUTER-I]
    Description = "F-COMPUTER-I"
    Cost = 500
    Mass = 100
    AntiCloak = 0
    AntiCloakRating = 0
    RangeIndex = 1
    LockBonus = 0
    Health = 40
    Race = "F" 
    
    [CloakItems\K-CLOAK-V]
    Description = "K-CLOAK-V"
    Cost = 2750
    Mass = 750
    CloakRating = 100
    CloakCost = 10
    Health = 40
    Race = "K" 
    
    

  • 14.3 Changing Hull Component Stats
    In HullItems.gf (also in the CommonSettings folder) we set the statistics for armour, transporters, and tractor beams. For transporters, the rating determines how many units the transporter can handle (e.g. can you beam across one hit and run party, 2, 3? etc).

    [ArmorItems\F-ARMOR-I]
    Description ="F-ARMOR-I"
    Cost = 500
    Mass = 1000
    Health = 10
    Race = "F" 
    
    [TransporterItems\F-TRANSPORTER-I]
    Description ="F-TRANSPRT-I"
    Cost = 500
    Mass = 100
    Rating = 1 
    Health = 10
    Race = "F" 
    
    [TractorItems\K-TRACTOR-I]
    Description ="K-TRACTOR-I"
    Cost = 500
    Mass = 100 
    Health = 10
    Race = "K" 
    
    

  • 14.4 Changing Engine Stats
    In the PowerItems.gf file in the CommonSettings folder we determine the characteristics of warp engines, impulse engines, and thrusters for each of the different races.

    Note that warp and thrusters use "power" to determine their effectiveness, while impulse engines use "efficiency".

    Also note that thrusters have their health commented out because they are not at present a targetable system.

    [WarpItems\F-WARP-I]
    Description ="F-WARP-I"
    Power = 25
    Cost = 3000
    Mass = 800
    Health = 44
    Race = "F" 
    
    [ImpulseItems\F-IMPULSE-I]
    Description ="F-IMPULSE-I"
    Cost = 600
    Mass = 400
    Efficiency = 9.0
    Health = 45
    Race = "F" 
    
    [ThrusterItems\F-THRUSTER-V]
    Description ="F-THRUSTR-V"
    Cost = 650
    Mass = 1000
    Power = 185
    //Health = 33
    Race = "F"
    
    

  • 14.5 Changing Shield Stats
    Finally, in ShieldItems.gf in the CommonSettings folder, we specify the characteristics for the shields for each of the playable races.

    Aside from cost and mass, we can specify the strength and efficiency (power draw?) for each shield type.

    [ShieldItems\F-SHIELD-I]
    Description ="F-SHIELD-I"
    Strength = 5
    Efficiency = 3.0
    Cost = 500
    Mass = 1000
    Race = "F" 
    
    

  ---

• 15. Modifying ships
  There are a considerable number of options for creating custom ships in the game, and for restricting their use if necessary.

  Modifications generally come in several forms:

  • Changes to the .gf files (described in sections 2-14 above)
  • Changes to the list of ship variants (DefaultLoadout.txt)
  • Changes to the fundamental ship structure descriptions (DefaultCore.txt)
  • Changes to the models used to represent ships in the game

  • 15.1 Modifications to DefaultLoadout.txt

    The DefaultLoadout.txt file is best edited using Excel, and it contains information describing each ship variant in the campaign.

    The information covers precise refit information (i.e. what types of weapons, shields, etc are in each hardpoint), availability (any, AI only, etc), officer quality, etc.

    This information dictates the ship's stats when a ship is made available for purchase in the shipyard or when an AI ship is generated (in mission or as a new AI character).

    For online servers, it is the server's DefaultLoadout.txt file that is used to generate AI and fill the shipyards, so it does not matter if individual players have customized their own DefaultLoadout.txt files.

    There are a great many details involved in customizing the DefaultLoadout.txt file - I'm not going to get into them here, but for a great guide I highly recommend Nomad's guide over at sfcx.org.

  • 15.2 Modifications to DefaultCore.txt

    Unlike modifications to the DefaultLoadout, each server will check to see that a player's DefaultCore.txt file matches that of the server. As a server admin, that means if you use a modified Core then everyone who plays on your server also needs to use that modified Core. As a player, it means that modifying your core means you can't play on any servers except those that use the same modification.

    As a result, MAKE BACKUPS OF YOUR ORIGINAL DEFAULTCORE.TXT file, and be prepared to swap back and forth between the original versions and whatever modified versions you have in use.

    Again, for customizing DefaultCore.txt I highly recommend Nomad's guide.

  • 15.3 Models
    Sorry, but I know nada about the whole modeling side of things.

    My best advice is to get on the Taldren Forums and check out the Models group, where I'm sure people will do a great job of helping you get started.

  ---

• 16. Databases: Flatfile and SQL (maybe someday)
  Virtually all of the files and settings discussed above must be edited before the campaign begins: the information is read at campaign startup and stored in a database (saved game) file for the campaign.

  To make changes to the settings once the campaign is underway involves editing the database file. You have to know what you're doing when you edit the file or you will corrupt the file and the campaign will become unplayable so make a backup of the file before you try any editing.

  At the moment the save files are stored as single large binary files, but in a future patch they may support an option to use SQL.

  • 16.1 Modifying a campaign on-the-fly: editing the flatfile DB
    For the moment, the save game files are large binary files, that must be edited with a special tool called a hex editor. A freeware hex editor is available at:

    http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm
       

    Each saved game file is located in its own folder (the folder name matches the saved game name) and the file name is Sfc3Spd.sds.

    Again, BE SURE YOU BACK UP THE FILE BEFORE YOU TRY EDITING IT WITH THE HEX EDITOR.

    To successfully edit the file, you need to know what kind of information is stored exactly where within the file. Unfortunately, that information hasn't been publicly released, so editing becomes a matter of trial and error.

    As an example, we can try editing the racial tensions (alliances) mid-campaign by opening the .sds file with the hex editor, and doing a search for "POLITIC". That will bring us to the file section where all the racial tensions have been stored. Then we start guessing about which particular bytes store the particular racial tensions we wish to alter, and replace them with the (hexadecimal) value we want. Not for the faint of heart, but some of the admins have gotten pretty adept at it.

    Just to get started, let's try editing our own prestige and editing the political alliances in a single player campaign:

    Editing prestige:

    (1) Load the game as it currently stands and make a note of your ship name and your current prestige, save the campaign and remember what you called it, exit the game

    (2 Go to folder Saves\YourCampaignName in your SFC3 folder and make a backup of file Sfc3Spd.sds (anytime you're manually editing the db there's a decent chance you're going to mess up and make the campaign unplayable, so backups are important)

    (3) Use the hex editor to open the file Sfc3Spd.sds

    (4) Do a search on your ship name, e.g. my ship is the "Tikka Terror", so I searched for the string "tikka"

    (5) Look a little ways past your ship name, and you'll see your in-game name

    (6) About 4 characters (8 hex digits) past the end of your in-game name, you'll see the hex numbers which represent your prestige. These values are represented in hexadecimal, but the left two hex values have been swapped with the right two.

    For instance, my prestige used to be 14920, which in hexadecimal is 3A48, so what shows in the database is 483A

    You can edit these to any value you like, e.g. FFFF gives you a prestige of 65535

    (7) Save the file and restart the game, loading your modified campaign

    (8) If the game won't load then you've messed something up, so replace Sfc3Spd.sds with the backup you made and try again

    Editing alliances

    Well, if that went ok, you might want to try changing some alliances mid-stream.

    (1) Make a note of the old relationship settings, e.g. suppose in the MetaMap.gf file we had settings like this:

    [PoliticalTension/StartingTensions/Federation]
    Federation=0
    Klingon=945
    Romulan=800
    Borg=1000
    Species8472=1000
    Cardassian=800
    Ferengi=200
    Rakellian=1000
    Pirate=1000
    Neutral=800
    
    etc.
    

    (2) Make a backup of file Sfc3Spd.sds

    (3) Use the hex editor to open the file Sfc3Spd.sds

    (4) Do a search on the string "political", shortly after that (about 24 characters or 48 hex digits) you'll see the stored political matrix, with values entered in hexadecimal in the same order as they appear in the MetaMap.gf file

    For the MetaMap settings shown up above, the matching hex values would be

    0000 // Federation=0
    03B1 // Klingon=945
    0320 // Romulan=800
    03E8 // Borg=1000
    03E8 // Species8472=1000
    0320 // Cardassian=800
    00C8 // Ferengi=200
    03E8 // Rakellian=1000
    03E8 // Pirate=1000
    0320 // Neutral=800
    

    However, the game inserts a third hex pair between each set of tensions, and swaps the order of the hex pairs, so the way it actually appears in Sfc3Spd.sds is:

    00 00 00 B1 03 5D 20 03 4F E8 03 64 E8 03 64 20 03 4F C8 00 13 E8 03 64 E8 03 64 20 03 4F
    

    Each triple pair represents one alliance setting, i.e. the first 00 00 00 corresponds to the Fed-to-Fed 0 rating, then the B1 03 5D is for the Fed-to-Klink 945 rating, etc.

    The two most useful triples are E80364 for total war and 000000 for complete alliance.

    If we wanted to make the Feds allied to the Klinks, we would change the 03B15D to 000000

    So make any changes you want, remembering that in the whole matrix there are 10 races, each with a sequence like that shown above.

    (5) Save the file and restart the campaign

    (6) If you've messed something up replace Sfc3Spd.sds with the backup you made and try again

  • 16.2 SQL campaign databases
    Well, if and when SQL actually becomes a working part of SFC I'll come back and work on this section.