Modder's Guide to Final Frontier Plus

TC01

Deity
Joined
Jun 28, 2009
Messages
2,216
Location
Irregularly Online
This thread is a work in progress at the moment, but ultimately it's meant to be a guide to modding Final Frontier Plus and merging it with your own mods.

Also, you can ask any questions about modding FF+ or working it into your own space mods here. If you're having trouble (for instance, I recall that when someone tried to get their mod working with FF+, there was a crash when initializing the main menu), you can either post about it here or start a new thread.

XML Reference:

CIV4BuildingInfo:

bNeverCapture, iConquestProb: These tags in vanilla Civ were not used in Final Frontier. They now can be used- to set either the probability of a building being destroyed or that the building will always be destroyed on the conquest of a city.

BuildingClassNeededs: This array in Final Frontier was used to require certain buildingclasses to be on the building planet. Now it merely requires the buildingclasses to be in the same system- the original functionality has been passed to a new array, PlanetBuildingClassNeededs.

bOnePerSystem: Boolean tag indicating that the building can only be built once per system. Accessed by CvBuildingInfo().isOnePerSystem().

iCostModIncrease: Integer tag indicating the increase in building cost for multiple buildings in a system (Works like it did in the python- "2" is normal, "3" is a higher cost). Accessed by CvBuildingInfo().getCostModIncrease().

PlanetYieldChanges: An array that lets you change the yields of the planet that the building was built on. The example below adds one food to the planet (like the Nutrition Facility). Accessed by CvBuildingInfo().getPlanetYieldChanges(int).

Code:
			<PlanetYieldChanges>
				<iYield>1</iYield>
				<iYield>0</iYield>
				<iYield>0</iYield>
			</PlanetYieldChanges>

iPlanetPopCapIncrease: Integer that specifies how much the building increases the population cap of the planet it is built on. Accessed by CvBuildingInfo().getPlanetPopCapIncrease().

SystemArtTag: String that points to the "Feature Model Tag" for buildings that have art visible in the game when built (like the Shipyards). Accessed by CvBuildingInfo().getSystemArtTag().

bMoon: Boolean saying that the building requires the current building planet to have a moon for the building to be constructed. Accessed by CvBuildingInfo().isMoon().

bRings: Boolean saying that the building requires the current building planet to have rings for the building to be constructed. Accessed by CvBuildingInfo().isRings().

PlanetBuildingClassNeededs: Array similar to BuildingClassNeededs, but the buildings listed here must be on the current building planet for the building to be constructed. Accessed by CvBuildingInfo().isBuildingClassNeededOnPlanet(iBuildingClass).

iSingleRingBuildingLocation: Integer used to define exceptions to the single building ring location system, used for building art orbiting the solar system. If not set to -1, a building will use the FEATURE_DUMMY_TAG_BUILDING_x where x is this value. Accessed by CvBuildingInfo().getSingleRingBuildingLocation().

TraitPlanetYieldChanges: Array for traits that, in combination with the building, cause yields to change on the planet the building is built on. The example is for the Forge and the Mining Facility. Accessed by CvBuildingInfo().getTraitPlanetYieldChanges(iTrait, iYield).

Code:
			<TraitPlanetYieldChanges>
				<TraitPlanetYieldChange>
					<TraitType>TRAIT_THE_FORGE</TraitType>
					<PlanetYieldChanges>
						<iYield>0</iYield>
						<iYield>1</iYield>
						<iYield>0</iYield>
					</PlanetYieldChanges>
				</TraitPlanetYieldChange>
			</TraitPlanetYieldChanges>

CIV4CivilizationInfo:
bAlien: Boolean tag currently unused. In theory, this flags a civ as one of the "alien" civs that a goody flagged with "bNewCiv" can spawn. Code not tested as no alien civs have been added. Accesse by CvCivilizationInfo().isAlien().

CIV4TraitInfo:
iFreePopulation: Integer that defines the free population that will be added to all cities a player with this trait has. Accessed by CvTraitInfo().getFreePopulation().

iFreeTradeRoutes: Integer that defines extra trade routes that will be added to all cities a player with this trait has. Accessed by CvTraitInfo().getFreeTradeRoutes().

iStartingGoldMultiplier: Integer that is multiplied by the default amount of starting gold a player with this trait starts with. Accessed by CvTraitInfo().getStartingGoldMultiplier().

YieldChanges: Array for yield changes (throughout the entire city, not just a specific planet) caused by the trait. Accessed by CvTraitInfo().getYieldChanges(iYield)

FreePlanetBuildingClass: String defining a building class that will be added to all planets in all solar systems founded by a player with the trait. Accessed by CvTraitInfo().getFreePlanetBuildingClass().

TradeRouteYieldChanges: Array for yield changes throughout the entire city per each trade route in the city. Accessed by CvTraitInfo().getTradeRouteYieldChanges(iYield).

CIV4CivicInfo:
UnitCombatCostMods: An array that lets you modify a given unit combat's cost under a civic. For instance, the array in the example makes light ships cost -10% less. Accessed by CvCivicInfo().getUnitCombatCostMods(int).

PlanetYieldChanges: An array that lets you change planet yields in the same style of other YieldChanges arrays. The example below adds one food to all planets (like the Utopia civic). Accessed by CvCivicInfo().getPlanetYieldChanges(int).

Code:
			<UnitCombatCostMods>
				<UnitCombatCostMod>
					<UnitCombat>UNITCOMBAT_LIGHT_SHIP</UnitCombat>
					<iCostMod>-10</iCostMod>
				</UnitCombatCostMod>
			</UnitCombatCostMods>
			<PlanetYieldChanges>
				<iYield>1</iYield>
				<iYield>0</iYield>
				<iYield>0</iYield>
			</PlanetYieldChanges>

CIV4GoodyInfo:
RequiredImprovement: String that lets you make the goody require a particular improvement. If left blank or not used, the goody can be received from any improvement. Accesed by CvGoodyInfo().getRequiredimprovement().

bDamageUnit: Boolean that says that the goody's effects will damage the unit that triggered it. Accessed by CvGoodyInfo().isDamage().

bNewCiv: Boolean that in theory creates a new civ flagged with "bAlien". Untested as no alien civs have been added (no enabled goody uses this). Accessed by CvGoodyInfo.isNewCiv().

CIV4FeatureInfo:
bNoBarbarianSpawn: Boolean that means barbarian units will not be allowed to spawn on this feature. Accessed by CvFeatureInfo().isNoBarbarianSpawn().

iMovePathExtraCost: Integer defining the extra "movement path cost" for this feature (used in calculating movement paths). Accessed by CvFeatureInfo().getExtraMovePathCost().

BlackHoleFeatureType: String defining the "Black Hole" matched with this gravity field feature- gravity field features will only pull units in if this is defined. Accessed by CvFeatureinfo().getBlackHoleFeatureType().

iGravityFieldForce: Integer defining the force of this gravity field feature. Dependent on BlackHoleFeatureType. Accessed by CvFeatureInfo().getGravityFieldForce().

iBlackHoleInArea: Integer defining the range of plots around a grav field that the game will look for it's BlackHoleFeatureType. Accessed by CvFeatureInfo().getBlackHoleInArea().

TargetWormholeType: String defining a feature that units moving onto this feature will be teleported to. Can be the same or different feature- so FEATURE_WORMHOLE's TargetWormholeType is FEATURE_WORMHOLE. Accessed by CvFeatureInfo().getTargetWormholeType().

CIV4ImprovementInfo:
UnitClassBuilt: String indicating the unit class of a unit created when the improvement is built. The unit is given to the player who is building the improvement. Accessed by CvImprovementInfo().getUnitClassBuilt().

CIV4TerrainInfo:
bFoundFeature: Boolean tag indicating that a city can only be built on the plot if there is a feature as well. Overruled by bFound. Accessed by CvTerrainInfo().isFoundFeature().

CIV4BuildInfo:
bStarbase: Boolean tag indicating that the build will produce a unit (that the build is making a starbase). This causes the game to check whether other units are building other "starbases" or there are other "starbase units" on the plot before allowing construction. Accessed by CvBuildInfo().isStarbase().

CIV4UnitInfo:
bStarbase: Boolean tag indicating that the unit is a "starbase". Starbase builds can't be built when starbase units are on the plot. Accessed by CvUnitInfo().isStarbase(), or alternatively CyUnit().isStarbase().

iCultureRange: Integer tag indicating the range of culture that will be created around the unit when it is created. Normally set to 0, set to 2 for starbases. Accessed by CvUnitInfo().getCultureRange().

MinBarbarianSpawnEra: String defining the earliest game era required for the barbarians to spawn this unit. Game era is the average of player eras. Accessed by CvUnitInfo.getMinBarbarianSpawnEra().

MaxBarbarianSpawnEra: String defining the latest game era required for the barbarians to spawn this unit. Game era is the average of player eras. Accessed by CvUnitInfo.getMaxBarbarianSpawnEra().

iBarbarianChanceMultiplier: Integer that increases the chance of this unit spawning as a barbarian. It is multiplied by the randomly generated chance, so if set to 2, the chance doubles, if set to 3, it triples, etc. Accessed by CvUnitInfo().getBarbarianChanceMultiplier.

iUpgradePriceOverride: Integer that hardcodes an upgrading price for upgrading to this unit, ignored if the price is 0 or less. Accessed by CvUnitInfo().getUpgradePriceOverride().

bDelta: Boolean that defines a unit as a "delta" unit. Is not necessary for all Delta units and does nothing except influence upgrade prices (see below). Only used for Delta Starbase at present. Accessed by CvUnitInfo().isDelta().

bOmega: Boolean that defines a unit as an "omega" unit. Is not necessary for all Omega units. What it does is this: if a unit is upgrading to an omega unit and is a normal (non-delta) unit, than the upgrade price is doubled. Only used for Omega Starbase at present. Accessed by CvUnitInfo().isOmega().

bOtherStation: Boolean that defines a space station (declared by bStarbase) as an "other station", i.e. not a starbase and therefore not something that spawns missiles. Accessed by CvUnitInfo().isOtherStation().

MovementSound: String that defines a 3D audio script ran when the unit moves. Accessed by CvUnitInfo().getMovementSound().

bMissile: Boolean that defines a unit as a missile, and therefore spawnable by starbases. Accessed by CvUnitInfo().isMissile().

Global Defines:

TURN_BARBARIANS_APPEAR: Integer defining the first turn barbarian units will appear

CONSTRUCT_SHIP: String defining the construction ship unitclass, for the AI's construction ship code.

FF_PALACE_BUILDINGCLASS: String defining the Palace/Capitol buildingclass. This tag does not exist in FF+ 1.62 and will only be added in the imminent release of the Mod Platform (and in future releases of FF+). It is necessary because for some reason I can't access the existing PALACE_BUILDINGCLASS tag in Python.

Final Frontier Worldbuilder:

My Final Frontier Worldbuilder project adds additional data to the WBS files created when loading and saving inside the in-game Worldbuilder. This new information iis documented below. Please note: the consequence of this is that third-party map editor programs such as MapView will create WBS files that do no work properly.

The planets of a solar system were stored under the "FeatureType=FEATURE_SOLAR_SYSTEM" line, as seen below:

Code:
PlanetType=ORANGE_PLANET, OrbitRing=4, PlanetSize=1, HasMoon=1, HasRings=0
PlanetType=RED_PLANET, OrbitRing=2, PlanetSize=2, HasMoon=0, HasRings=0
PlanetType=RED_PLANET, OrbitRing=1, PlanetSize=1, HasMoon=0, HasRings=0
PlanetType=BLUE_PLANET, OrbitRing=7, PlanetSize=2, HasMoon=0, HasRings=0
PlanetType=GREEN_PLANET, OrbitRing=3, PlanetSize=1, HasMoon=0, HasRings=0
PlanetType=RED_PLANET, OrbitRing=8, PlanetSize=0, HasMoon=0, HasRings=0

Now, two additional tags have been added to the end of this list. One is called "PlanetName=". It specifies what the name of the planet is. The second is called "PlanetBonusType=", and it specifies what the planet's resource is (if there is one). See below for an example:

Code:
PlanetType=ORANGE_PLANET, OrbitRing=4, PlanetSize=1, HasMoon=1, HasRings=0, PlanetName=Xi Horus, PlanetBonusType=NO_BONUS
PlanetType=RED_PLANET, OrbitRing=2, PlanetSize=2, HasMoon=0, HasRings=0, PlanetName=Zeus Cancer, PlanetBonusType=NO_BONUS
PlanetType=RED_PLANET, OrbitRing=1, PlanetSize=1, HasMoon=0, HasRings=0, PlanetName=Sigma Libra, PlanetBonusType=BONUS_FISH
PlanetType=BLUE_PLANET, OrbitRing=7, PlanetSize=2, HasMoon=0, HasRings=0, PlanetName=Gamma Hephaestus, PlanetBonusType=NO_BONUS
PlanetType=GREEN_PLANET, OrbitRing=3, PlanetSize=1, HasMoon=0, HasRings=0, PlanetName=Paradise, PlanetBonusType=NO_BONUS
PlanetType=RED_PLANET, OrbitRing=8, PlanetSize=0, HasMoon=0, HasRings=0, PlanetName=Pi Hermes, PlanetBonusType=NO_BONUSPlanetBonusType=NO_BONUS

The following lines of code can be added to any city define (below any "BeginCity"). They control the distribution of "CityPopulation=" among various planets in the solar system. The total of all the values of the planet population tags must equal the city population, and it should go under the "CityPopulation=" line.

Code:
Planet1Population=2
Planet2Population=1
Planet3Population=0
Planet4Population=1
Planet5Population=2
Planet6Population=1
Planet7Population=0
Planet8Population=1

The following lines of code can be added to any city define (below any "BeginCity"). They store buildings to a specific planet, so "Planet1BuildingType=" means that the listed building is added to Planet 1, and the same for all the others. They should be added under the last "BuildingType=" line)

Code:
Planet1BuildingType=BUILDING_CAPITOL
Planet2BuildingType=BUILDING_NUTRITION_FACILITY
Planet3BuildingType=BUILDING_MINING_FACILITY
Planet4BuildingType=BUILDING_RECYCLING_CENTER
Planet5BuildingType=BUILDING_NUTRITION_FACILITY
Planet6BuildingType=BUILDING_MINING_FACILITY
Planet7BuildingType=BUILDING_RECYCLING_CENTER
Planet8BuildingType=BUILDING_CAPITOL

The following lines of code can be added to any city define (under BeginCity). They specify the selected planet and the building planet ring for each city- the planet that is selected in the city screen and the planet that buildings will be created on.

Code:
SelectedPlanet= 2
BuildingPlanetRing = 2

Miscellaneous:

AI Auto-Play:

You can also use AI Auto Play in this mod. To turn on AI Auto Play, you need to first enable the console- turn on "cheats" by opening up the BTS .ini file, searching for "CheatCode = 0", and changing the "0" to "chipotle". The .ini file can be found in your Beyond the Sword directory (there should be a shortcut titled _Civ4Config). Then you must open up the console by typing "Shift + ~" in game.

Once in the python console, enter the following to activate AI Auto Play, where "x" is the number of turns AI Auto Play should last.

Code:
CyGame().setAIAutoPlay(x)

Final Frontier Debugger:

Jon Shafer built some debugging functionality into Final Frontier. Specifically, throughout the mod's python files there are lots of printd() statements which output text to the PythonDbg.log file. These statements are normally disabled. However, you can activate them if you need more information.

If you open CvSolarSystem.py, at the top you should see this code:

Code:
#########################################
#########################################
g_bPrintDebugText = false
#########################################
#########################################

def printd(szText):
	if (g_bPrintDebugText):
		print(szText)

If you change the value of g_bPrintDebugText to True, the debug text will be printed.
 
Mod Platform Version:

The Mod Platform is a version of Final Frontier Plus designed to be a platform, or engine, for other people to build total conversions on. It's specifically been released to aid some modders in merging FF+ with their own mods; modders who don't want all the fancy features like Wormholes and Resources from Planets, and modders who don't want to have to strip out existing civs and other stuff like that.

It can be downloaded here (hosted on WPC).

Solving Final Frontier Dependencies:

There are two references to Final Frontier in the mod's files. The first is in CIV4ArtDefines_Misc.xml. It reads as follows in Final Frontier:

Code:
		<MiscArtInfo>
			<Type>DEFAULT_THEME_NAME</Type>
			<Path>Mods/Final Frontier Plus/Resource/Civ4.thm</Path>
			<fScale>0.0</fScale>
			<NIF>None</NIF>
			<KFM>None</KFM>
		</MiscArtInfo>

As of patch 1.64, this now points to Final Frontier Plus. However, you should change it to point to your own mod's Resource folder to prevent Final Frontier or Final Frontier Plus from being a dependency.

Likewise, you will need to edit the Civ4.thm file located in the Resource folder. That is actually a text file, and reads as follows:

Code:
// *** Control Bitmap Theme file

// Set the resource 
resource_path	"Mods/Final Frontier/Resource";

// Setup common properties
include			"Mods/Final Frontier/Resource/Themes/Civ4/Civ4Theme.thm";

Again, as of patch 1.64, it now points to Final Frontier Plus. And again, you should change this to point to your own mod.

If these errors are not made, GFC errors will occur when a user tries to run the mod who does not have Final Frontier (or Final Frontier Plus) installed.
 
In CIV4BuildingInfo.xml the iConquestProb value should be the probability of the building surviving a conquest, not of being destroyed. That is what it is used for in regular BtS.

As has been the case for quite some time, the Python for this in CvFinalFrontierEvents.py, in onCityAcquired, is using it as the chance to destroy the building ("if (iRand < gc.getBuildingInfo(iBuildingLoop).getConquestProbability()):" then destroy it). This is reversed from the meaning in regular BtS, where the "<" would be ">=" in the condition. In a few cases this causes buildings to always be kept instead of always destroyed due to the values in the XML: the BUILDING_RESEARCH_LAB has iConquestProb = 0 and also bNeverCapture = 0 so it is currently always surviving (having iConquestProb = 0 ought to be identical in outcome to having bNeverCapture = 1 except that the latter avoids the random number being generated). Ditto for BUILDING_SPACEPORT, BUILDING_MANUFACTURING_PLANT, BUILDING_RESEARCH_INSTITUTE, BUILDING_ASSEMBLY_PLANT, BUILDING_STAR_CITADEL, BUILDING_SPACEPARK, BUILDING_PBS, BUILDING_NANOSEPARATION_SYSTEM, and the defined but unused BUILDING_CAPITOL_FINANCIAL.
 
I replaced your eras with the default FF ones properly, but when I go to load up the game I get an error in Civ4ForceControls regarding ERA_ISOLATION. Civ4ForceControls is in the vanilla directory, but in the file I find no refrences to anything that could refer to era_isolation. ForceControls itself refers to multiplayer options so I'm doubly confused. Note that the game loads up fine (I don't know about play yet, there are some python issues I have to solve) and era_isolation is the only error of that type that pops up. Any help would be appreciated as this is not dealt with in the modders guide.

EDIT: You should also probably point out in your guide that you replaced the eras. That tripped me up the first time I tried to merge.
 
I replaced your eras with the default FF ones properly, but when I go to load up the game I get an error in Civ4ForceControls regarding ERA_ISOLATION. Civ4ForceControls is in the vanilla directory, but in the file I find no refrences to anything that could refer to era_isolation. ForceControls itself refers to multiplayer options so I'm doubly confused. Note that the game loads up fine (I don't know about play yet, there are some python issues I have to solve) and era_isolation is the only error of that type that pops up. Any help would be appreciated as this is not dealt with in the modders guide.

EDIT: You should also probably point out in your guide that you replaced the eras. That tripped me up the first time I tried to merge.

You'll need to change the global define STANDARD_ERA to fix this. I think that should fix the ForceControl error.

Code:
	<Define>
		<DefineName>STANDARD_ERA</DefineName>
		<DefineTextVal>ERA_ISOLATION</DefineTextVal>
	</Define>

You'll also need to replace the eras in the MinEra and MaxEra BarbarianSpawn tags in CIV4UnitInfos (mentioned in guide).

Although, Final Frontier doesn't actually have eras- or, rather, it does, but they're the standard eras from Civ 4 and it only uses one of them- Modern, renamed Galactic.

But I will add this information to the guide.
 
Thanks. It shouldn't matter I don't have the min/max era infos in unitinfos as all new xml tags are not nescesary for the mod to run, right? I seem to remember reading something about that on the old thread.
 
Thanks. It shouldn't matter I don't have the min/max era infos in unitinfos as all new xml tags are not nescesary for the mod to run, right? I seem to remember reading something about that on the old thread.

No, I don't think anything is absolutely necessary that the mod will crash without it, or give you errors, since everything's minOccurs="0". But some features require new XML tags. Some don't really matter, others are more important.

For instance, if you have starbases in your mod, the starbase tags (UnitClassBuilt in ImprovementInfo, bStarbase in UnitInfo and BuildInfo) are needed.

And if you want barbarians to spawn, you'll need to set up the min/max barbarian spawn era system- unless of course you re-add the old Python barbarian spawning code.
 
Looks like I'll have to go back through and add the XML tags in again.

Quick question, does the order of XML tags in a file matter? eg, could I have the art defines up top?
 
Looks like I'll have to go back through and add the XML tags in again.

Quick question, does the order of XML tags in a file matter? eg, could I have the art defines up top?

Yes, it matters (unfortunately). All my new XML tags go at the bottom of the entry, in the order that they're posted in the reference.
 
Hi. I'm trying to build a scenario/minor modmod to FFP. I can pretty much get everything on my own, but I was wondering if you had a more comprehensive guide on all the planet types in the world builder, because the scenario involves recreating our Solar System, as well as a couple other (fictional) Star Systems.
 
Hi. I'm trying to build a scenario/minor modmod to FFP. I can pretty much get everything on my own, but I was wondering if you had a more comprehensive guide on all the planet types in the world builder, because the scenario involves recreating our Solar System, as well as a couple other (fictional) Star Systems.

I can tell you that there are six colors:

YELLOW_PLANET
GREEN_PLANET
WHITE_PLANET
BLUE_PLANET
RED_PLANET
GRAY_PLANET

And that there are three sizes:

0
1
2

Then, if you want a planet to have rings or a moon, you set that tag to 1 (HasMoons = 1, HasRings = 1).

And then the OrbitRing tags go from 1 to 8 (you cannot have more than 8 planets in a system).
 
Can a planet have more than one moon? Also, do you know which of those could best pass for Gas Giants, and which for more terrestrial objects?
 
You left out a planet type: the ORANGE_PLANET... (This one looks very similar to the Yellow version - the one that actually looks orange to me is the Red type.)

The planet types that are displayed with the atmosphere effect are the Green, Orange, and White. Only the Green is shown with the cloud effect (the Green planet type is the one that looks a lot like the Earth as it has water and land arranged in continents). Both of these could be changed: it's controlled by the Python via a series of "if" statements.

The base yields of each planet type:
Blue = 0:food:, 2:hammers:, 5:commerce:.
Gray = 0:food:, 3:hammers:, 3:commerce:.
Green = 3:food:, 1:hammers:, 2:commerce:.
Orange = 2:food:, 2:hammers:, 1:commerce:.
Red = 1:food:, 2:hammers:, 3:commerce:.
Yellow = 1:food:, 1:hammers:, 6:commerce:.
White = 2 :food:, 0:hammers:, 3:commerce:.

This not very good for making the Earth's solar system, but you can probably come close enough for a rough visual match. There is no real provision for large gas giants. You're pretty much stuck with Mercury as a size 0 planet (Gray), Venus, Earth, and Mars as size 1 (probably as Orange, Green, and Red - although Red doesn't get the atmosphere effect), and the other four as size 2 (perhaps as Yellow, Yellow with rings, White, and Blue or something like that) - and no Pluto. I'd give the Earth a moon, and probably Jupiter and Saturn; the rest I would just leave out (one moon per planet, and only one size of moon).

One problem with this is that the Earth can obviously support a much higher population than any of the others, but with this sort of scheme the gas giants can support more population since the size is the base population that can work the planet. Of course, in the game a planet can only have one resource (and only one planet in a system can have one, but that is irrelevant for the solar system) but the Earth has all of the included planetary resources and more (the "building" that goes with each of the 3 food/health resources increases the population that can be assigned to work the planet by 1). I'd give one of the food resources to your Earth.

(In FF+ terms, the Earth is a ridiculously good starting planet due to all of the resources, and the rest of the solar system is pretty nice as well - no randomly generated system in FF+ is allowed to have more than 7 planets and we have 8 + Pluto and more stuff beyond that.)
 
In regards to moons: a planet cannot have more than one moon, at least not without messing around with the XML art defines for the Solar System and the Python code used to activate it.

And I have no idea how you would do that, I'm afraid.
 
CIV4TraitInfo:
iFreePopulation: Integer that defines the free population that will be added to all cities a player with this trait has. Accessed by CvTraitInfo().getFreePopulation().

iFreeTradeRoutes: Integer that defines extra trade routes that will be added to all cities a player with this trait has. Accessed by CvTraitInfo().getFreeTradeRoutes().

iStartingGoldMultiplier: Integer that is multiplied by the default amount of starting gold a player with this trait starts with. Accessed by CvTraitInfo().getStartingGoldMultiplier().

YieldChanges: Array for yield changes (throughout the entire city, not just a specific planet) caused by the trait. Accessed by CvTraitInfo().getYieldChanges(iYield)

FreePlanetBuildingClass: String defining a building class that will be added to all planets in all solar systems founded by a player with the trait. Accessed by CvTraitInfo().getFreePlanetBuildingClass().

TradeRouteYieldChanges: Array for yield changes throughout the entire city per each trade route in the city. Accessed by CvTraitInfo().getTradeRouteYieldChanges(iYield).
If i wanted to add 2 or 3 of these trait values to a single civ's trait is there a specific order i need to place them in or can they just be added to the bottom of an existing trait in any order?
i.e. Civ 1 gets
iStartingGoldMultiplier:
FreePlanetBuildingClass:
YieldChanges:
iFreeTradeRoutes:
TradeRouteYieldChanges:
Civ 2 gets
iFreePopulation:
iStartingGoldMultiplier:
YieldChanges:
and then civ 3 gets
iFreeTradeRoutes:
YieldChanges:
FreePlanetBuildingClass:
iStartingGoldMultiplier:
 
You need to put them in the order they're placed in the schema file, skipping missing elements. This should (and happens to be) be the same as they are in the first post:

Code:
		<element type="iFreePopulation" minOccurs="0"/>
		<element type="iFreeTradeRoutes" minOccurs="0"/>
		<element type="iStartingGoldMultiplier" minOccurs="0"/>
		<element type="YieldChanges" minOccurs="0"/>
		<element type="FreePlanetBuildingClass" minOccurs="0"/>
		<element type="TradeRouteYieldChanges" minOccurs="0"/>
 
Top Bottom