Export descr buildings.txt (RTW Modding)

Summary

This article is based on The Complete EDB Guide for Rome:Total War the original article was written by Dol Guldur and imported with his permission as part of the Scriptorium project. The article may have been altered since import - please refer to the history page for details of changes, or reference the original document.

This is an in-depth explanation of the export_descr_buildings.txt file, which is the primary base for modding buildings and determining which units can be recruited from them.

Dol Guldur put the original article together for his own reference, but decided to open it up to all, with the request that they also aid in improving and adding to it. If you are not at all familiar with the basics of the EDB file then you should become so before reading this. The file works alongside a good few other files and may not have the desired effect if these associated files are not modded.

Please help make this the one-stop source for EDB-related information. This Wiki article can be updated to include further information but please also post your comments, corrections and additions in the general forum of the Org RTW Workshop in this discussion thread.

This later edited by Suppanut with more updated data.

Hidden resources

The file begins proper with a declaration of the hidden resources. You may have up to 64 of these. They should all be listed here. The file seems to accept both space- and comma-separated lists. Do not use a hidden_resource in the EDB file and forget to declare it as this will result in a crash to desktop (CTD). It is reported that the rome hidden resource must be kept as the game uses it when checking victory conditions. These hidden resources can be assigned to regions in the descr_regions.txt file.

Building Trees

You will then find listed in the EDB file the building tree for each building type complete with a block of code for each building. You may have up to 64 such trees with a maximum of 9 levels (buildings) each though spread over a maximum of 5 settlement levels (though buildings attached to villages will not show up on the building browser). You can read more about this in the thread initiated by Black Crow

The tree initiates with a declaration of the building type. Here's the beginning of the tree that lists buildings which provide archers and other missile units...

 building missiles 
 { 
 levels practice_field archery_range catapult_range siege_engineer 
 {

the first line is the building type. After the opening curly bracket the levels of that building type are listed (space-delimited and with "levels" preceeding).

You can designate your own names for the building type should you wish to not make them universally available to all factions/cultures. However, core_buildings (aka government buildings), walls and hinterland buildings (roads, mines, and farms) cannot be factionally or culturally designated (though some of their levels may be excluded from certain cultures/factions).

For example, you could have:

 building missiles_roman 
 { 
 levels practice_field archery_range catapult_range siege_engineer 
 {

Which of course could be used to specify a purely roman tree of such buildings. Name of level could be changed but require proper description and text lines in export_buildings.txt.

 Note 1: There are 3 hardcoded building trees which must always included in export_descr_buildings.txt, "core_building", "port_buildings", and "defenses". All these 3 buildings trees contain special function which set by hardcoded (upgrade settlement, trigger sea trade, upgrade complicate wall function in battle map). If not including them in, game would give error warning of missing building tree and exit before reaching main menu.

Building Blocks - Requirements

The tree then lists a block of code for each building (i.e. each of the levels declared). Continuing from our example above we will look at the first level of the "building missiles" tree, the practice_field:

 practice_field requires factions { barbarian, ct_carthage, eastern, parthia, egyptian, greek, roman, }
 {

The first line states the requirements necessary to be satisfied in order for the building to be available for construction. All factions defined in descr_cultures.txt, and so this particular building can be built by all factions. Any combination of factions/cultures can be listed. Both visible and hidden resources can be used as requirements as may "building_present_min_level x y" where x is the building type and y the level of that building type. This latter simply requires a certain minimum level of building of a building type to be present in that settlement before the practice_field can become available for construction. The connector "and" can be used to compound requirements, for example:

 practice_field requires factions { barbarian, roman, } and resource iron and hidden_resource woodland 
 and building_present_min_level market trader
 {

List of Requirements' Conditions for Buildings

"factions { x, }" (x = faction id or culture id or "all", detect if for faction as mentioned)

"resource x" (x = trade resource as defined in descr_sm_resources.txt and placing by descr_strat.txt, detect if specified trade resource exists in region or not)

"hidden_resource x" (x = hidden resource as declared in earlier part of export_descr_buildings.txt and assigned from descr_regions.txt, detect if specified hidden resource exists in region or not)

"building_present x" (x = name of building tree, detect if building in that building tree exists or not, considered to be less load for engine than its counterpart below)

"building_present_min_level x y" (x = name of building tree, y = name of building level, detect if building in the building tree x in the settlement exists at the same level or higher than y, considered to be more load for engine than its counterpart above)

"marian_reforms" (detect if marian_reforms event has already triggered or not) Connectors

Conditions can be combined by using connectors. These work in a similar way to mathematics' set logic but only "requires", "and", "or", and "not" are available.

"x requires y" Declaration of condition, x = building level or recruitment or bonus or religious_belief, y = the rest of condition. Each line requires this part to be declared once (and not more than once).

"x and y" Set intersection, both condition x and condition y must be true to be valid

"x or y" Set union, either condition x, condition y, or both conditions must be true to be valid. A point to note is that if the first condition x is made up of multiple parts, only its last part interchanges with y. On the other hand, the second condition y is always treated as a single block even if made of many parts. Examples below...

"x and a and b or c and d" In this case only condition "b" would interchange with condition "c and d"

"x and a or b or c and d" In this case condition "a" would interchange with condition "b" and also interchange with condition "c and d"

"not x" Set inversion, condition x must be false to be valid, "not" must always put behind "requires" or "and" or "or" as it cannot be used alone.

 Note 2: Not conditionals can result in problems with the display of the building in the building browser. If used in a building requirement it would cause this building to not appear at all in building browser. If it is using in the capability part, it would prevent that particular bonus line from ever being displayed in building browser even if the condition is valid.

The basic connectors "and/or" and "not" could allow the modder to create conditions up to a certain degree of complexity, some conditions turn out to be much more elaborate than others to implement with a system as simple as this. To find out more about how to use requirements and connectors take look at this thread.

If this building is not the first building in the building tree, both its building condition and the upgrade condition of the previous building above it (for detail, see below) must be met for the player to be allowed build it. This allows more complex upgrade conditions included branching of building tree.

 Note 3: Not conditionals (even if true) and positive conditionals that result false seem to break the culture/faction for the slave faction if those buildings are placed at game start - see this thread.

 Note 4: All of the above can be used as capability requirements too though the building_present/building_present_min_level should not be used as it will cause a CTD when the player uses the right-click feature added in later versions of RTW. This could be circumvented by the "conceal line" bug/exploit by adding not as part of condition. If use for recruitment capability, that building must not contain any bonus capability (except "religious_belief" which work differently from other capabilities) or it would cause a CTD even if recruitment line is properly concealed from display.

 Note 5: Slave faction does not use the condition that is defined for its faction but instead uses the conditions of the faction defined as its subfaction for each particular settlement (in game tooltips subfactions are mentioned inside () ). So there cannot be any building which exclusive for the slave faction in game. But slave faction condition still requires for building requirement condition (see Note 6:)

 Note 6: Building condition for a particular building tree must work like a pyramid scheme, lower level buildings must cover all the requirements of buildings above them, at least nominally, and this including slave faction which never uses those conditions in game. If condition is not covered it leads to a warning message about "gap" after exit. This warning error is not a serious bug on its own but it blocks all other errors the game may detect by internal parsing from being displayed (it would only display the first error message) thus it makes it more difficult to debug. Therefore, fixing this problem is recommended. 
 This can be fixed by creating a loop condition or dummy condition which would make an undesirable condition nominally valid, but in a way that it would never be valid in game. Here are some examples of conditions which are valid nominally but never in game (just as planned) such as putting in a condition that requires a resource or hidden resource which never doesn’t exist in front of an "or" condition, follow by the actual condition the modder want to execute. This method may lead to display of building in browser even if modder not want to but this could be avoided by clever way of placing "not" in the valid condition. This can be put directly into direct building requirement line or put on upgrade line (see below).

Building Blocks - Capability

Example:

 capability
 {
 recruit "carthaginian peltast" 0 requires factions { spain, }
 recruit "barb peltast gaul" 0 requires factions { gauls, }
 recruit "barb peltast german" 0 requires factions { germans, }
 recruit "barb slinger briton" 0 requires factions { britons, }
 recruit "barb archer dacian" 0 requires factions { dacia, }
 recruit "barb archer scythian" 0 requires factions { scythia, }
 recruit "carthaginian peltast" 0 requires factions { carthage, }
 recruit "carthaginian archer" 0 requires factions { numidia, }
 recruit "east peltast" 0 requires factions { armenia, pontus, }
 recruit "east slinger" 0 requires factions { parthia, }
 recruit "egyptian peltast" 0 requires factions { egyptian, }
 recruit "egyptian slingers" 0 requires factions { egyptian, }
 recruit "greek peltast" 0 requires factions { greek, }
 recruit "roman velite" 0 requires factions { roman, }
 recruit "roman light infantry auxillia" 0 requires factions { roman, } and hidden_resource gondor
 recruits_morale_bonus bonus 1 requires factions { dacia, }
 }

The Capability section lists the capabilities (i.e. the recruitment capability and building effects) of any given settlement which contains this building. Capability could be divide into 3 categories, recruit, bonus, religious_belief. Each of them have their own rules about conditioning.

 Note 7: Capability in single building in the settlement could not have active valid effect entries trigger more than 32 at the same time, if there are more than 32 recruit/effect entries active in the same building in the settlement at the same time, CTD would occur.

Recruitment

The pool of potential requirements that can be attached to both recruitment and effect lines are basically the same as those used for the building's construction requirement.

 recruit "unit's type" x

The "unit's type" is unit name as defined in export_descr_unit.txt. Don't confuse it with unit's dictionary

The "x" listed with recruits refers to the level of Experience the unit begins with when first recruited. It can of course be any number between 0 and 9.

Special condition in case condition served as bonus to enhance already exist recruitment line

 recruit "unit's type" bonus x

This condition would not generate recruitment option but would modified exp of current active recruitment condition of specific type of unit instead.

Conditions for recruitment lines:

"factions { x, }" (x = faction id or culture id or "all", detect if for faction as mentioned)

"resource x" (x = trade resource as defined in descr_sm_resources.txt and placing by descr_strat.txt, detect if specified trade resource exist in region or not)

"hidden_resource x" (x = hidden resource as declared in earlier part of export_descr_buildings.txt and assigned from descr_regions.txt, detect if specified hidden resource exist in region or not)

"marian_reforms" (detect if marian_reforms event has already triggered or not)

"building_factions { x, }" (x = culture id, "slave", or "all", detect if faction as stated here build this building. This condition is complicate due to in RTW engine only display culture of builder but condition still valid on faction level. Faction "slave" is useful for loophole below)

Note 8: Although slave shared every line with normal faction it act as subfaction in that settlement, slave could have their own exclusive unitsby give condition for recruit units which that faction could not own in export_descr_unit.txt but slave could under that faction's conditions. In reverse, modder could lock some units out of slave recruitment by removed slave ownership in export_descr_unit.txt

Conditions for recruitment lines which requires additional consideration:

"building_present x" (x = name of building tree, detect if building in that building tree exist or not, considered to be less load for engine than its counterpart below)

"building_present_min_level x y" (x = name of building tree, y = name of building level, detect if building in that building tree exist at the same level or higher than one it specified or not, considered to be more load for engine than its counterpart above)

"Building_present"/"building_present_min_level" should be avoid as they will cause a CTD for 2 reasons. First is building browser display bugs which could be circumvent by "conceal line" bug/exploited by add not as part of condition. Second is recruitment which condition building as condition must not share the same building with other bonus capability (except "religious_belief") or it would cause CTD even if recruitment line is properly concealed from display.

"Concealed capability line" Bug/Exploited

As state above, capability line which contain "not" as part of valid condition would not show on building browser even if bonus is valid on settlement, and in reverse, any line without "not" would also cause line to always show up as long as faction is right. This could lead to exploits by using condition which always valid even if "not" is part of it to hide the line or using condition which always invalid but not have not as part of it to create dummy bonus line for display purpose but not give real bonus.

Example of universal concealed line condition: - "not building_factions { slave, }" (hide the line due to "not" is part of valid condition but always valid due to slave never use such condition anyway)

Example of dummy line condition: - "building_factions { slave, }" (condition is valid but would never fulfilled anyway as slave never use their own line) - "hidden_resource x" (with x = hidden resource which defined but never assigned anywhere)

Building Bonus/Effects

Bonus/effects has two forms of conditioning

Declaration Condition (ready to use bonus)

"<effect> x <requires conditions>" (x = integer)

Modification Condition (not count as bonus/effect on its own, but could modified exist declaration condition in settlement)

"<effect> <bonus> x <requires conditions>" (x = + or - number)

Effects which need to declared before start modification (need to use declaration condition to set value first, higher one would replacing lower one, to increase or decrease value requires modificaton condtion line)

• farming_level (due to attached visual effect, 1/2/3+ = 33%/66%/100% of arable land in region on strategy map becomes farmland)
• mine_resource (due to attached visual effect of convert gold and silver resource into mine, it is requires before mining income become useable)
• road_level (due to attached visual effect, 0 = dirt road, 1 = paved road, 2+ = highways
• stage_games (due to it is acting as feature switch)
• stage_races (due to it is acting as feature switch)
• upgrade_bodyguard (due to it is acting as feature switch)
• gate_strength (due to it is acting as feature switch)
• gate_defences (due to it is acting as feature switch)
• tower_level (due to it is acting as feature switch)
• wall_level (due to it is acting as feature switch)
• trade_fleet (due to this is blank dummy bonus which only have display effect, real bonus is hardcoded on port_buildings tree)
• armour
• weapon_simple
• weapon_bladed
• weapon_missile
• weapon_siege
• weapons_other
• construction_cost_bonus_military (not seem to works, please report if you found what is it using for)
• construction_cost_bonus_religious (for all building tree with prefix "temple_")
• construction_cost_bonus_defensive (for wall building tree, not sure if it tie to "defences" building tree as hardcode or it tie to wall_level bonus)
• construction_cost_bonus_other (for everything else)
• construction_time_bonus_military (not seem to works, please report if you found what is it using for)
• construction_time_bonus_religious (for all building tree with prefix "temple_")
• construction_time_bonus_defensive (for wall building tree, not sure if it tie to "defences" building tree as hardcode or it tie to wall_level bonus
• construction_time_bonus_other (for everything else)

The rest of effects could stack up bonus from declaration condition on its own negative modification still requires modification condition line

Conditions for Effect lines:

"factions { x, }" (x = faction id or culture id or "all", detect if for faction as mentioned)

"resource x" (x = trade resource as defined in descr_sm_resources.txt and placing by descr_strat.txt, detect if specified trade resource exist in region or not)

"hidden_resource x" (x = hidden resource as declared in earlier part of export_descr_buildings.txt and assigned from descr_regions.txt, detect if specified hidden resource exist in region or not)

"marian_reforms" (detect if marian_reforms event has already triggered or not)

"building_factions { x, }" (x = culture id, "slave", or "all", detect if faction as stated here build this building. This condition is complicate due to in RTW engine only recognized culture of builder, not faction that build it, so although define condition based on faction is valid but result would be awkward, "slave" is exception due to useful loophole below)

Conditions for Effect lines which requires concealed line exploited:

"building_present x" (x = name of building tree, detect if building in that building tree exist or not, considered to be less load for engine than its counterpart below)

"building_present_min_level x y" (x = name of building tree, y = name of building level, detect if building in that building tree exist at the same level or higher than one it specified or not, considered to be more load for engine than its counterpart above)

List of valid bonus and effects:

• population_growth_bonus (pop. growth) 1-25 (0.5-12.5% growth bonus)
• population_health_bonus (public health) 1-25 (0.5-12.5% growth bonus from health and 5-125% happiness due to health)

dinarii base farming incomes) [5]

• happiness_bonus (public order due to happiness) 1-25 (5-125% public order bonus)
• law_bonus (public order bonus due to law) 1-25 (5-125% public order bonus, reduce corruption)
• trade_base_income_bonus (increases trade goods) 1-32767 (add 10-327670% to trade income from both land and sea, +10% per level) (source: experimentation; Suppanut)
• taxable_income_bonus (tax income bonus) 1-32767 (add 10-327670 to taxable income directly) (source: experimentation; Suppanut)
• trade_level_bonus (increase in land trade) 1-32767 (add 100-3276700% to base land trade income, calculate from land trade base without any road upgrade, +100% per level) (source: experimentation; Suppanut)

• recruits_exp_bonus (upgrades XP of units recruited) 1-5 (1-5)
• armour (armour upgrade) 1-3 (1-3)
• weapon_simple (upgrades melee (light) weapons) 1-3 (1-3)
• weapon_bladed (upgrades bladed (heavy) weapons) 1-3 (1-3)
• weapon_missile (upgrades missile weapons) 1-3 (1-3)
• weapon_siege (upgrades siege weapons) 1-3 (1-3) (no localization display)
• weapons_other (upgrades "other" weapons) 1-3 (1-3) (no localization display)
• bodyguard (improves general's bodyguard) ? * (comes into effect only after Marian Reforms)

• farming_level (farms) (farms and food pruduction improvement) 1-25 (0.5-12.5% growth bonus from food and 80-2000 *mine_resource (income from mining) 1-32767 (set mine value to 50-1638350, convert into income by multiply by mine resource*summation of gold&silver's trade value in the region*0.1) (source: experimentation; Suppanut)
• road_level (improved roads and trade) 0-3 (0-3) (0 = dirt road, 1 = paved road & +100% land trade income, 2 = highways & 200% land trade income, 3 = highways & +300% land trade income, all calculated from base land trade income) (source: experimentation; Suppanut)

• gate_strength (gates) 0-2 (0 = wooden, 1 = reinforced, 2 = iron-bound)
• gate_defences (gate defence) 0-1 (0 = none, 1 = scorched sand/boiling oil)
• tower_level (towers) 0-2 (0 = arrow, 1 = fire arrow, 2 = scorpion/ballista)
• wall_level (walls) 0-4 (0 = palisade, 1 = wooden, 2 = stone, 3 = large stone, 4 = epic stone unless modder modified buildings in descr_engine.txt and descr_building_battle.txt)

• stage_games (allows gladiatorial games) 1-3 (1-3) [5]
• stage_races (allows races) 1-2 (1-2) [5]

• construction_cost_bonus_military (percentile cost reduction for recruitment buildings but does not seem to work) 1-100 (1-100%)
• construction_cost_bonus_religious (percentile cost reduction for temples) 1-100 (1-100%)
• construction_cost_bonus_defensive (percentile cost reduction for walls) 1-100 (1-100%)
• construction_cost_bonus_other (percentile cost reduction for civil buildings but seems to apply to all buildings except religious ones) 1-100 (1-100%)
• construction_time_bonus_military (percentile time reduction for constructing recruitment buildings but does not seem to work) 1-100 (1-100%)
• construction_time_bonus_religious (percentile time reduction for constructing temples) 1-100 (1-100%)
• construction_time_bonus_defensive (percentile time reduction for constructing walls) 1-100 (1-100%)
• construction_time_bonus_other (percentile time reduction for constructing civil buildings but also seems to apply to all buildings except religious ones) 1-100 (1-100%)

- Special case effect (see below)

• religious_belief [pagan/zoroastrian/christianity] 1-x (5-x%)

- List of untested or bonus that obsolete/not work

• fire_risk (population_fire_risk_bonus entry in strat.txt) (reduces risk of fire) - could not test, fire disaster disable in version 1.5/1.6
• population_loyalty_bonus (public order) - does not appear to work
• recruits_morale_bonus (increases morale of units recruited) 1-4 (1-4) - no real effect in version 1.5/1.6
• trade_fleet (trade fleets) 1-3 (1-3) [5] - dummy bonus, has no real effect in game

Notes on above list...

[1] wooden are default though not explicitly stated

[2] does not appear to work; stone walls of any kind come with scorched sand/boiling oil

[3] default towers are watchtowers though not explicitly stated

[4] defensive capabilities seems to come with the wall_level regardless of what value they are given! See note below.

[5] see Quietus's A Comprehensive Rome: Total War Guide (Tools & Other Resources) at the end of this Guide.

[6] needs further research because it adds more taxes than it says in the building description.

For example you add taxable_income_bonus 25, in the building description it will say "Tax income bonus: 25%" and with 400 people you would normally get 328 denari now you would get 914 which is an increase of
about 179% but it messes up the tax system. (for more information see: http://forums.totalwar.org/vb/showthread.php?37831-Tax-Income thanks to Therother)

Religious Belief Effects

religious_belief effect is counted as special case as condition could not use "building_present" or "building_present_min_level" as it would cause CTD when trigger the effect no matter modder conceal the line or not. It also could not use along with "bonus" connector too.

• religious_belief [pagan/zoroastrian/christianity] 1-x (5-x%)

Available condition to use for religious_belief effect

"factions { x, }" (x = faction id or culture id or "all", detect if for faction as mentioned)

"resource x" (x = trade resource as defined in descr_sm_resources.txt and placing by descr_strat.txt, detect if specified trade resource exist in region or not)

"hidden_resource x" (x = hidden resource as declared in earlier part of export_descr_buildings.txt and assigned from descr_regions.txt, detect if specified hidden resource exist in region or not)

"marian_reforms" (detect if marian_reforms event has already triggered or not)

"building_factions { x, }" (x = culture id, "slave", or "all", detect if faction as stated here build this building. This condition is complicate due to in RTW engine only recognized culture of builder, not faction that build it, so although define condition based on faction is valid but result would be awkward, "slave" is exception due to useful loophole below)

Building Blocks - Faction_Capability

These are similar to capabilities except they are applied faction-wide rather than just in one settlement (regional). For example, inserting:

 faction_capability
 {
 construction_time_bonus_defensive bonus 50 requires factions { parthia, }
 }

after the Capabilty block of a building (and before the construction line) will, when such a building is built by Parthia, reduce building times of defensive structures (i.e. walls) by half in all Parthian settlements.

Available condition to use for faction_capability section

"factions { x, }" (x = faction id or culture id or "all", detect if for faction as mentioned)

"resource x" (x = trade resource as defined in descr_sm_resources.txt and placing by descr_strat.txt, detect if specified trade resource exist in region or not)

"hidden_resource x" (x = hidden resource as declared in earlier part of export_descr_buildings.txt and assigned from descr_regions.txt, detect if specified hidden resource exist in region or not)

"marian_reforms" (detect if marian_reforms event has already triggered or not)

"building_factions", "building_present", and "building_present_min_level" would cause CTD when using in faction_capability section.

Negative effects

Modder could assign negative number of bonus in modification condition but effect could only able to negate the same bonus from other buildings but bonus itself could not fall below 0 with some exception.

Exception - religious_belief could go into negative value on display in settlement review panel. - recruit exp modification on specific unit could go from 0 to become 9 if negative value go beyond it tolerated level

Cumulative effect in single settlement

Cumulative effects in single settlement could not go beyond hardcode limit of bonus (see effect list above). Game engine could tolerate negative number cumulation in single settlement to some degree but the more negative it become the more CTD would likely to happened. No negative hardcoded has been reported as finding coming ai-only game which stuck until some specific bonus disable or reduced (in case of positive) or increase (in case of negative) but could not recreate it by intentionally set condition to that value at the start of campaign play by human player. From opinion of wiki author, growth, health, farm, and religious_belief should not have negative effect cumulation lower than -4 in single settlement which coming from result of testing ai-only game in Extended Cultures V.

Building Blocks - End

The end of each building block comprises the construction time (in turns), the cost, the minimum level of settlement necessary for the building in question to be built, and upgrades (if any). Note that the latter is quite correct to be in the plural - you can list more than one upgrade (top-level buildings should of course have no upgrade listed). Modification of "upgrades" section could help in create complex building condition (see section below).

 construction 3 
 cost 1200 
 settlement_min large_town 
 upgrades 
 { 
 archery_range 
 } 
 }

Upgrades Section

Upgrades section allow building tree to be branching and allow branching of building condition easier. Even if modder don't want to branch the building, it still allow more complicate building condition by section condition into several pieces similar to "if/or" condition in coding. In order to able to build next level of building, condition on both upgrades part and building part must be truth.

Example 1: Branching upgrade.

 upgrades 
 { 
 elite_archery_range requires building_present_min_level barracks city_barracks
 catapult_range requires building_present_min_level smiths foundry
 archery_stadium requires building_present_min_level market great_forum
 } 
 }

This would allow branching condition inside the same building tree, in this case, 3 choices.

Example 2: Branching condition of the same buildings.

 upgrades 
 { 
 catapult_range requires hidden_resource a and hidden_resource d
 catapult_range requires hidden_resource b and hidden_resource e
 catapult_range requires hidden_resource c and hidden_resource f
 } 
 }

Condition (a and d) or (b and e) or (c and f) not possible due to limit of how to use "or" in RTW engine but would be possible with using of upgrades section.

Note 8: Pyramid scheme inside building tree still need to be fulfilled. Next building entry inside the tree, no matter has upgrades connection or not must have valid pyramid scheme of building condition to prevent "gap between building" warning. This could be easily done by using upgrade line exclusive express lene of condition as mentioned in Note 5:.

The End of Building Tree

You will find "plugins" section at the very end of the building trees - ignore these, they cannot be implemented.

Note on Barbarian Building Trees

Although factions in the barbarian culture apparently can be designated 4th and 5th level settlements at game start there seems no mechanism for triggering upgrading past a third level settlement in the game itself. In other words the Barbarian culture is limited in its upgrades to (from a village) town - large town - city. It cannot upgrade to large or huge cities. You can read more about this in this thread. Of course, in BI this has all changed and all cultures may upgrade through all five government buildings.

Note on Building Names & Descriptions

The names and textual descriptions of all buildings (inc. the universal ones such as core_buildings) can all be specified per faction (as can building requirements, capabilities and faction capabilities of course). Dol Guldur has written a tutorial on this.

Temples & Indestructibility of Buildings

Hardcoded building trees prefix which add special property to building tree are....

- "temple_" (make building tree with this prefix are mutually exclusive from one another)

- "hinterland_" (make building indestructable, but also make building unrepairable too which is one of reason why flood disaster is disable in RTW)

By change "temple_" prefix to something else, game would nolonger treat that building as part of interchangable "temple_" set. If change all of them, player would be able to construct several temples at at the same time (but edit related text file is required for building to operate properly)

Following this same logic we can now add the "hinterland_" prefix to building tree names to make previously destructible buildings indestructible - that is, it will disable the hammer button in the building scroll.

Note on Associated Files

data\export_buildings.txt

This file lists the in-game textual description of the building name, the building description, and a short version of the building description. It should match the code name in the EDB.

This file also contains the "_name" elements which provide the text for the building thread summaries (i.e. the text for each building type in the in-game Building Browser).

data\text\export_descr_buildings_enums.txt

This file enumerates the tags for the textual descriptions of the building names and descriptions (long and short). It seems to be an obsolete file.

data\descr_ui_buildings.txt

From discussion thread (thanks to Nikolai1962):

bunch of lines in this file of the form temple_of_battle_shrine shrine temple_of_battle_temple temple temple_of_battle_large_temple large_temple temple_of_battle_awesome_temple awesome_temple temple_of_battle_pantheon pantheon temple_of_farming_shrine shrine what these all do is give the game an alternative name to look for when loading a building graphic. so in vanilla in tells the game for all the different temple buildings all the shrine level ones load the shrine graphic etc. This can save on the number of graphics you have to keep track of, rename etc. For example if you had modded the game to have seperate barracks for each of the barb factions called brit_barracks, gaul_barracks etc, instead of having a separate graphic for each one you could write brit_barracks barracks gaul_barracks barracks etc. in this file and the game will look for the graphic called "#barbarian_barracks" in the UI folder/pak file.

Nero666 reports that deleting either of the lines referencing Carthaginian near the start of the list in the DUB file will overcome the problem of not being able to add that culture to new buildings without causing an error. For more information please see link below: LINK: https://www.twcenter.net/forums/showthread.php?t=13734

Tools & Other Resources

Required programmes: Notepad (or other text editor)

Optional tools: Hadrian building editor, Excel macro for recruit lines

EDB Recruit Lines Excel Macro by Godless Graham http://forums.totalwar.org/vb/showthread.php?t=49448

Hadrian building editor by GodsPetMonkey https://www.twcenter.net/downloads/db/?mod=245

Quietus's A Comprehensive Rome: Total War Guide (visit Economic section to read how buildings affect trade) http://forums.totalwar.org/vb/showthread.php?t=45315

External Links

Related Posts:

• Complex conditionals for recruiting and building
• A quick question from a modding newbie
• Additional capabilities and requirements for buildings

Initial content for this article was based on: Org Scriptorium Article Posted here with the permission of the original author: Dol Guldur Please note that the content may have been altered since import. Subsequent amendments are welcome but are not the responsibility of the original author.