XML (Advanced) Guide to Adding Buildings and Wonders to Brave New World

LeeS · May 2, 2014

END OF DEFINING YOUR BUILDING

You need to tell the XML that you are done ADDING a NEW building; you do this using the following command:

Code:

</Row>

You MUST include this command at the end of EACH new BUILDING you are adding to the game.
.....................................................................................................................................................................

END OF DEFINING BUILDINGS

You need to tell the XML that you are done adding information to the "<Buildings>" table; you do this by the following command:

Code:

</Buildings>

You MUST include this command at the end of your new-building(s) definition(s). If you are adding more than one new building, you wait to include this command until after the end of the LAST building you are adding to the XML.

</GameData> here ?

Spoiler :

.....................................................................................................................................................................

EXECUTABLE CODE REVIEW

NOT A WORLD WONDER

If I DON'T want my building to be a world wonder, I would change my buildings table code as shown, assuming I didn't want to add anything new to my building except a reference to a custom-made icon group:

Spoiler :

A WORLD WONDER

If I DO want my building to be a world wonder, and I wanted to add "1" free social policy to my world wonder, I would add-in the "FreePolicies" command. I might also decide to remove the two (2) merchant specialist slots, since World Wonders no longer are "meant" to have specialists attached to them (though the game WILL let you add specialists to wonders). In either case, I can keep the great merchant great-person points, however.

I would want to add the "NukeImmune" attribute, bump the conquest probability to 100%, eliminate the "FreeStartEra", and set "HurryCostModifier" to "-1". I would also want to eliminate the "GoldMaintenance" since wonders don't require any. Obviously, if I were "really" adding a new World Wonder, I would set a much higher hammers cost, but I think there are enough changes for you to digest between the two versions of my example building, so I'll leave that alone.

Spoiler :

I didn't change the entries for "Type" and "BuildingClass" between the two versions of the "building", not-wonder and wonder, because I don't actually need to.

ICON ATLASES TABLE

Since I made a reference in both of these buildings examples to an icon atlas called "MY_NEW_ICON_ATLAS" I would also need to include entries in the "IconTextureAtlases" table for that atlas somewhere in my mod. Here's what I would add, assuming I would be using the same artwork files as were discussed earlier.

Spoiler :

This is what my XML would look like without any intermediary commentary between the "<Buildings>" table and the "<IconTextureAtlases>" table, and if everything were placed within the same ".XML" file:

Spoiler :

Code:

<GameData>
	<Buildings>
		<Row>
			<Type>BUILDING_EXAMPLE</Type>
			<BuildingClass>BUILDINGCLASS_EXAMPLE</BuildingClass>
			<Cost>100</Cost>
			<PrereqTech>TECH_POTTERY</PrereqTech>
			<Help>TXT_KEY_BUILDING_EXAMPLE_HELP</Help>
			<Description>TXT_KEY_BUILDING_EXAMPLE</Description>
			<Civilopedia>TXT_KEY_BUILDING_EXAMPLE_PEDIA</Civilopedia>
			<Strategy>TXT_KEY_BUILDING_EXAMPLE_STRATEGY</Strategy>
			<ArtDefineTag>NONE</ArtDefineTag>
			<SpecialistType>SPECIALIST_MERCHANT</SpecialistType>
			<GreatPeopleRateChange>1</GreatPeopleRateChange>
			<MinAreaSize>-1</MinAreaSize>
			<ConquestProb>100</ConquestProb>
			<HurryCostModifier>-1</HurryCostModifier>
			<NukeImmune>true</NukeImmune>
			<PlotBuyCostModifier>-10</PlotBuyCostModifier>
			<FreePolicies>1</FreePolicies>
			<IconAtlas>MY_NEW_ICON_ATLAS</IconAtlas>
			<PortraitIndex>0</PortraitIndex>
			<!-- WONDER SPLASH STUFF -->
			<WonderSplashImage>MyNewWonder.dds</WonderSplashImage>
			<WonderSplashAnchor>L,B</WonderSplashAnchor>
			<WonderSplashAudio>NONE</WonderSplashAudio>
			<Quote>TXT_KEY_WONDER_MYNEWWONDER_QUOTE</Quote>
		</Row>
	</Buildings>

	<IconTextureAtlases>
		<Row>
			<Atlas>MY_NEW_ICON_ATLAS</Atlas>
			<IconSize>256</IconSize>
			<Filename>MyNewAtlas256.dds</Filename>
			<IconsPerRow>8</IconsPerRow>
			<IconsPerColumn>8</IconsPerColumn>
		</Row>
		<Row>
			<Atlas>MY_NEW_ICON_ATLAS</Atlas>
			<IconSize>128</IconSize>
			<Filename>MyNewAtlas128.dds</Filename>
			<IconsPerRow>8</IconsPerRow>
			<IconsPerColumn>8</IconsPerColumn>
		</Row>
		<Row>
			<Atlas>MY_NEW_ICON_ATLAS</Atlas>
			<IconSize>64</IconSize>
			<Filename>MyNewAtlas64.dds</Filename>
			<IconsPerRow>8</IconsPerRow>
			<IconsPerColumn>8</IconsPerColumn>
		</Row>
		<Row>
			<Atlas>MY_NEW_ICON_ATLAS</Atlas>
			<IconSize>45</IconSize>
			<Filename>MyNewAtlas45.dds</Filename>
			<IconsPerRow>8</IconsPerRow>
			<IconsPerColumn>8</IconsPerColumn>
		</Row>
	</IconTextureAtlases>
</GameData>

NOTE:

I generally will not be including the </IconTextureAtlases> table in future code examples simply because I want to keep the amount of stuff you have to look through to a minimum.

WHAT'S NEXT ?

At this point I've completed the discussion of the <Buildings> table, and I've explained the function and format for the <IconTextureAtlases> table. I'll move on from the <Buildings> table, and begin to discuss other tables that can affect your building, or that are required to properly insert your building into the game. Most of the tables that will follow will have pretty short "sections" devoted to them, since any one building doesn't add much total XML code when it has an entry in a particular table.

END OF THE <Buildings> TABLE -- END OF THE <Buildings> TABLE -- END OF THE <Buildings> TABLE -- END OF THE <Buildings> TABLE

LeeS · May 2, 2014

The <BuildingClasses> table is used to tell the game what CLASS of building your new building fits into.

If your new building is a unique building that replaces, say, the Barracks, you do not need to make an entry in your mod for the <BuildingClasses> table.

If your building is a completely-new class of building, you DO need an entry for it under the <BuildingClasses> table. New National Wonders and World Wonders ALWAYS require an entry in the <BuildingClasses> table.

You can have the following lines in your entry:

Type

This is the Building CLASS name, and is REQUIRED. Note that the function of the command <Type> changes between the <Buildings> table and the <BuildingClasses> table.

DefaultBuilding

This is the name of the default BUILDING within the CLASS. For World or National Wonders this will always be the same as the building <Type> entry found in the <Buildings> table for the wonder.

Description

This is a "TXT_KEY_" look-up reference, and should be the same "TXT_KEY_" reference as the one found in the <Buildings> table for the default building. In practical terms, for new building types, and for national and world wonders, enter the same information here as entered for "Description" in the <Buildings> table.

MaxGlobalInstances

Tells the game how many times one of the buildings that fit-into this building CLASS can be built WORLD-WIDE during a single game. In practical terms, this is only used with world wonders, and then is always set to a value of "1".

This command can me omitted when it does not apply to your building.

MaxPlayerInstances

Tells the game how many times a SINGLE PLAYER can build one of the buildings that fit-into this building CLASS during a single game. In practical terms, this is usually used with national wonders, and then is usually to a value of "1". An exception to this rule is the recycling center building, which has a MaxPlayerInstances of "5", allowing a player to build no more than five (5) recycling centers during a single game.

This command can me omitted when it does not apply to your building.

EXAMPLES

If I wanted to use my example building as a WORLD wonder, I would make the following entry for the <BuildingClasses> table:

Code:

<BuildingClasses>
	<Row>
		<Type>BUILDINGCLASS_EXAMPLE</Type>
		<DefaultBuilding>BUILDING_EXAMPLE</DefaultBuilding>
		<Description>TXT_KEY_BUILDING_EXAMPLE</Description>
		<MaxGlobalInstances>1</MaxGlobalInstances>
	</Row>
</BuildingClasses>

If I wanted to use my example building as a NATIONAL wonder, I would make the following entry for the <BuildingClasses> table:

Code:

<BuildingClasses>
	<Row>
		<Type>BUILDINGCLASS_EXAMPLE</Type>
		<DefaultBuilding>BUILDING_EXAMPLE</DefaultBuilding>
		<Description>TXT_KEY_BUILDING_EXAMPLE</Description>
		<MaxPlayerInstances>1</MaxPlayerInstances>
	</Row>
</BuildingClasses>

If I wanted to use my example building as a "normal" building that can be built as many times as a player wanted, I would make the following entry for the <BuildingClasses> table:

Code:

<BuildingClasses>
	<Row>
		<Type>BUILDINGCLASS_EXAMPLE</Type>
		<DefaultBuilding>BUILDING_EXAMPLE</DefaultBuilding>
		<Description>TXT_KEY_BUILDING_EXAMPLE</Description>
	</Row>
</BuildingClasses>

If I wanted to use my example building as a "normal" building that can be built ONLY four (4) times by a player, I would make the following entry for the <BuildingClasses> table:

Code:

<BuildingClasses>
	<Row>
		<Type>BUILDINGCLASS_EXAMPLE</Type>
		<DefaultBuilding>BUILDING_EXAMPLE</DefaultBuilding>
		<Description>TXT_KEY_BUILDING_EXAMPLE</Description>
		<MaxPlayerInstances>4</MaxPlayerInstances>
	</Row>
</BuildingClasses>

LeeS · May 2, 2014

The <Civilization_BuildingClassOverrides> table is used to lock-out barbarians and city-states from building a specified CLASS of building, and to override the normal list of what buildings a playable CIV can build, assigning a unique building within a given CLASS instead.

CivilizationType

Defines which civilization's list of buildings is to be changed. In this entry CIVILIZATION_BARBARIAN refers to Barbarians and CIVILIZATION_MINOR refers to all city-states. The format is:

Code:

<CivilizationType>CIVILIZATION_BARBARIAN</CivilizationType>

BuildingClassType

Defines the CLASS of building for the override. The format is:

Code:

<BuildingClassType>BUILDINGCLASS_CASTLE</BuildingClassType>

BuildingType

Defines the BUILDING that replaces the default building for the playable Civilization. The format is:

Code:

<BuildingType>BUILDING_MUGHAL_FORT</BuildingType>

To lock-out a civilization from constructing anything in a BUILDING CLASS, the command is formatted as

Code:

<BuildingType/>

WORLD WONDERS and NATIONAL WONDERS

You should always "lock-out" Barbarians and City-States from building any world or national wonder you add to the game. You will need to have an entry in the <Civilization_BuildingClassOverrides> table for Barbarians and another for City-States.

EXAMPLE

I've shown a properly-formatted <Civilization_BuildingClassOverrides> table below with entries from the actual FIRAXIS-supplied XML that are used to lock-out Barbarians and City-States from building the Musicians' Guild building, and the entry that replaces the CASTLE with the MUGHAL FORT for India.

Code:

<Civilization_BuildingClassOverrides>
	<Row>
		<CivilizationType>CIVILIZATION_BARBARIAN</CivilizationType>
		<BuildingClassType>BUILDINGCLASS_MUSICIANS_GUILD</BuildingClassType>
		<BuildingType/>
	</Row>
	<Row>
		<CivilizationType>CIVILIZATION_MINOR</CivilizationType>
		<BuildingClassType>BUILDINGCLASS_MUSICIANS_GUILD</BuildingClassType>
		<BuildingType/>
	</Row>
	<Row>
		<CivilizationType>CIVILIZATION_INDIA</CivilizationType>
		<BuildingClassType>BUILDINGCLASS_CASTLE</BuildingClassType>
		<BuildingType>BUILDING_MUGHAL_FORT</BuildingType>
	</Row>
</Civilization_BuildingClassOverrides>

LeeS · May 2, 2014

The <Building_PrereqBuildingClasses> table is used to specify a building CLASS that must already exist in an empire before a building can be constructed. As a practical matter, it is used to specify what building must be present in ALL cities before a National Wonder can be built. You should generally not try to use this table for any other purpose. You will nearly always want to specify "-1" as the NumBuildingNeeded.

There may be times when you wish to create a new national wonder that does not require every city to have built a particular prerequisite building. In such cases, simply omit this table altogether.

BuildingType

specifies the building for which a prerequisite is about to be stated. As a practical matter, this is always a national wonder.

BuildingClassType

specifies the prerequisite CLASS of building that must exist before the building specified in BuildingType can be constructed.

NumBuildingNeeded

specifies how many of the prerequisite buildings must exist throughout a player's empire before the player can construct the building mentioned in BuildingType.
In the case of National Wonders, this is set to "-1", which is used to signal the game that one "prereq" building is required in EVERY CITY of a player's empire. Puppetted cities do not count, but cities that are being "razed to the ground" do.
The game does not deal with "real" numbers specified for NumBuildingNeeded in a way that seems intuitive. It will tend to double any real whole number entered for this command.

When a positive whole number is stated for NumBuildingNeeded, the game modifies this number based upon world size:

The game appears to round down to the nearest whole number after making the calculation.

INHERENT LIMITATIONS OF THE TABLE

I have tried to use this table to require that a certain number of "regular" buildings (A) must exist in the empire before another "regular" building (B) can be constructed. As noted, the game tends toward doubling the requirement stated in the table, so that up to twice as many buildings (A) are required before the first building (B) can be built. Thereafter, the game will not allow the construction of a second building (B) regardless of how many buildings (A) exist in the empire.

Any building that has an entry for it in this table will only be able to be constructed once per player per game, regardless of the setting of <MaxPlayerOccurances> you make in the <BuildingClasses> table.

EXAMPLE OF THE TABLE AS USED BY FIRAXIS:

Here is a properly-formatted example of this table, using the Heroic Epic national wonder entry as it actually appears in the FIRAXIS-supplied XML:

Code:

<Building_PrereqBuildingClasses>
	<Row>
		<BuildingType>BUILDING_HEROIC_EPIC</BuildingType>
		<BuildingClassType>BUILDINGCLASS_BARRACKS</BuildingClassType>
		<NumBuildingNeeded>-1</NumBuildingNeeded>
	</Row>
</Building_PrereqBuildingClasses>

To "read" this entry in the table, it says that BUILDING_HEROIC_EPIC requires one BUILDINGCLASS_BARRACKS building to be present in every city before BUILDING_HEROIC_EPIC can be constructed. Since Kreposts and Ikandas belong to the BUILDINGCLASS_BARRACKS class of buildings, they too are being covered by this entry.

TABLE BEHAVIOR UNDER DIFFERENT CONDITIONS:

(1) A regular building

I created two new buildings. The first I called a "Practice Range", and the second I called an "Archery Range". What I wanted was a general low-cost building (the Practive Range) that could be built early in the game and would be available in every city. I made it give a small extra amount of experience to archery units, but had no other effects. I wanted the "Archery Range" to be a much more powerful building contributing substantially increased experience to archery units as well as substantial increases in their production. But I didn't want to overpower the game with "Archery Ranges", so I structured a <Building_PrereqBuildingClasses> table as follows, to require that the empire had completed 6 Practice Ranges before it could build an Archery Range:

Code:

<Building_PrereqBuildingClasses>
	<Row>
		<BuildingType>BUILDING_ARCHERY_RANGE</BuildingType>
		<BuildingClassType>BUILDINGCLASS_PRACTICE_RANGE</BuildingClassType>
		<NumBuildingNeeded>6</NumBuildingNeeded>
	</Row>
</Building_PrereqBuildingClasses>

I had a <Building_ClassesNeededInCity> table as follows, to require that the city trying to build an Archery Range must first have finished a Practice Range:

Code:

<Building_ClassesNeededInCity>
	<Row>
		<BuildingType>BUILDING_ARCHERY_RANGE</BuildingType>
		<BuildingClassType>BUILDINGCLASS_PRACTICE_RANGE</BuildingClassType>
	</Row>
</Building_ClassesNeededInCity>

The result was that the game forced me to build twelve (12) Practice Ranges before it allowed me to build an Archery Range, NOT the six (6) I had specified, because I was playing on a Huge map. After I built the first Archery Range in my empire, the game would not allow me to build a second Archery Range. It would allow me to add the second Archery Range to a city's build que, but every time I progressed the game to the next turn, the game deleted the second Archery Range from the que and started work on the next item in the city build list.

(2) A World Wonder

It is possible to require that a world wonder can only be built when every city within an empire has built a prerequisite building. This is not normal practice in CIV5, but it can be done. The <Building_PrereqBuildingClasses> will allow you to create such a requirement. If I am adding a world wonder called Giant Refridgerator, I could require that every city in an empire has a Granary before the Giant Refridgerator can be built. I would structure my table as follows:

Code:

<Building_PrereqBuildingClasses>
	<Row>
		<BuildingType>BUILDING_GIANT_REFRIDGERATOR</BuildingType>
		<BuildingClassType>BUILDINGCLASS_GRANARY</BuildingClassType>
		<NumBuildingNeeded>-1</NumBuildingNeeded>
	</Row>
</Building_PrereqBuildingClasses>

EXTRA NOTE APPLYING TO ALL METHODS OF USING THIS TABLE:

It is not strictly necessary to have a <Building_ClassesNeededInCity> table "paired up with" the <Building_PrereqBuildingClasses> table to get everything to work properly. National Wonders generally have such a pairing, but it is not strictly required.

LeeS · May 2, 2014

The <Building_ClassesNeededInCity> table is used to specify a building that must already exist within a SPECIFIC CITY before an "upgrade" building can be built in that SPECIFIC CITY. Where no such requirement is needed for your mod, you can omit the entire table. National wonders generally have an entry in this table in addition to their entry in the <Building_PrereqBuildingClasses> table. World Wonders do not generally have an entry in the <Building_ClassesNeededInCity> table, but they can.

BuildingType

specifies the building for which a prerequisite is about to be stated. This can be either a wonder or a "regular" building.

BuildingClassType

specifies the prerequisite CLASS of building that must exist before the building specified in BuildingType can be constructed.

TABLE EXAMPLES

Here is a properly-formatted example of this table, using my example building as the "BuildingType", and specifying that a Barracks-Class building must already have been constructed in the city before I can construct my example building:

Code:

<Building_ClassesNeededInCity>
	<Row>
		<BuildingType>BUILDING_EXAMPLE</BuildingType>
		<BuildingClassType>BUILDINGCLASS_BARRACKS</BuildingClassType>
	</Row>
</Building_ClassesNeededInCity>

Here is a properly-formatted example of this table, using the Heroic Epic national wonder entry as it actually appears in the FIRAXIS-supplied XML:

Code:

<Building_ClassesNeededInCity>
	<Row>
		<BuildingType>BUILDING_HEROIC_EPIC</BuildingType>
		<BuildingClassType>BUILDINGCLASS_BARRACKS</BuildingClassType>
	</Row>
</Building_ClassesNeededInCity>

When you add a new building to the game that will be required in order to build a pre-existing building in the game a separate entry is required for the default building as well as any unique buildings. If I add a new building I'll call the BUILDING_PRACTICE_YARD that will act as a prerequisite building before a BARRACKS can be constructed, I must add commands for the BARRACKS, the KREPOST, and the IKANDA that tell the game that a BUILDINGCLASS_PRACTICE_YARD must exist in a city before a BARRACKS, KREPOST, or IKANDA can be constructed. I must have a prerequisite entry for all three of the BARRACKS-CLASS buildings. This is the table as I need to include it to instruct the game that a PRACTICE YARD is needed before a BARRACKS can be constructed:

Code:

<Building_ClassesNeededInCity>
	<Row>
		<BuildingType>BUILDING_BARRACKS</BuildingType>
		<BuildingClassType>BUILDINGCLASS_PRACTICE_YARD</BuildingClassType>
	</Row>
	<Row>
		<BuildingType>BUILDING_KREPOST</BuildingType>
		<BuildingClassType>BUILDINGCLASS_PRACTICE_YARD</BuildingClassType>
	</Row>
	<Row>
		<BuildingType>BUILDING_IKANDA</BuildingType>
		<BuildingClassType>BUILDINGCLASS_PRACTICE_YARD</BuildingClassType>
	</Row>
</Building_ClassesNeededInCity>

If I want to require that the BARRACKS exist in a city before a PRACTICE YARD is constructed, I only need one entry in the table, since the prerequisite building is described by its Building CLASS:

Code:

<Building_ClassesNeededInCity>
	<Row>
		<BuildingType>BUILDING_PRACTICE_YARD</BuildingType>
		<BuildingClassType>BUILDINGCLASS_BARRACKS</BuildingClassType>
	</Row>
</Building_ClassesNeededInCity>

FOLLOW-UP ON <Building_PrereqBuildingClasses> and <Building_ClassesNeededInCity> tables.

In case the distinction between these two tables are still a little murky, here is one way to think of them:

<Building_PrereqBuildingClasses> tells the game HOW MANY of a prerequisite building must exist THROUGHOUT THE EMPIRE, and is only intended for use with National Wonders.
<Building_ClassesNeededInCity> tells the game which building is needed IN AN INDIVIDUAL CITY before an additional building can be constructed IN THAT SAME INDIVIDUAL CITY. This table is really intended for "regular" buildings, but the way the developers made the game, NATIONAL WONDERS still fit this requirement, so they also need an entry in this table.

LeeS · May 2, 2014

The <Building_LockedBuildingClasses> table is used to keep a player from being able to construct building-X in a city when building-Y has already been constructed there. If your mod does not require such a lock-out you can omit the entire table.

BuildingType

Used to designate the building for which a "lock-out" is to be specified.

BuildingClassType

Is presented in the form of a building-CLASS that locks out being able to build the building specified in BuildingType.

The entries in the table can be "read" as:

THIS building (defined by BuildingType) cannot be constructed in a city when another CLASS of building (defined by BuildingClassType) has already been constructed there.

FIRAXIS did not use this table anywhere, but I have seen at least one mod that does use this table.

EXAMPLE OF USE (Mutual Lock-Out)

To use this table as a mutual lock-out there has to be an entry for both buildings that lock each other out, one for building-X, and one for building-Y.

If I create a new building called BUILDING_FLYINGSCHOOL and create its buildingclass as BUILDINGCLASS_FLYINGSCHOOL, I could create a <Building_LockedBuildingClasses> table in my mod that forces a player to choose between building a "Flying School" OR building an "Airport" within a single city. Here is what my <Building_LockedBuildingClasses> table would look like:

Code:

<Building_LockedBuildingClasses>
	<Row>
		<BuildingType>BUILDING_AIRPORT</BuildingType>
		<BuildingClassType>BUILDINGCLASS_FLYINGSCHOOL</BuildingClassType>
	</Row>
	<Row>
		<BuildingType>BUILDING_FLYINGSCHOOL</BuildingType>
		<BuildingClassType>BUILDINGCLASS_AIRPORT</BuildingClassType>
	</Row>
</Building_LockedBuildingClasses>

The first entry tells the game that a player cannot build an AIRPORT if there is already a Flying-School-CLASS building in the city.
The second entry tells the game that a player cannot build a FLYING SCHOOL if there is already an Airport-CLASS building in the city.

EXAMPLE OF USE (One-Directional Lock-Out)

If I create a new wonder called BUILDING_TEMPLARS, I could create a <Building_LockedBuildingClasses> table in my mod that forces a player to construct the new wonder in a city OTHER THAN the capital city:

Code:

<Building_LockedBuildingClasses>
	<Row>
		<BuildingType>BUILDING_TEMPLARS</BuildingType>
		<BuildingClassType>BUILDINGCLASS_PALACE</BuildingClassType>
	</Row>
</Building_LockedBuildingClasses>

In this instance I really only need the one entry in the table, specifying I cannot construct the wonder BUILDING_TEMPLARS in a city that already has a Palace.

LeeS · May 2, 2014

The <Building_TechAndPrereqs> table is used to specify an ADDITIONAL technology that is required to construct the building. A player has to have discovered the technology stated directly in the <Buildings> table for PrereqTech, AND they must have discovered the technology specified in THIS table. When you do not want an additional technology prerequisite for your building, you can omit the entire table.

As a practical matter, only when the two techs are at the same "rung" of the technology ladder (reading left to right) is there really much point in adding an additional requirement in this table. It is just as effective, and certainly simpler, to choose the higher of two technology "rungs" as the building's <PreregTech> directly in the <Buildings> table than to add an additional requirement under the <Building_TechAndPrereqs> table.

BuildingType

Specifies the building for which an additional technology prerequisite is about to be stated.

TechType

Specifies the technology that is an ADDITIONAL prerequisite for the building.

EXAMPLE OF USE

Using the Flying School building again, I would probably specify in the <Buildings> table that the PrereqTech for the Flying School was FLIGHT, but I might also decide to state an additional tech requirement for the Flying School is COMBUSTION. The <Building_TechAndPrereqs> table for my mod would therefore look like the following:

Code:

<Building_TechAndPrereqs>
	<Row>
		<BuildingType>BUILDING_FLYINGSCHOOL</BuildingType>
		<TechType>TECH_COMBUSTION</TechType>
	</Row>
</Building_TechAndPrereqs>

LeeS · May 2, 2014

For the remainder of this document, unless specifically noted otherwise, all tables shown are optional.

You can safely omit including any of these tables when they aren't needed by your mod.

.........................................................................................................................................................................

Difference Betweeen MODIFIER Tables and CHANGES Tables

In the subsequent portions of this guide, many tables are "Changes" tables, and many are "Modifiers" tables. These two table "types" effect yields or costs in different and discreet ways. Many modders misunderstand how these tables differ, and how they actually work.

MODIFIER Tables

Generally, Modifier tables ADJUST some kind of Yield. These tables do not ALWAYS adjust a YIELD, but in most cases they do. Regardless of whether a specific Modifier table adjusts Yields, or whether it adjusts something else (such as gold purchasing costs in cities), it is stated as a PERCENTAGE ADJUSTMENT.
MODIFIER tables do NOT make a direct addition to a Yield.
In order for a "Yield Modifier" table to ADJUST a yield, there must ALREADY BE a yield of that type.
MODIFYING a yield by 100% when there is not already a yield present will not accomplish anything.
MODIFYING an existing yield of "1 total of something" by 1% WILL make an adjustment, but it won't have much of a noticable effect.
The numerical entries made in these tables should (as a general rule) be on the order of "10", "20", "30", "50", "100", etc., and not on the order of "1", "2", "3".

Here are some examples of Yield Modifiers taken from the Building_YieldModifiers table and repeated here EXACTLY as they are included in the FIRAXIS-supplied XML.

The entries I picked are for Floating Gardens, Workshop, Market, and University. I picked these four because each adjusts a different KIND of Yield. The entries in this table show how the Floating Gardens adjusts FOOD by +15%, the Workshop adjusts PRODUCTION by +10%, the Market adjusts GOLD by +25%, and the University adjusts SCIENCE by +33% in the city.

Code:

<Building_YieldModifiers>
	<Row>
		<BuildingType>BUILDING_FLOATING_GARDENS</BuildingType>
		<YieldType>YIELD_FOOD</YieldType>
		<Yield>15</Yield>
	</Row>
	<Row>
		<BuildingType>BUILDING_WORKSHOP</BuildingType>
		<YieldType>YIELD_PRODUCTION</YieldType>
		<Yield>10</Yield>
	</Row>
	<Row>
		<BuildingType>BUILDING_MARKET</BuildingType>
		<YieldType>YIELD_GOLD</YieldType>
		<Yield>25</Yield>
	</Row>
	<Row>
		<BuildingType>BUILDING_UNIVERSITY</BuildingType>
		<YieldType>YIELD_SCIENCE</YieldType>
		<Yield>33</Yield>
	</Row>
</Building_YieldModifiers>

NEGATIVE NUMBERS MODIFIER TABLES

Negative numbers in Modifier tables are also sometimes appropriate, and will have a decreasing effect. As an example of this, the Big Ben world wonder adjusts the costs of gold purchasing in cities by -15%. It does this through an entry in the <Building_HurryModifiers> table. Here is the actual entry from that table for the Big Ben World Wonder:

Code:

<Building_HurryModifiers>
	<Row>
		<BuildingType>BUILDING_BIG_BEN</BuildingType>
		<HurryType>HURRY_GOLD</HurryType>
		<HurryCostModifier>-15</HurryCostModifier>
	</Row>
</Building_HurryModifiers>

Since <Building_HurryModifiers> is a MODIFIER table, it adjusts "Hurrying" by a percentage of whatever HurryType is stated. In practical terms, this table can only really be used to adjust the gold costs of purchasing in cities, but it is still a Modifier-type table. The adjustment percentage is being made against the cost of hurrying (gold purchasing), and since all cities already have hurrying (gold purchasing) costs, there actually is an EXISTING condition to be modified. The fact that you as the player don't have enough gold in your treasury to buy something at any given point in time doesn't matter, since what is actually being adjusted is the amount of gold you NEED TO HAVE in your treasury to purchase something.

[[I don't really like my definition of "CHANGES tables".]]
[[need to re-think how to explain it.]]

CHANGES Tables

Changes tables make a direct change to something, and are generally Yield-Changing tables. A Yield of "1" in such a table DIRECTLY ADDS "1" total yield of whatever YieldType has been specified. It does not matter whether or not the XML for a building already includes an amount of the Yield, these types of tables will add more of an existing yield, or they will add an entirely new kind of yield, in the total amount specified.

.........................................................................................................................................................................

BUILDING YIELD MODIFIERS TABLE

The <Building_YieldModifiers> table is used to modify yields such as FOOD and GOLD, and affects only the city where the building is constructed. The modification is a percentage change to the total yield occuring in the city. The modifier adjusts city-level yields directly, and so only shows in the "city yields box" when a player mouses-over a type of yield within the city-yields box.

Appropriate Buildings:

Entries to this table are open-ended in terms of which sort of building an entry is appropriate to. This table was probably "intended" by FIRAXIS only to be used with "regular" buildings, but World and National wonder entries should not have an imbalancing effect on game-play. Remember that this table only effects the city that constructed the building.

Table Commands:

BuildingType

Specifies the building that will make the modification occur.

YieldType

Specifies the type of yield to be modified

Yield

Specifies the amount of modification as a PERCENTAGE

Yield Types that work with this table are:

YIELD_FOOD
YIELD_GOLD
YIELD_PRODUCTION
YIELD_SCIENCE

Yield Types that DO NOT work with this table are:

YIELD_CULTURE *
YIELD_FAITH
YIELD_TOURISM

* use the CultureRateModifier command in the <Buildings> table instead.

EXAMPLES for the <Building_YieldModifiers> table:

Here are some examples of Yield Modifiers taken from the "Building_YieldModifiers" table and repeated here EXACTLY as they are included in the FIRAXIS-supplied XML.
The entries in this table are for Floating Gardens, Workshop, Market, and University. The entries in this table show how the Floating Gardens adjusts FOOD by +15%, the Workshop adjusts PRODUCTION by +10%, the Market adjusts GOLD by +25%, and the University adjusts SCIENCE by +33% in the city.

Code:

<Building_YieldModifiers>
	<Row>
		<BuildingType>BUILDING_FLOATING_GARDENS</BuildingType>
		<YieldType>YIELD_FOOD</YieldType>
		<Yield>15</Yield>
	</Row>
	<Row>
		<BuildingType>BUILDING_WORKSHOP</BuildingType>
		<YieldType>YIELD_PRODUCTION</YieldType>
		<Yield>10</Yield>
	</Row>
	<Row>
		<BuildingType>BUILDING_MARKET</BuildingType>
		<YieldType>YIELD_GOLD</YieldType>
		<Yield>25</Yield>
	</Row>
	<Row>
		<BuildingType>BUILDING_UNIVERSITY</BuildingType>
		<YieldType>YIELD_SCIENCE</YieldType>
		<Yield>33</Yield>
	</Row>
</Building_YieldModifiers>

.........................................................................................................................................................................

BUILDING GLOBAL YIELD MODIFIERS TABLE

The <Building_GlobalYieldModifiers> table is used to modify yields such as FOOD and GOLD, but the effects are empire-wide, affecting every city. The modification is a percentage change to the total yield occuring in cities. The modifier adjusts city-level yields directly, and so only shows in the "city yields box" when a player mouses-over a type of yield within the city-yields box.

Appropriate Buildings:

Entries to this table should be limited to World or National wonders, since the table has such a wide-ranging effect.

Table Commands:

BuildingType

Specifies the building that will make the modification occur.

YieldType

Specifies the type of yield to be modified

Yield

Specifies the amount of modification as a PERCENTAGE.

Yield Types that work with this table are:

YIELD_FOOD
YIELD_GOLD
YIELD_PRODUCTION
YIELD_SCIENCE

Yield Types that DO NOT work with this table are:

YIELD_FAITH
YIELD_TOURISM
YIELD_CULTURE *

* use the GlobalCultureRateModifier command in the <Buildings> table instead. Use of this command will have the exact same effect you are looking for as attempting to jam YIELD_CULTURE into the <Building_GlobalYieldModifiers> table.

EXAMPLE for the <Building_GlobalYieldModifiers> table:

Here is a properly-formatted example of the Building_GlobalYieldModifiers table. This is the EXACT entry used in the FIRAXIS-supplied XML for the Temple of Artemis world wonder. It boosts FOOD yields in all cities by 10%.

Code:

<Building_GlobalYieldModifiers>
	<Row>
		<BuildingType>BUILDING_TEMPLE_ARTEMIS</BuildingType>
		<YieldType>YIELD_FOOD</YieldType>
		<Yield>10</Yield>
	</Row>
</Building_GlobalYieldModifiers>

.........................................................................................................................................................................

AREA YIELD MODIFIERS TABLE

The <Building_AreaYieldModifiers> table is used to affect city yield-totals in multiple cities within an "area". The modifier adjusts city-level yields directly, and so only shows in the "city yields box" under "Area Modifiers" when a player mouses-over a type of yield within the city-yields box.

GOLD, PRODUCTION, and SCIENCE yields show a direct and mathematically-obvious change based on the modifier-amount, but with FOOD (as always) it is a little more difficult to determine whether there is "really" a modification occuring, although mousing-over FOOD does show that a modification is being made.

Appropriate Buildings:

entries to this table should be limited to World or National wonders, since the table has such a wide-ranging effect.

Commands for the table:

BuildingType

Specifies the building that will make the modification occur.

YieldType

specifies the type of yield to be modified

Yield

Specifies the amount of modification as a PERCENTAGE.

Yield Types that work with this table are:

YIELD_FOOD
YIELD_GOLD
YIELD_PRODUCTION
YIELD_SCIENCE

Yield Types that DO NOT work with this table are:

YIELD_FAITH
YIELD_TOURISM
YIELD_CULTURE

use the CultureRateModifier command or the GlobalCultureRateModifier command in the <Buildings> table instead. Neither of these commands works for culture exactly as the <Building_AreaYieldModifiers> table does for the other yields; GlobalCultureRateModifier will be the closest approximate command for creating a similar effect for culture yields.

EXAMPLES for the <Building_AreaYieldModifiers> table:

Here is a properly-formatted example of the Building_AreaYieldModifiers table. For the purposes of the example, I am showing a new world wonder called "BUILDING_GIANT_REFRIDGERATOR", the primary effect of which would be to bump FOOD yields in any city located within the "continental area" by 10%.

Code:

<Building_AreaYieldModifiers>
	<Row>
		<BuildingType>BUILDING_GIANT_REFRIDGERATOR</BuildingType>
		<YieldType>YIELD_FOOD</YieldType>
		<Yield>10</Yield>
	</Row>
</Building_AreaYieldModifiers>

NOTE ON THE AFFECTED "AREA":

The "Area" affected by this modifier is any city on the same continent. I assume the "area" will be the same island-mass when playing on Archipelago-style maps, but since I don't generally play on those, I haven't tested if there is any difference in the way the "area" function works.

.........................................................................................................................................................................

HURRY MODIFIERS TABLE

The <Building_HurryModifiers> table is used to modifying the costs of hurrying empire-wide. In practical terms, this table was added to the XML to allow the BIG BEN world wonder to adjust gold purchasing costs in ALL cities by -15%.

Use of this table should be limited to World or National Wonders.

Table Commands:

BuildingType

Specifies the building that will make the modification occur.

HurryType

Specifies the type of "hurrying". There are only two kinds of "hurrying" defined in the game XML, HURRY_POPULATION and HURRY_GOLD. HURRY_GOLD refers to gold purchasing in cities. I have ABSOLUTELY NO IDEA how HURRY_POPULATION would be used.

ONLY USE "HURRY_GOLD" IN YOUR BUILDING MODS !!

"HURRY INFOS" REFERENCE:

"Hurry Infos" are defined in the file "CIV5HurryInfos.XML", located in the "GameInfo" folder of the ORIGINAL (Vanilla) Civilization5 XML. On my Windows8 computer, the full folder-path address for this "GameInfo" folder is:

C:\Program Files (x86)\Steam\SteamApps\common\Sid Meier's Civilization V\assets\Gameplay\XML\GameInfo

HurryCostModifier

Specifies the percentage-change to the "hurrying" cost.

EXAMPLE OF USE

Here is the actual entry from the <Building_HurryModifiers> table for the Big Ben World Wonder:

Code:

<Building_HurryModifiers>
	<Row>
		<BuildingType>BUILDING_BIG_BEN</BuildingType>
		<HurryType>HURRY_GOLD</HurryType>
		<HurryCostModifier>-15</HurryCostModifier>
	</Row>
</Building_HurryModifiers>

The Big Ben world wonder LOWERS the cost of gold-purchasing in cities by 15%. The entry in this table is how the FIRAXIS-supplied XML accomplishes this effect. The minus sign in this case is critical. Without it, Big Ben would INCREASE the costs of gold purchasing.

LeeS · May 2, 2014

BUILDING YIELD CHANGES TABLE

The <Building_YieldChanges> table is used to DIRECTLY-ATTACH yields to a building as an inherent property of the building itself. This table does not have ANY effect on tiles surrounding the city where a building is constructed. Any type of building is appropriate for an entry in this table: "regular" buildings, National Wonders, and World Wonders.

Table Commands:

BuildingType

Specifies the building to which a yield is about to be added.

YieldType

Specifies the type of yield to be added.

Yield

Specifies the total yield amount that will be added. This is entered as a WHOLE NUMBER, and is usually POSITIVE. Negative numbers would subtract yield.

Yield Types that work with this table are:

YIELD_FOOD
YIELD_GOLD
YIELD_PRODUCTION
YIELD_SCIENCE
YIELD_CULTURE
YIELD_FAITH

TOURISM cannot be used with this table.

Examples:

Here are some properly-formatted examples for the "Building_YieldChanges" table. For the purposes of the example, I am using a new world wonder called BUILDING_GIANT_REFRIDGERATOR to show adding one (1) yield of every appropriate YieldType for this table.

(click on the Spoiler button to see the example)

Spoiler :

Even though there would not have been any total amount of "yield" for any of the YieldTypes shown before the game "read-in" this table, these are still "changes" to the amount of yields the building generates. Zero (0) total yield of something (such as YIELD_CULTURE) is still a "yield amount", so this table still "changes" what was there before.

Keep in mind that this table ADDS the specified number of the specified yield type. Minus (-) signs in the yield amount will subtract the specified yield amount from the city totals. Using a negative yield amount in this table gives the desired effect in terms of gameplay, but when the player mouses-over a building to see its yields the game will show +- 1 FOOD instead of - 1 FOOD. This is a hard-coded limitation to the game.

........................................................................................................

BUILDING-CONTROLLED SPECIALIST YIELD CHANGES TABLE

The <Building_SpecialistYieldChanges> table is used to change the yields that CITIZEN-SPECIALISTS normally produce. These are the "specialists" that fit into the "specialist slots" for buildings such as the Workshop and the University.
This table is a global effects table. Any entry in this table will affect Specialists throughout a player's empire, and should be limited to National and World wonders.

Table Commands:

BuildingType

Specifies the building that will affect CITIZEN-SPECIALIST yields

SpecialistType

Specifies the type of CITIZEN-SPECIALIST that will be affected.
You must pick ONLY ONE of the following TYPES of SPECIALISTS for each entry in the table:

SPECIALIST_CITIZEN *
SPECIALIST_SCIENTIST
SPECIALIST_MERCHANT
SPECIALIST_ENGINEER
SPECIALIST_WRITER
SPECIALIST_ARTIST
SPECIALIST_MUSICIAN

* SPECIALIST_CITIZEN is the XML designation for unemployed citizens.

YieldType

Specifies the Type of Yield to be added to what a citizen-specialist generates.

Yield Types that work with this table are:

YIELD_GOLD
YIELD_PRODUCTION**
YIELD_SCIENCE
YIELD_FOOD

** Changes through this table to the YIELD_PRODUCTION of unemployed citizens (SPECIALIST_CITIZEN) actually have no effect. The +1 Production they give is hard-coded. Not even the Statue of Liberty World Wonder added by Firaxis actually has any effect on this.

Yield Types that DO NOT work with this table are:

YIELD_CULTURE
YIELD_FAITH

It may appear that Culture and Faith work with this table. Mousing over a specialist-type that has been enhanced with Culture or Faith under this table will show the change in yields. However, neither the city yields box nor the empire-level "yields" reflect any change to Specialist Culture or Faith yields. In order for a yield to have any effect on the game, the changes in yields must "make it" to the city yields box.

Yield

Specifies the amount of the yield change that will occur.

EXAMPLE OF USE

The Statue of Liberty world wonder adds +1 PRODUCTION to CITIZEN, ARTIST, SCIENTIST, MERCHANT, and ENGINEER specialists. Here is the actual entry of the <Building_SpecialistYieldChanges> table for the Statue of Liberty World Wonder:

(click on the Spoiler button to see the example)

Spoiler :

......................................................................................................

BUILDING YIELD CHANGES PER POPULATION TABLE

The <Building_YieldChangesPerPop> table is used to add yields to the city based on city population. The yield additions show up in the "city yields box".
Yield is specified as a PERCENTAGE of ONE (1) yield per population, per turn.
The table DOES NOT modify TOTAL yield by a percentage based upon population.
This table is appropriate for all buildings, in the sense that adding an entry under the table for a building only has an effect in the city where the building is constructed. Libraries, Public Schools, and Paper Makers all use this table.
National and World wonders can also use this table so long as the entry amount made for "Yield" is not ridiculously high.

BuildingType

Specifies the building that will add a yield to the city.

YieldType

Specifies the type of yield to be added.

Yield Types that work with this table are:

YIELD_FOOD
YIELD_GOLD
YIELD_PRODUCTION
YIELD_SCIENCE

TOURISM, FAITH, and CULTURE cannot be used with this table.
There is a mod called "India Civilization Pack" available on the steam workshop that has an LUA file to allow for use of FAITH with this table. If you want to use FAITH in this table in your mod, you could ask for permission from the authors of that mod to use their LUA.

Yield

Specifies the percentage of a SINGLE YIELD to be added per population. Entries for "Yield" should be positive whole numbers, and should be on the order of "10", "25", "50", etc., and not on the order of "1", "2", "3".

EXAMPLE OF USE

The Library adds +1 SCIENCE for every two (2) citizens. It does so by an entry of "50" in the Yield command under this table. Here is the entry for this table as is used for the Library building:

Code:

<Building_YieldChangesPerPop>
	<Row>
		<BuildingType>BUILDING_LIBRARY</BuildingType>
		<YieldType>YIELD_SCIENCE</YieldType>
		<Yield>50</Yield>
	</Row>
</Building_YieldChangesPerPop>

If I wanted to change the Library building to not only give its SCIENCE benefit, but to also add one (1) PRODUCTION for every four (4) citizens in a city, I would alter the table as follows:

Code:

<Building_YieldChangesPerPop>
	<Row>
		<BuildingType>BUILDING_LIBRARY</BuildingType>
		<YieldType>YIELD_SCIENCE</YieldType>
		<Yield>50</Yield>
	</Row>
	<Row>
		<BuildingType>BUILDING_LIBRARY</BuildingType>
		<YieldType>YIELD_PRODUCTION</YieldType>
		<Yield>25</Yield>
	</Row>
</Building_YieldChangesPerPop>

If I also wanted to make the "BUILDING_GIANT_REFRIDGERATOR" add one (1) FOOD to the city for every citizen in the city, this would be rather over-powered, but I could do it, and I would alter the <Building_YieldChangesPerPop> table as shown:

Code:

<Building_YieldChangesPerPop>
	<Row>
		<BuildingType>BUILDING_LIBRARY</BuildingType>
		<YieldType>YIELD_SCIENCE</YieldType>
		<Yield>50</Yield>
	</Row>
	<Row>
		<BuildingType>BUILDING_LIBRARY</BuildingType>
		<YieldType>YIELD_PRODUCTION</YieldType>
		<Yield>25</Yield>
	</Row>
	<Row>
		<BuildingType>BUILDING_GIANT_REFRIDGERATOR</BuildingType>
		<YieldType>YIELD_FOOD</YieldType>
		<Yield>100</Yield>
	</Row>
</Building_YieldChangesPerPop>

Remember that the BUILDING_GIANT_REFRIDGERATOR is a fictitious world wonder I have been using in various examples within this tutorial.

..........................................................................................................

BUILDING-CLASS YIELD CHANGES TABLE

The <Building_BuildingClassYieldChanges> table is used to allow the construction of a world wonder to alter the "yield effects" of a "regular" building. The effects are global in that they occur for every city in an empire, but they are also limited because the "regular" building must exist in an individual city for there to be any effect in that city.

The use of this table should be reserved to National or World Wonders only. In the commentary that follows I have referred therefore to a Wonder as being the type of "building" that creates the new effects.

You can also use this table to make the construction of a world wonder affect the yields of another world wonder or a national wonder. The game does not really care which building class is entered for BuildingClassType, but you should probably not as a general rule cause World Wonder A to change the effects of World Wonder B. There is at least one world wonder mod available on the Steam Workshop that uses this table to change the effects of the PALACE.

Table Commands:

BuildingType

Specifies the Wonder that will change the yield effects of a regular-type building.

BuildingClassType

Specifies the CLASS of regular building that will be affected by construction of the Wonder stated in BuildingType.

YieldType

Specifies the type of Yield that will be changed or added.

Yield Types that work with this table are:

YIELD_GOLD
YIELD_PRODUCTION
YIELD_SCIENCE
YIELD_CULTURE
YIELD_FOOD
YIELD_FAITH

Niether Tourism nor Happiness can be used in this table.

YieldChange

Specifies the amount of change for the yield type stated in YieldType.

EXAMPLE OF USE

The Neuschwanstein world wonder adds +3 GOLD and +2 CULTURE to every CASTLE-CLASS building in a player's empire. Since "BUILDINGCLASS_CASTLE" must be specfied in this table instead of simply "BUILDING_CASTLE", both CASTLES and MUGHAL FORTS are elligable to recieve the Neuschwanstein world wonder benefits.

Here is the entry in the "<Building_BuildingClassYieldChanges>" table for the Neuschwanstein World Wonder:

Code:

<Building_BuildingClassYieldChanges>
	<Row>
		<BuildingType>BUILDING_NEUSCHWANSTEIN</BuildingType>
		<BuildingClassType>BUILDINGCLASS_CASTLE</BuildingClassType>
		<YieldType>YIELD_GOLD</YieldType>
		<YieldChange>3</YieldChange>
	</Row>
	<Row>
		<BuildingType>BUILDING_NEUSCHWANSTEIN</BuildingType>
		<BuildingClassType>BUILDINGCLASS_CASTLE</BuildingClassType>
		<YieldType>YIELD_CULTURE</YieldType>
		<YieldChange>2</YieldChange>
	</Row>
</Building_BuildingClassYieldChanges>

.........................................................................................................................

BUILDING-CLASS HAPPINESS CHANGES TABLE

The <Building_BuildingClassHappiness> table is used to make a world wonder add happiness to a regular building. Either World or National Wonders would be appropriate to use with this table. In the commentary that follows I have referred therefore to a Wonder as being the type of "building" that creates the new effects.

You can also use this table to make the construction of a world wonder affect the happiness yield of another world wonder or a national wonder. The game does not really care which building class is entered for BuildingClassType, but you should probably not as a general rule cause World Wonder A to change the effects of World Wonder B.

Table Commands:

BuildingType

Specifies the wonder that will add happiness to a regular building.

BuildingClassType

Specifies the CLASS of building for which happiness will be added. Building CLASS is used so that a civilization's unique replacement building will also qualify for the happiness increase.

Happiness

Specifies the amount of happiness to be added.

EXAMPLE OF USE:

The Neuschwanstein world wonder adds +1 HAPPINESS to every CASTLE-CLASS building in a player's empire. Since "BUILDINGCLASS_CASTLE" must be specfied in this table instead of simply "BUILDING_CASTLE", both CASTLES and MUGHAL FORTS are elligable to recieve the Neuschwanstein world wonder HAPPINESS benefit.

Here is the entry in the <Building_BuildingClassHappiness> table for the Neuschwanstein World Wonder:

Code:

<Building_BuildingClassHappiness>
	<Row>
		<BuildingType>BUILDING_NEUSCHWANSTEIN</BuildingType>
		<BuildingClassType>BUILDINGCLASS_CASTLE</BuildingClassType>
		<Happiness>1</Happiness>
	</Row>
</Building_BuildingClassHappiness>

..........................................................................................................................

BUILDING YIELD CHANGES PER RELIGION TABLE

The <Building_YieldChangesPerReligion> table is used to add yields based upon the number of religions present in the city. The yields are added "to the building" as opposed to a tile or improvement surrounding the city. The yield specified is added once for EVERY religion that has at least one (1) follower in the city.

In the FIRAXIS-supplied XML, the CANDI building uses this table to add +2 Faith for every religion present in the city.

This table would be appropriate for any building, national wonder, or world wonder, so long as the entries under this table do not state ridiculously high yield amounts.

Table Commands:

BuildingType

Specifies the building for which yields will be added.

YieldType

Specifies the type of yield that will be added.

Yield

Specifies the amount of yield that will be added. Note that this table uses a different numerical format for "Yield" than the norm. "200" translates to "2".

EXAMPLE OF USE:

Here is the table as used by FIRAXIS for the Candi building:

Code:

<Building_YieldChangesPerReligion>
	<Row>
		<BuildingType>BUILDING_CANDI</BuildingType>
		<YieldType>YIELD_FAITH</YieldType>
		<Yield>200</Yield>
	</Row>
</Building_YieldChangesPerReligion>

NOTE:

I have not experimented with this table as yet, and can not say one way or the other whether YieldTypes other than Faith can be used.

LeeS · May 2, 2014

RIVER PLOT YIELD CHANGES TABLE

The <Building_RiverPlotYieldChanges> table is used to change plot yields along rivers. Since map tiles, or "plots", are always located on one side of a river instead of having the river run through the "middle" of the tile, any tile inside the working radius of a city that is also located NEXT TO a river will be affected by entries in this table. Buildings that have an entry in this table will affect any and all "river plots" within the working radius of the city where the building is constructed.

In order for entries in this table to have any effect on yields for a particular tile, the following conditions must all be met:

The Building that adds the yields must 1st be constructed in the city.
The tile must be within the cultural borders of the empire.
The tile must be worked by a citizen of the city. This also requires that the tile is within a range of three tiles of the city.
The tile must be NEXT TO a river.

Table Commands:

BuildingType

Specifies the building that creates the yield change on river plots.

YieldType

Specifies the type of yield that will be added.

Allowed Yield Types:

YIELD_GOLD
YIELD_PRODUCTION
YIELD_SCIENCE
YIELD_CULTURE
YIELD_FOOD
YIELD_FAITH

"TOURISM" cannot be stated as a yield-type in this table.

Yield

Specifies the amount of yield that will be added.

Appropriate buildings:

"Regular" buildings, National Wonders, and World Wonders would all be appropriate for this table, as the effects are local to the city.

ADDITIONAL NOTES ON THE TABLE:

Generally, you will want to require the city be built along a river if you have an entry for your building under this table, but it is not strictly required. Any city that has a map-tile qualifying as a "river tile" can be affected by this table, even if the city itself is not located along a river.
If you only want your building to be available to river cities, you will have to have the <River>true</River> command in your building under the <Buildings> table. You might also use the <FreshWater>true</FreshWater> command, which requires the city to be built along a river or next to a lake.

EXAMPLE OF USE:

If I wanted my fictitious world wonder the BUILDING_GIANT_REFRIDGERATOR to add one (1) GOLD and one (1) FAITH to river tiles, my entry for the <Building_RiverPlotYieldChanges> table would look like the following:

Code:

<Building_RiverPlotYieldChanges>
	<Row>
		<BuildingType>BUILDING_GIANT_REFRIDGERATOR</BuildingType>
		<YieldType>YIELD_GOLD</YieldType>
		<Yield>1</Yield>
	</Row>
	<Row>
		<BuildingType>BUILDING_GIANT_REFRIDGERATOR</BuildingType>
		<YieldType>YIELD_FAITH</YieldType>
		<Yield>1</Yield>
	</Row>
</Building_RiverPlotYieldChanges>

Remember that the effects are local to the city where the building (or wonder) is constructed, so the table entries would only have an effect on river tiles around the city where the Giant Refridgerator was built.

......................................................................................................................................................................

SEA PLOT YIELD CHANGES TABLE

The <Building_SeaPlotYieldChanges> table is used to change plot yields for coast AND ocean tiles. It does not matter whether an individual tile has a sea resource on it (such as FISH). When a building that has an entry in this table is constructed in a city, all coast and ocean plots are affected by the changes shown in this table.

Although you would normally limit this table to buildings that also have the coastal "water" requirement, it is not strictly required. Any building that has entries in this table will immediately begin to affect coastal and ocean plots within the city radius as soon as the building is constructed, whether or not the city itself is built along a coastline.

In order for entries in this table to have any effect on yields for a particular tile, the following conditions must all be met:

The Building that adds the yields must 1st be constructed in the city.
The tile must be within the cultural borders of the empire.
The tile must be worked by a citizen of the city. This also requires that the tile is within a range of three tiles of the city.
The tile must be a COAST or OCEAN tile.

Table Commands:

BuildingType

Specifies the building that creates the yield change on sea plots.

YieldType

Specifies the type of yield that will be added.

Any of the following yield-types can be used with this table:

YIELD_GOLD
YIELD_PRODUCTION
YIELD_SCIENCE
YIELD_CULTURE
YIELD_FOOD
YIELD_FAITH

"TOURISM" cannot be stated as a yield-type in this table.

Yield

Specifies the amount of yield that will be added.

Appropriate buildings:

"Regular" buildings, National Wonders, and World Wonders would all be appropriate for this table, as the effects are local to the city.

ADDITIONAL NOTES ON THE TABLE:

If you only want your building to be available to coastal cities, you will have to have the <Water>true</Water> command for your building under the <Buildings> table.

EXAMPLE OF USE:

If I wanted my fictitious world wonder the BUILDING_GIANT_REFRIDGERATOR to add one (1) FOOD and one (1) PRODUCTION to coast and ocean tiles, my entry for the <Building_SeaPlotYieldChanges> table would look like the following:

Code:

<Building_SeaPlotYieldChanges>
	<Row>
		<BuildingType>BUILDING_GIANT_REFRIDGERATOR</BuildingType>
		<YieldType>YIELD_PRODUCTION</YieldType>
		<Yield>1</Yield>
	</Row>
	<Row>
		<BuildingType>BUILDING_GIANT_REFRIDGERATOR</BuildingType>
		<YieldType>YIELD_FOOD</YieldType>
		<Yield>1</Yield>
	</Row>
</Building_SeaPlotYieldChanges>

.............................................................................................................................................................

LAKE PLOT YIELD CHANGES TABLE

The <Building_LakePlotYieldChanges> table is used to change plot yields for lake tiles.

Although you would normally limit this table to buildings in cities that are next to lakes, it is not strictly required. Any building that has entries in this table will immediately begin to affect lake plots within the city radius as soon as the building is constructed, whether or not the city itself is built next to a lake.

In order for entries in this table to have any effect on yields for a particular tile, the following conditions must all be met:

The Building that adds the yields must 1st be constructed in the city.
The tile must be within the cultural borders of the empire.
The tile must be worked by a citizen of the city. This also requires that the tile is within a range of three tiles of the city.
The tile must be a LAKE tile.

Table Commands:

BuildingType

Specifies the building that creates the yield change on lake plots.

YieldType

Specifies the type of yield that will be added.

Any of the following yield-types can be used with this table:

YIELD_GOLD
YIELD_PRODUCTION
YIELD_SCIENCE
YIELD_CULTURE
YIELD_FOOD
YIELD_FAITH

"TOURISM" cannot be stated as a yield-type in this table.

Yield

Specifies the amount of yield that will be added.

Appropriate buildings:

"Regular" buildings, National Wonders, and World Wonders would all be appropriate for this table, as the effects are local to the city.

ADDITIONAL NOTES ON THE TABLE:

Generally, you will want to require the city be built along a river or next to a lake if you have an entry for your building under this table, but it is not strictly required. Any city that has a map-tile qualifying as a "lake tile" can be affected by this table, even if the city itself is not located next to a lake.

If you only want your building to be available to lake and river cities, you will have to have the <FreshWater>true</FreshWater> command in your building under the <Buildings> table. Remember the <FreshWater>true</FreshWater> command requires the city to be built next to a lake OR along a river. There is no command that specfies adjacency ONLY to a lake.

EXAMPLE OF USE:

If I wanted my fictitious world wonder the BUILDING_GIANT_REFRIDGERATOR to add one (1) of every type of yield available under this table, my entry for the <Building_LakePlotYieldChanges> table would look like the following:

(click on the Spoiler button to see the example)

Spoiler :

Any lake tile within the working range of the city would be effected by the entries to this table. If there were NO lake tiles present within the working range of the city, the entries in this table would still be "valid" so far as the game software would be concerned, but nothing would happen within the play-through of that particular game, since one of the conditions for the changes to take effect would not be satisfied.

.....................................................................................................................................................................

SEA RESOURCE YIELD CHANGES TABLE

The <Building_SeaResourceYieldChanges> table is used to change plot yields on coast or ocean tiles that contain a sea resource. Any of the resources (Fish, Whales, Pearls, Crab, Oil) allow the yield change to occur. You do not specify an individual type of resource (such as Whales) in this table.

Although you would normally limit this table to buildings that also have the coastal "water" requirement, it is not strictly required.

In order for entries in this table to have any effect on yields for a particular tile, the following conditions must all be met:

The Building that adds the yields must 1st be constructed in the city.
The tile must be within the cultural borders of the empire.
The tile must be worked by a citizen of the city. This also requires that the tile is within a range of three tiles of the city.
The tile must be a COAST or OCEAN tile.
The tile must contain a sea RESOURCE.

Table Commands:

BuildingType

Specifies the building that creates the yield change on sea resource plots.

YieldType

Specifies the type of yield that will be added.

Any of the following yield-types can be used with this table:
YIELD_GOLD
YIELD_PRODUCTION
YIELD_SCIENCE
YIELD_CULTURE
YIELD_FOOD
YIELD_FAITH

"TOURISM" cannot be stated as a yield-type in this table.

Yield

Specifies the amount of yield that will be added.

Appropriate buildings:

"Regular" buildings, National Wonders, and World Wonders would all be appropriate for this table, as the effects are local to the city.

ADDITIONAL NOTES ON THE TABLE:

You should generally limit your building to be available to coastal cities, so you will want to have the <Water>true</Water> command for your building under the <Buildings> table.

EXAMPLE OF USE:

Here is the actual FIRAXIS-supplied game XML for this table showing how the Seaport building adds +1 PRODUCTION and GOLD to sea resources, and the Lighthouse building adds +1 PRODUCTION to sea resources:

Code:

<Building_SeaResourceYieldChanges>
	<Row>
		<BuildingType>BUILDING_SEAPORT</BuildingType>
		<YieldType>YIELD_PRODUCTION</YieldType>
		<Yield>1</Yield>
	</Row>
	<Row>
		<BuildingType>BUILDING_SEAPORT</BuildingType>
		<YieldType>YIELD_GOLD</YieldType>
		<Yield>1</Yield>
	</Row>
	<Row>
		<BuildingType>BUILDING_LIGHTHOUSE</BuildingType>
		<YieldType>YIELD_PRODUCTION</YieldType>
		<Yield>1</Yield>
	</Row>
</Building_SeaResourceYieldChanges>

........................................................................................................................................................................

FEATURE YIELD CHANGES TABLE

The <Building_FeatureYieldChanges> table is used to add yields to tiles surrounding a city based upon the types of terrain FEATURES located within the city working radius.

In order for entries in this table to have any effect on yields for a particular tile, the following conditions must all be met:

The Building that adds the yields must 1st be constructed in the city.
The tile must be within the cultural borders of the empire.
The tile must be worked by a citizen of the city. This also requires that the tile is within a range of three tiles of the city.
The tile must have the type of FEATURE specified.

Table Commands:

BuildingType

Specifies the building that will add yields to tiles with the appropriate feature(s).

FeatureType

Specifies the type of terrain FEATURE that will be affected.

Any of the following "normal" feature-types can be used with this table:

FEATURE_JUNGLE
FEATURE_FOREST
FEATURE_OASIS
FEATURE_FLOOD_PLAINS
FEATURE_MARSH
FEATURE_ATOLL

YieldType

Specifies the type of yield that will be added to the tile.

Any of the following yield-types can be used with this table:

YIELD_GOLD
YIELD_PRODUCTION
YIELD_SCIENCE
YIELD_CULTURE
YIELD_FOOD
YIELD_FAITH

"TOURISM" cannot be stated as a yield-type in this table.

Yield

Specifies the amount of the yield that will be added.

Appropriate buildings:

"Regular" buildings, National Wonders, and World Wonders would all be appropriate for this table, as the effects are local to the city.

ADDITIONAL NOTES ON THE TABLE:

Any of the natural wonders are also considered "Features" within the game XML, and can be used in this table.

(click on the spoiler button to see the list)

Spoiler :

Just as for "normal" features, entries to the <Building_FeatureYieldChanges> table with Natural Wonder "features" will only have an effect if the natural wonder happens to be within the working range of the city that constructs the building or wonder. There is no way (via XML) to require that a feature is within the working range of the city before a particular Wonder or Building can be constructed. Trying to jam the name of a natural wonder "feature" into one of the terrain requirements commands of the <Buildings> table will not work.

EXAMPLE OF USE:

The following example of the <Building_FeatureYieldChanges> table is taken directly from the FIRAXIS-supplied XML, and shows how the University, Wat, Longhouse, and Bazaar buildings all add yields to feature plots within the city radius where the buildings are constructed.

University Jungle +2 Science
Wat Jungle +2 Science
Longhouse Forest +1 Production
Bazaar Oasis +2 Gold

(click on the spoiler button to see the example)

Spoiler :

YIELDS SUBTRACTION

The Petra World Wonder actually uses this table to SUBTRACT yields based on feature-type. This is done to achieve the Petra's Effect of adding +1 FOOD and +1 PRODUCTION to all desert tiles EXCEPT Flood Plains. Elsewhere in the XML, the Petra World Wonder adds the FOOD and PRODUCTION bumps to ALL DESERT TILES, which INCLUDES Flood Plains. So, entries are made for the Petra World Wonder to "subtract back out" the yield bumps from Flood Plain tiles. Here are the entries in the <Building_FeatureYieldChanges> table used for the Petra World Wonder:

Code:

<Building_FeatureYieldChanges>
	<Row>
		<BuildingType>BUILDING_PETRA</BuildingType>
		<FeatureType>FEATURE_FLOOD_PLAINS</FeatureType>
		<YieldType>YIELD_FOOD</YieldType>
		<Yield>[B][COLOR="Red"]-1[/COLOR][/B]</Yield>
	</Row>
	<Row>
		<BuildingType>BUILDING_PETRA</BuildingType>
		<FeatureType>FEATURE_FLOOD_PLAINS</FeatureType>
		<YieldType>YIELD_PRODUCTION</YieldType>
		<Yield>[B][COLOR="Red"]-1[/COLOR][/B]</Yield>
	</Row>
</Building_FeatureYieldChanges>

I have usually phrased changes to yield tables as "additions", but stating negative numbers in the Yield command field of any table will accomplish a subtraction of yield.

...............................................................................................................................................................

TERRAIN YIELD CHANGES TABLE

The <Building_TerrainYieldChanges> table is used to add yields to tiles surrounding a city based upon the types of TERRAINS located within the city working radius.

In order for entries in this table to have any effect on yields for a particular tile, the following conditions must all be met:

The Building that adds the yields must 1st be constructed in the city.
The tile must be within the cultural borders of the empire.
The tile must be worked by a citizen of the city. This also requires that the tile is within a range of three tiles of the city.
The tile must have the type of TERRAIN specified.

Table Commands:

BuildingType

Specifies the building that will add yields to tiles with the appropriate TERRAIN.

TerrainType

Specifies the type of TERRAIN that will be affected.

Any of the following terrain specifications will work for "TerrainType":

TERRAIN_GRASS grasslands tiles, whether flatlands or hills
TERRAIN_PLAINS plains tiles, whether flatlands or hills
TERRAIN_DESERT desert tiles, whether flatlands or hills
TERRAIN_TUNDRA tundra tiles, whether flatlands or hills
TERRAIN_SNOW snowy waste tiles, whether flatlands or hills

You cannot specify "HILL" or "HILLS" as a "TerrainType". Although "TERRAIN_HILL" is a valid type of terrain listed in the "Terrains.XML" file, attempts to use it in this table have no effect. I have seen this attempted with at least one Gods & Kings Expansion World Wonder MOD, but the construction of that world wonder had no effect whatsoever on surrounding hill plots.

I haven't tried to jam "TERRAIN_COAST" or "TERRAIN_OCEAN" into this table, so they may actually work. If so, the need to do so would be rare since there is already a <Building_SeaPlotYieldChanges> table to use.

YieldType

Specifies the type of yield that will be added to the tile.

Any of the following yield-types can be used with this table:

YIELD_GOLD
YIELD_PRODUCTION
YIELD_SCIENCE
YIELD_CULTURE
YIELD_FOOD
YIELD_FAITH

"TOURISM" cannot be stated as a yield-type in this table.

Yield

Specifies the amount of the yield that will be added.

Appropriate buildings:

"Regular" buildings, National Wonders, and World Wonders would all be appropriate for this table, as the effects are local to the city.

ADDITIONAL NOTES ON THE TABLE:

You will usually want your building to be limited to construction in cities that are ON or NEARBY TO the type of terrain you are adding <Building_TerrainYieldChanges> entries for, so you should usually have an entry in the <Buildings> table for NearbyTerrainRequired that specifies the same type of terrain as you are naming in TerrainType under the <Building_TerrainYieldChanges> table. You do not HAVE TO make such a terrain-related restriction in the <Buildings> table, but your building will probably seem more focused and balanced AS A MOD ADDITION TO THE GAME when you do.

EXAMPLE OF USE:

I mentioned the Petra World Wonder in the comments on the previous XML-table, so I have used it here as the example of properly-formatted code for the <Building_TerrainYieldChanges> table. This is the code that bumps desert terrain tile yields by +1 Production and +1 Food:

Code:

<Building_TerrainYieldChanges>
	<Row>
		<BuildingType>BUILDING_PETRA</BuildingType>
		<TerrainType>TERRAIN_DESERT</TerrainType>
		<YieldType>YIELD_FOOD</YieldType>
		<Yield>1</Yield>
	</Row>
	<Row>
		<BuildingType>BUILDING_PETRA</BuildingType>
		<TerrainType>TERRAIN_DESERT</TerrainType>
		<YieldType>YIELD_PRODUCTION</YieldType>
		<Yield>1</Yield>
	</Row>
</Building_TerrainYieldChanges>

LeeS · May 2, 2014

RESOURCE YIELD CHANGES TABLE

The <Building_ResourceYieldChanges> table is used to allow a building to add yields to specific resources. Any resource is usually appropriate for use in this table EXCEPT the "special luxury" ones such as those that only can be given by city-states.

A tile improvement that connects the luxury, bonus, or resource to an empire's trade network, such as a pasture, is NOT required.

In order for entries in this table to have any effect on yields for a particular tile, the following conditions must all be met:

The Building that adds the yields must 1st be constructed in the city.
The tile must be within the cultural borders of the empire.
The tile must be worked by a citizen of the city. This also requires that the tile is within a range of three tiles of the city.
The tile must contain the resource specified within the individual building-entry in the table.

Table Commands:

BuildingType
Specifies the building that creates the yield change on resource plots.

ResourceType
Specifies the type of resource that will be affected.

YieldType

Specifies the type of yield that will be added or increased.
Any of the following yield-types can be used with this table:

YIELD_GOLD
YIELD_PRODUCTION
YIELD_SCIENCE
YIELD_CULTURE
YIELD_FOOD
YIELD_FAITH

"TOURISM" cannot be stated as a yield-type in this table.

Yield
Specifies the amount of the yield addition or increase.

Appropriate buildings:

"Regular" buildings, National Wonders, and World Wonders would all be appropriate for this table, as the effects are local to the city.

ADDITIONAL NOTES ON THE TABLE:

I have included a full listing of resources as they must appear in XML code within the file List_Resources.XML s o I will not list all of the resource names here. This link is to a mediafire file sharing address where you can either directly look at the file and then close it when done, or you can download it to your desktop.
There is no difference, from the point-of-view of using this table, between coastal-city buildings and inland-city buildings. Both will make use of this table to add yields to a specific type of resource.
Each and every copy of a resource within the working range of the city will be affected by entries to this table. So, if there is an entry for Cows, and there are three Cow resources within range of the city, all three will be affected by entries in this table for "RESOURCE_COW".

**Note that the XML uses "RESOURCE_COW" and NOT "RESOURCE_CATTLE".

EXAMPLE OF USE:

I have copied the most of the table as it is used in the FIRAXIS-supplied game XML. Click on the spoiler button to see the examples of how this table should look for various different buildings supplied by Firaxis, as well as different resources-types and yield-types.

Spoiler :

Code:

<Building_ResourceYieldChanges>
	<Row>
		<BuildingType>BUILDING_MINT</BuildingType>
		<ResourceType>RESOURCE_GOLD</ResourceType>
		<YieldType>YIELD_GOLD</YieldType>
		<Yield>2</Yield>
	</Row>
	<Row>
		<BuildingType>BUILDING_STABLE</BuildingType>
		<ResourceType>RESOURCE_COW</ResourceType>
		<YieldType>YIELD_PRODUCTION</YieldType>
		<Yield>1</Yield>
	</Row>
	<Row>
		<BuildingType>BUILDING_GRANARY</BuildingType>
		<ResourceType>RESOURCE_WHEAT</ResourceType>
		<YieldType>YIELD_FOOD</YieldType>
		<Yield>1</Yield>
	</Row>
	<Row>
		<BuildingType>BUILDING_GRANARY</BuildingType>
		<ResourceType>RESOURCE_BANANA</ResourceType>
		<YieldType>YIELD_FOOD</YieldType>
		<Yield>1</Yield>
	</Row>
	<Row>
		<BuildingType>BUILDING_STABLE</BuildingType>
		<ResourceType>RESOURCE_SHEEP</ResourceType>
		<YieldType>YIELD_PRODUCTION</YieldType>
		<Yield>1</Yield>
	</Row>
	<Row>
		<BuildingType>BUILDING_STABLE</BuildingType>
		<ResourceType>RESOURCE_HORSE</ResourceType>
		<YieldType>YIELD_PRODUCTION</YieldType>
		<Yield>1</Yield>
	</Row>
	<Row>
		<BuildingType>BUILDING_LIGHTHOUSE</BuildingType>
		<ResourceType>RESOURCE_FISH</ResourceType>
		<YieldType>YIELD_FOOD</YieldType>
		<Yield>1</Yield>
	</Row>
	<Row>
		<BuildingType>BUILDING_FORGE</BuildingType>
		<ResourceType>RESOURCE_IRON</ResourceType>
		<YieldType>YIELD_PRODUCTION</YieldType>
		<Yield>1</Yield>
	</Row>
	<Row>
		<BuildingType>BUILDING_STONE_WORKS</BuildingType>
		<ResourceType>RESOURCE_MARBLE</ResourceType>
		<YieldType>YIELD_PRODUCTION</YieldType>
		<Yield>1</Yield>
	</Row>
	<Row>
		<BuildingType>BUILDING_BAZAAR</BuildingType>
		<ResourceType>RESOURCE_OIL</ResourceType>
		<YieldType>YIELD_GOLD</YieldType>
		<Yield>2</Yield>
	</Row>
	<Row>
		<BuildingType>BUILDING_MONASTERY</BuildingType>
		<ResourceType>RESOURCE_INCENSE</ResourceType>
		<YieldType>YIELD_FAITH</YieldType>
		<Yield>1</Yield>
	</Row>
	<Row>
		<BuildingType>BUILDING_MONASTERY</BuildingType>
		<ResourceType>RESOURCE_WINE</ResourceType>
		<YieldType>YIELD_FAITH</YieldType>
		<Yield>1</Yield>
	</Row>
	<Row>
		<BuildingType>BUILDING_MONASTERY</BuildingType>
		<ResourceType>RESOURCE_INCENSE</ResourceType>
		<YieldType>YIELD_CULTURE</YieldType>
		<Yield>1</Yield>
	</Row>
	<Row>
		<BuildingType>BUILDING_MONASTERY</BuildingType>
		<ResourceType>RESOURCE_WINE</ResourceType>
		<YieldType>YIELD_CULTURE</YieldType>
		<Yield>1</Yield>
	</Row>
</Building_ResourceYieldChanges>

.....................................................................................................................................................................................................................................................

LOCAL RESOURCE "ANDS" TABLE

This is the first of two tables that set prerequisites to a building's construction based on the presence of resources around a city. The resource must be improved with the usual worker-unit-built improvement before the resource is considered to be "present", and the resource must be located within the workable-tiles range of the city, NOT just within its cultural borders.

The <Building_LocalResourceAnds> table is used to specify which resource(s) must be present in a city's vicinity before a building can be constructed. EVERY entry in this table must be "satisfied" before the building can be constructed or purchased. If you place two entries in this table for the same building, then BOTH resources must be present and improved within the city's working radius. For the "Ands" table, the MORE entries for a single building, the HARDER it is to meet the surrounding resource requirements.

Appropriate Buildings:

Any type of building (regular, National Wonder, or World Wonder) is appropriate for this table, but you must consider the likelihood that the building will ever be able to be built by a player when you structure your resource requirements.

IMPORTANT NOTE:

Never make entries for a single building to both the <Building_LocalResourceAnds> table and the <Building_LocalResourceOrs> table that follows.

HINT --- WHICH TABLE TO USE

If after reading the description for this table and for the <Building_LocalResourceOrs> table that follows you are not certain which table to use for a building with only one (1) resource-type requirement in the vicinity of the city, the answer is to always use the "Ands" table when there is to be only one resource required near the city.

Table Commands:

BuildingType

Specifies the building for which a resource shall be required.

ResourceType

Specifies the required resource.

RESOURCE LIMITATIONS:

The only resources that should not usually appear in this table are the special city-state luxury resources and the Indonesian "magic" resources.

EXAMPLE OF USE:

This is the entry in the <Building_LocalResourceAnds> table for the Forge building. It specifies that Iron (but only Iron) is required in the city working-radius before the Forge can be built in a city.
This is copied EXACTLY from the FIRAXIS-supplied XML:

Code:

<Building_LocalResourceAnds>
	<Row>
		<BuildingType>BUILDING_FORGE</BuildingType>
		<ResourceType>RESOURCE_IRON</ResourceType>
	</Row>
</Building_LocalResourceAnds>

I could use the <Building_LocalResourceAnds> table with a new National Wonder called the National Food Bank and I could set-up the entries in the table so that a player would have to have both Wheat and Cattle available in a city before the national wonder could be constructed in that city. The table would look like the following:

(click on the spoiler butrton to see the example)

Spoiler :

This would result in a reasonably buildable national wonder, though there would be no certainty that the wonder would be buildable in any single play-through of the game. If I used the <Building_LocalResourceAnds> table to change the requirements so that Wheat, Cattle, and Sheep must ALL be present within the radius of an individual city, then the new National Food Bank might never be able to be built. But if I wanted to go ahead and set-up such a requirement, the <Building_LocalResourceAnds> table would be as follows:

(click on the spoiler button to see this example)

Spoiler :

....................................................................................................................................................................................................................................................

LOCAL RESOURCE "ORS" TABLE

This is the second of two tables that set prerequisites to a building's construction based on the presence of resources around a city. The resource must be improved with the usual worker-unit-built improvement before the resource is considered to be "present", and the resource must be located within the workable-tiles range of the city, not just within its cultural borders.

The <Building_LocalResourceOrs> table is used to specify which resource(s) must be present in a city's vicinity before a building can be constructed. Only one entry in this table must be "satisfied" before the building can be constructed or purchased. If you place two entries in this table for the same building, then either resource can be present and improved within the city's working radius. For the "Ors" table, the more entries for a single building, the easier it is to meet the surrounding resource requirements. There is a limit of no more than five (5) resources can be specified in this table for any one building.

Appropriate Buildings:

Any type of building (regular, National Wonder, or World Wonder) is appropriate for this table, but you must consider the likelihood that the building will ever be able to be built by a player when you structure your resource requirements.

IMPORTANT NOTE:

Never make entries for a single building to both the <Building_LocalResourceAnds> table and the <Building_LocalResourceOrs> table.

Table Commands:

BuildingType

Specifies the building for which a resource shall be required.

ResourceType

Specifies the required resource.

RESOURCE LIMITATIONS:

The only resources that should not usually appear in this table are the special city-state luxury resources and the Indonesian "magic" resources.

EXAMPLE OF USE:

This is the entry in the <Building_LocalResourceOrs> table for the Stable building. It specifies that any one of Horses, Sheep, or Cattle is required in the city working-radius before the Stable can be built in a city. Note that the XML-name for "Cattle" is actually "RESOURCE_COW". This is copied EXACTLY from the FIRAXIS-supplied XML:

(click on the spoiler button to see the example)

Spoiler :

....................................................................................................................................................................................................................................................

RESOURCE QUANTITY REQUIREMENTS TABLE

The <Building_ResourceQuantityRequirements> table is used to specify what strategic resources the empire must have available before a building can be constructed. There is no need for the resource to be located within the city's workable radius. All that is needed is that the empire has the required quantity of the required resource.

Any type of building (regular, National Wonder, or World Wonder) is appropriate for this table in the sense that requiring a resource be available to an empire before a world or national wonder can be constructed won't "break the game". As a practical matter, modders don't usually state resource requirements for new National or World Wonders.

Table Commands:

BuildingType

Specifies the building for which there is a strategic resource quantity requirement.

ResourceType

Specifies the resource that is required.

Cost

Specifies how many "resource points" are required. This number will immediately be deducted from the empire's available quantity when construction of the building is started, or the building is placed in a city build list.

RESOURCE LIMITATIONS:

Only the strategic resources should normally appear in this table.

RESOURCE_ALUMINUM
RESOURCE_COAL
RESOURCE_URANIUM
RESOURCE_HORSE
RESOURCE_IRON
RESOURCE_OIL

EXAMPLE OF USE:

This is the entry in the <Building_ResourceQuantityRequirements> table for the Hydro Plant, Factory, Nuclear Plant, and Spaceship Factory buildings. This table and its specifications is the method by which these four buildings are made to "require" and "use up" various strategic resources in specified quantities. For all four of these buildings, the strategic resource "cost" amount is one (1). The table as shown is copied EXACTLY from the FIRAXIS-supplied XML:

(click the spoiler button to see the example)

Spoiler :

....................................................................................................................................................................................................................................................

RESOURCE QUANTITY TABLE

Expansion Compatibility Note:

This table was added in G&K, and so will not work for Vanilla.
The table functions identically for G&K and BNW

<Building_ResourceQuantity> Table:

The <Building_ResourceQuantity> table is used to make buildings "give out" a specified amount of either (a) a strategic resource, or (b), a luxury resource. The amount of the resource stated is added to the empire's stocks of the strategic or luxury resource. The strategic resource additions will show directly at the top of the game display. Luxury resources will be added, but the amount available only shows on the "secondary" screens, such as the trade table that shows how many of a resource an empire has available to trade away to another player.

This table was added, really, to allow the Recycling Center to grant Aluminum stocks to the player, thereby ensuring that every player would have access to at least SOME aluminum in every game. MOD creators have used the table mainly to add luxuries to the game. Generally, when adding luxuries to a player's stocks, MOD creators have limited the use of this table to World Wonders.

Any type of building (regular or wonder) can have an entry in this table, but for the most part the Recycling Center already covers the only really glaring potential resource-lack that existed, so you should as a general rule not use this table. The game will not become "broken" if you do, there just won't in most cases be much point in adding new buildings that merely give away strategic resources for free, especially since more than one MOd author has already posted to the Steam Workshop mods that add a few targetted buildings which ensure that each empire can at least get their hands on a limited amount of every strategic resource.

RESOURCE LIMITATIONS:

only the pre-existing strategic resources should generally appear in this table.

RESOURCE_ALUMINUM
RESOURCE_COAL
RESOURCE_URANIUM
RESOURCE_HORSE
RESOURCE_IRON
RESOURCE_OIL

Adding pre-existing LUXURY resources to this table (the ones that occur naturally on the game map) would ensure that more players can get their hands on copies of the Firaxs-supplied game luxuries, but it would also tend to break the game in terms of luxury trading, and in terms of keeping luxuries somewhat scarce.
Adding pre-existing bonus resources to this table is possible, but since the game does not allow trading of these, there would be little point except in cases where you want to control ability to construct Building-X based on the quantity of Building-Y an empire has.
- In the highlighted special-use case, you would have Building-Y give a 'bonus' resource, even if it is a 'bogus' resource only added into the game in order to create the limitation-mechanic you desire.
- Sukritact's Events & Decisions mod does this very sort of thing by adding "Magistrates" as a "dummy" or "bogus" resource to the game, and then this new resource is given to players by certain buildings, and the "decisions" players enact consume these resources.

Table Commands:

BuildingType

Specifies the building that will give resources.

ResourceType

Specifies the resource to be given.

Quantity

Specifies the quantity to be given.

EXAMPLE OF USE: (Strategic Resources)

This is the table as used by FIRAXIS to make the Recycling Center give free aluminum to the player:

Code:

<Building_ResourceQuantity>
	<Row>
		<BuildingType>BUILDING_RECYCLING_CENTER</BuildingType>
		<ResourceType>RESOURCE_ALUMINUM</ResourceType>
		<Quantity>2</Quantity>
	</Row>
</Building_ResourceQuantity>

Remember that a player can only build five (5) Recycling Centers within the course of a single game. This restriction acts as a brake on how much Aluminum a player can "get his hands on" by construction of buildings. To get more Aluminum than the 10 from Recycling Centers, the player is forced to trade for it, to find some on the game map that hasn't been "gobbled up" by AI players, or to TAKE IT by conquest.
You should tend to follow this example with any resource-granting building you add to the game, and not make it TOO easy for a player to become rich in a strategic resource simply through the construction of buildings.

EXAMPLE OF USE:(New Luxury Resources added to the game by your MOD)

If I add a new luxury to the game called "RESOURCE_GUACAMOLE_COFFEE_BEANS" that can only be accessed by constructing a World Wonder we'll call the "BUILDING_GUACAMOLE_COFFEE_HOUSE", my <Building_ResourceQuantity> table might look like the following:

Code:

<Building_ResourceQuantity>
	<Row>
		<BuildingType>BUILDING_GUACAMOLE_COFFEE_HOUSE</BuildingType>
		<ResourceType>RESOURCE_GUACAMOLE_COFFEE_BEANS</ResourceType>
		<Quantity>2</Quantity>
	</Row>
</Building_ResourceQuantity>

This would grant two copies of the new Guacamole Coffee Beans luxury to the empire that constructs the Guacamole Coffee House wonder. One copy the empire can then keep to enhance happiness, and the second can be traded away to the highest bidder.

LeeS · May 2, 2014

TECH ENHANCED YIELD CHANGES TABLE

The <Building_TechEnhancedYieldChanges> table is used to create additional yields for a building based upon discovery of a technology that comes later in the tech tree than the building's PreReqTech.

The table only has an effect if the building has an entry for EnhancedYieldTech in the <Buildings> table.

For example, if the building has an entry of <EnhancedYieldTech>TECH_FLIGHT</EnhancedYieldTech> in the <Buildings> table, any yields specified under the <Building_TechEnhancedYieldChanges> table take effect when the player discovers the technology FLIGHT.

The yields are attached directly to the building as an inherent property, and are not dependant on any terrain or resource surrounding the city. However, the change in yields do not always show in the city display as being part of the building's properties. The changes will be shown in the city yields box for the correct type of yield after the enhancing tech is discovered by the player.

Table Commands:

BuildingType

Specifies the building for which yields will be enhanced based upon discovery of a technology.

YieldType

Specifies the type of yield that will be added.
Any of the following yield-types can be used with this table:

YIELD_GOLD
YIELD_PRODUCTION
YIELD_SCIENCE
YIELD_CULTURE
YIELD_FOOD
YIELD_FAITH

"TOURISM" cannot be stated as a yield-type in this table.

Yield

Specifies the amount of the yield that will be added.

Appropriate buildings:

"Regular" buildings, National Wonders, and World Wonders would all be appropriate for this table, as the effects are local to the city.

EXAMPLE OF USE:

Here is an example drawn from the game-XML and used to make the PETRA world wonder add +6 Culture when the Archaeology tech is discovered by the player that built the Petra wonder:

Code:

<Building_TechEnhancedYieldChanges>
	<Row>
		<BuildingType>BUILDING_PETRA</BuildingType>
		<YieldType>YIELD_CULTURE</YieldType>
		<Yield>6</Yield>
	</Row>
</Building_TechEnhancedYieldChanges>

NOTE:

Remember that the "enhancing tech" is not stated in this table, it is stated as a direct attribute of the building in the <Buildings> table.

.................................................................................................................................................................................

FREE UNITS TABLE

The <Building_FreeUnits> table is used to make buildings give free units to the player. As a general rule, you should limit the type of buildings using this table to National and World Wonders.

Great People 'Cost' Effects:

When Great People are given directly within this table as a result of constructing a wonder or building, the 'cost' for nearly all Great People is incremented.

The increment is applied to all Great People of the same 'Great People Group'.
Great Artists, Great Writers, and Great Musicians are each their own 'Group', so a Great Artist generated by the table does not affect the needed Great Writer and Great Musician points needed for the next great person to spawn.
Granting a Great Engineer increments the cost in Great People Points for the next Great Engineer, Great Scientist, and Great Merchant. The same effect applies when granting a Great Scientist or a Great Merchant.
Great Prophets are affected but the effect is applied to the Faith Cost of the next Great Prophet.
Great Generals and Great Admirals are not affected so far as I have been able to determine. The 'experience' cost of the next Great General or Great Admiral is not changed.
All cities in an empire are affected, so in that sense this table has a 'global' effect.

Table Commands:

BuildingType

Specifies the building that will give free units.

UnitType

Specifies the type of free unit(s) that will be given.

NumUnits

Specifies the number of free units that will be given.

LIMITS TO "UNITTYPE"

Any type of Great Person can be used with this table.

Great Prophets can be used with this table without concern as to whether or not a player has already created a religion. In such a case, the player would use the supplied great prophet to found their religion for their empire.
Free great prophets aren't entirely free in the sense that each such great prophet created within an empire increases the faith cost for generation of the next great prophet just as if the free great prophet had been generated in the normal way.
You should probably never have a wonder give more than 1 free great prophet.

Workers, Workboats, and Settlers can be used with this table.
Caravans and Cargo Ships can be used with this table.
Missionaries and Inquisitors can be used with this table.

care must be used to ensure that a player has also already founded or "has" a religion. This is easiest done by requiring the building to be built in a holy city.
if a free missionary is created in a city without a majority religion, the missionary will be created by the game without a "religion-tag", and will be unable to spread any religion anywhere because it was created without being assigned as a missionary of a particular religion.
I have not tested to see what happens when an inquisitor is given for free in a city that has no majority religion.

Combat units CAN be used with this table.

for combat units, the "UnitType" has to be the simple unit name, and not the Unit-CLASS name.
any unit mentioned in the table will be given when the building that gives free units is built, regardless of whether the player has researched the technology that usually "unlocks" the unit.
any unit mentioned in the table that a player is not normally able to build will be replaced by the appropriate unit for that player.
even though you only state the simple unit name in the <Building_FreeUnits> table, the game makes the appropriate replacements based on the CLASS of unit to which the simple unit belongs. For combat units, therefore, you should always use the default unit within the unit-class for entries in the <Building_FreeUnits> table.
units given with this table never recieve extra experience, regardless of the number or nature of experience-enhancing buildings that exist in a city where the free units are spawned

Civilian UNIT designations commonly used with this table:

(click on spoiler button to see the list)

Spoiler :

Combat UNIT designations for this table are as follows:

(click on spoiler button to see the list)

Spoiler :

EXAMPLE OF USE:

I have taken a sampling of the buildings that normally give free units, and shown the entries in the <Building_FreeUnits> table for those buildings. The choices I made were primarily to show the format for giving different types of free units, as it is used in the FIRAXIS-supplied XML.

Spoiler :

EXAMPLES FOR COMBAT UNITS:

Example (1)

Since combat units can be used with this table, I could make a building give free MUSKETMAN units, and to do so my table would look like the following, if I chose to make the BARRACKS give a free Musketman:

Code:

<Building_FreeUnits>
	<Row>
		<BuildingType>BUILDING_BARRACKS</BuildingType>
		<UnitType>UNIT_MUSKETMAN</UnitType>
		<NumUnits>1</NumUnits>
	</Row>
</Building_FreeUnits>

Every time a player built a Barracks, they would get a free Musketman. But this would result in Musketmen becoming available far too early in the game.

Example (2)

I might decide, then, to add a new CLASS of building called BUILDINGCLASS_GUNPOWDER_BARRACKS with the default version of this building the BUILDING_GUNPOWDER_BARRACKS. I would make this new class of building require the Gunpowder technology, and I would probably want the building to give a few benefits based on creating Gunpowder-type units, one of which might be to give a free Musketman whenever a Gunpowder Barracks is constructed. I would alter my <Building_FreeUnits> table as follows, to give the free Musketman unit:

Code:

<Building_FreeUnits>
	<Row>
		<BuildingType>BUILDING_GUNPOWDER_BARRACKS</BuildingType>
		<UnitType>UNIT_MUSKETMAN</UnitType>
		<NumUnits>1</NumUnits>
	</Row>
</Building_FreeUnits>

America and France (for example) would not get a simple Musketman, they would get their respective unique units, Minuteman and Musketeer. Bear in mind that the game will automatically make the proper substitutions.

Example (3)

Since the designator for which building is to give free units is the simple building name and not the Building-CLASS name, a separate entry is required for each building within a class. So, if I were to make BARRACKS give a free Archer, as an example, I would also need to have entries in the <Building_FreeUnits> table for the Krepost and the Ikanda.

Code:

<Building_FreeUnits>
	<Row>
		<BuildingType>BUILDING_BARRACKS</BuildingType>
		<UnitType>UNIT_ARCHER</UnitType>
		<NumUnits>1</NumUnits>
	</Row>
	<Row>
		<BuildingType>BUILDING_IKANDA</BuildingType>
		<UnitType>UNIT_ARCHER</UnitType>
		<NumUnits>1</NumUnits>
	</Row>
	<Row>
		<BuildingType>BUILDING_KREPOST</BuildingType>
		<UnitType>UNIT_ARCHER</UnitType>
		<NumUnits>1</NumUnits>
	</Row>
</Building_FreeUnits>

LeeS · May 2, 2014

The next few tables that will be discussed use either a unit's DOMAIN type or its UNITCOMBAT type to speed production of the unit or to grant free Combat Experience Points to the unit.

If the table is a "DOMAIN" table, then the three main domain types AIR, LAND and SEA are used to determine how much experience or how much increased production towards finishing a unit will be created by the building.

If the table is a "UNITCOMBAT" table, then the unitcombat types are used to determine how much experience or how much increased production towards finishing a unit will be created by the building.

Any building that adds production or experience will come into effect when a unit is built in a city, and multiple effects will stack.

Buildings that speed production of units based on DOMAIN:

Building Domain Modification
Seaport SEA +15 % Production
Forge LAND +15 % Production

Buildings that grant experience based on DOMAIN:

Building Domains XP Comment
Barracks (Krepost, Ikanda) ALL +15 XP none
Armory ALL +15 XP none
Military Academy ALL +15 XP none
Brandenburg Gate Wonder ALL +15 XP none
Royal Libray ALL +10 XP (when great work slot is filled)

Buildings that speed production of units based on UNITCOMBAT:

Building Units Modifier
Temple of Artemis Wonder ARCHER +15 % Production
Kremlin Wonder ARMOR +50 % Production
Stable MOUNTED +15 % Production
Ducal Stable MOUNTED +15 % Production

Buildings that grant experience based on UNITCOMBAT:

Building Units XP's
Ducal Stable MOUNTED +15 XP

If a city has a Forge and a Stable (or Ducal Stable), PRODUCTION of MOUNTED units would be increased by +30 %. If a city has a Ducal Stable, a Barracks, and an Armory, total free XP's would be +45 XP's for MOUNTED units, but all other units would only get the XP's granted by the Barracks and the Armory.

...............................................................................................................................

Here is an outline that shows which UNITCOMBAT types belong to each of the three DOMAINS (Land, Air, and Sea) as well as which classes of units belong to each UNITCOMBAT type. The listing shows the names of DOMAINS and UNITCOMBAT types as they MUST appear in any of the "unit-enhancing" tables that follow. The unitclass is never used in these tables, but I have included them as a reference for which sorts of units belong to which UNITCOMBAT type.

(click on the spoiler button to see the listing)

Spoiler :

Code:

			DOMAIN_LAND (contains the following unitcombat subtypes)

UNITCOMBAT_RECON					UNITCOMBAT_GUN
	UNITCLASS_SCOUT					UNITCLASS_MUSKETMAN
							UNITCLASS_RIFLEMAN
UNITCOMBAT_MELEE						UNITCLASS_GREAT_WAR_INFANTRY
	UNITCLASS_WARRIOR				UNITCLASS_INFANTRY
	UNITCLASS_SPEARMAN				UNITCLASS_MARINE
	UNITCLASS_PIKEMAN				UNITCLASS_MOBILE_SAM
	UNITCLASS_SWORDSMAN				UNITCLASS_ANTI_AIRCRAFT_GUN
	UNITCLASS_LONGSWORDSMAN				UNITCLASS_ANTI_TANK_GUN
							UNITCLASS_MECHANIZED_INFANTRY
UNITCOMBAT_ARCHER					UNITCLASS_PARATROOPER
	UNITCLASS_ARCHER					UNITCLASS_XCOM_SQUAD
	UNITCLASS_CHARIOT_ARCHER
	UNITCLASS_COMPOSITE_BOWMAN		UNITCOMBAT_MOUNTED
	UNITCLASS_CROSSBOWMAN				UNITCLASS_HORSEMAN
	UNITCLASS_GATLINGGUN				UNITCLASS_KNIGHT
	UNITCLASS_MACHINE_GUN				UNITCLASS_LANCER
	UNITCLASS_BAZOOKA				UNITCLASS_CAVALRY

UNITCOMBAT_SIEGE					UNITCOMBAT_ARMOR
	UNITCLASS_CATAPULT				UNITCLASS_WWI_TANK
	UNITCLASS_TREBUCHET				UNITCLASS_TANK
	UNITCLASS_CANNON					UNITCLASS_MODERN_ARMOR
	UNITCLASS_ARTILLERY				UNITCLASS_MECH
	UNITCLASS_ROCKET_ARTILLERY

UNITCOMBAT_HELICOPTER (to me strange, but also true)
	UNITCLASS_HELICOPTER_GUNSHIP

.....................................................................................

		DOMAIN_AIR (contains the following unitcombat subtypes)

UNITCOMBAT_FIGHTER			UNITCOMBAT_BOMBER
	UNITCLASS_TRIPLANE			UNITCLASS_WWI_BOMBER
	UNITCLASS_FIGHTER			UNITCLASS_BOMBER
	UNITCLASS_JET_FIGHTER			UNITCLASS_STEALTH_BOMBER

.................................................................................

		DOMAIN_SEA (contains the following unitcombat subtypes)

UNITCOMBAT_NAVALRANGED
	UNITCLASS_GALLEASS
	UNITCLASS_TRIREME............UNIT_BYZANTINE_DROMON
	UNITCLASS_FRIGATE
	UNITCLASS_MISSILE_CRUISER
	UNITCLASS_BATTLESHIP

UNITCOMBAT_NAVALMELEE			UNITCOMBAT_SUBMARINE
	UNITCLASS_GALLEY				UNITCLASS_SUBMARINE
	UNITCLASS_TRIREME			UNITCLASS_NUCLEAR_SUBMARINE
	UNITCLASS_PRIVATEER
	UNITCLASS_CARAVEL
	UNITCLASS_IRONCLAD		UNITCOMBAT_CARRIER
	UNITCLASS_DESTROYER			UNITCLASS_CARRIER

.................................................................................................................................................................................

DOMAIN FREE EXPERIENCES TABLE

The <Building_DomainFreeExperiences> table is used to make a building give experience (XP's) to units built or purchased in the city, depending on the DOMAIN of the unit.

Any building type (regular, National Wonder, World Wonder) is appropriate for this table since the effects are limited to the city in which the building is constructed.

Free experience given to units by buildings will "stack", so any number of buildings in the same city can give free experience to units.

Table Commands:

BuildingType
Specifies the building that will grant experience.

DomainType
Specifies the Unit DOMAIN (AIR, LAND, or SEA) that will be affected.

Experience
Specifies the amount of experience given to the unit for "free" by the building.

EXAMPLE OF USE:

The Barracks building gives free experience to all combat unit types. It does so by having a different entry in the "<Building_DomainFreeExperiences>" table for each of the three DOMAINS (AIR, LAND, SEA). For the BARRACKS building, the table is as follows. These are the EXACT entries for the BARRACKS building:

Click the spoiler button the see the example)

Spoiler :

If I want a building to give experience only to units of one domain, and not the other two, then I simply don't include entries in the <Building_DomainFreeExperiences> table for unwanted domains. Here is the table as I would need to include it in a mod to have a Flying School building give experience only to AIR units:

Code:

<Building_DomainFreeExperiences>
	<Row>
		<BuildingType>BUILDING_FLYINGSCHOOL</BuildingType>
		<DomainType>DOMAIN_AIR</DomainType>
		<Experience>15</Experience>
	</Row>
</Building_DomainFreeExperiences>

Instead, if I want the LIGHTHOUSE building to give experience to SEA units only, the table would be:

Code:

<Building_DomainFreeExperiences>
	<Row>
		<BuildingType>BUILDING_LIGHTHOUSE</BuildingType>
		<DomainType>DOMAIN_SEA</DomainType>
		<Experience>15</Experience>
	</Row>
</Building_DomainFreeExperiences>

.................................................................................................................................................................................

UNIT COMBAT FREE EXPERIENCES TABLE

The <Building_UnitCombatFreeExperiences> table is used to make a building give experience (XP's) to units built or purchased in the city, depending on the UNITCOMBAT of the unit.

Any building type (regular, National Wonder, World Wonder) is appropriate for this table since the effects are limited to the city in which the building is constructed.

Free experience given to units by buildings will "stack", so any number of buildings in the same city can give free experience to units.

Table Commands:

BuildingType
Specifies the building that will grant experience.

UnitCombatType
Specifies the UNITCOMBAT type for which experience will be given.

Experience
Specifies the amount of unit Experience (XP's) given to the unit for "free" by the building when the unit being built in the city is of the UNITCOMBAT type stated in UnitCombatType.

EXAMPLE OF USE:

The Ducal Stable building gives free experience to all MOUNTED unit types. It does so by specifying "UNITCOMBAT_MOUNTED" in the UnitCombatType field. For the DUCAL STABLE building, the table is as follows. These are the EXACT entries for the DUCAL STABLE building:

Code:

<Building_UnitCombatFreeExperiences>
	<Row>
		<BuildingType>BUILDING_DUCAL_STABLE</BuildingType>
		<UnitCombatType>UNITCOMBAT_MOUNTED</UnitCombatType>
		<Experience>15</Experience>
	</Row>
</Building_UnitCombatFreeExperiences>

If I want to have the Temple of Artemis world wonder add 15 XP's to archery units in addition to its archery unit production speed increase, I would add the table to my mod as follows:

Code:

<Building_UnitCombatFreeExperiences>
	<Row>
		<BuildingType>BUILDING_TEMPLE_ARTEMIS</BuildingType>
		<UnitCombatType>UNITCOMBAT_ARCHER</UnitCombatType>
		<Experience>15</Experience>
	</Row>
</Building_UnitCombatFreeExperiences>

If I create a new building called a Tank Factory, I might want it to grant 25 extra XP's to armored units. The <Building_UnitCombatFreeExperiences> table I would add to my mod would be as follows:

Code:

<Building_UnitCombatFreeExperiences>
	<Row>
		<BuildingType>BUILDING_TANK_FACTORY</BuildingType>
		<UnitCombatType>UNITCOMBAT_ARMOR</UnitCombatType>
		<Experience>25</Experience>
	</Row>
</Building_UnitCombatFreeExperiences>

.................................................................................................................................................................................

UNIT COMBAT PRODUCTION MODIFIERS TABLE

The <Building_UnitCombatProductionModifiers> table is used to make a building speed production of units built in the city depending upon the UNITCOMBAT type of the unit.

Any building type (regular, National Wonder, World Wonder) is appropriate for this table since the effects are limited to the city in which the building is constructed.

Table Commands:

BuildingType
Specifies the building that will speed production of units.

UnitCombatType
Specifies the UNITCOMBAT type for which production will be increased.

Modifier
Specifies the PERCENTAGE increase in unit PRODUCTION when the unit being built in the city is of the UNITCOMBAT type stated in UnitCombatType.

EXAMPLE OF USE:

Here is a properly-formatted example of the <Building_UnitCombatProductionModifiers> table. This is the EXACT entry used in the FIRAXIS-supplied XML for the Temple of Artemis world wonder. It increases the production of ARCHER-type units by 15%.

Code:

<Building_UnitCombatProductionModifiers>
	<Row>
		<BuildingType>BUILDING_TEMPLE_ARTEMIS</BuildingType>
		<UnitCombatType>UNITCOMBAT_ARCHER</UnitCombatType>
		<Modifier>15</Modifier>
	</Row>
</Building_UnitCombatProductionModifiers>

If I create a new building called a Tank Factory, I might want it to speed production of armored units by 25 percent. The <Building_UnitCombatProductionModifiers> table I would add to my mod would be as follows:

Code:

<Building_UnitCombatProductionModifiers>
	<Row>
		<BuildingType>BUILDING_TANK_FACTORY</BuildingType>
		<UnitCombatType>UNITCOMBAT_ARMOR</UnitCombatType>
		<Modifier>25</Modifier>
	</Row>
</Building_UnitCombatProductionModifiers>

.................................................................................................................................................................................

DOMAIN PRODUCTION MODIFIERS TABLE

The <Building_DomainProductionModifiers> table is used to make a building speed production of units built in the city depending upon the DOMAIN type of the unit.

Any building type (regular, National Wonder, World Wonder) is appropriate for this table since the effects are limited to the city in which the building is constructed.

Table Commands:

BuildingType
Specifies the building that will speed unit production.

DomainType
Specifies the Unit DOMAIN (AIR, LAND, or SEA) that will be affected.

Modifier
Specifies the PERCENTAGE increase in unit PRODUCTION when the unit being built in the city is of the unit DOMAIN stated in DomainType.

EXAMPLE OF USE:

Here is a properly-formatted example of the <Building_DomainProductionModifiers> table. This is the EXACT set of table entries used in the FIRAXIS-supplied XML for the Seaport and Forge buildings. Seaports and Forges bump unit production as follows (click the spoiler button to see):

Spoiler :

If I create a new building called an Aircraft Factory, and want it to increase production speed of all AIR units by 50 percent, the entry in my mod for the <Building_DomainProductionModifiers> table would be:

Code:

<Building_DomainProductionModifiers>
	<Row>
		<BuildingType>BUILDING_AIRCRAFT_FACTORY</BuildingType>
		<DomainType>DOMAIN_AIR</DomainType>
		<Modifier>50</Modifier>
	</Row>
</Building_DomainProductionModifiers>

.................................................................................................................................................................................

DOMAIN FREE EXPERIENCES PER GREAT WORK TABLE

The <Building_DomainFreeExperiencePerGreatWork> table is used to allow buildings to grant experience to combat units based on the unit DOMAIN, and whether or not the building's great works slot(s) have been filled. Experience granted for free is PER great work, so a building with multiple great works slots (such as the Uffizi world wonder) could theoretically grant a large bump in experience. As a practical matter, since greats works are fairly difficult to come by, it is likely that any one building will usually have no more than one of its great works slots filled.

Any type of building is appropriate for this table so long as it is also a great works building. The Royal Library, which is a "regular" building by my definition, uses this exact feature to grant extra experience to combat units when its great works slot is filled. National Wonders (palaces) and World Wonders would also be appropriate for inclusion in this table, but unless you also add great works slots to a new National or World Wonder, there would be little point in adding entries for a building to the <Building_DomainFreeExperiencePerGreatWork> table.

Table Commands:

BuildingType
Specifies the building that will grant experience.

DomainType
Specifies the Unit DOMAIN (AIR, LAND, or SEA) that will be affected.

Experience
Specifies the amount of experience given to the unit for "free" by the building for EACH great work currently installed in the Building's great work slots. The great works must be in the building stated for BuildingType in this table, not just located within the city.

EXAMPLE OF USE:

This is the entry in the <Building_DomainFreeExperiencePerGreatWork> table for the Royal Library building. This is copied EXACTLY from the FIRAXIS-supplied XML (click the spoiler button to see the example):

Spoiler :

LeeS · May 2, 2014

The <Building_Flavors> table is used to make the AI want to build a particular building, depending on how a building's flavors match up to the "stategy" the AI is currently pursuing, and also to the civilization leader's flavor settings. The higher the flavor number, the more the AI will want to build a building whose flavors match the AI's strategy flavors. If an AI is currently pursuing a "science" strategy it will be more likely to choose buildings that are science flavored, and whose science flavor number is higher.

ALL BUILDINGS REQUIRE FLAVORING !!

Omitting Flavoring altogether will not allow the AI to assign priority to the building, nor allow it to understand what the building is good for. Omitting flavors from a building is a great way to "secretly" cheat against the AI, but it won't result in balanced gameplay. Nonetheless, the <Building_Flavors> table is not actually required in order for a building to be added to the game.

Table Commands:

BuildingType
Specifies the building for which a flavor is to be assigned.

FlavorType
Specifies the flavor type assigned to the building.

Flavor
Specifies the amount of the "flavoring" to assign to the building. The higher this number, the more likely the AI will be to build the building.

Building Flavors

These are the building flavors that can be used:
(click spoiler button to see the list)

Spoiler :

Notes on some of the Flavors:
(click on the spoiler button to see)

Spoiler :

(This is not an exhaustive listing)

FLAVOR_GROWTH

use "growth" flavoring, not "food" flavoring.

FLAVOR_AIR

so far as I can see only used by the recycling center.

FLAVOR_DIPLOMACY

this was used with the now-defunct united nations wonder, but is still used with the intelligence agency national wonder.

FLAVOR_AIRLIFT

used in the airport building. Since the "airlift" capability is really useless to repeat in a new building, there is not much use for this flavoring in new buildings.

FLAVOR_TILE_IMPROVEMENT

pyramids world wonder uses this with a flavor setting of "45". Any building or wonder that would affect tile improvement speed would use a similar flavoring.

FLAVOR_RELIGION

should be used with buildings that have a religious theme, or which add faith.

FLAVOR_WONDER

should always be included with National and World Wonders. The Workshop and Longhouse also have a "WONDER" flavoring (10) because they both boost production in a city. Most National and World Wonders have a "WONDER" flavor setting of 20 or 25. Industrial era wonders like the Eiffel Tower and Pentagon tend to have a setting of 30. The Hagia Sophia has a setting of "15", and the Forbidden Palace has a setting of "100", which is meant to make AI players lust to have the Forbidden Palace a lot more than any other World Wonder.

FLAVOR_NAVAL_GROWTH

this is to tell the game that the building has an effect on coastal-city growth based on coast and sea food improvement. It is not used to tell the game that the building is good for building naval units.

FLAVOR_NAVAL_TILE_IMPROVEMENT

similar to "FLAVOR_NAVAL_GROWTH" except that it is used to signify that the building will have an affect on coastal and sea improved resources.

FLAVOR_I_TRADE_ORIGIN

buildings that have the trade route origin bonus assigned to them should also include this flavoring. Markets, Banks, Stock Exchanges, East India Company, and the Caravansary all have this flavoring.

FLAVOR_I_SEA_TRADE_ROUTE

used to signify that the building is good for sea trade routes. The Granary, Workshop, and Harbor buildings all have this flavoring to some degree. Oddly, the Longhouse omits this flavoring.

FLAVOR_I_LAND_TRADE_ROUTE

used to signify that the building is good for land trade routes. The Granary, Workshop, and Caravansary buildings all have this flavoring to some degree. Oddly, the Longhouse omits this flavoring.

FLAVOR_I_TRADE_DESTINATION

buildings that have the trade route destination bonus assigned to them should also include this flavoring. Markets, Banks, Stock Exchanges, and the East India Company all have this flavoring.

SOME IDEAS ON HOW TO STRUCTURE FLAVOR SETTINGS:

First, decide what the primary function of your building is, in terms of flavor types. A building will generally have one or more primary effects, and any number of minor "extra" effects. Concentrate first on the primary effects. So, if the building is a wonder, there should be a "Wonder" flavor. If it is a wonder that mostly adds growth to cities, then it should also have "Growth" as a primary effect. Second, give thought to the nature of any "extra" or secondary effects a building has. If it adds a happiness point or two, this would be a minor or "extra" effect. If it also adds a point or two of faith, this too would be a minor effect. Appropriate flavorings to start with for such a wonder might be:

Flavor Type effect Flavor Setting
FLAVOR_WONDER (primary) "25" flavor points
FLAVOR_GROWTH (primary) "25" flavor points
FLAVOR_HAPPINESS (extra) "5" flavor points
FLAVOR_RELIGION (extra) "5" flavor points

To add the flavorings in a properly-formatted <Building_Flavors> table, we need a building name, so I will use "BUILDING_NATIONAL_FOOD_BANK" as the name of the wonder. The table would look like the following:

(click on the spoiler button to see)

Spoiler :

Don't sweat ball-bearings over whether or not you have created the "perfect" flavorings table for your building. Pick flavors that seem reasonable, and then assign what seem reasonable values. Check to see if the AI tends to want to build your building by playing a couple of games, and using the In-Game Editor Mod to see what AI players are building from time to time. If the AIs are using your building, well and good. If they seem to build your building far too often (sacrificing alternate choices that make more sense to you given their situation) you might have to examine your building's flavorings and reduce one or more of them.

LeeS · May 2, 2014

The <Building_ThemingBonuses> table is used to control the theming bonuses that apply when great works or artifacts are placed in a world wonder's great works and artifacts slots. Since neither regular buildings nor National Wonders work correctly so far as adding great works slots and having the building or National Wonder show properly in the Culture Overview panel, you should limit entries in the <Building_ThemingBonuses> table to World Wonders.

WORLD WONDERS DO NOT SUFFER THIS SHORTCOMING

NOTE: there are a couple of MODS that have been made recently that are addressing the in-game culture overview display shortcomings but at this point I'm not sure how "finished" they are. I have seen at least two such mods on the Steam Workshop. Both "fix" the culture-overview panel by adding a custom "Something.LUA" file to the mod. In order for your mod to make use of these fixes you would have to include one or other of these "Something.LUA" files as part of your mod, but you should first ask the author of these mods for permission to use the LUA. Or you would need to leave a note on your steam workshop mod page telling potential subscribers that they also need to have one of the mods activated that change the culure-overview panel in order to use your mod. There may also be mod loading order requirements which might need to be addressed

Table Commands:

BuildingType

Specifies the building or wonder to which theming bonus(es) will be applied. Remember that some of the buildings as supplied by FIRAXIS have great works slots. The Museum building also has theming bonuses associated with it. Because these FIRAXIS-supplied buildings were "hard-coded" into the Culture Overview panel, they work correctly.

Description

Specifies a text pop-up message that will be used when the requirements for gaining the theming bonus are met. You can fill in the text you want used directly or you can specify a "TXT_KEY_" look-up that you will add to your language table (such as <Language_en_US>). Multiple theming bonus entries can be made for the same wonder. The <Description> entry you make is a short little additional "title" that will be applied to the wonder when a particular theming bonus condition has been met.
When the theming bonus requirement for the Hermitage have been met, the pop-up message "Museum of World Art" is added to the Hermitage when it is moused-over in the city display or the cultural overview screen.
The only real "game function" to <Description> in this table is to make these little pop-up texts appear and thereby act as a reminder that the player has fulfilled the theming bonus, or one of the theming bonuses, that apply to the building or wonder.

Bonus

Specifies the amount of bonus tourism. Should be stated as whole numbers and should be on the order of "1", "2", "3", "4", etc. Far too high a value will only serve to break the balance of the game.

SameEra

Specifies that the great works/artifacts must be from the same era for the theming bonus to apply. Use "true" for this command. "SameEra" and "UniqueEras" cannot both be used in the same theming bonus entry.

UniqueEras

Specifies that the great works/artifacts must be from different eras for the theming bonus to apply. Use "true" for this command. "SameEra" and "UniqueEras" cannot both be used in the same theming bonus entry.

MustBeArt

Specifies that the great works slots must be filled with great works of ART. The theming bonus entry will not apply if one of the great works slots is filled with an archaeological artifact. Use "true" for this command. "MustBeArt" cannot be used in the same theming bonus entry with one containing "MustBeArtifact" or "MustBeEqualArtArtifact".

MustBeArtifact

Specifies that the great works slots must be filled with ARTIFACTS. The theming bonus entry will not apply if one of the great works slots is filled with a great work of art. Use "true" for this command. "MustBeArtifact" cannot be used in the same theming bonus entry with one containing "MustBeArt" or "MustBeEqualArtArtifact".

MustBeEqualArtArtifact

Specifies that the great works slots must be filled with both ARTIFACTS and ART in equal numbers. The theming bonus entry will not apply if there is an unequal number of ART:ARTIFACTS. Only use this command when your wonder has an even number of slots for great works of art or for artifacts. When your building contains two (2) great works of art/artifacts slots, you can use this command to require that the great works slots must be filled with one (1) work of art and one (1) archaeological artifact. Use "true" for this command. "MustBeEqualArtArtifact" cannot be used in the same theming bonus entry with one containing "MustBeArt" or "MustBeArtifact".

RequiresOwner

Specifies that the great works or artifacts must all be from the same civilization that owns the building or the wonder. Use "true" for this command. "RequiresOwner" cannot be used in the same theming bonus entry with one containing "RequiresSamePlayer", "RequiresUniquePlayers", or "RequiresAnyButOwner".

RequiresAnyButOwner

Specifies that the great works or artifacts must all be from different civilizations than the one that built the wonder or building. It does not matter which civilization they are from so long as they are all different than the owner of the wonder or building. Use "true" for this command. "RequiresAnyButOwner" cannot be used in the same theming bonus entry with one containing "RequiresOwner", "RequiresUniquePlayers", or "RequiresSamePlayer".

RequiresSamePlayer

Specifies that the great works or artifacts must all be from the same civilization. It does not matter which civilization they are from so long as they are all from the same one. Use "true" for this command. "RequiresSamePlayer" cannot be used in the same theming bonus entry with one containing "RequiresOwner", "RequiresUniquePlayers", or "RequiresAnyButOwner".

RequiresUniquePlayers

Specifies that each of the great works or artifacts must be from a different civilization. It does not matter which civilization they are from so long as no two great works or artifacts are from the same civilization. Use "true" for this command. "RequiresUniquePlayers" cannot be used in the same theming bonus entry with one containing "RequiresOwner", "RequiresSamePlayer", or "RequiresAnyButOwner".

AIPriority
Specifies the amount of "priority" AI players should assign to fulfilling the requirements of the individual theming bonus entry. Use a positive whole number. The higher the number, the greater the priority the AI players will place on meeting the conditions of this individual theming bonus requirement. If you add more than one possible set of theming bonus conditions to the same building or wonder, you should have a higher number for "AIPriority" in the entry that gives the most theming bonus. Here are the AI Priorities that exist already within the game for the buildings and wonders that have theming bonuses attached to them:

(click on spoiler button to see)

Spoiler :

Building or Wonder AI Priority Theming Bonus Theming Bonus Condition
BUILDING_MUSEUM 2 2 same era, all art, all from owner
BUILDING_MUSEUM 2 2 same era, all art, all different from owner
BUILDING_MUSEUM 2 2 same era, all artifact, all from owner
BUILDING_MUSEUM 2 2 same era, all artifact, all different from owner
BUILDING_MUSEUM 1 1 same era, all art
BUILDING_MUSEUM 1 1 same era, all artifact
BUILDING_MUSEUM 1 1 same era, all from owner
BUILDING_MUSEUM 1 1 same era, all different from owner
BUILDING_MUSEUM 1 1 all art, all from owner
BUILDING_MUSEUM 1 1 all art, all different from owner
BUILDING_MUSEUM 1 1 all artifact, all from owner
BUILDING_MUSEUM 1 1 all artifact, all different from owner
BUILDING_HERMITAGE 4 3 unique eras, all art, all from different civs
BUILDING_OXFORD_UNIVERSITY 1 2 writing, unique eras, all different from owner
BUILDING_SISTINE_CHAPEL 3 2 same era, all art, all from same civ
BUILDING_LOUVRE 5 4 unique eras, equal art-artifact, all from different civs
BUILDING_GREAT_LIBRARY 2 2 writing, unique eras, all from different civs
BUILDING_SYDNEY_OPERA_HOUSE 1 2 music, unique eras, all from same civ
BUILDING_UFFIZI 6 3 same era, all art, all from same civ
BUILDING_GLOBE_THEATER 3 2 writing, same era, all from same civ
BUILDING_BROADWAY 2 3 music, same era, all from same civ

I have noted what type of great works the buildings or wonders have only when the great works slots are not for art or artifacts.

Note that the Museum building has multiple theming bonus entries in the <Building_ThemingBonuses> table, and therefore has multiple AIPriority settings associated with it.

Since the Hermitage world wonder has a much higher AI Priority than any of the Museum AI Priorities, AI players will be much more likely to attempt to fill-out the theming bonus requirement for the Hermitage than for the Museum. The AI players will be much more likely to try to fulfill the theming bonus requirements for the Globe Theater or Great Library world wonders than they will be to fulfill the Oxford University theming bonus. They must still have the correct types of great works from the eras and civilizations as required by the various bonuses, but when they have all they need and can make a choice between getting the Oxford University theming bonus or the Globe Theater theming bonues, they'll go for the Globe Theater theming bonus.

You should tend to bear this chart in mind structuring the amount of theming bonus your buildings or wonders give, and the value of the AI Priority you assign to your theming bonus(es).

Proper Format for the various Theming Bonus Commands:

(click spoiler button to see)

Spoiler :

Each entry in the <Building_ThemingBonuses> table can only have one of the following two era commands:

Code:

<SameEra>true</SameEra>
<UniqueEras>true</UniqueEras>

Each entry in the <Building_ThemingBonuses> table for buildings or wonders with Great Works of Art or Artifacts slots can contain only one (1) of the following three commands that specify the combination of Art and/or Artifacts.
Entries in the <Building_ThemingBonuses> table for buildings or wonders with Great Works of Writing or Great Works of Music should not contain any of the following three commands:

Code:

<MustBeArt>true</MustBeArt>
<MustBeArtifact>true</MustBeArtifact>
<MustBeEqualArtArtifact>true</MustBeEqualArtArtifact>

Each entry in the <Building_ThemingBonuses> table can only have one of the following four "which civilization" commands.:

Code:

<RequiresOwner>true</RequiresOwner>
<RequiresAnyButOwner>true</RequiresAnyButOwner>
<RequiresUniquePlayers>true</RequiresUniquePlayers>
<RequiresSamePlayer>true</RequiresSamePlayer>

When you wish to leave the civilization requirements "wide-open", simply omit any of these requirements.

LeeS · May 2, 2014

THEMING BONUS TABLE AS USED IN-GAME BY FIRAXIS: The Museum Building

The Museum building has multiple sets of condtions that can be met, any one of which will grant a theming bonus to the museum built in an individual city. A Museum built elsewhere within the same empire might also have a qualfiying set of artworks or artifacts that fulfill the exact same set of criteria, or that have a different set of criteria, and therefore qualify for one of the other theming bonuses that can be applied to a Museum.

Here is the Theming Bonus Table for the Museum. I have added comments pulled from the chart above to show which conditions are being applied with each of the entries in the <Building_ThemingBonuses> table:

(click on the spoiler button)

Spoiler :

Code:

<Building_ThemingBonuses>
	<!-- requires same era, all art, all from the Museum owner's civilization -->
	<Row>
		<BuildingType>BUILDING_MUSEUM</BuildingType>
		<Description>TXT_KEY_THEMING_BONUS_MUSEUM_1</Description>
		<Bonus>2</Bonus>
		<SameEra>true</SameEra>
		<MustBeArt>true</MustBeArt>
		<RequiresOwner>true</RequiresOwner>
		<AIPriority>2</AIPriority>
	</Row>
	<!-- requires same era, all art, all from civilizations different from the Museum's owner -->
	<Row>
		<BuildingType>BUILDING_MUSEUM</BuildingType>
		<Description>TXT_KEY_THEMING_BONUS_MUSEUM_1</Description>
		<Bonus>2</Bonus>
		<SameEra>true</SameEra>
		<MustBeArt>true</MustBeArt>
		<RequiresAnyButOwner>true</RequiresAnyButOwner>
		<AIPriority>2</AIPriority>
	</Row>
	<!-- requires same era, all artifact, all from the Museum owner's civilization -->
	<Row>
		<BuildingType>BUILDING_MUSEUM</BuildingType>
		<Description>TXT_KEY_THEMING_BONUS_MUSEUM_2</Description>
		<Bonus>2</Bonus>
		<SameEra>true</SameEra>
		<MustBeArtifact>true</MustBeArtifact>
		<RequiresOwner>true</RequiresOwner>
		<AIPriority>2</AIPriority>
	</Row>
	<!-- requires same era, all artifact, all from civilizations different from the Museum's owner -->
	<Row>
		<BuildingType>BUILDING_MUSEUM</BuildingType>
		<Description>TXT_KEY_THEMING_BONUS_MUSEUM_2</Description>
		<Bonus>2</Bonus>
		<SameEra>true</SameEra>
		<MustBeArtifact>true</MustBeArtifact>
		<RequiresAnyButOwner>true</RequiresAnyButOwner>
		<AIPriority>2</AIPriority>
	</Row>
	<!-- requires same era, all art, no conditions regarding civilizations -->
	<Row>
		<BuildingType>BUILDING_MUSEUM</BuildingType>
		<Description>TXT_KEY_THEMING_BONUS_MUSEUM_3</Description>
		<Bonus>1</Bonus>
		<SameEra>true</SameEra>
		<MustBeArt>true</MustBeArt>
		<AIPriority>1</AIPriority>
	</Row>
	<!-- requires same era, all artifact, no conditions regarding civilizations -->
	<Row>
		<BuildingType>BUILDING_MUSEUM</BuildingType>
		<Description>TXT_KEY_THEMING_BONUS_MUSEUM_4</Description>
		<Bonus>1</Bonus>
		<SameEra>true</SameEra>
		<MustBeArtifact>true</MustBeArtifact>
		<AIPriority>1</AIPriority>
	</Row>
	<!-- requires same era, no conditions on art or artifact, all from the Museum owner's civilization -->
	<Row>
		<BuildingType>BUILDING_MUSEUM</BuildingType>
		<Description>TXT_KEY_THEMING_BONUS_MUSEUM_5</Description>
		<Bonus>1</Bonus>
		<SameEra>true</SameEra>
		<RequiresOwner>true</RequiresOwner>
		<AIPriority>1</AIPriority>
	</Row>
	<!-- requires same era, no conditions on art or artifact, all from civilizations different from the Museum's owner -->
	<Row>
		<BuildingType>BUILDING_MUSEUM</BuildingType>
		<Description>TXT_KEY_THEMING_BONUS_MUSEUM_6</Description>
		<Bonus>1</Bonus>
		<SameEra>true</SameEra>
		<RequiresAnyButOwner>true</RequiresAnyButOwner>
		<AIPriority>1</AIPriority>
	</Row>
	<!-- requires all art, all from the Museum owner's civilization -->
	<Row>
		<BuildingType>BUILDING_MUSEUM</BuildingType>
		<Description>TXT_KEY_THEMING_BONUS_MUSEUM_7</Description>
		<Bonus>1</Bonus>
		<MustBeArt>true</MustBeArt>
		<RequiresOwner>true</RequiresOwner>
		<AIPriority>1</AIPriority>
	</Row>
	<!-- requires all art, all from civilizations different from the Museum's owner -->
	<Row>
		<BuildingType>BUILDING_MUSEUM</BuildingType>
		<Description>TXT_KEY_THEMING_BONUS_MUSEUM_7</Description>
		<Bonus>1</Bonus>
		<MustBeArt>true</MustBeArt>
		<RequiresAnyButOwner>true</RequiresAnyButOwner>
		<AIPriority>1</AIPriority>
	</Row>
	<!-- requires all artifact, all from the Museum owner's civilization -->
	<Row>
		<BuildingType>BUILDING_MUSEUM</BuildingType>
		<Description>TXT_KEY_THEMING_BONUS_MUSEUM_8</Description>
		<Bonus>1</Bonus>
		<MustBeArtifact>true</MustBeArtifact>
		<RequiresOwner>true</RequiresOwner>
		<AIPriority>1</AIPriority>
	</Row>
	<!-- requires all artifact, all from civilizations different from the Museum's owner -->
	<Row>
		<BuildingType>BUILDING_MUSEUM</BuildingType>
		<Description>TXT_KEY_THEMING_BONUS_MUSEUM_8</Description>
		<Bonus>1</Bonus>
		<MustBeArtifact>true</MustBeArtifact>
		<RequiresAnyButOwner>true</RequiresAnyButOwner>
		<AIPriority>1</AIPriority>
	</Row>
</Building_ThemingBonuses>

Elsewhere in the FIRAXIS-supplied game XML are the actual text messages that are displayed when a theming condition has been met and a player mouses over the Museum in the Cultural Overview panel. These messages are contained within a language table, so for the English language they are added to the <Language_en_US> table. The format for these short little pop-up messages is a little different than those modders are generally used to using, in that they contain "wildcard" commands.
The actual text that will be displayed depends on the game era from which the artifacts or artworks came, as well as the civilization that owns the Museum, and/or the civilization from which the artifacts or artworks originated.

To show the manner the actual message will appear, when either of the two conditions for the 1st theming bonus "TXT-KEY" is met the following entry in the <Language_en_US> table will be active:

Code:

<Language_en_US>
	<Row Tag="TXT_KEY_THEMING_BONUS_MUSEUM_1">
		<Text>Museum of {1_EraAdjective} {2_CivAdjective} Art</Text>
	</Row>
</Language_en_US>

The two possible conditions that will activate this message are:

both are artworks from the same era, and from the same civilization as the Museum's owner.
both are artworks from the same era, but are both from civilizations different from the Museum's owner.

The actual message that would be displayed if both works were from the ancient era and from the American civilization is:

Museum of Ancient American Art

The actual message that would be displayed if both works were from the classical era and from the American civilization is:

Museum of Classical American Art

The two entries that apply from the <Building_ThemingBonuses> table are (click on spoiler button below to see):

Spoiler :

Here is the entire <Language_en_US> table for the Museum for the little theming-bonus added pop-up messages, with added comments for which set or sets of conditions activate the pop-up for an individual Museum within a particular city (click on the spoiler button below to see):

Spoiler :

I've added comments as to the requirements that must be fulfilled before each of these would become active in-game.

Code:

<Language_en_US>
	<!-- requires same era, all art, all from the Museum owner's civilization -->
	<!-- requires same era, all art, all from civilizations different from the Museum's owner -->
	<Row Tag="TXT_KEY_THEMING_BONUS_MUSEUM_1">
		<Text>Museum of {1_EraAdjective} {2_CivAdjective} Art</Text>
	</Row>

	<!-- requires same era, all artifact, all from the Museum owner's civilization -->
	<!-- requires same era, all artifact, all from civilizations different from the Museum's owner -->
	<Row Tag="TXT_KEY_THEMING_BONUS_MUSEUM_2">
		<Text>Museum of {1_EraAdjective} {2_CivAdjective} Warfare</Text>
	</Row>

	<!-- requires same era, all art, no conditions regarding civilizations -->
	<Row Tag="TXT_KEY_THEMING_BONUS_MUSEUM_3">
		<Text>Museum of {1_EraAdjective} Art</Text>
	</Row>

	<!-- requires same era, all artifact, no conditions regarding civilizations -->
	<Row Tag="TXT_KEY_THEMING_BONUS_MUSEUM_4">
		<Text>Museum of {1_EraAdjective} Warfare</Text>
	</Row>

	<!-- requires same era, no conditions on art or artifact, all from the Museum owner's civilization -->
	<Row Tag="TXT_KEY_THEMING_BONUS_MUSEUM_5">
		<Text>{1_CivAdjective} Museum of the {2_EraAdjective} Era</Text>
	</Row>

	<!-- requires same era, no conditions on art or artifact, all from civilizations different from the Museum's owner -->
	<Row Tag="TXT_KEY_THEMING_BONUS_MUSEUM_6">
		<Text>World Museum of the {1_EraAdjective} Era</Text>
	</Row>

	<!-- requires all art, all from the Museum owner's civilization -->
	<!-- requires all art, all from civilizations different from the Museum's owner -->
	<Row Tag="TXT_KEY_THEMING_BONUS_MUSEUM_7">
		<Text>Museum of {1_CivAdjective} Art</Text>
	</Row>

	<!-- requires all artifact, all from the Museum owner's civilization -->
	<!-- requires all artifact, all from civilizations different from the Museum's owner -->
	<Row Tag="TXT_KEY_THEMING_BONUS_MUSEUM_8">
		<Text>Museum of {1_CivAdjective} Warfare</Text>
	</Row>
</Language_en_US>

THEMING BONUS TABLE AS USED IN-GAME BY FIRAXIS: World Wonders

This is the theming bonus table as used by FIRAXIS for the remainder of the buildings or wonders that FIRAXIS added theming bonuses to (click on the spoiler button):

Spoiler :

Code:

<Building_ThemingBonuses>
	<Row>
		<BuildingType>BUILDING_HERMITAGE</BuildingType>
		<Description>TXT_KEY_THEMING_BONUS_HERMITAGE</Description>
		<Bonus>3</Bonus>
		<UniqueEras>true</UniqueEras>
		<MustBeArt>true</MustBeArt>
		<RequiresUniquePlayers>true</RequiresUniquePlayers>
		<AIPriority>4</AIPriority>
	</Row>
	<Row>
		<BuildingType>BUILDING_OXFORD_UNIVERSITY</BuildingType>
		<Description>TXT_KEY_THEMING_BONUS_OXFORD_UNIVERSITY</Description>
		<Bonus>2</Bonus>
		<UniqueEras>true</UniqueEras>
		<RequiresAnyButOwner>true</RequiresAnyButOwner>
		<AIPriority>1</AIPriority>
	</Row>
	<Row>
		<BuildingType>BUILDING_SISTINE_CHAPEL</BuildingType>
		<Description>TXT_KEY_THEMING_BONUS_SISTINE_CHAPEL</Description>
		<Bonus>2</Bonus>
		<SameEra>true</SameEra>
		<MustBeArt>true</MustBeArt>
		<RequiresSamePlayer>true</RequiresSamePlayer>
		<AIPriority>3</AIPriority>
	</Row>
	<Row>
		<BuildingType>BUILDING_LOUVRE</BuildingType>
		<Description>TXT_KEY_THEMING_BONUS_LOUVRE</Description>
		<Bonus>4</Bonus>
		<UniqueEras>true</UniqueEras>
		<MustBeEqualArtArtifact>true</MustBeEqualArtArtifact>
		<RequiresUniquePlayers>true</RequiresUniquePlayers>
		<AIPriority>5</AIPriority>
	</Row>
	<Row>
		<BuildingType>BUILDING_GREAT_LIBRARY</BuildingType>
		<Description>TXT_KEY_THEMING_BONUS_GREAT_LIBRARY</Description>
		<Bonus>2</Bonus>
		<UniqueEras>true</UniqueEras>
		<RequiresUniquePlayers>true</RequiresUniquePlayers>
		<AIPriority>2</AIPriority>
	</Row>
	<Row>
		<BuildingType>BUILDING_SYDNEY_OPERA_HOUSE</BuildingType>
		<Description>TXT_KEY_THEMING_BONUS_SYDNEY_OPERA_HOUSE</Description>
		<Bonus>2</Bonus>
		<UniqueEras>true</UniqueEras>
		<RequiresSamePlayer>true</RequiresSamePlayer>
		<AIPriority>1</AIPriority>
	</Row>
	<Row>
		<BuildingType>BUILDING_BROADWAY</BuildingType>
		<Description>TXT_KEY_THEMING_BONUS_BROADWAY</Description>
		<Bonus>3</Bonus>
		<SameEra>true</SameEra>
		<RequiresSamePlayer>true</RequiresSamePlayer>
		<AIPriority>2</AIPriority>
	</Row>
	<Row>
		<BuildingType>BUILDING_GLOBE_THEATER</BuildingType>
		<Description>TXT_KEY_THEMING_BONUS_GLOBE_THEATER</Description>
		<Bonus>2</Bonus>
		<SameEra>true</SameEra>
		<RequiresSamePlayer>true</RequiresSamePlayer>
		<AIPriority>3</AIPriority>
	</Row>
	<Row>
		<BuildingType>BUILDING_UFFIZI</BuildingType>
		<Description>TXT_KEY_THEMING_BONUS_UFFIZI</Description>
		<Bonus>3</Bonus>
		<SameEra>true</SameEra>
		<MustBeArt>true</MustBeArt>
		<RequiresSamePlayer>true</RequiresSamePlayer>
		<AIPriority>6</AIPriority>
	</Row>
</Building_ThemingBonuses>

And the <Language_en_US> table for pop-up messages as used by FIRAXIS for the remainder of the buildings or wonders that FIRAXIS added theming bonuses to (click on the spoiler button):

Spoiler :

EXAMPLE THEMING BONUS TABLE FOR A NEW WORLD WONDER: Naval Emporium

In order to test my understanding of the <Building_ThemingBonuses> table I added theming bonuses to a wonder I had been using in my private at-home mods. The wonder I chose to test this on happend to be a coastal-city-only wonder where I had previously added two great works of writing. In this example, therefore, you won't see anything related to artworks or artifact conditions. I set up two different conditions for which different level of bonuses would apply.

Condition #1: had to be from the same era and civilization as the wonder owner, and applied a bonus of "2"
Condition #2: had to be from the different eras but the same civilization as the wonder owner, and applied a bonus of "1"

I had used an XML building name of "BUILDING_EMPORIUM_NAVAL". Here is the <Building_ThemingBonuses> as I created it (click on the spoiler button to see):

Spoiler :

I added this command to my wonder's <Buildings> table:

Code:

<ThemingBonusHelp>TXT_KEY_BUILDING_EMPORIUM_NAVAL_THEMING_BONUS_HELP</ThemingBonusHelp>

This was my <Language_en_US>"table after I added the commands related to theming bonuses (click on the spoiler button):

Spoiler :

The <ThemingBonusHelp> command is added directly as part of the building in the <Buildings> table, but the text you specify does not appear anywhere in-game until the wonder is constructed. The text then only shows as part of the pop-up messages when a player mouses over the theming bonus area of a wonder's great works in the Culture Overview panel.
In order to test that the theming bonus system for my "BUILDING_EMPORIUM_NAVAL" was operating as I had expected, I used the In-Game Editor mod to crank out two Great Writers. After I moved the reulting two Great Works of Writing from where the game had originally placed them, my +2 theming bonus immediately appeared, and the description "Emporium of Medieval American Sea Lore" appeared as part of the theming bonus pop-up info. I had been in the Medieval era and was playing as America.

I could also have structured my <Building_ThemingBonuses> and <Language_en_US> tables as follows and thereby eliminated the need to add anything to my <Language_en_US> table for the theming bonus <Description> TXT_KEY tags (click the spoiler button to see):

Spoiler :

ONE MORE HINT:

Since the amount of information you can enter under the <Language_en_US> table for the <ThemingBonusHelp> tag is somewhat limited, and only appears in-game after the wonder has been constructed, you might want to add a <Strategy> command to your wonder in the <Buildings> table, and then fill in more detailed information about the theming bonus(es) that apply to your wonder. This would allow the player to see what they need to do to get the theming bonus(es) from the very start of the game. Here is how that would effect my commands in the <Language_en_US> table for the BUILDING_EMPORIUM_NAVAL wonder (click on the spoiler button):

Spoiler :

LeeS · May 2, 2014

The next few tables do not appear in the FIRAXIS-supplied "CIV5Buildings.XML" files found in the "Buildings" folder. They are from the "CIV5Beliefs.XML" file in the "Religions" folder. Since these tables affect buildings in one way or another they are included in this guide.

All of the tables shown are Building CLASS tables. If you are adding a new unique building to an existing CLASS of buildings (such as Public Schools) you do not need to add any entries to these building-CLASS tables to get your building to be affected by belief adoptions in the same manner as the "standard" building would be.

I have included a complete listing of the Brave New World beliefs in the file called List_Beliefs.XML

.................................................................................................................................................................................

BELIEF-CONTROLLED BUILDING-CLASS YIELD CHANGES TABLE

The <Belief_BuildingClassYieldChanges> table is used to increase a building's yields based upon the adoption of a religious belief. Any of the belief "types" can be used with this table, whether Pantheon, Founder, Enhancer, etc.
You can use any existing belief with a building, or you can create a new belief and use it to enhance the effect of an existing building. Or, you can create a new building or wonder and use an existing belief to enhance it, or use a new belief you add to the game.

Table Commands:

BeliefType
Specifies the name of the belief that will change a building's yields

BuildingClassType
Specifies the CLASS of the building for which yields are to be changed.

YieldType
Specifies the type of Yield that will be changed.
Any of the following yield-types can be used with this table:

YIELD_GOLD
YIELD_PRODUCTION
YIELD_SCIENCE
YIELD_CULTURE
YIELD_FOOD
YIELD_FAITH

"TOURISM" cannot be stated as a yield-type in this table. There is an entirely separate beliefs table for that function.

YieldChange
Specifies the amount of the change to the building's yield.

Appropriate buildings:
"Regular" buildings, National Wonders, and World Wonders would all be appropriate for this table, as the effects are determined by the adoption of a belief.

EXAMPLE OF USE:

The example shown is taken directly from the FIRAXIS-supplied XML contained within the "Beliefs.XML" file. It shows how four different beliefs a player can adopt will change the yields of specific buildings. Two of the available beliefs change the yields to Shrines, a third belief changes the yields to Temples, and the fourth belief changes the yields to Amphitheaters. (click the spoiler to see the example)

Spoiler :

.................................................................................................................................................................................

BELIEF-CONTROLLED BUILDING-CLASS HAPPINESS CHANGES TABLE

The <Belief_BuildingClassHappiness> table is used to increase a building's happiness effect based upon the adoption of a religious belief. Any of the belief "types" can be used with this table, whether Pantheon, Founder, Enhancer, etc.

You can use any existing belief with a building, or you can create a new belief and use it to enhance the effect of an existing building. Or, you can create a new building or wonder and use an existing belief to enhance it, or use a new belief you add to the game.

Table Commands:

BeliefType
Specifies the name of the belief that will change a building's happiness yield.

BuildingClassType
Specifies the CLASS of the building to which extra happiness is added.

Happiness
Specifies how much happiness is to be added.

Appropriate buildings:

"Regular" buildings, National Wonders, and World Wonders would all be appropriate for this table, as the effects are determined by the adoption of a belief.

EXAMPLE OF USE:

The example shown is taken directly from the FIRAXIS-supplied XML contained within the "Beliefs.XML" file. It shows how three different beliefs a player can adopt will add happiness to the effects of specific buildings. (click the spoiler button to see the example)

Spoiler :

.................................................................................................................................................................................

BELIEF-CONTROLLED BUILDING-CLASS TOURISM CHANGES TABLE

The <Belief_BuildingClassTourism> table is used to increase a building's tourism effect based upon the adoption of a religious belief. Any of the belief "types" can be used with this table, whether Pantheon, Founder, Enhancer, etc.

You can use any existing belief with a building, or you can create a new belief and use it to enhance the effect of an existing building. Or, you can create a new building or wonder and use an existing belief to enhance it, or use a new belief you add to the game.

Table Commands:

BeliefType
Specifies the name of the belief that will change a building's tourism yield.

BuildingClassType
Specifies the CLASS of the building to which extra tourism is added. The buildings effected do not need to already have a tourism effect.

Tourism
Specifies how much tourism will be added.

Appropriate buildings:

"Regular" buildings, National Wonders, and World Wonders would all be appropriate for this table, as the effects are determined by the adoption of a belief.

EXAMPLE OF USE:

The example shown is taken directly from the FIRAXIS-supplied XML contained within the "Beliefs.XML" file. It shows how the "Religious Art" Belief will add 5 tourism to the Hermitage National Wonder. (click on the spoiler button to see the example)

Spoiler :

.................................................................................................................................................................................

BELIEF-CONTROLLED BUILDING-CLASS PURCHASES TABLE

The <Belief_BuildingClassFaithPurchase> table is used to control which beliefs allow the faith-purchase of which buildings.

You can use any existing follower, founder, enhancer or reformation belief to allow the purchase of a new building, or you can create a new belief and use it to allow the purchase of an existing building.

The game does not care how many different beliefs "unlock" the same building, nor does it care how many buildings are unlocked by the same belief. All the game cares about is whether or not the belief is a Pantheon belief. Pantheon beliefs will not work in this table. The game will not crash, it will simply ignore entries of a pantheon belief.

Table Commands:

BeliefType
Specifies the name of the belief that allows purchasing a building with faith. The game will ignore any specification of a pantheon belief.

BuildingClassType
Specifies the CLASS of the building for which faith-purchasing will be allowed.

EXAMPLE OF USE:

The example shown is taken directly from the FIRAXIS-supplied XML contained within the "Beliefs.XML" file. It shows how the "Cathedrals" Belief allows the faith purchase of Cathedrals, the "Mosques" Belief allows the faith purchase of Mosques, the "Pagodas" Belief allows the faith purchase of Pagodas, and the "Monasteries" Belief allows the faith purchase of Monasteries. It also shows how the Reformation Belief "Jesuit Education" allows the faith purchase of later-game educational buildings. (click the spoiler button to see the example)

Spoiler :

ADDITIONAL NOTE:

I also tested whether a reformation belief will allow additional buying of buildings with faith (as is done with Jesuit Education), and it does work. Nor does the game seem to care much which buildings are added. Factories, Workshops, Libraries, Amphitheaters, Opera Houses all worked when I experimented with them.

I have not experimented with special case buildings such as Harbors or Watermills to see how these buildings work or do not work.

LeeS · May 2, 2014

The next few tables do not appear in the FIRAXIS-supplied "CIV5Buildings.XML" files found in the "Buildings" folder. They are from the "CIV5Policies.XML" file in the "GameInfo" folder. Since these tables affect buildings in one way or another they are included in this guide.

These tables are all Building CLASS tables. If you are adding a new unique building to an existing CLASS of buildings (such as Barracks) you do not need to add any entries to these tables to get your building to be affected by policy adoptions in the same manner as the "standard" building would be.

I have included a complete listing of the Brave New World social policies in the file called List_Policies.XML
.................................................................................................................................................................................

POLICY-CONTROLLED BUILDING-CLASS YIELD CHANGES TABLE

The <Policy_BuildingClassYieldChanges> table is used to make adoption of social policies change building yields. This is done using the CLASS of the building, rather than the simple building name.

Table Commands:

PolicyType
Specifies the policy that will change the yields of a building.

BuildingClassType
Specifies the CLASS of building for which yields will be changed.

YieldType
Specifies the type of yield that will be changed.
Any of the following yield-types can be used with this table:

YIELD_GOLD
YIELD_PRODUCTION
YIELD_SCIENCE
YIELD_FOOD
YIELD_FAITH

"YIELD_CULTURE" and "YIELD_TOURISM" should not be used as yield-types in this table.

YieldChange
Specifies the amount of change to the yield.

Appropriate buildings:

"Regular" buildings, National Wonders, and World Wonders would all be appropriate for this table, as the effects are local to the city.

EXAMPLE OF USE:

Here is a portion of the table as is used in the FIRAXIS-supplied XML. It shows how the Social Policy "POLICY_ORGANIZED_RELIGION" changes the Faith yield of Shrines by +1, how the Social Policy "POLICY_MERCANTILISM" changes the Science yield of Mints by +1, and how the Social Policy "POLICY_MERCHANT_NAVY" changes the Gold yield of Harbors by +1. (click the spoiler button to see the example)

Spoiler :

.................................................................................................................................................................................

POLICY-CONTROLLED BUILDING-CLASS PRODUCTION MODIFIERS TABLE

The <Policy_BuildingClassProductionModifiers> table is used to increase the rate at which specific buildings are constructed, based upon the adoption of a specified social policy or policy branch.

Appropriate buildings:

"Regular" buildings, National Wonders, and World Wonders would all be appropriate for this table, since all this table does is speed the production of stated specific buildings.

NOTE: This table is only used to speed the production of the buildings specified. It does not allow a "production modifier effect" in the city once the building has been constructed.

Table Commands:

PolicyType
Specifies the name of the social policy (or branch) that allows the increase in building construction.

BuildingClassType
Specifies the CLASS of the building for which construction will be accelerated.

ProductionModifier
Specifies the PERCENTAGE of production increase for the CLASS of building stated in BuildingClassType.

EXAMPLE OF USE:

The example shown is taken directly from the FIRAXIS-supplied XML contained within the "Policies.XML" file. It shows how the adoption of various policies (or policy branches) speed the construction of specific buildings. Note that the Piety Branch "unlocker" is itself considered a "policy" by the game, the name for which is POLICY_PIETY.

POLICY_PIETY increases production of BUILDINGCLASS_SHRINE and BUILDINGCLASS_TEMPLE by 100%.
POLICY_CULTURAL_CENTERS increases production of BUILDINGCLASS_MONUMENT by 50%.
POLICY_PROFESSIONAL_ARMY increases production of BUILDINGCLASS_BARRACKS by 50%.
POLICY_SOCIALIST_REALISM increases production of BUILDINGCLASS_MONUMENT by 100%.

Spoiler :

.................................................................................................................................................................................

POLICY-CONTROLLED BUILDING-CLASS TOURISM MODIFIERS TABLE

The <Policy_BuildingClassTourismModifiers> table is used to make a building modify CITY tourism yields. It is NOT used to directly modify any tourism the building might generate, nor to directly ADD a yield of tourism to the building.

Table Commands

PolicyType
Specifies the policy that will make a building modify city tourism.

BuildingClassType
Specifies the CLASS of building that will modify city tourism.

TourismModifier
Specifies the percentage amount of modification to city tourism.

Appropriate buildings:

"Regular" buildings, National Wonders, and World Wonders would all be appropriate for this table, as the effects are local to the city.

EXAMPLE OF USE:

This is the full listing of the table as is used by FIRAXIS. The example of this table shows how the Social Policy "POLICY_MEDIA_CULTURE" makes the Broadcast Tower building bump city tourism yields by 34% ; essentially, this is a one-third upward bump in city tourism. In a city where there is no tourism being generated, there is no effect.

Code:

<Policy_BuildingClassTourismModifiers>
	<Row>
		<PolicyType>POLICY_MEDIA_CULTURE</PolicyType>
		<BuildingClassType>BUILDINGCLASS_BROADCAST_TOWER</BuildingClassType>
		<TourismModifier>34</TourismModifier>
	</Row>
</Policy_BuildingClassTourismModifiers>

.................................................................................................................................................................................

POLICY-CONTROLLED BUILDING-CLASS HAPPINESS CHANGES TABLE

The <Policy_BuildingClassHappiness> table is used to make adoption of social policies increase (or add) happiness to specific buildings.

Table Commands:

PolicyType
Specifies the policy that will add happiness to a building.

BuildingClassType
Specifies the CLASS of building for which happiness will be added.

Happiness
Specifies the amount of the happiness addition.

Appropriate buildings:

"Regular" buildings, National Wonders, and World Wonders would all be appropriate for this table, as the effects are local to the city.

EXAMPLE OF USE:

Here is a portion of the table as is used in the FIRAXIS-supplied XML. It shows how a few different buildings have happiness added by adoption of social policies.

"POLICY_NAVAL_TRADITION" adds one (1) happiness to Harbors.
"POLICY_UNIVERSAL_HEALTHCARE_F" the Freedom Ideology "Healthcare Policy" adds one (1) happiness to the Grand Temple National Wonder.
"POLICY_UNIVERSAL_HEALTHCARE_O" the Order Ideology "Healthcare Policy" adds one (1) happiness to the empire's Palace.
"POLICY_UNIVERSAL_HEALTHCARE_A" the Autocracy Ideology "Healthcare Policy" adds one (1) happiness to the empire's Palace.

(click on the spoiler button to see the example)

Spoiler :

.................................................................................................................................................................................

POLICY-CONTROLLED BUILDING-CLASS YIELD MODIFIERS TABLE

The <Policy_BuildingClassYieldModifiers> table is used to make the adoption of a social policy have a modifying effect on overall city yields. The specified social policy must be adopted by a player AND the building must exist in the city before any city yields modification will occur.

Table Commands:

PolicyType
Specifies the Social Policy required to make a building modify city yields.

BuildingClassType
Specifies the CLASS of building for which a yield modification is to be stated.

YieldType
Specifies the type of city yield that will be modified.
Any of the following yield-types can be used with this table:

YIELD_GOLD
YIELD_PRODUCTION
YIELD_SCIENCE
YIELD_CULTURE
YIELD_FOOD
YIELD_FAITH [[i need to re-verify for faith]]

"TOURISM" cannot be stated as a yield-type in this table.

YieldMod
Specifies the PERCENTAGE modification that will occur.

Appropriate buildings:

"Regular" buildings, National Wonders, and World Wonders would all be appropriate for this table, as the effects are local to the city.

EXAMPLE OF USE:

Here is a portion of the table as is used in the FIRAXIS-supplied XML. It shows how a few different buildings create modifications of city yields by adoption of social policies.

"POLICY_FREE_THOUGHT" creates a 17% bump in SCIENCE yields if Universities or Wats have been constructed in cities.
"POLICY_THEOCRACY" creates a 25% bump in GOLD yields if Temples, Burial Tombs, or Mud Pyramid Mosques have been constructed in cities.
"POLICY_WORKERS_FACULTIES" creates a 25% bump in SCIENCE yields if Factories have been constructed in cities.

(click on the spoiler button to see the example)

Spoiler :

.................................................................................................................................................................................

POLICY-CONTROLLED BUILDING-CLASS CULTURE YIELD CHANGES TABLE

The <Policy_BuildingClassCultureChanges> table is used to make adoption of social policies increase (or add) culture to specific buildings.

Table Commands:

PolicyType
Specifies the policy that will change culture yield of a building.

BuildingClassType
Specifies the CLASS of building for which culture yields will be changed.

CultureChange
Specifies the amount of the culture change.

Appropriate buildings:

"Regular" buildings, National Wonders, and World Wonders would all be appropriate for this table, as the effects are local to the city.

EXAMPLE OF USE:

Here is the table as is used in the FIRAXIS-supplied XML. It shows how adopting the TRADITION policy branch adds 3 CULTURE to the palace building. This is the mechanic used to make adoption of the TRADITION social policy branch add culture in the empire's capital. "POLICY_TRADITION" is the social policy a player actually adopts when they "unlock" the TRADITION social policy branch. For the purposes of XML-tables, the game treats the "unlocker" policies as just another normal social policy.

Code:

<Policy_BuildingClassCultureChanges>
	<Row>
		<PolicyType>POLICY_TRADITION</PolicyType>
		<BuildingClassType>BUILDINGCLASS_PALACE</BuildingClassType>
		<CultureChange>3</CultureChange>
	</Row>
</Policy_BuildingClassCultureChanges>

LeeS · May 2, 2014

The following tables do not actually do anything. I have experimented with them all and cannot see where any changes ever were enacted by the game based on entries to these tables. Remember that this guide is directed toward the Brave New World expansion.

<Building_FreeSpecialistCounts>
<Building_ResourceFaithChanges>
<Building_ResourceCultureChanges>

The <Building_ResourceFaithChanges> table was added in the Gods & Kings expansion but never actually used by FIRAXIS in the XML.

The <Building_ResourceCultureChanges> table was used with the Civ5 "Vanilla" version of the game. To update an old mod that used this table, simply change the entries to use the <Building_ResourceYieldChanges> table, as shown earlier in this document, and use YIELD_CULTURE as the <YieldType>.

note added 5-17-2014:

A Steam friend of mine noted that he was able to get the <Building_ResourceYieldModifiers> table to function though he said he was having problems with it always working. In my previous testing of this table I was stupidly looking in the wrong place for the table's effects. Once I have had a chance to perform some further tests I will be editing the appropriate portions of this guide to reflect the results of said testing.

.............................................................................................................................
(info on this table will be moved to a more appropriate place once I determine where I can insert it)

RESOURCE-BASED CITY-YIELDS MODIFIER

The <Building_ResourceYieldModifiers> table is used to modify yields such as FOOD and GOLD, and affects only the city where the building is constructed. The modification is a percentage change to the total yield occuring in the city. The modifier adjusts city-level yields directly, and so only shows in the "city yields box" when a player mouses-over a type of yield within the city-yields box. The modification will show as coming "from resources".

In order for entries in this table to have any effect on city yields, the following conditions must all be met:

The Building that modifies yields must 1st be constructed in the city.
A tile with the specified type of resource must be within the workable range of the city and this tile must be within the cultural borders of the empire.
The tile containing the correct resource must NOT HAVE ALREADY BEEN IMPROVED with the usual worker-created tile improvement for the given resource. The TILE IMPROVEMENT must occur AFTER the construction of the BUILDING.

Stacking Effects:

An individual building can only give a modification once for each type of resource. The same building can give a FOOD modification and also give a GOLD modification for the same resource type, but multiple copies of the same resource within the workable range of the city do not stack.

If BUILDING_A gives a +5% FOOD modification for wheat, and there are six copies of wheat being worked by the city, the modification will still only be +5%.
If BUILDING_A gives a +5% FOOD modification for wheat, and a +5% FOOD modification for cattle, the total FOOD modification within the city will be +10% if the city has AT LEAST ONE copy of both wheat and cattle within the workable range of the city.

Appropriate Buildings:

Entries to this table are open-ended in terms of which sort of building an entry is appropriate to. Remember that this table only effects the city that constructed the building.

TABLE COMMANDS

BuildingType
Specifies the building that will make the modification occur.

ResourceType
Specifies the resoiurce that will enhance by a percentage a specified type of total city yield.

YieldType
Specifies the type of city-yield to be modified.
Yield Types that work with this table are:

YIELD_FOOD
YIELD_GOLD
YIELD_PRODUCTION
YIELD_SCIENCE

Yield Types that DO NOT work with this table are:

YIELD_CULTURE
YIELD_FAITH
"Tourism" cannot be used in this table since it is not a Yield as defined by the game.

Yield
Specifies the amount of modification as a PERCENTAGE.

EXAMPLE

If I were adding a new building called a Basillica, and I wanted it to bump city food yields by 5% after a source of wheat is improved I would have a <Building_ResourceYieldModifiers> table as follows:

Code:

<Building_ResourceYieldModifiers>
	<Row>
		<BuildingType>BUILDING_BASILLICA</BuildingType>
		<ResourceType>RESOURCE_WHEAT</ResourceType>
		<YieldType>YIELD_FOOD</YieldType>
		<Yield>5</Yield>
	</Row>
</Building_ResourceYieldModifiers>

LeeS · May 2, 2014

GUIDE FOR CHANGING FIRAXIS-SUPPLIED BUILDINGS XML
(Supplement to Buildings Guide)

INTRODUCTION:

In this supplement to the to the main portion of this guide I'll discuss methods for changing the XML of FIRAXIS-supplied buildings and wonders. I will be making the assumption that you have read through the Buildings Guide to a sufficient extent that you at least understand the concepts of the various XML tables that relate to buildings and wonders. I am not expecting that you will be a grand master class expert at everything presented in the previously.

(I)

Where previously I made the assumption that everything presented was done as if something new was being added to the game, this supplement by necessity is based on the assumption that I am changing what already exists in the game as supplied by FIRAXIS. This supplement will therefore more commonly make use of <Update> commands than it will of <Row> commands.

(II)

In order to change what already exists in the XML you really do need to know what it is that already exists. This requires that you familiarize yourself with where the various FIRAXIS-supplied XML files and folders are, and what folders contain what sort of information. For the Brave New World expansion of the game the file path for finding the XML on your computer is:

C:\Program Files (x86)\Steam\SteamApps\common\Sid Meier's Civilization V\assets\DLC\Expansion2\Gameplay\XML

This is as it is structured on my Windows8 computer. If you have a Windows7 machine, your full file path might vary a little bit from the filepath I've shown. All of the FIRAXIS-supplied information for the Buildings tables is contained within a further subfolder called "Buildings". So, the full file path for that folder is:

C:\Program Files (x86)\Steam\SteamApps\common\Sid Meier's Civilization V\assets\DLC\Expansion2\Gameplay\XML\Buildings

I suggest you make a shortcut to the overall XML folder or to the Buildings folder, and place it on your desktop to make it easier to return to the FIRAXIS-supplied Buildings folder. Once you find the overall XML folder on your computer you could also copy everything in the "XML" folder and paste it into your "My Documents" to make it even easier to find again later on. If you decide to use this method, make sure you COPY the "...\XML" folder rather than "CUT" the folder.

Once you've navigated to and found the "...\Gameplay\XML\Buildings" folder you will see 6 files within it. The files are

CIV5BuildingClasses.xml
CIV5BuildingClasses_Expansion2.xml
CIV5BuildingClasses_Inherited_Expansion2.xml
CIV5Buildings.xml
CIV5Buildings_Expansion2.xml
CIV5Buildings_Inherited_Expansion2.xml

Files #1, #2, and #3 define building classes, and the last three define actual buildings. When FIRAXIS published the Brave New World expansion to the game they adopted the convention of assigning designations of XML file names with "_Expansion2" at the end signifying information (such as buildings) that is new with the Brave New World expansion, and file names with "_Inherited_Expansion2" at the end signifying information (such as buildings) that was first introduced in the Gods & Kings expansion and may or may not have been changed with the Brave New World expansion. Files without these extras added to the name contain information that came with the original game (Vanilla Civ5) and in many cases the information has been changed in the Brave New World expansion.

Since the Workshop building was part of the original game, you would look in file #4 (CIV5Buildings.xml) to find the Brave New World version of the Workshop building. Since Constabularies and Police Stations were introduced in the Gods & Kings expansion, you would look in file #6 (CIV5Buildings_Inherited_Expansion2.xml) for the Brave New World versions of the Constabulary and Police Station. You would look in file #5 (CIV5Buildings_Expansion2.xml) for the XML of Hotels and Caravansaries. Wherever you see these extensions to the XML file names, the convention I've explained applies.

(III)

Commands that will be discussed in this supplement are:

<Update>
<Set>
<Where>
<Replace>
<Delete>

(IV)

As Derek "Kael" Paxton (available here -> http://kael.civfanatics.net/files/ModdersGuide.pdf) and "Ceej12" (available here -> http://steamcommunity.com/sharedfiles/filedetails/?id=120875856) have already created guides to operating ModBuddy I will expect you to refer to those so far as the procedures required to create a mod in ModBuddy is concerned. Once you have created a mod and are ready to enter XML commands into it, you are ready to use the reference information I will present here.

(V)

The information shown here uses the game-tables that relate to buildings. But the commands, structure, syntax, and methods demonstrated apply to all of the game XML-tables, whether those tables are for buildings, or units, or promotions, or what have you.

MAKING CHANGES TO THE FIRAXIS XML: <Update> , <Where> , and <Set>

(I) What is <Update> ?

When you wish to create a mod that will alter the XML as supplied by FIRAXIS you go about creating your mod in the ModBuddy program just as if you were going to create an entirely new building. But when you add your XML commands to your mod, the structure and syntax of the commands you use will be slightly different from that you use to add something completely new to the game. The vast majority of the time you will be using a command called <Update> rather than the <Row> command you should be familiar with. <Update> literally tells the game you are going to "update" (or "change") the XML-information that FIRAXIS supplied with the game.

(II) Structuring an <Update>

To use the <Update> command, you first have to know which game-table you are going to be making changes to, as well as the "entry" (Row) you are going to alter. For example, if I want to change the effects of the Workshop to make it add 20 % production in a city instead of the usual 10 %, I have to know where that original XML-command that adds the 10 % is located in terms of which XML game-table it appears within. When a building creates a percentage modification to city yields, that will be located in the <Building_YieldModifiers> table. So, I would look in the file "CIV5Buildings.xml" (because the Workshop building was supplied with the original version of the game) for the <Building_YieldModifiers> table. In this table I would find the following entry:

Code:

<Row>
	<BuildingType>BUILDING_WORKSHOP</BuildingType>
	<YieldType>YIELD_PRODUCTION</YieldType>
	<Yield>10</Yield>
</Row>

Since I want to change this so that the "Yield" is now "20" instead of the old "10", I need to tell the game that my change to the game rules will be to the <Building_YieldModifiers> table. First, of course, I need the <GameData> command to tell the game I am adding new information to the game. Then I tell the game I am going to make changes to the information it has in the <Building_YieldModifiers> table. I do this by simply adding the command <Building_YieldModifiers> underneath my <GameData> command. These are the first two lines of my mod (the line numbers "1=", "2=", etc., are not something you include in your actual mods):

Code:

1=	<GameData>
2=		<Building_YieldModifiers>

Now I am ready to begin changing the settings that FIRAXIS supplied for the Workshop building. I do this first by adding an <Update> command for line "3=". This tells the game to change information it already has registered under the <Building_YieldModifiers> table:

Code:

1=	<GameData>
2=		<Building_YieldModifiers>
3=			<Update>

Next I add a <Where> command to tell the game literally where to make the changes to the <Building_YieldModifiers> table. I fill in the "where" by stating BuildingType="BUILDING_WORKSHOP":

Code:

1=	<GameData>
2=		<Building_YieldModifiers>
3=			<Update>
4=				<Where BuildingType="BUILDING_WORKSHOP"/>

By adding the "/" at the end of line #4, I am telling the game that I am finished defining "where" to make the changes. I do need the " characters at the beginning and end of BUILDING_WORKSHOP.

Now I need to tell the game what changes to make. I do this by using the <Set> command. The <Set> commands writes over the top of whatever was already there, so it does not matter what was already there. This means that I make my "setting" in this next line "20", not "10" (as if I were adding 10 to what was already there).

Code:

1=	<GameData>
2=		<Building_YieldModifiers>
3=			<Update>
4=				<Where BuildingType="BUILDING_WORKSHOP"/>
5=				<Set Yield="20"/>

Just as for the <Where> command, adding the "/" at the end of line #5 tells the game that I am finished defining what changes I wish to "set". Again, I need the " characters at the beginning and end of 20.

Since I am done with my changes to the game rules, I need to 1st close-out the <Update> command, then the <Building_YieldModifiers> table, and finally the <GameData>:

Code:

1=	<GameData>
2=		<Building_YieldModifiers>
3=			<Update>
4=				<Where BuildingType="BUILDING_WORKSHOP"/>
5=				<Set Yield="20"/>
6=			</Update>
7=		</Building_YieldModifiers>
8=	</GameData>

If the Workshop building made more than one change to city yields in the <Building_YieldModifiers> table, then line #4 would tell the game to make changes to both or all of these city yields. To take care of that possibility I can adjust my <Where> command in line #4 so that only changes to "BUILDING_WORKSHOP" and "YIELD_PRODUCTION" are made. I would make those changes as shown here:

Code:

4=	<Where BuildingType="BUILDING_WORKSHOP" YieldType="YIELD_PRODUCTION"/>

When you stack multiple conditions in your <Where> command the game will only make changes to entries that match-up to all of the conditions you specify. If there is no "match-up" to even one of your conditions, the <Set> command will not do anything since all of the conditions required in the <Where> command are not satisfied. Using this altered line #4 instead of the one I first showed, and taking out all the line numbers, the 8 lines of my mod would be:

Code:

<GameData>
	<Building_YieldModifiers>
		<Update>
			<Where BuildingType="BUILDING_WORKSHOP" YieldType="YIELD_PRODUCTION"/>
			<Set Yield="20"/>
		</Update>
	</Building_YieldModifiers>
</GameData>

Here is an alternative method I can use to accomplish the exact same effect on the game:

Code:

<GameData>
	<Building_YieldModifiers>
		<Update>
			<Where BuildingType="BUILDING_WORKSHOP" YieldType="YIELD_PRODUCTION"/>
			<Set>
				<Yield>20</Yield>
			</Set>
		</Update>
	</Building_YieldModifiers>
</GameData>

Or, I can state the Set command before the Where command:

Code:

<GameData>
	<Building_YieldModifiers>
		<Update>
			<Set Yield="20"/>
			<Where BuildingType="BUILDING_WORKSHOP" YieldType="YIELD_PRODUCTION"/>
		</Update>
	</Building_YieldModifiers>
</GameData>

So far as the game is concerned there is no difference between these three methods of stating my <Update>.

(III) <Where> and <Set> pairs within the <Update>.

You can only have one set of <Where> and <Set> commands between one <Update> opener command and its required </Update> closer command. The following is an example of what is not allowed because it violates this rule:

Code:

<GameData>
	<Building_YieldModifiers>
		<Update>
			<Set Yield="20"/>
			<Where BuildingType="BUILDING_WORKSHOP" YieldType="YIELD_PRODUCTION"/>

			<Set Yield="20"/>
			<Where BuildingType="BUILDING_LONGHOUSE" YieldType="YIELD_PRODUCTION"/>
		</Update>
	</Building_YieldModifiers>
</GameData>

You have to make your code be two <Update> commands, like this:

Code:

<GameData>
	<Building_YieldModifiers>
		[COLOR="Blue"]<Update>[/COLOR]
			<Set Yield="20"/>
			<Where BuildingType="BUILDING_WORKSHOP" YieldType="YIELD_PRODUCTION"/>
		[COLOR="blue"]</Update>[/COLOR]

		[COLOR="blue"]<Update>[/COLOR]
			<Set Yield="20"/>
			<Where BuildingType="BUILDING_LONGHOUSE" YieldType="YIELD_PRODUCTION"/>
		[COLOR="blue"]</Update>[/COLOR]
	</Building_YieldModifiers>
</GameData>

NOTE: In providing this example I did not check existing code to see whether "BUILDING_LONGHOUSE" would need an <Update> to "YIELD_PRODUCTION". I was only interested in clarification to you of how you must structure multiple groups of <Where> and <Set>.

MAKING CHANGES TO THE FIRAXIS XML: <Row>

(I) Changes that use the <Row> command:

There are times when I want to change the effects of an existing building, but I would use the <Row> command instead of the <Update> command. I do this when the change to the building effects adds something "new" to a game table.

The Workshop adds 2 hammers (Production) directly to the city yields in addition to its 10 % increase in overall city production. It does not, however, directly add any culture points to the city. If I want to add +1 Culture as a direct effect of the Workshop building, I would do that in the <Building_YieldChanges> table. First, by looking at the existing entries in this table for the Workshop, I see that there is only one entry, and that is for the +2 Production a Workshop adds to a city's yields. Here is that entry in the <Building_YieldChanges> table:

Code:

<Building_YieldChanges>
	<Row>
		<BuildingType>BUILDING_WORKSHOP</BuildingType>
		<YieldType>YIELD_PRODUCTION</YieldType>
		<Yield>2</Yield>
	</Row>
</Building_YieldChanges>

If I want to add a +1 Culture bump to the Workshop, I will not change anything about the existing entry for extra Production. Instead, I will add a new entry that adds +1 Culture to the <Building_YieldChanges> table for the Workshop. I do so by 1st stating the <GameData> command and then the <Building_YieldChanges> command to tell the game I am going to give it some changes to the pre-existing <Building_YieldChanges> table:

Code:

1=	<GameData>
2=		<Building_YieldChanges>

Since I wish to add a NEW entry to the <Building_YieldChanges> table (not change an existing entry) I use the <Row> command instead of the <Update> command.

Code:

1=	<GameData>
2=		<Building_YieldChanges>
3=			[COLOR="Red"]<Row>[/COLOR]

Next, I add a line telling the game the Workshop building will have a new "yield change":

Code:

1=	<GameData>
2=		<Building_YieldChanges>
3=			<Row>
4=				[COLOR="red"]<BuildingType>BUILDING_WORKSHOP</BuildingType>[/COLOR]

Then I specify the type of yield I want to add (Culture in this example):

Code:

1=	<GameData>
2=		<Building_YieldChanges>
3=			<Row>
4=				<BuildingType>BUILDING_WORKSHOP</BuildingType>
5=				[COLOR="red"]<YieldType>YIELD_CULTURE</YieldType>[/COLOR]

For the next line, I tell the game how many culture points (per turn) to add to the city yields:

Code:

1=	<GameData>
2=		<Building_YieldChanges>
3=			<Row>
4=				<BuildingType>BUILDING_WORKSHOP</BuildingType>
5=				<YieldType>YIELD_CULTURE</YieldType>
6=				[COLOR="red"]<Yield>1</Yield>[/COLOR]

Finally, I add three more lines to "close-out" the open row, table, and game data:

Code:

1=	<GameData>
2=		<Building_YieldChanges>
3=			<Row>
4=				<BuildingType>BUILDING_WORKSHOP</BuildingType>
5=				<YieldType>YIELD_CULTURE</YieldType>
6=				<Yield>1</Yield>
7=			[COLOR="red"]</Row>[/COLOR]
8=		[COLOR="red"]</Building_YieldChanges>[/COLOR]
9=	[COLOR="red"]</GameData>[/COLOR]

Shown next is the actual text I would type into my mod, without the line numbers:

Code:

<GameData>
	<Building_YieldChanges>
		<Row>
			<BuildingType>BUILDING_WORKSHOP</BuildingType>
			<YieldType>YIELD_CULTURE</YieldType>
			<Yield>1</Yield>
		</Row>
	</Building_YieldChanges>
</GameData>

MAKING CHANGES TO THE FIRAXIS XML: Mixing of <Row> and <Update>

(I) Mixing of <Row> and <Update> Commands:

The game software does not limit you to choosing to use either <Update> or <Row> commands within the same XML-file, or within the same mod. You can and often do "mix and match" the commands within the same mod, or even within the same game-table within the same mod. Nor is there a requirement within mods that all commands be related. You can have commands that alter existing buildings in the same file as commands that add or adjust a unit promotion or a religious belief or a social policy.

Both of the example adjustments to the Workshop that I demonstrated previously could be added within the same mod. My mod would look like this, with line numbers added for later discussion (click the spoiler button):

Spoiler :

Given that I've already discussed these two alterations to the Workshop building, I will only add a few comments here related specifically to changes I made when merging them together.

The first and most obvious change is that I move my command to close out <GameData> to the very end. The </GameData> commmand is moved to line # 16 because I only need to specify </GameData> when I am completely done adding XML to an individual file within my mod.
In line # 7, I still need to close the </Building_YieldModifiers> table before I can move on to make changes or additions to the <Building_YieldChanges> table.
Line # 8 is a blank line that I put in between the two tables to make it easier for me to read my XML later on. This is a habit I generally employ between game tables. The game software allows you to leave blank lines without any actual effect on XML commands. Nor do you have to enter any special sort of code or commmand to tell the game that you are leaving a blank line. I don't generally leave a blank line between the opening <GameData> command and the command for the first game table I am going to change, so there is no blank line between line #1 and line #2. Nor do I usually leave a blank line between the closing command of my last game table and my </GameData> command. But you can leave blank lines in both these places if it makes it easier for you to read your XML.

To show what the XML woould actually look like in a functional mod, I have removed the line numbers and shown that below (click on the spoiler button):

Spoiler :

I could save this in an XML-file and build my mod in ModBuddy for play at home, or I could go ahead and publish my mod to the steam workshop. If I only use the mod in private, at home, there's really no problem with that. But if I publish the mod to the steam workshop, there's no way for the player to know, in-game, what the altered Workshop building does. So, before I can consider this as being a completely done mod, I need to think about adding in-game text-commands to my mod. The procedures for that will be covered next.

XML (Advanced) Guide to Adding Buildings and Wonders to Brave New World

Imperator

Imperator

Imperator

Imperator

Imperator

Imperator

Imperator

Imperator

Imperator

Imperator

Imperator

Imperator

Imperator

Imperator

Imperator

Imperator

Imperator

Imperator

Imperator

Imperator

Similar threads