Hands-On Usage
has_cavalry_ratio is commonly used in combat-related modifier or trait trigger scenarios, such as granting exclusive combat bonuses to a combatant when their cavalry composition reaches a sufficient threshold, or activating cavalry charge decisions/traits in specific terrain types (e.g., plains, deserts). It is only effective within the COMBATANT scope (i.e., the perspective of each side in combat), so it typically appears in on_combat_enter or combat-related event trigger blocks.
# Cavalry-led charge: triggers special trait when attacker's cavalry ratio exceeds 50%
on_combat_enter = {
attacker = {
limit = {
is_attacker = yes
has_cavalry_ratio > 0.5
is_fighting_in_terrain = plains
}
add_trait = { trait = cavalry_charge_specialist }
}
}
Synergy
- is_attacker / is_defender: Distinguish between attacker and defender before checking cavalry ratio, avoiding logic triggering simultaneously for both sides and ensuring effects apply only to the intended party.
- is_fighting_in_terrain: Cavalry gains more pronounced advantages in specific terrains (plains, deserts); stacking terrain detection with cavalry ratio checks enables more tactically realistic conditional logic.
- has_artillery_ratio: Structurally analogous to artillery ratio triggering, often paired for "unit composition assessment" logic, facilitating comparison or mutual exclusion when handling different unit type-dominant force compositions.
- is_winning: Stack additional bonuses when your side is already winning and cavalry ratio is high, simulating the tactical effect of cavalry expanding victories and pursuing routed enemies.
Common Pitfalls
- Forgetting the scope must be COMBATANT: Writing
has_cavalry_ratio directly in country scope or province scope causes script errors or prevents triggering; code must be positioned within the context blocks of combatants (such as within attacker = { } or defender = { }) to function properly.
- Using assignment or equality operators instead of comparison operators:
has_cavalry_ratio = 0.5 semantically means "equals exact value," which is almost impossible to hit in practice; use inequality operators like > 0.5 or > 0.3 instead, otherwise the condition remains perpetually false yet difficult to detect.