Hands-On Usage
can_build_railway is commonly used in mods to check whether railway construction conditions are met. For example, it can be placed in a decision's available block to restrict players to building only when a viable path exists between specific provinces. It can also be used in event option trigger blocks, combined with controller_priority to dynamically filter enemy-controlled areas and implement logic that only allows building along allied territory.
# Example of decision availability condition: only opens if a railway can be built between capital and target state
available = {
can_build_railway = {
build_only_on_allied = yes
fallback = yes
start_state = 42
target_state = 100
controller_priority = {
base = 1
modifier = {
is_ally_with = ROOT
add = 3
}
}
}
}
Synergy
[build_railway](/wiki/effect/build_railway): can_build_railway serves as a prerequisite check; once passed, use build_railway to actually execute the construction. The two have highly symmetric parameter structures and can reuse the same path/start_state/target_state configuration.
[has_railway_connection](/wiki/trigger/has_railway_connection): Commonly combined with this trigger—first use has_railway_connection to exclude cases where a connection already exists, then confirm the new path is viable with can_build_railway to avoid duplicate construction.
[has_railway_level](/wiki/trigger/has_railway_level): Used to simultaneously check the existing railway level in the target area; combined with can_build_railway, it determines whether to build new or upgrade existing, making the logic more complete.
[if](/wiki/effect/if) / [if](/wiki/trigger/if): Embed can_build_railway within if conditional branches to dynamically select different construction strategies or hint text based on path viability.
Common Pitfalls
- Misunderstanding priority when
path, start_province/target_province, and start_state/target_state are written simultaneously: The three pathfinding methods are not equivalent stacks. The game processes them in option 1 → 2 → 3 priority order, and only falls back to the next option if the previous one fails when fallback = yes is enabled. Without fallback enabled, even if multiple option sets are written, only the first valid one is read; subsequent ones are silently ignored.
controller_priority returns negative values but you expect the path to still pass: Negative values are designed to mean "refuse to pass through provinces controlled by this entity." If you mistakenly set neutral or enemy province weights to negative, the entire path may be judged impassable due to inability to bypass it, causing the trigger to always return false. This hidden cutoff is easy to overlook during debugging.