Chapter 2: Dynamic modifiers, effects, collections and arguments 2017-01-13

[NycholusV]

This is the second chapter of my guide on modifiers, explaining the underlying anatomy of the modifiers system including dynamic modifiers (modifier types), effects and collections.

Moderator Action: link to compromised site removed

I apologise for how long it's taken to get this second chapter out. I've been very busy working on other civ-related things, such as my map script which is still a work-in-progress.

* * *​

In this chapter, you will learn how to define your own dynamic modifiers, which will allow for a very high degree of versatility in your modding. We will once again be creating a basic ‘balance patch’ as an example for you to follow along with, that will make the following changes:

1. Founding Fathers (America’s special ability) increases the rate of border expansion by 20% in all cities.
2. Mimar Sinan’s (Great Engineer) ability instantly grants +4 Population.

By the end of this chapter, you should be able to:

• Create and implement your own dynamic modifiers.
• Understand what collections and effects are and how they are used by dynamic modifiers.
• Understand how collections and effects relate to each other and to the concept of ‘subjects’.
• Appreciate why creating your own dynamic modifiers is often necessary.
• Determine what modifier arguments are valid for a modifier.

Moderator Action: Chapter 2 content copied below

Download the example mod. Please do not attempt to copy and paste code from this webpage; this will not work due to the way that WordPress formats inverted commas.

In this chapter, you will learn how to define your own dynamic modifiers, which will allow for a very high degree of versatility in your modding. We will once again be creating a basic ‘balance patch’ as an example for you to follow along with, that will make the following changes:

1. Founding Fathers (America’s special ability) increases the rate of border expansion by 20% in all cities.
2. Mimar Sinan’s (Great Engineer) ability instantly grants +4 Population.

By the end of this chapter, you should be able to:

• Create and implement your own dynamic modifiers.
• Understand what collections and effects are and how they are used by dynamic modifiers.
• Understand how collections and effects relate to each other and to the concept of ‘subjects’.
• Appreciate why creating your own dynamic modifiers is often necessary.
• Determine what modifier arguments are valid for a modifier.

Effects and Collections
In the last chapter, we created and implemented modifiers using modifier types predefined in the base game. Now, we are going to move onto defining our own modifier types. The ability to define your own modifier types opens up an even greater degree of flexibility in your modding endeavours. Furthermore, it is important to understand how modifier types work to appreciate the overall anatomy of the modifier system, to assist in debugging, and because they relate to modifier arguments and requirements.

Modifier types are defined in the DynamicModifiers table. It is important to note that dynamic modifier and modifier type are essentially synonymous terms, with DynamicModifiers used as the name of the table, and ModifierType used as the column name. Modifier types consist of two crucial components – an effect and a collection. Effects and collections are the hard-coded roots of the modifier system. The definitions of effects and collections cannot be changed without going beyond the scope of XML/SQL based modding. Thus, modifier types are the most fundamental components that are open to modding.

So what exactly are effects and collections? We’ll start with effects. The effect is the actual change in the game that is applied by the modifier. Be it an increase in border expansion, the granting of a free unit, or a yield bonus – it is the effect that is responsible for taking action and changing something in the game. But what is this something that the effect changes? Well, recall in the last chapter, we talked about the subjects of modifiers being what the modifier applies to. Going deeper into the structure of the modifier system, the subjects are the something that the effect changes. And this is fundamentally what an effect is – it is what a modifier uses to produce a change in the subjects.

But how does the game know what the subjects actually are? This brings us to collections. The subjects of a modifier are actually defined by the collection. A collection is simply a group of entities in the game to which a modifier can apply to, i.e. the valid subjects of a modifier. Remember that the entity-modifier tables determine the owner of the modifier, which is what the modifier is attached to. So the owner of a modifier is determined by the entity-modifier tables and the subjects are determined in the DynamicModifiers table, as collections. But as you will see in the examples, there are many collections which are relative to the owner. For instance, there is a collection called PLAYER_CITIES which refers to all of the cities possessed by the player to whom the modifier is attached. This allows you to attach a modifier to a player (whether it be via a trait, policy, Great Person, etc.) and have the effect applied only to that player’s cities. So, while the owner and the subjects are very distinct concepts, the subjects can be relative to the owner. Of course, it is not the case than any effect can be applied to any collection. If you try creating a dynamic modifier using ADJUST_CITY_GROWTH as the effect and ALL_UNITS as the collection, you will find that this will not work, as it is clearly nonsensical to be “adjusting the city growth rate of a unit”. An exhaustive list of collections can be found in GameEffects.xml, but check out the reference page for collections which also contains detailed explanations for your convenience (coming soon).

As mentioned previously, the effect and the collection are the only two components of a modifier type. A ModifierType simply takes an effect and specifies a collection for it to be applied to. Just as the entries of the Modifiers table can be thought of a particular fashioning of a ModifierType, a ModifierType can be thought of as a particular fashioning of an effect. You can create different modifier types to apply the same effect to all cities, to cities possessed by a player only, to capital cities only, and so on. Hopefully this gives you an appreciation and understanding of the hierarchy of the modifier system. A modifier uses a particular modifier type for a single specific purpose, and a modifier type applies a particular effect on a particular collection. A full list of effects is available in GameEffects.xml. It is intended that a reference page for effects will be available on this website soon, but given the huge number of effects, this will likely take a while.

Let’s briefly summarise the columns of the DynamicModifiers table:

• ModifierType: The name of the modifier type, as referenced in the Modifiers table. The naming convention for modifier type names is to always begin with ‘MODIFIER_’ followed by the name of the collection and then the name of the effect, for example:
  MODIFIER_ALL_CITIES_CULTURE_BORDER_EXPANSION
  MODIFIER_PLAYER_UNITS_ADJUST_HEAL_PER_TURN
  MODIFIER_SINGLE_CITY_GRANT_PRODUCTION_IN_CITY
• CollectionType: The collection that this dynamic modifier applies to, i.e. the valid subjects of the modifier.
• EffectType: The effect that this dynamic modifier applies to its subjects.

Modifier Types
Let’s start working on our balance patch. We’ll begin by filling out the entity-modifier tables like we did in the first chapter.

INSERT INTO TraitModifiers (TraitType, ModifierId)
VALUES (‘TRAIT_CIVILIZATION_FOUNDING_FATHERS’, ‘TRAIT_INCREASED_CULTURE_BORDER_EXPANSION’);INSERT INTO GreatPersonIndividualActionModifiers (GreatPersonIndividualType, ModifierId, AttachmentTargetType)
VALUES (‘GREAT_PERSON_INDIVIDUAL_MIMAR_SINAN’, ‘GREATPERSON_CITY_POPULATION’, ‘GREAT_PERSON_ACTION_ATTACHMENT_TARGET_DISTRICT_IN_TILE’);
Now let’s consider how we’re going to fill in the Modifiers table. To do this we need to know what modifier types we’re going to use. When creating modifiers, always check whether the Modifiers.xml to see whether the ModifierType you intend to use already exists in the base game. It will often be the case that the ModifierType you intend to implement already exists in the base game, as was the case with all the examples in the previous chapter. Consider the first item in our balance patch. How will we know whether or not the appropriate ModifierType already exists in the base game? Remember that a ModifierType is simply defined by a particular effect applied upon a particular collection. In our case, we want to apply an increased rate of a border expansion to all of a player’s cities. So we want a ModifierType with the effect that adjusts the rate of border expansion, and the collection ‘PLAYER_CITIES’. Take a look at the Modifiers.xml file. You might try searching ‘BORDER_EXPANSION’. And sure enough, you’ll find this:

<Row>
<ModifierType>MODIFIER_ALL_CITIES_CULTURE_BORDER_EXPANSION</ModifierType>
<CollectionType>COLLECTION_ALL_CITIES</CollectionType>
<EffectType>EFFECT_ADJUST_CITY_CULTURE_BORDER_EXPANSION</EffectType>
</Row>
Is this the ModifierType we’re looking for? Well, the EffectType looks like it’s correct. But the CollectionType is ‘ALL_CITIES’, which is not what we’re looking for. We want to the collection to be ‘PLAYER_CITIES’. So we have the correct effect, but not the correct collection.

An important referencing technique when searching for a ModifierType is to search the Modifiers.xml file for the EffectType. Doing so will enable you to browse through all the modifier types that use the same effect with a different collection. Now that we know the exact name of the effect we’re looking for, we can do this.

But alas, the ModifierType we just found is the only one that uses the effect we’re looking for. This means that the ModifierType we want to implement does not exist in the base game. This brings us to an important point about the creation of custom modifier types. The sole purpose of creating custom modifier types is to fill in the blanks left by the base game. There are many effect-collection combinations that are not used in the base game, but which are perfectly valid. In our case, the developers needed to create a ModifierType to adjust border expansion in all cities (specifically the Religious Settlements pantheon, of course subject to the requirement that the city follows the pantheon), but it was never necessary in the base game for this effect to apply only to a particular player’s cities. So when creating a modifier, you will want to check the Modifiers.xml file to see if the ModifierType already exists, and if it doesn’t, then you’ll have to create your own.

Let’s create the modifier type for our first component. Remember to stick to the naming conventions. It will make things much easier for you and others adapting or debugging your work.

INSERT INTO DynamicModifiers (ModifierType, CollectionType, EffectType)
VALUES (‘MODIFIER_PLAYER_CITIES_CULTURE_BORDER_EXPANSION’, ‘COLLECTION_PLAYER_CITIES’, ‘EFFECT_ADJUST_CITY_CULTURE_BORDER_EXPANSION’);
There’s one more important thing you need to do to define a custom ModifierType. If you’ve been observant when looking through the Modifiers.xml file, you may already know what it is. As a general rule, anything in the game referred to as a ‘type’ requires an entry in the Types table. As you can see in Modifiers.xml, modifier types are no exception. For our new ModifierType to work, we need to add the following:

INSERT INTO Types (Type, Kind)
VALUES (‘MODIFIER_PLAYER_CITIES_CULTURE_BORDER_EXPANSION’, ‘KIND_MODIFIER’);
Now we’ll finally add the modifier to the Modifiers table. (Note that the order of these entries in your files does not matter; how you structure your mod is up to you.)

INSERT INTO Modifiers (ModifierId, ModifierType)
VALUES (‘TRAIT_INCREASED_CULTURE_BORDER_EXPANSION’, ‘MODIFIER_PLAYER_CITIES_CULTURE_BORDER_EXPANSION’);
Originally, the second component of this balance patch was going to be a change to the inherent government bonus of Theocracy, granting +1 Amenity to all cities with a Temple. But there’s a problem with this, and it’s worth mentioning. In GameEffects.xml, you may have noticed there is an effect named EFFECT_ADJUST_BUILDING_AMENITY. If we wanted to make Temple’s provide Amenities, it would seem that this is the effect to use. We might define a dynamic modifier like this:

INSERT INTO DynamicModifiers (ModifierType, CollectionType, EffectType)
VALUES (‘MODIFIER_PLAYER_CITIES_ADJUST_BUILDING_AMENITY’, ‘COLLECTION_PLAYER_CITIES’, ‘EFFECT_ADJUST_BUILDING_AMENITY’);
But upon testing, one will find that this does not work, and the GameEffects.log file will reveal why. EFFECT_ADJUST_BUILDING_AMENITY is ‘not supported’ by the game, as the log file will plainly state. Be cautioned when defining custom modifier types that there are many effects not used by the game that will simply not work, like this one, and also some that appear to work but are completely mysterious in terms of what they do or how they are to be used.

Let’s move on to the actual second component of the balance patch. We’ll start as we did before, checking to ensure that the appropriate modifier type is not already available in the base game. Remember what to consider when looking for a modifier type – the effect (what the modifier does), and the collection (what the modifier acts upon). You should be able to convince yourself that there is no modifier type that changes the population of a specific single city. However, there are two that are of interest to us:

<Row>
<ModifierType>MODIFIER_PLAYER_CITIES_ADD_POPULATION</ModifierType>
<CollectionType>COLLECTION_PLAYER_CITIES</CollectionType>
<EffectType>EFFECT_ADJUST_CITY_POPULATION</EffectType>
</Row>


…

<Row>
<ModifierType>MODIFIER_PLAYER_NEAREST_CITY_ADD_POPULATION</ModifierType>
<CollectionType>COLLECTION_UNIT_NEAREST_OWNER_CITY</CollectionType>
<EffectType>EFFECT_ADJUST_CITY_POPULATION</EffectType>
</Row>

These both use EFFECT_ADJUST_CITY_POPULATION, which is the effect we want to use. But these are the only modifier types using that effect, and neither of them use the collection we want. We want the adjustment of population to apply to only to a specific single city. The former adjusts the population of all of a player’s cities, and the latter adjusts the population of the city closest to a unit (this is used for the population tribal village). So in this case, we again need to define our own modifier type.

INSERT INTO DynamicModifiers (ModifierType, CollectionType, EffectType)
VALUES (‘MODIFIER_SINGLE_CITY_ADD_POPULATION’, ‘COLLECTION_OWNER’, ‘EFFECT_ADJUST_CITY_POPULATION’);
You may be somewhat confused by this. What is COLLECTION_OWNER? This is a very important collection to be familiar with. What assigning this collection essentially does is it sets the subjects of the modifier to be the owner of the modifier. In other words, what the modifier is attached to is also what it acts upon. In our entity-modifier tables earlier in this chapter, we attached our modifier to a city (remember that the Great Person entity-modifier table works slightly differently to the others, the Great Person attaches a modifier to an entity when its ability is activated). But we also want this modifier to act upon the city itself. For this reason, we use the collection COLLECTION_OWNER. And you may have noticed that in Modifiers.xml, all modifiers that refer to a ‘single city’ also use this collection. Using this collection to set the subjects of a modifier to its owner can be used not only for cities, but for any other entity in the game that a modifier can be attached to.

Don’t forget to add an entry to the Types table:

INSERT INTO Types (Type, Kind)
VALUES (‘MODIFIER_SINGLE_CITY_ADD_POPULATION’, ‘KIND_MODIFIER’);
For the Modifiers table, this is a case where we want to ensure that the modifier only applies once, so we will set the RunOnce and Permanent columns to ‘1’.

INSERT INTO Modifiers (ModifierId, ModifierType, RunOnce, Permanent)
VALUES (‘GREATPERSON_CITY_POPULATION’, ‘MODIFIER_SINGLE_CITY_ADD_POPULATION’, ‘1’, ‘1’);
Determining Modifier Arguments
We still need to do one more thing before our mod will work. As we discussed in the last chapter, many modifiers have arguments that need to be entered into the ModifierArguments table. Remember that these modifiers are assigned to a Modifier, not a modifier type. However, as was also briefly mentioned in the previous chapter, the valid arguments of a modifier are determined not by the modifier, nor the modifier type, but the effect. This is perhaps the most important reason why it is necessary to understand the anatomy of the modifier system down to the level of effects and collections. How do we know what the appropriate arguments for a modifier are? The answer to this is simply cross-referencing the base game code. The valid arguments of a modifier is always based on the effect. Another way of putting this is that all modifiers with the same effect have the same argument specifications. So to find the appropriate arguments for a modifier you are implementing, search the game code for a modifier with the same effect, and see what its arguments are.

Let’s do this for the first component of our balance patch. We want to find out the valid arguments for the effect EFFECT_ADJUST_CITY_CULTURE_BORDER_EXPANSION. First, we need to find a base game modifier type that uses this effect. Recall that the modifier type definitions for the base game are stored in Modifiers.xml. Earlier in the chapter, we found this entry:

<Row>
<ModifierType>MODIFIER_ALL_CITIES_CULTURE_BORDER_EXPANSION</ModifierType>
<CollectionType>COLLECTION_ALL_CITIES</CollectionType>
<EffectType>EFFECT_ADJUST_CITY_CULTURE_BORDER_EXPANSION</EffectType>
</Row>
Of course, if we hadn’t found this already, it would be as easy as searching for the desired EffectType in the file.

So we have MODIFIER_ALL_CITIES_CULTURE_BORDER_EXPANSION as a base game modifier type that uses the same effect. Now we need to find a modifier that uses this modifier type. To do this we will search the entire Base » Assets » Gameplay » Data folder for the modifier type in question. On Windows, there should be a search bar in the top-right of the Explorer window. You may have to select the ‘Search’ tab and ensure that ‘File contents’ is marked under ‘Advanced options’. The search should return two files: Modifiers.xml (the file we were just looking at) and Beliefs.xml. Obviously any base game modifier type is going to appear in Modifiers.xml, but that file only stores the definitions of modifier types. What we’re looking for is a modifier that uses the specified modifier type. If you know Civilization 6 inside-out by now, ‘Beliefs.xml’ should ring a bell – the ‘Religious Settlements’ pantheon. Opening the file and searching the file for our modifier type, you should find this:

<Row>
<ModifierId>RELIGIOUS_SETTLEMENTS_CULTUREBORDER</ModifierId>
<ModifierType>MODIFIER_ALL_CITIES_CULTURE_BORDER_EXPANSION</ModifierType>
<SubjectRequirementSetId>CITY_FOLLOWS_PANTHEON_REQUIREMENTS</SubjectRequirementSetId>
</Row>
So now we have a modifier that uses the same effect as our modifier, and therefore has the same argument specifications as ours. Searching the file for the ModifierId in the entry, you should find this:

<Row>
<ModifierId>RELIGIOUS_SETTLEMENTS_CULTUREBORDER</ModifierId>
<Name>Amount</Name>
<Value>15</Value>
</Row>
And that right there is what we’ve been looking for. One can easily infer that Amount is referring to the percentage increase in border expansion, which is 15 for the Religious Settlements pantheon. With this knowledge, we can now create our entry in the ModifierArguments table.

INSERT INTO ModifierArguments (ModifierId, Name, Value)
VALUES (‘TRAIT_INCREASED_CULTURE_BORDER_EXPANSION’, ‘Amount’, ’20’);
A few points to remember:

• Many effects have more than one argument in their specification. Conversely, some effects have no arguments.
• If a modifier’s arguments are invalid, the GameEffects.log file will say so (as long as you have effects logging set to diagnostic).
• Determining the modifier arguments is just as important if you are using a ModifierType from the base game. In this case, you can simply search for the ModifierType in the Data folder to begin with.

Let’s summarise the steps in determining the modifier arguments of a modifier:

1. Search Modifiers.xml to find a base game ModifierType using the same EffectType as your modifier’s ModifierType. If your modifier itself uses a base game ModifierType, you can skip this step.
2. Search for the base game ModifierType in the Data folder. (Note: It may also be worth checking the DLC folder in the game’s root directory if you can’t find anything. This will become more frequently necessary as more DLCs are released.)
3. Open a file (other than Modifiers.xml) that was returned by the search, and search that file to find a modifier that uses the ModifierType we’ve been looking for.
4. Search the same file for the ModifierId you just found. In doing so you should be able to find the modifier arguments for that modifier. Those arguments are what you need to replicate for your modifier.

Try following these steps once again to determine the valid modifier arguments for the second component of our balance patch.

We are looking for a ModifierType in Modifiers.xml using the EffectType EFFECT_ADJUST_CITY_POPULATION. There are two:

<Row>
<ModifierType>MODIFIER_PLAYER_CITIES_ADD_POPULATION</ModifierType>
<CollectionType>COLLECTION_PLAYER_CITIES</CollectionType>
<EffectType>EFFECT_ADJUST_CITY_POPULATION</EffectType>
</Row>


…

<Row>
<ModifierType>MODIFIER_PLAYER_NEAREST_CITY_ADD_POPULATION</ModifierType>
<CollectionType>COLLECTION_UNIT_NEAREST_OWNER_CITY</CollectionType>
<EffectType>EFFECT_ADJUST_CITY_POPULATION</EffectType>
</Row>

We’ll start by searching for the first one in the Data folder. This returns no results (other than Modifiers.xml). This means that for whatever reason, MODIFIER_PLAYER_CITIES_ADD_POPULATION has been included by the developers in the base game code, but is not actually used anywhere. So let’s try the second one.

This time, the search should return GoodyHuts.xml. Searching the file for the ModifierType again, we find a definition for a modifier, with ModifierId GOODY_SURVIVORS_ADD_POPULATION. Then we search the file for this, and we find:

<Row>
<ModifierId>GOODY_SURVIVORS_ADD_POPULATION</ModifierId>
<Name>Amount</Name>
<Value>1</Value>
</Row>
You should be able to infer from this what our ModifierArguments entry will look like:

INSERT INTO ModifierArguments (ModifierId, Name, Value)
VALUES (‘GREATPERSON_CITY_POPULATION’, ‘Amount’, ‘4’);
And we’re done! Once again, the changes we made in our mod will not be reflected in the game’s text, which is beyond the scope of this guide.

In the next chapter, we’ll discuss how to set up requirements for modifiers, allow you to restrict when an effect takes action on a subject based on a broad variety of parameters.

Previous chapter:
Chapter 1: Creating and attaching modifiers

 

[NycholusV]

Entity-Modifier Tables​

Notes:

• Some tables use ModifierID rather than ModifierId. The reason for this is not apparent.
• The ModifierId/ModifierID column does not have a foreign key restraint.
• In this reference, all columns are text and not null unless other wise specified.

BeliefModifiers
Attaches a modifier to a particular religious belief. Note that requirements must be used in the Modifiers table to restrict the modifier to the religion founder, cities following the religion, or cities following the pantheon.

Columns:

• BeliefType: Identifies the belief from the Beliefs table to attach the modifier to.
• ModifierID: Identifies the modifier that is attached to the belief.

BuildingModifiers
Attaches a modifier to a particular building. The modifier is applied to any location (tile, district, city, etc.) that has the specified building.

Columns:

• BuildingType: Identifies the building from the Buildings table to attach the modifier to.
• ModifierId: Identifies the modifier that is attached to the building.

CivicModifiers
Attaches a modifier to a particular civic. The modifier is applied to any player that has developed the civic.

Columns:

• CivicType: Identifies the civic from the Civics table to attach the modifier to.
• ModifierId: Identifies the modifier that is attached to the civic.

DistrictModifiers
Attaches a modifier to a particular district. The modifier is applied to the location (tile, district, city, etc.) that has the specified district.

Columns:

• DistrictType: Identifies the district from the Districts table to attach the modifier to.
• ModifierId: Identifies the modifier that is attached to the district.

GameModifiers
Attaches a modifier to the game. These modifiers are loaded as soon as a game is started.

Columns:

• ModifierId: Identifies the modifier that is attached to the game.

GoodyHutSubTypes
Not really an entity-modifier table, however, goody huts use modifiers to grant their bonuses, and this table contains a ModifierId column to accommodate for this. The goody hut modifiers used by the base game all have the RunOnce and Permanent columns in the Modifiers table set to true.

Columns:

• GoodyHut: Identifies the goody hut type from the GoodyHuts table to attach the modifier to. Note that name of this column in GoodyHuts is GoodyHutType.
• SubTypeGoodyHut: Identifies the sub-type of goody hut, serving as the primary key of this table.
• Description (nullable): Identifies the text used in the popup upon obtaining this goody hut.
• Weight (integer): Identifies the probability out of 100 that a goody hut of type GoodyHut will turn out to be of this sub-type.
• ModifierID: Identifies the modifier that is attached to the building.
• UpgradeUnit (boolean): Identifies whether or not this goody hut upgrades the unit that obtains it. False by default.
• Turn (integer): Identifies the minimum turn number that this goody hut bonus can be obtained. Zero by default. (I am not sure how or if this is scaled according to game speed.)
• Experience (boolean): Identifies whether or not this goody hut provides experience to the unit that obtains it. False by default.
• Heal (integer): Identifies whether or not this goody hut heals the unit that obtains it. Zero by default. (The precise function of this I am unsure of. GoodyHuts.xml sets this value to ‘4’ for the goody hut that provides a free unit heal.)
• Relic (boolean): Identifies whether or not this goody hut provides a free relic. False by default.
• Trader (boolean): Identifies whether or not this goody provides a free trader. False by default.
• MinOneCity (boolean): Presumably identifies whether or not the goody hut bonus can only be obtained once per city owned by the player. (Verification needed.) False by default.
• RequiresUnit (boolean): (Seems to be associated with goody hut bonuses related to units, but I’m not sure what exactly this does.)

GovernmentModifiers
Attaches a modifier to a particular government. The modifier is applied to any player that has the specified government. This is how both inherent and legacy bonuses are implemented.

Columns:

• GovernmentType: Identifies the government type from the Governments table to attach the modifier to.
• ModifierId: Identifies the modifier that is attached to the government.

GreatPersonIndividualActionModifiers
Attaches a modifier to a particular Great Person action. The modifier is applied when the Great Person’s action is used. Unlike most other entity-modifier attachments, Great Person action modifiers do not necessarily attach to the Great Person unit itself. For this reason, this table contains one extra column, which specifies what the modifier is attached to.

Columns:

• GreatPersonIndividualType: Identifies the Great Person from the GreatPersonIndividuals table to attach the modifier to.
• ModifierId: Identifies the modifier that is attached when the Great Person performs its action.
• AttachmentTargetType: Identifies what the modifier should be attached to. Refer to the list below for the possible values of this column.

Values of AttachmentTargetType used in the game:

• GREAT_PERSON_ACTION_ATTACHMENT_TARGET_DISTRICT_IN_TILE: Attaches the modifier to the district that the Great Person is stationed in.
• GREAT_PERSON_ACTION_ATTACHMENT_TARGET_DISTRICT_WONDER_IN_TILE: Attaches the modifier to the wonder that the Great Person is stationed in.
• GREAT_PERSON_ACTION_ATTACHMENT_TARGET_PLAYER: Attaches the modifier to the player in possession of the Great Person.
• GREAT_PERSON_ACTION_ATTACHMENT_TARGET_UNIT_DOMAIN_MILITARY_IN_TILE: Attaches the modifier to a military unit on the same tile as the Great Person.
• GREAT_PERSON_ACTION_ATTACHMENT_TARGET_UNIT_GREATPERSON: Attaches the modifier to the Great Person him/herself.

GreatPersonIndividualBirthModifiers
Attaches a modifier to a particular Great Person. The modifier is applied to any player that recruits the Great Person.

Columns:

• GreatPersonIndividualType: Identifies the Great Person from the GreatPersonIndividuals table to attach the modifier to.
• ModifierId: Identifies the modifier that is attached to the Great Person.

ImprovementModifiers
Attaches a modifier to a particular tile improvement. The modifier is applied to the tile that has the specified improvement.

Columns:

• ImprovementType: Identifies the improvement from the Improvements table to attach the modifier to.
• ModifierId: Identifies the modifier that is attached to the improvement.

PolicyModifiers
Attaches a modifier to a particular social policy. The modifier is applied to any player that has the specified social policy.

Columns:

• PolicyType: Identifies the social policy from the Policies table to attach the modifier to.
• ModifierId: Identifies the modifier that is attached to the social policy.

ProjectCompletionModifiers
Attaches a modifier to a particular project. The modifier is applied to the location (tile, district, city, etc.) that completes the specified project.

Columns:

• ProjectType: Identifies the project from the Projects table to attach the modifier to.
• ModifierId: Identifies the modifier that is attached to the project.

TechnologyModifiers
Attaches a modifier to a particular technology. The modifier is applied to any player that has researched the technology.

Columns:

• TechnologyType: Identifies the technology from the Technologies table to attach the modifier to.
• ModifierId: Identifies the modifier that is attached to the technology.

TraitModifiers
Attaches a modifier to a particular trait. The modifier is applied to any player that has the specified trait as its special ability or leader bonus.

Columns:

• TraitType: Identifies the trait from the Traits table to attach the modifier to.
• ModifierId: Identifies the modifier that is attached to the specified trait.

UnitAbilityModifiers
Attaches a modifier to a particular unit ability. The modifier is applied to any unit with the ability. Note that unit abilities are distinct from unit promotions.

Columns:

• UnitAbilityType: Identifies the ability from the UnitAbilities table to attach the modifier to.
• ModifierId: Identifies the modifier that is attached to the specified ability.

UnitPromotionModifiers
Attaches a modifier to a particular unit promotion. The modifier is applied to any unit with the promotion.

Columns:

• UnitPromotionType: Identifies the promotion from the UnitPromotions table to attach the modifier to.
• ModifierId: Identifies the modifier that is attached to the specified promotion.

Moderator Action: this post was created to copy the content of the compromised site here -Gedemon

 

[Pusperk]

Perfect guide. I have problem understand this:
I have modifier for improvement dynamics type. This modifier test improvement tile on resource and if this is true,
add second modifier. (Effect_attach_modifier, collection_single_plot_yields)
Second modifier has type (adjust city amenities from religion) with collection type 'owner'.
Function is ok, when build improvement with resource add amenity to city where improvement is build.
Owner first modifier is improvement or plot tile?
Who is owner second modifier? Improvement or city where improvement is build? Who is subject second modifier?
City?
Thanks for guide
Pusperk

 

[NycholusV]

Perfect guide. I have problem understand this:
I have modifier for improvement dynamics type. This modifier test improvement tile on resource and if this is true,
add second modifier. (Effect_attach_modifier, collection_single_plot_yields)
Second modifier has type (adjust city amenities from religion) with collection type 'owner'.
Function is ok, when build improvement with resource add amenity to city where improvement is build.
Owner first modifier is improvement or plot tile?
Who is owner second modifier? Improvement or city where improvement is build? Who is subject second modifier?
City?
Thanks for guide
Pusperk

Could you post your code here?

 

[Pusperk]

Yes.

<GameInfo>
    <Types>
        <!-- Definition new type modifier - dynamic modifier -->
        <Row Type="TCS_MODIFIER_PLOT_ADJUST_CITY_AMENITIES" Kind="KIND_MODIFIER"/>
    </Types>
    <!-- Definition new dynamic modifier -->
    <DynamicModifiers>
        <Row>
            <ModifierType>TCS_MODIFIER_PLOT_ADJUST_CITY_AMENITIES</ModifierType>
            <CollectionType>COLLECTION_SINGLE_PLOT_YIELDS</CollectionType>
            <EffectType>EFFECT_ATTACH_MODIFIER</EffectType>
        </Row>
    </DynamicModifiers>
    <!-- Definition new modifier -->
    <Modifiers>
        <Row>
            <ModifierId>TCS_ADD_AMENITY_FROM_DIAMONDS</ModifierId>
            <ModifierType>MODIFIER_SINGLE_CITY_ADJUST_CITY_AMENITIES_FROM_RELIGION</ModifierType>
            <SubjectRequirementSetId>TCS_CITY_HAS_PALACE_REQUIREMENTS</SubjectRequirementSetId>
        </Row>
        <Row>
            <ModifierId>TCS_ADD_AMENITY_FROM_DIAMONDS_MINE</ModifierId>
            <ModifierType>TCS_MODIFIER_PLOT_ADJUST_CITY_AMENITIES</ModifierType>
            <SubjectRequirementSetId>TCS_HAS_DIAMONDS</SubjectRequirementSetId>
        </Row>
    </Modifiers>
    <ModifierArguments>
    <Row>
            <ModifierId>TCS_ADD_AMENITY_FROM_DIAMONDS_MINE</ModifierId>
            <Name>ModifierId</Name>
            <Value>TCS_ADD_AMENITY_FROM_DIAMONDS</Value>
        </Row>
        <Row>
            <ModifierId>TCS_ADD_AMENITY_FROM_DIAMONDS</ModifierId>
            <Name>Amount</Name>
            <Value>2</Value>
        </Row>
    </ModifierArguments>
    <ImprovementModifiers>
        <Row>
            <ImprovementType>IMPROVEMENT_QUARRY</ImprovementType>
            <ModifierId>TCS_ADD_AMENITY_FROM_DIAMONDS_MINE</ModifierId>
        </Row>
    </ImprovementModifiers>
    <Requirements>
        <Row>
            <RequirementId>TCS_REQUIRES_CITY_HAS_DIAMONDS</RequirementId>
            <RequirementType>REQUIREMENT_PLOT_RESOURCE_TYPE_MATCHES</RequirementType>
        </Row>
        <Row>
            <RequirementId>TCS_REQUIRES_CITY_HAS_PALACE</RequirementId>
            <RequirementType>REQUIREMENT_CITY_HAS_BUILDING</RequirementType>
        </Row>
    </Requirements>
    <RequirementArguments>
        <Row>
            <RequirementId>TCS_REQUIRES_CITY_HAS_DIAMONDS</RequirementId>
            <Name>ResourceType</Name>
            <Value>RESOURCE_STONE</Value>
        </Row>
        <Row>
            <RequirementId>TCS_REQUIRES_CITY_HAS_PALACE</RequirementId>
            <Name>BuildingType</Name>
            <Value>BUILDING_PALACE</Value>
        </Row>
    </RequirementArguments>
    <RequirementSets>
        <Row>
            <RequirementSetId>TCS_HAS_DIAMONDS</RequirementSetId>
            <RequirementSetType>REQUIREMENTSET_TEST_ALL</RequirementSetType>
        </Row>
        <Row>
            <RequirementSetId>TCS_CITY_HAS_PALACE_REQUIREMENTS</RequirementSetId>
            <RequirementSetType>REQUIREMENTSET_TEST_ALL</RequirementSetType>
        </Row>
    </RequirementSets>
    <RequirementSetRequirements>
        <Row>
            <RequirementSetId>TCS_HAS_DIAMONDS</RequirementSetId>
            <RequirementId>TCS_REQUIRES_CITY_HAS_DIAMONDS</RequirementId>
        </Row>
        <Row>
            <RequirementSetId>TCS_CITY_HAS_PALACE_REQUIREMENTS</RequirementSetId>
            <RequirementId>TCS_REQUIRES_CITY_HAS_PALACE</RequirementId>
        </Row>
    </RequirementSetRequirements>
</GameInfo>

 

[NycholusV]

TCS_ADD_AMENITY_FROM_DIAMONDS_MINE

• Owner: Plots, because you have this in ImprovementModifiers.
• Subject(s): Plots, because the modifier type uses COLLECTION_SINGLE_PLOT_YIELDS.

TCS_ADD_AMENITY_FROM_DIAMONDS

• Owner: Plots, because the previous modifier is attaching this one to its subjects.
• Subject(s): Plots, because MODIFIER_SINGLE_CITY_ADJUST_CITY_AMENITIES_FROM_RELIGION uses COLLECTION_OWNER.

 

[Deliverator]

Thanks for tutorial @NycholusV.

I'm trying to get something that ought to be simple working. I just want a Religion Belief to enable the construction of a particular unit.

Here's my edited code:

<?xml version="1.0" encoding="utf-8"?>
<GameData>
...
    <Units>
        <Row UnitType="UNIT_TEMPLAR" BaseMoves="2" Cost="130" AdvisorType="ADVISOR_CONQUEST" BaseSightRange="2" ZoneOfControl="true"
            Domain="DOMAIN_LAND" FormationClass="FORMATION_CLASS_LAND_COMBAT" Name="LOC_UNIT_TEMPLAR_NAME"
            Description="LOC_UNIT_TEMPLAR_DESCRIPTION" PurchaseYield="YIELD_FAITH" PromotionClass="PROMOTION_CLASS_MELEE" Maintenance="2"
            Combat="40" PrereqTech="TECH_IRON_WORKING" MandatoryObsoleteTech="TECH_REPLACEABLE_PARTS" TraitType="TRAIT_CIVILIZATION_UNIT_TEMPLAR"/>
    </Units>
    <Traits>
        <Row TraitType="TRAIT_CIVILIZATION_UNIT_TEMPLAR" Name="LOC_UNIT_TEMPLAR_NAME"/>
    </Traits>
...
    <Modifiers>
        <Row>
            <ModifierId>JUST_WAR_TEMPLAR_UNIT_BONUS</ModifierId>
            <ModifierType>MODIFIER_ALL_PLAYERS_GRANT_TRAIT</ModifierType>
            <SubjectRequirementSetId>PLAYER_FOUNDED_RELIGION_REQUIREMENTS</SubjectRequirementSetId>
        </Row>
    </Modifiers>
    <ModifierArguments>
        <Row>
            <ModifierId>JUST_WAR_TEMPLAR_UNIT_BONUS</ModifierId>
            <Name>TraitType</Name>
            <Value>TRAIT_CIVILIZATION_UNIT_TEMPLAR</Value>
        </Row>
    </ModifierArguments>
    <BeliefModifiers>
        <Row BeliefType="BELIEF_JUST_WAR">
            <ModifierId>JUST_WAR_TEMPLAR_UNIT_BONUS</ModifierId>
        </Row>
    </BeliefModifiers>
</GameData>

From what I can tell MODIFIER_ALL_PLAYERS_GRANT_TRAIT doesn't work. Any ideas on how else to achieve this?

Edit: Can I use the COLLECTION_PLAYER_CITIES with EFFECT_ATTACH_MODIFIER and then MODIFIER_SINGLE_CITY_GRANT_BUILDING_IN_CITY to grant a building which enables the unit?

 

[Deliverator]

I don't fully understand what how the different combinations of the RunOnce and Permanent flags work. What happens if RunOnce is true but Permanent is false, or if Permanent is true and RunOnce is false?

 

[mauporte]

Thanks for the guide, really helpful. Is there also a way to create effects?

 

[greyTiger]

Has anyone found a way to activate\deactivate modifiers independently through commands or lua function calls? This would be great as we could implement new game mechanics that update the core game using modifiers.

 

[Magil]

I don't fully understand what how the different combinations of the RunOnce and Permanent flags work. What happens if RunOnce is true but Permanent is false, or if Permanent is true and RunOnce is false?

I'd also like to know this, I have no idea what these two lines do.

 

[IllustriousYou]

Thanks for the guide, really helpful. Is there also a way to create effects?

No. The set of game effects listed in GameEffects.xml is hard-coded into the engine, per the comments on lines 3 and 4:

<!-- What goes in here? -->
<!-- Any built-in GameEffect type that is exposed by the DLL. -->

 

[isau]

Thanks for tutorial @NycholusV.

I'm trying to get something that ought to be simple working. I just want a Religion Belief to enable the construction of a particular unit.

Here's my edited code:

<?xml version="1.0" encoding="utf-8"?>
<GameData>
...
    <Units>
        <Row UnitType="UNIT_TEMPLAR" BaseMoves="2" Cost="130" AdvisorType="ADVISOR_CONQUEST" BaseSightRange="2" ZoneOfControl="true"
            Domain="DOMAIN_LAND" FormationClass="FORMATION_CLASS_LAND_COMBAT" Name="LOC_UNIT_TEMPLAR_NAME"
            Description="LOC_UNIT_TEMPLAR_DESCRIPTION" PurchaseYield="YIELD_FAITH" PromotionClass="PROMOTION_CLASS_MELEE" Maintenance="2"
            Combat="40" PrereqTech="TECH_IRON_WORKING" MandatoryObsoleteTech="TECH_REPLACEABLE_PARTS" TraitType="TRAIT_CIVILIZATION_UNIT_TEMPLAR"/>
    </Units>
    <Traits>
        <Row TraitType="TRAIT_CIVILIZATION_UNIT_TEMPLAR" Name="LOC_UNIT_TEMPLAR_NAME"/>
    </Traits>
...
    <Modifiers>
        <Row>
            <ModifierId>JUST_WAR_TEMPLAR_UNIT_BONUS</ModifierId>
            <ModifierType>MODIFIER_ALL_PLAYERS_GRANT_TRAIT</ModifierType>
            <SubjectRequirementSetId>PLAYER_FOUNDED_RELIGION_REQUIREMENTS</SubjectRequirementSetId>
        </Row>
    </Modifiers>
    <ModifierArguments>
        <Row>
            <ModifierId>JUST_WAR_TEMPLAR_UNIT_BONUS</ModifierId>
            <Name>TraitType</Name>
            <Value>TRAIT_CIVILIZATION_UNIT_TEMPLAR</Value>
        </Row>
    </ModifierArguments>
    <BeliefModifiers>
        <Row BeliefType="BELIEF_JUST_WAR">
            <ModifierId>JUST_WAR_TEMPLAR_UNIT_BONUS</ModifierId>
        </Row>
    </BeliefModifiers>
</GameData>

From what I can tell MODIFIER_ALL_PLAYERS_GRANT_TRAIT doesn't work. Any ideas on how else to achieve this?

Edit: Can I use the COLLECTION_PLAYER_CITIES with EFFECT_ATTACH_MODIFIER and then MODIFIER_SINGLE_CITY_GRANT_BUILDING_IN_CITY to grant a building which enables the unit?

Thanks for tutorial @NycholusV.

I'm trying to get something that ought to be simple working. I just want a Religion Belief to enable the construction of a particular unit.

Here's my edited code:

<?xml version="1.0" encoding="utf-8"?>
<GameData>
...
    <Units>
        <Row UnitType="UNIT_TEMPLAR" BaseMoves="2" Cost="130" AdvisorType="ADVISOR_CONQUEST" BaseSightRange="2" ZoneOfControl="true"
            Domain="DOMAIN_LAND" FormationClass="FORMATION_CLASS_LAND_COMBAT" Name="LOC_UNIT_TEMPLAR_NAME"
            Description="LOC_UNIT_TEMPLAR_DESCRIPTION" PurchaseYield="YIELD_FAITH" PromotionClass="PROMOTION_CLASS_MELEE" Maintenance="2"
            Combat="40" PrereqTech="TECH_IRON_WORKING" MandatoryObsoleteTech="TECH_REPLACEABLE_PARTS" TraitType="TRAIT_CIVILIZATION_UNIT_TEMPLAR"/>
    </Units>
    <Traits>
        <Row TraitType="TRAIT_CIVILIZATION_UNIT_TEMPLAR" Name="LOC_UNIT_TEMPLAR_NAME"/>
    </Traits>
...
    <Modifiers>
        <Row>
            <ModifierId>JUST_WAR_TEMPLAR_UNIT_BONUS</ModifierId>
            <ModifierType>MODIFIER_ALL_PLAYERS_GRANT_TRAIT</ModifierType>
            <SubjectRequirementSetId>PLAYER_FOUNDED_RELIGION_REQUIREMENTS</SubjectRequirementSetId>
        </Row>
    </Modifiers>
    <ModifierArguments>
        <Row>
            <ModifierId>JUST_WAR_TEMPLAR_UNIT_BONUS</ModifierId>
            <Name>TraitType</Name>
            <Value>TRAIT_CIVILIZATION_UNIT_TEMPLAR</Value>
        </Row>
    </ModifierArguments>
    <BeliefModifiers>
        <Row BeliefType="BELIEF_JUST_WAR">
            <ModifierId>JUST_WAR_TEMPLAR_UNIT_BONUS</ModifierId>
        </Row>
    </BeliefModifiers>
</GameData>

From what I can tell MODIFIER_ALL_PLAYERS_GRANT_TRAIT doesn't work. Any ideas on how else to achieve this?

Edit: Can I use the COLLECTION_PLAYER_CITIES with EFFECT_ATTACH_MODIFIER and then MODIFIER_SINGLE_CITY_GRANT_BUILDING_IN_CITY to grant a building which enables the unit?

I haven't tried the method you suggested. The "easiest" way to do this I think is to create a dummy Resource that the unit requires. Have the religion provide one copy of the resource (so it can't be traded).

Use a resource like Jeans as the template so the resource doesn't appear on the map.

Downside will be the strategic resource icon will show at the top of the screen. You can deal with this somewhat by setting it so the resource has a revealed Civic or Tech. Downside of that is the resource will still be "revealed" when people reach that tech, at least according to the Civ or Tech tree. They won't actually see anything if it's not on the map.

Reminds me once again that Firaxis needs to make Techs and Civics that are unresearchable and don't appear in the trees. Would solve a million issues.

 

[mauporte]

No. The set of game effects listed in GameEffects.xml is hard-coded into the engine, per the comments on lines 3 and 4:

<!-- What goes in here? -->
<!-- Any built-in GameEffect type that is exposed by the DLL. -->

I thought so when I realized there was no GameEffects table in the Data xmls,
I'm no videogame programmer but it does seem clunky the way effects are defined, I mean for example there is a grant_spy effect and an increase_trade_route_capacity effect; I would've thought of something like this:
<GameEffects> <Effect Type><UnitType> <Amount> etc. etc.
I don't know, it seems simpler that way.

 

[luei333]

I don't fully understand what how the different combinations of the RunOnce and Permanent flags work. What happens if RunOnce is true but Permanent is false, or if Permanent is true and RunOnce is false?

I'd also like to know this, I have no idea what these two lines do.

He actually goes into these in the first chapter. Direct quote:

• RunOnce: A boolean that identifies whether or not this modifier applies a one-time effect, such as a free unit, an inspiration or eureka boost, etc. False by default. It is not always clear when this should be used, but when in doubt, refer to the base game files and emulate them, i.e. find a modifier with the same ModifierType as the one you’re using, and use that as a reference.
• Permanent: A boolean that identifies whether or not this modifier should apply permanently. False by default. While seemingly contradictory, this is often used in conjunction with RunOnce. This is to prevent the modifier from applying itself again if, for whatever reason, the modifier disappears and then reappears. There are also some cases where this is used without RunOnce. Again, when in doubt as to whether you should use these, emulate the base game.

Short version, RunOnce means that the modifier will only run one time, instead of constantly applying its effects over multiple turns. Only really applicable for certain things, like granting units or population, etc.

Permanent means that the modifier will ALWAYS exist on that entity, as long as the entity itself exists. Persistent bonuses, like bonuses to yields, will be applied forever and aren't turned off when the requirements are no longer met. And since the modifier can never be UN-applied, it can never be RE-applied. Combined with RunOnce, you can make modifiers that can trigger once, and only ever once per entity they can affect.

Imagine adding a modifier to a city that grants 1 population (or a similar effect), and requires a builder to be in the city center's tile. The first time a builder walk onto its tile, the city will receive an extra population. If the RunOnce value isn't set to true, it will likely continue to gain extra population every turn or so, as long as the builder remains on its tile (or however often the effect would trigger). If Permanent but not RunOnce, it will likely gain extra population continuously for the rest of the game! Adding RunOnce means that the city would get extra population only one time, but without permanent it could trigger multiple times. Not sure on the exact nature there, but it might be as simple as moving the builder off of the tile and back on repeatedly to trigger the population gain again and again. With both RunOnce and Permanent set, that city would only ever be able to gain 1 extra population from having a builder on its tile, no matter how many different builders go on it throughout the course of the game.

 

[luei333]

I'm trying to get something that ought to be simple working. I just want a Religion Belief to enable the construction of a particular unit.

You could add a building dependency to the unit, much like the Temple has to the Apostle or the Archaeological Museum has to the Archaeologist. When a city gets your belief (use the same structure many of the religious modifiers do, the collection is all cities, but the requirement is that they follow your belief), then have the modifier grant them the free building (could just be a building with no effect or anything), and voila, they can train your unit, or buy it with faith, etc. Problem is, you'd have to remove the building once the city no longer has the belief, but that's much easier to do via Lua than fussing with resources. Also, the building will be visible in the city details panel, even if you hide its entries from the Civilopedia. An easy way to get around this is to include it in the design. Maybe the belief lets you build a religious building, and that building lets you train the unit you want. Could be a cheap building, maybe with only a +1 or +2 faith bonus besides giving access to the unit. Food for thought.

 

[luei333]

Also, NycholusV, I love you for providing these tutorials. The first one helped me immensely in understanding how the modifiers system worked back when it was first posted, and by the time you posted this second chapter, I'd already figured out all the stuff you talked about in it! Definitely some of the best resources for modding Civ 6 so far.

 

[richardsvensson]

Thanks a lot for the two chapters on Modifiers! Really useful.

I've managed to change the Gold Yield for Shrines to 1 and Temples to 2 by using modifiers. However, I'm struggling with giving the bonus only once a civic (Reformed Church) is discovered. I can't figure out how to solve it.

My first thought was to use OwnerRequirementSetId and specify that PLAYER_HAS_CIVIC_REFORMED_CHURCH, or something like that. (I couldn't find that one in the list and don't know how to create my own requirements)

I've also been thinking about the possibility of linking the modifiers:

Leader Trait --> Civic Modifier --> Bonus Yield for Building

Would that give the Civic Modifier only to the leader(s) with that particular Leader trait, or to all players?

 

[Rajendran]

NycholusV,
I downloaded this chapter file/mod (no changes were done) but noticed the following error in the log file pertaining to this mod.

 

[kassambique]

Hello,

thanks for the two interesting chapters, I was able to create a first modifier and indeed see it in the game (yeehaw) but I'm struggling with another one. I'd like to give the ability ABILITY_CAPTIVE_WORKERS to units of this new civilization, this ability is yet defined une the UnitAbilities file of the game.
Even though there is no error when building the mode and fire tuner seems to apply the modifier MODIFIER_RWK_PLAYER_UNITS_CAN_CAPTURE to all unit, the ability is not there on each unit, as if one step to "propagate" the modifier from "Player's unit" to the unit itself was missing. But I can't see what, can somebody help?

Thanks

--==========================================================================================================================
-- CIVILIZATIONS: TRAITS
--==========================================================================================================================
-- Types
--------------------------------------------------------------------------------------------------------------------------   
INSERT INTO Types   
        (Type,                                                    Kind)
VALUES    ('TRAIT_CIVILIZATION_RWK_CAN_CAPTURE',                        'KIND_TRAIT'),
        ('MODIFIER_RWK_PLAYER_UNITS_CAN_CAPTURE',               'KIND_MODIFIER');   
        
        
--------------------------------------------------------------------------------------------------------------------------           
-- Traits           
--------------------------------------------------------------------------------------------------------------------------               
INSERT INTO Traits               
        (TraitType,                                                    Name,                                                    Description)
VALUES    ('TRAIT_CIVILIZATION_RWK_CAN_CAPTURE',                        'LOC_TRAIT_CIVILIZATION_RWK_CAN_CAPTURE_NAME',                    'LOC_TRAIT_CIVILIZATION_RWK_CAN_CAPTURE_DESCRIPTION');
--------------------------------------------------------------------------------------------------------------------------       
-- TraitModifiers       
--------------------------------------------------------------------------------------------------------------------------           
INSERT INTO TraitModifiers           
        (TraitType,                                            ModifierId)
VALUES    ('TRAIT_CIVILIZATION_RWK_CAN_CAPTURE',                    'MODIFIER_RWK_PLAYER_UNITS_CAN_CAPTURE');   


                                                                                
--------------------------------------------------------------------------------------------------------------------------
-- Modifiers
--------------------------------------------------------------------------------------------------------------------------
INSERT INTO Modifiers   
        (ModifierId,                                                ModifierType, Permanent)
VALUES    ('MODIFIER_RWK_PLAYER_UNITS_CAN_CAPTURE',                                        'MODIFIER_PLAYER_UNITS_GRANT_ABILITY', '1');           
--------------------------------------------------------------------------------------------------------------------------
-- ModifierArguments
--------------------------------------------------------------------------------------------------------------------------
INSERT INTO ModifierArguments
        (ModifierId,                                                Name,                        Value)
VALUES    ('MODIFIER_RWK_PLAYER_UNITS_CAN_CAPTURE',         'AbilityType',  'ABILITY_CAPTIVE_WORKERS');