|
NuclearWessels' guide to SFC3 campaign modification
Please note that this server manual will now be outdated, this is just a
general info page if you need more specific details then STG reccomends that you
visit
www.dynaverse.net
(for single-player dynaverse campaigns and online servers)This document is still
a work in progress, and care should be taken in using the information here since
some of it is undoubtedly inaccurate, but it should provide a decent
introduction to the process of setting up and customizing campaigns for
StarFleetCommand 3. It covers both single-player campaigns and online servers.
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
Important: Starfleet Command III is a copyright of Activision, while the
game code is a copyright of Taldren, and Star Trek is a copyright of Paramount
Pictures. 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.
Document Structure
-
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?
-
-
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.
-
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.
-
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).
-
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
-
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:
-
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
-
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:
- Players and the AI: what ships are out there?
-
Ships in the dynaverse come in three flavours:
-
Ships that belong to players, and as such are a permanent part of the
dynaverse (well, permanent until they're destroyed or traded in)
-
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.
-
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:
-
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
-
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.
-
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.
-
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).
-
Run the
ServerPlatform.exe program in the server kit folder
-
Choose option 1 to start the server
-
If you wish to stop the server later, simply hit enter to bring up the
options menu, then choose shutdown.
-
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
h |
