国策制作

国策的定义在/Hearts of Iron IV/common/national_focus/*.txt。

Focus tree

A focus tree is defined by using a focus_tree = { ... } block. The following arguments are used:

id = my_focus_tree decides the ID that the focus tree uses. It is mandatory to define, and an overlap will result in an error. The ID is primarily used for the has_focus_tree trigger and the load_focus_tree effect, whose tooltips use it as a localization key.

country = { ... } is a MTTH block that assigns a score for the focus tree, deciding which one is used in-game. This is evaluated before the game's start and the check is essentially never refreshed. The focus tree with the highest score will be the one that gets loaded for the country. By default, the score starts with 1. A typical usage looks like this:

country = {
    factor = 0
    modifier = {
        add = 20
        original_tag = TRA
    }
}

In this case, countries originating from  Transylvania (i.e. the country itself and any civil war or collaboration government breakaways, as ensured by the original_tag trigger) will have the score of 20, while every other country will have the score of 0. Assuming that there is no other focus tree where  Transylvania has a higher country score, this will ensure that this focus tree gets loaded for it.

default = yes sets the focus tree to be marked as default. In total, there should be one total default focus tree, no more, no less. A focus tree being marked as default means that if every other focus tree has a country score of 0, this tree will be chosen instead. Additionally, a country starting with a focus tree will fail to appear in the "minor countries" section within the "interesting countries" menu before the game's start. If this is left out from a focus tree, it gets assumed to be non-default.

reset_on_civilwar = no is not determined on its effect. Instead, this is how focus trees are handled in civil wars, regardless of if reset_on_civilwar is set or how it's set:

When a civil war starts, the original country will always continue using the focus tree. The focus it's doing will not be paused or cancelled by the civil war itself. The revolter will have the focus tree it's using evaluated when the civil war starts, assigning one depending on each tree's country = { ... } value. If the same focus tree gets used for the revolting country as the one that the original country used when the civil war started, every focus that the original country has completed will get completed for the revolting country, including setting the same focus progress for the one that's being completed by the original country at the moment. Otherwise, the focus progress will get lost.

shared_focus = TAG_focusname will set the focus tree to include the specified shared focus and every focus that is connected to it via prerequisites. Setting this to a non-existing focus causes a game crash when loading into the main menu.

continuous_focus_position = { x = 1200 y = 100 } is the position of the top left corner of the continuous focus menu in pixels. For comparison, by default, the continuous focus palette has the position of 50 on the X axis and 1000 on the Y axis. If both x and y are set to 0 or the position is undefined for the tree, it resets to the default position.

initial_show_position = { ... } decides the initial position of the camera when the focus tree is first opened. There are 2 ways to arrange it:

• focus = TAG_focusname will make the camera centre on the specified focus in particular. It'll be in the top centre of the screen exactly, taking offsets into consideration.
• x = 12 y = 0 decides the exact position of the top-centre of the camera. This uses the same coordinate system as regular focuses do, by default a unit of x being equal to 96 pixels and a unit of y being equal to 130 pixels

This also accepts offset = { ... }, adding the specified values to respective positions if the conditions within the trigger = { ... } trigger block are met for the country. For example, this will apply the modifier and result in a position of x = 13, y = 1 if the country is BHR:

initial_show_position = {
    x = 17
    y = 0
    offset = {
        x = -4
        y = 1
        trigger = {
            tag = BHR
        }
    }
}

focus = { ... } are the focuses themselves. Each focus that's put within the focus tree will. The focuses have to be within a focus_tree = { ... } in order to let the game know which focus tree exactly to assign them to. If a focus = { ... } blocks ends up outside of a focus_tree = { ... } or within another focus = { ... }, this gets marked within the error log as "focus" being an unexpected token, fixed by adjusting brackets as needed.

Examples

Pure minimum, with 2 focuses:

折叠The text in this section has been collapsed by default.
focus_tree = { id = BHR_focus_tree country = { base = 0 modifier = { add = 10 tag = BHR } } focus = { ... } focus = { ... } }

Average tree, with 2 focuses:

折叠The text in this section has been collapsed by default.
focus_tree = { id = OMA_focus_tree country = { base = 0 modifier = { tag = 25 original_tag = OMA } } continuous_focus_position = { x = 450 y = 800 } initial_show_position = { focus = OMA_focus_name } focus = { id = OMA_focus_name ... } focus = { ... } }

National focuses

This is a community maintained wiki. If you spot a mistake, please help with fixing it.

The ID for the focus is defined using id = TAG_focusname. While it's optional to preface the focus' ID with the country's tag, doing so is preferred to avoid overlapping focus IDs from different focus trees. Having the same focus ID in different focus trees leads to errors, such as broken prerequisite lines and effects or triggers such as complete_national_focus or has_completed_focus not working correctly. Instead, it could be possible to use shared focuses to put the same focus in different focus trees.

Name and description

The name of the focus depending on the language that's turned on is defined within /Hearts of Iron IV/localisation/, using the ID of the focus as the localisation key. For English in particular, this is defined within any /Hearts of Iron IV/localisation/english/*_l_english.yml file with the UTF-8-BOM encoding. It is preferable to use new localisation files when possible rather than overwriting base game localisation in order to not have to change that for compatibility with recent versions, and to do so, the file should have a new name that doesn't exist in base game, but it must still end with _l_english.yml to be loaded properly. The focus' ID is used as the localisation key used to establish the name in the enabled language, while a description uses the focus' ID with _desc appended:

l_english:
 TAG_focus_name: "Example focus"
 TAG_focus_name_desc: "Example focus description"

Position

The position of the focus is decided via x = 5 and y = 1 attributes. By default, a unit of x is equal to 96 pixels and a unit of y is equal to 130 pixels. In other words, a focus directly below another focus would have a unit difference of 1, while a focus directly to the right of another one would have a unit difference of 2. By default, this is relative to the top left corner of the tree: a larger x value moves the focus right, a larger y value moves the focus down.

It is also possible and preferred (on focuses with prerequisites) to make the focus' position be relative to another focus with doing relative_position_id = TAG_other_focus. This will position the focus relative to that focus, adding the x and y values to the other focus' position (after calculating that one's relative_position_id too). Doing so allows for more flexibility in the focus tree design by allowing to easily modify the position of the entire branch at the same time, due to updates to the children focuses' positioning. This also allows to only use the later offset = { ... } only in the top focus of each branch that requires to be moved.

For example, if focus A has x = 1 y = 2, focus B is positioned relative to focus A and has x = 3 y = 4, then the focus B will be positioned, in total, 4 steps to the right and 6 steps down of the top-left corner. A focus C positioned relative to focus B at x = -1 y = 1 would then be located 3 steps to the right and 7 steps down of the top-left corner.

The game can behave unstably with an incorrect relative position ID. A recursion (such as a focus being positioned relative to itself or focus A and focus B being positioned relative to each other) may cause a game crash since it is impossible to determine the exact position of the focus, and the focus must also be located in the same focus tree for the argument to work properly.

Changing a focus' position based on a condition being met is done with offset = { ... }. The x = 10 and y = -3 values will be added to the focus' position if the conditions within trigger = { ... } are met for the country when the focus tree is loaded. This looks like the following:

offset = {
    x = -5
    trigger = {
        has_dlc = "Poland: United and Ready"
    }
}

This in particular will move the focus 5 units to the left if the "Poland: United and Ready" DLC is turned on. This check also can be refreshed mid-session with the mark_focus_tree_layout_dirty effect, applying the offset if true.

Interaction with other focuses

prerequisite = { focus = TAG_other_focus } decides the focuses necessary to complete for this focus to be available. At least one focus within a prerequisite has to be completed to mark the prerequisite as true, and each prerequisite much be completed to take the focus. If neither of the prerequisites is located in the same focus tree, then the focus will not appear. In other words, an OR statement is done by putting 2 focuses inside a prerequisite as prerequisite = { focus = TAG_other_focus_1 focus = TAG_other_focus_2 }, while an AND statement is done by putting two different prerequisites like the following:

prerequisite = { focus = TAG_other_focus_1 }
prerequisite = { focus = TAG_other_focus_2 }

This system cannot represent every boolean logical arrangement, such as  (Where , , and  represent whether a focus is complete) or with anything using negation. In this case, it can be possible to, instead, put an OR statement for either of the focuses necessary to complete this one and use the has_completed_focus trigger within the available = { ... } block with necessary flow control tools. A custom trigger tooltip can be used to make it easier for the player to understand.

mutually_exclusive = { focus = TAG_other_focus } makes this focus impossible to select if the specified focus has been completed. If both focuses are mutually exclusive toward each other, then the mutually exclusive arrows will be shown in the focus tree view. Mutual exclusivity to multiple focuses is usually done by putting several of focus = TAG_focusname in the same mutually_exclusive, but defining several of mutually_exclusive is also possible.

Neither prerequisites nor mutual exclusivity require the other focus to be in the same focus tree. This means that it can be used with shared focuses to declare a regular, non-shared focus as mutually exclusive or a prerequisite without any errors, even when used in a focus tree not containing that focus.

The difference between prerequisites and using has_completed_focus within the available = { ... } block is that the prerequisites show up as lines within the national focus tree view and show up separately from other triggers in the tooltip of a focus.

There is an issue that leads to prerequisite lines not working properly: duplicate focus IDs within different focus trees. In this case, the game can take the position of the focuses as the ones within the different focus tree that contains the same focuses, leading to them appearing to link towards empty spaces or start inside of them. This can also break the path-generating algorithm and make it use the wrong turn sprites, which will show up broken even in trees that don't have any duplicates.

In order to avoid this, duplicate focus IDs must be avoided. A simple way to decrease the chance drastically is to preface the focus IDs with the country tag (such as TAG_focus_name) or something else that's unique for the focus tree (Such as REGION_focus_name for a shared regional tree). If the same focus tree should be used for several countries, this can be done by only having one focus tree where the country = { ... } of the tree is set up so that the desire to use it is the highest for several countries instead of just one; if the same focus tree branch should be used within several different focus trees, then shared focuses can achieve exactly that.

Additionally, the game intends for a focus' prerequisite to be placed above the focus that requires it and it is unable to correctly generate the path to the focus otherwise, which will show up as having a path that uses the wrong sprites in the 90° turns.

Icon

General sprite overview

For loading GFX, the game uses the sprite system. Sprites are code definitions that attach a name to an image file, as well as optionally adding additional information, such as animation, the amount of frames, the way that the image will be loaded, and so on. This means placing an image into the gfx folder isn't enough for it to work, a sprite has to use that image file as well. Sprites are defined in any /Hearts of Iron IV/interface/*.gfx file (this is separate from gfx/interface/), opened with a text editor. To create a new .gfx file, a text file can be created and renamed to change the extension (on Windows, the Windows Explorer needs to show the extensions, which it doesn't by default). In particular, sprites are defined within a spriteTypes = { ... } block, as to separate from fonts and map arrows also defined in that folder, while the simplest sprite with the least mandatory properties is a spriteType = { ... }. The simplest sprite definition looks like the following: spriteTypes = { spriteType = { name = GFX_first_sprite # In some cases, beginning with GFX_ is mandatory for it to work. texturefile = gfx/interface/folder/filename.dds # The folder and filename don't matter, as long as they are correct } # Only the forward slash '/' (can be doubled as '//') can be used to separate folders. spriteType = { # The image doesn't have to be .dds, as .tga and .png are acceptable. name = GFX_second_sprite texturefile = gfx/interface/folder2/filename2.dds noOfFrames = 2 # Splits the image into 2 halves, which may be switched between dynamically in GUI } } In this case, this creates a sprite with the name of GFX_first_sprite and attaches the /Hearts of Iron IV/gfx/interface/folder/filename.dds image to it, and a second sprite similarly. The second sprite will be split into 2 frames: this is decided by having the left half of the image as the first frame and the right half as the second frame (more frames would further split the image horizontally). This doesn't make the sprite animated, just turns on the option to switch between the two halves as needed. GFX_second_sprite:1 serves as a reference to the first frame, and GUI can be set up to change the shown frame depending on context, such as with radio stations. In order to add animation, a frameAnimatedSpriteType is used. It's never mandatory to copy a base game file to change a sprite. If there are duplicate definitions of a sprite with the same name in different files, the game will prioritise the one that would be evaluated later, based on the filename, and the older sprite will be ignored in entirety. This can be ensured by beginning the replacement file's name with a symbol late in the ASCII character table. Typically the lowercase letter 'z' is used for this purpose. For example, to change the amount of frames in GFX_idea_traits_strip to 10, it is possible to define a sprite with that name with 10 frames in the mod's modname/interface/zz_replace.gfx file instead of copying over the base game file. Since most .gfx files define integral parts of the user interface, copying them over can lead to the mod's loaded files missing sprites upon a major game update, which would appear in-game as the default image, which is the error dog by default. As to ease the burden of needing to check the interface files, it's best to never copy over .gfx files, unless more additions would be actively harmful to the mod, such as with interface/subuniticons.gfx

Within a focus, an icon is assigned with the line of icon = GFX_focus_icon. This assigns two sprites to the focus, in particular:

• Regular sprite, with the name of GFX_focus_icon. This is used in the focus description view and in the focus tree view when the focus is unavailable, is being completed, or has been completed.
• Sprite for the shine animation, with the name of GFX_focus_icon_shine (With _shine at the end). This is used in the focus tree view for focuses that are currently available and in the country politics and diplomacy views for the focus currently being complete. Since the game doesn't use filenames in evaluation, putting the spriteType definition into a file with shine in the filename isn't either necessary or sufficient. Only the name of the sprite is used, which must be the same as the regular sprite with _shine appended to the end. The most common mistake when the shine doesn't work is not following this naming rule.

If one of these is undefined or is defined incorrectly, the missing focus icon will be used instead of the appropriate sprite, however the working sprite will continue to be used.

If the texturefile links to a non-existing file, whether it's the folder path that's incorrect or the filename, including the extension, the focus icon will appear as fully transparent.

By default, the base game stores images for focus icons in the /Hearts of Iron IV/gfx/interface/goals/ folder and sprites in the interface/goals.gfx and interface/goals_shine.gfx files. Since there's no reason to copy the files to the mod and doing so will lead to needing to update the file after a major update to use new sprites, it's best to create a new file in the folder for sprite definitions.

The following is an example of an interface file that defines both of the sprites:

折叠 Example interface file

spriteTypes = { spriteType = { name = GFX_focus_icon texturefile = gfx/interface/goals/filename.dds } spriteType = { name = GFX_focus_icon_shine # Change the name, note to keep _shine in the end texturefile = gfx/interface/goals/filename.dds # Change to the focus icon effectFile = gfx/FX/buttonstate.lua animation = { animationmaskfile = gfx/interface/goals/filename.dds # Change to the focus icon animationtexturefile = gfx/interface/goals/shine_overlay.dds animationrotation = -90.0 animationlooping = no animationtime = 0.75 animationdelay = 0 animationblendmode = "add" animationtype = "scrolling" animationrotationoffset = { x = 0.0 y = 0.0 } animationtexturescale = { x = 1.0 y = 1.0 } } animation = { animationmaskfile = gfx/interface/goals/filename.dds # Change to the focus icon animationtexturefile = gfx/interface/goals/shine_overlay.dds animationrotation = 90.0 animationlooping = no animationtime = 0.75 animationdelay = 0 animationblendmode = "add" animationtype = "scrolling" animationrotationoffset = { x = 0.0 y = 0.0 } animationtexturescale = { x = 1.0 y = 1.0 } } legacy_lazy_load = no } }

When copying from the template, note to change the animationmaskfile in each animation within the sprite with the shine alongside the texturefile and name.

Dynamic appearance

dynamic = yes allows the title and icon of the focus to be dynamic. In particular, it allows using scripted localisation in focus titles and a dynamic icon. If false or unset, it will still allow using them, but instead it will pick one at the game's start and never change it.

Dynamic icons are treated similarly to events' titles or descriptions: instead of a single icon = GFX_focus_example a focus can contain multiple icon = { ... } at the same time, each with a unique trigger. The first possible icon will get used in the focus. An icon = { ... } consists of a trigger = { ... }, which must be fulfilled by the country for the icon to be selectable, and value = GFX_focus_example, which determines the 2 sprites used for the focus.

An example dynamic focus definition, with all other optional arguments omitted:

focus = {
    id = TAG_political_focus # In localisation, TAG_political_focus: "[THIS.GetRulingIdeology] political focus"
    icon = {
        trigger = { has_government = democratic }
        value = GFX_focus_example_democratic
    }
    icon = {
        value = GFX_focus_example_fallback
    }
    dynamic = yes

Triggers

See also: Triggers

In order to take the focus, aside from the focus prerequisites, the conditions within the available = { ... } block must be met. This functions as an AND block, so each of the triggers must be true to fulfilled. Scopes can be used to check for conditions for other countries or within states. By default, the scope is of the country doing the focus. For example, this example requires the country to have more than 10% Stability and for the state 294 to be owned by the  Republic of Qatar:

available = {
    stability > 0.1
    294 = { is_owned_by = QAT }
}

bypass = { ... } is similar, but for bypassing the focus. Bypassing a focus marks the focus as complete, but does not grant its effects within the completion reward. The exact same applies as to available: it's an AND block that assumes the country doing the focus by default. bypass_if_unavailable = yes can be used to make the focus automatically bypass as soon as the available = { ... } block is not met without needing to port over the triggers.

allow_branch = { ... } is used to tell when the focus should be visible. This is only checked when the focus tree is first loaded. However, this check also can be refreshed mid-session with the mark_focus_tree_layout_dirty effect, making the focus visible or invisible depending on if it's true or not. By default, a focus will also be disallowed if either of the parent focuses (as set by prerequisites) is disallowed. However, a focus containing allow_branch within its definition will only check its own allowed status, still showing up if it has disallowed parents. This means that if a branch is set to be disallowed under certain conditions, the first focus in any sub-branch that has its own conditions for being allowed must also contain the parent branch's condition within of itself, while other focuses may not have any allow_branch defined at all due to it being inherited from parents.

available_if_capitulated = yes sets the focus to be possible to complete while being capitulated. By default, this is set to false.

cancel_if_invalid = no and continue_if_invalid = yes decide how to treat the focus if the available = { ... } block becomes false while doing it. By default, these are true and false respectively. If both are set to false, the focus would pause when the available = { ... } block is false. This will not remove the gain_focus static modifier, which by default results in costing 1 Political Power per day when doing the focus.

cancel = { ... } decides additional conditions which would cancel the focus if met. This is usually paired with cancel_if_invalid = no.

historical_ai = { ... } decides when the AI is able to pick this focus with the historical focus turned on. This does not ensure it picks this focus, rather prevents it from picking it when false. This takes priority over the order of focuses granted within AI strategy plans: if the AI were to do this focus next by the plan, yet historical_ai = { ... } is false and historical focus is turned on, then it won't be able to.

Effects

See also: Effects

The primary reward of the focus is done with completion_reward = { ... }. This executes each effect within the specified scopes in order that they are put in the file. The assumed scope is the country doing the focus. For example, this would add 100 Political Power to the country doing the focus and fire the my_event.0 country event to  Oman:

completion_reward = {
    add_political_power = 100
    OMA = { country_event = my_event.0 }
}

The tooltip of the focus can be changed with complete_tooltip = { ... }, which is also an effect block. This would be equivalent to putting the contents of the reward inside of hidden_effect and using effect_tooltip in the same reward. This can be useful if the tooltip of the reward appears cluttered. For instance, using random_owned_controlled_state thrice with the same effect in each one can result in a cluttered tooltip, as each state and its effects would appear individually. But if, instead, the code sets a state flag for each state in the reward and, in the tooltip, uses every_state limited to the ones that have the state flag, it'll show the same effect being executed for 3 states at the same time, cutting it into a third of what it was.

Additionally, select_effect = { ... } is used to execute an effect when the focus is selected. This has no tooltip shown to the player. This also automatically makes the focus impossible to cancel manually. It may still be cancelled automatically if set to do so, so in most cases it'd be preferable to set it to not cancel if invalid in order to prevent the effects within from firing more than once, as there is no way to execute an effect when the focus gets cancelled.

The focus is not yet marked as complete when the effects are being executed. What this means is that any has_completed_focus check ran within will return as false. This can be a hinderance in some cases, most commonly when using allow_branch (as the effect to refresh the check will not work properly when put within a focus). Some alternatives can be considered:

• Country flags to track that a focus has been completed. Since country flags are set immediately, as long as the setting precedes the requirement, this will work.
• Delaying the effects that would require the focus to be complete. This is usually done by firing a hidden event. If done with no delay, the event will be fired right after the focus is complete, resulting in no noticeable delay for the player, but still executing the effects in order.
• Forcefully marking the focus to be complete. This, for example, can be done by using load_focus_tree for the same focus tree with the completed focuses being kept. Doing so will not interrupt the completion reward's execution.

取消(cancel)

(变量类型: AND trigger, 默认: { }) 当国策进行中而取消触发器变为真时，国策将会取消。与普通的AND触发器不同，一个空的取消触发器被视为假。

无效时取消(cancel_if_invalid)

(变量类型: 布尔boolean, 默认: yes) 如果为真，当available变为假时正在进行的国策会被取消。

无效时继续(continue_if_invalid)

(变量类型: 布尔boolean, 默认: no) 如果为真，cancel和cancel_if_invalid会被忽略

开始效果(select_effect)

(变量类型: effect) 当国策被选中开始时，效果将会实施。

完成奖励(completion_reward)

(变量类型: effect) 当国策完成时，效果将会实施。

完成提示(complete_tooltip)

(变量类型: effect) 国策的完成提示将会显示这里面的效果而不是真正的完成奖励completion_reward。

跳过(bypass)

(变量类型: AND trigger, 默认: { }) 当跳过触发器为真时，任意当前正在进行中或者可用的国策都会跳过。与普通的AND触发器不同，一个空的跳过触发器被视为假。Bypassing ignores the available trigger. 当一个国策有互斥选项时，玩家需要手动选择跳过。otherwise the bypass happens automatically as soon as the conditions are fulfilled.

图标(icon)

(变量类型: 字符串string) 图形图标名，一般是在/Hearts of Iron IV/interface/goals.gfx中定义。

x坐标(x)

(变量类型: 整数integer, 默认: 0) 国策的水平坐标，网格行。

y坐标(y)

(变量类型: 整数integer, 默认: 0) 国策的垂直坐标，网格列。

坐标移动(offset)

一个对x和y坐标属性的额外转换，以一个触发器为条件。x和y坐标属性是整数integers，其中的触发器是一个AND触发器。例子如下：

offset = {
	x = -1
	y = 0
	trigger = {
		NOT = { has_dlc = "Man the Guns" }
	}
}

相对位置id(relative_position_id)

(变量类型: 字符串string) 此国策的图形坐标将相对于参考原点国策的位置生成。通常来说参考原点国策会是该国策的前置国策，这样就可以做到移动根国策就可以移动整棵国策树。在编辑国策树时推荐使用相对位置。代码样例如下：

focus = {
	id = root_focus
	x = 2
	y = 0
}
focus = {
	id = branch_focus
	relative_position_id = root_focus
	x = -1
	y = 1
}

在这种情况下，root_focus的坐标为（2,0），而branch_focus的实际坐标为（1,1），可以通过移动root_focus来一起移动其后的整个国策树。

historical

(变量类型: 布尔boolean, 默认: no) 从未使用

历史AI(historical_ai)

(变量类型: AND trigger, 默认: { }) 如果历史AI国策是开启状态，AI只会当这个触发器为真时才会选择这个国策。

is_historical_focus_on

(变量类型: 布尔boolean, 默认: no) 当历史AI国策为启用时，这个布尔值为真。 使用例:

ai_will_do = {
        modifier = {
	        factor = 0
	        is_historical_focus_on = yes
	        date < 1145.1.4
        }
}

AI意愿(ai_will_do)

(变量类型: MTTH, 默认: { base = 1 }) 定义AI选择这个国策的可能性。The value is further modified by +50% if the focus is not at the root of a branch, proportionately reduced if a mutually exclusive choice, as well as multiplied by any focus_factors in AI strategy plans. For each available focus, the AI generates a random number between 0 and the calculated value. It chooses the focus with the highest resulting number.

For example if two focuses are available with calculated values of 1.5 and 3 respectively, the former has a chance of 1-in-6 to be picked and the latter 5-in-6.

导致与某国的战争(will_lead_to_war_with)

(变量类型: country tag) 当该国策进行时，这个国家会收到提示警告，告知本国正在被正当化战争借口。可以出现多次。

本地化(Localization)

国策的本地化键值以国策的id（或文本id）作为前缀。例如，有一个国策id = XYZ，那么本地化键值应该为：

• XYZ：名称
• XYZ_desc：描述

国策树

每一个国家都有一个包括许多国策的国策树。并且还可以加入持续性国策和共享国策。

属性

id

(变量类型: 字符串string) 国策树的独一无二的标识符。

国家(country)

(变量类型: MTTH, 默认: { base = 1 })国家（tag）适用这个国策的分数。一个国家会使用相应分值最高的国策树。为了把国策树给到相应国家上，这个值应该高于默认的0，为目标国家添加一个较高的修正值。

默认(default)

(变量类型: 布尔boolean, 默认 no) 如果为yes，这个国策树会给所有没有比0更高的分值的国策树的国家。只有一个国策树应该设为默认，在原版游戏中是generic_focus。

在内战中重设(reset_on_civil_war)

(变量类型: 布尔boolean, 默认: yes) 如果为no，当内战中新出现的国家获得相同的国策树时，它会自动继承原国家的所有国策进度。否则，内战出现的国家会从头开始进行国策。

持续性国策位置(continuous_focus_position)

(变量类型: point, 默认: { x = 0, y = 0 }) 持续性国策面板的视觉位置。

国策(focus)

(变量类型: national focus) 以上文中所说的方式定义和添加一个国策。可以出现多次。

共享国策(shared_focus)

(变量类型: 字符串string) 使得该国策及它的依赖项可以被植入其他国策树。可以出现多次。一个共享国策必须在任何国策树之外用shared_focus定义，否则它的含义和普通国策相同。

例子

shared_focus = {
    id = shared_1
    x = 10
    offset = {
        x = 10
        trigger = {
            tag = LIT
        }
    }
    completion_reward = {
        army_experience = 10
    }
}
focus_tree = {
    id = lithuania_focus
    country = {
        base = 0
        modifier = {
            add = 10
            tag = LIT
        }
    }
    shared_focus = shared_1

    focus = {
        id = LIT_focus_1
        x = 10
        completion_reward = {
            navy_experience = 10
        }
    }
    focus = {
        id = LIT_focus_2
        prerequisite = { focus = LIT_focus_1 }
        relative_position_id = LIT_focus_1
        y = 10
        completion_reward = {
            navy_experience = 10
        }
    }
}
focus_tree = {
    id = basic_focus
    country = {
        base = 1
    }
    shared_focus = shared_1
}

模组制作