Welcome to aiscripters.com!

Fact

Std AI uses

In Parser

In AoK

Description

true

y

y

y

This fact is always true.

false

y

y

This fact is always false. (?) May be a "not" of all the following facts ?

and

y

y

y

Conditional "and".

nand

y

y

y

Conditional "not and".

nor

y

y

y

Conditional "not or"

not

y

y

y

Conditional "not"

or

y

y

y

Conditional "or".

xnor

y

y

Conditional "exclusive not or".

xor

y

y

Conditional "exclusive or".

attack-soldier-count <rel-op> <value>

y

y

y

Checks the computer player’s attack soldier count. An attack soldier is a land-based military unit currently assigned to attack groups.

attack-warboat-count <rel-op> <value>

y

y

Checks the computer player’s attack warboat count. An attack warboat is a boat capable of attacking and currently assigned to attack groups.

building-available <building>

y

y

Checks that the building is available to the computer player's civ, and that the tech tree prerequisites are met. It does not check that there are enough resources to build the building. It allows the use of building line wildcard parameters for the <building>.

building-count <rel-op> <value>

y

y

Checks the computer player's building count. Only existing buildings are included.

building-count-total <rel-op> <value>

y

y

Checks the computer player's total building count. The total includes existing and queued buildings.

building-type-count <building> <rel-op> <value>

y

y

y

Checks the computer player's building count. Only existing buildings of the given type are included. It allows the use of building line wildcard parameters for the <building>.

building-type-count-total <building> <rel-op> <value>

y

y

y

Checks the computer player's total building count. The total includes existing and queued buildings of the given type. It allows the use of building line wildcard parameters for the <building>.

can-afford-building <building>

y

y

Checks whether the computer player has enough resources to build the given building. It does not take into account escrowed resources. It allows the use of building line wildcard parameters for the <building>.

can-afford-complete-wall <perimeter> <wall>

y

y

y

Checks whether the computer player has enough resources to finish the given wall at the given perimeter. It does not take into account escrowed resources. In particular it checks: ? That the wall type is available to the computer player’s civilization. ? That the tech tree prerequisites for using that wall type are met. ? That the resources needed for completing a wall line are available, not counting escrow amounts.

can-afford-research <research-item>

y

y

Checks whether the computer player has enough resources to perform the given research. The fact does not take into account escrowed resources.

can-afford-unit <unit>

y

y

y

Checks whether the computer player has enough resources to train given unit. The fact does not take into account escrowed resources. The fact allows the use of unit line wildcard parameters for the <unit>.

can-build <building>

y

y

y

This fact checks whether the computer player can build the given building. In particular it checks:? That the building is available to the computer player’s civilization.? That the tech tree prerequisites for building are met.? That the resources needed for the building are available, not counting escrow amounts. The fact allows the use of building line wildcard parameters for the <building>.

can-build-gate <perimeter>

y

y

checks whether construction of a gate as part of the given perimeter wall can start.The fact does not take into account escrow resources.In particular it checks:That the gate is available to the computer player’s civilization.That the tech tree prerequisites for building a gate are met.That the resources needed for building a gate are available, not counting escrow amounts.That there is a location to build a gate.

can-build-gate-with-escrow <perimeter>

y

y

y

checks whether construction of a gate as part of the given perimeter wall can start.The fact takes into account escrow resources.In particular it checks:That the gate is available to the computer player’s civilization.That the tech tree prerequisites for building a gate are met.That the resources needed for building a gate are available when using escrow amounts.That there is a location to build a gate.

can-build-wall <perimeter> <wall-type>

y

y

checks whether a wall line of the given wall type can be built at the given perimeter.The fact does not take into account escrow resources.In particular it checks:That the wall type is available to the computer player’s civilization.That the tech tree prerequisites for using that wall type are met.That the resources needed for building a wall line are available, not counting escrow amounts.That there is a location to build a wall line.The fact allows the use of wall line wildcard parameters for the <wall-type>.

can-build-wall-with-escrow <perimeter> <wall>

y

y

y

checks whether a wall line of the given wall type can be built at the given perimeter.The fact takes into account escrow resources.In particular it checks:That the wall type is available to the computer player’s civilization.That the tech tree prerequisites for using that wall type are met.That the resources needed for building a wall line are available when using escrow amounts.That there is a location to build a wall line.The fact allows the use of wall line wildcard parameters for the <wall-type>.

can-build-with-escrow <building>

y

y

y

checks whether the computer player can build the given building. In particular it checks:That the building is available to the computer player’s civilization.That the tech tree prerequisites for building are met.That the resources needed for building are available when using escrow amounts.The fact allows the use of building line wildcard parameters for the <building>.

can-buy-commodity <commodity>

y

y

y

checks whether the computer player can buy one lot of the given commodity.The fact does not take into account escrowed resources.

can-research <research-item>

y

y

y

checks if the given research can start. In particular it checks:That the research item is available to the computer player's civilization.That the tech tree prerequisites for research are met.That resources needed for research are available, not counting escrow amounts.That there is a building that is not busy and is ready to start research.

can-research-with-escrow <research-item>

y

y

y

checks if the given research can start. In particular it checks:That the research item is available to the computer player's civilization.That the tech tree prerequisites for research are met.That resources needed for research are available when using escrow amounts.That there is a building that is not busy and is ready to start research.

can-sell-commodity <commodity>

y

y

y

checks whether the computer player can sell one lot of the given commodity.The fact does not take into account escrowed resources.

can-spy

y

y

y

fact checks if the spy command can be executed.The fact takes into account escrowed resources.

can-spy-with-escrow

y

y

fact checks if spy command can be executed.The fact does not take into account escrowed resources.

can-train <unit>

y

y

y

checks if the training of the given unit can start. In particular it checks:That the unit is available to the computer player's civilization.That the tech tree prerequisites for training the unit are met.That resources needed for training the unit are available, not counting escrow amounts.That there is enough housing headroom for the unit.That there is a building that is not busy and is ready to start training the unit.The fact allows the use of unit line wildcard parameters for the <unit>.

can-train-with-escrow <unit>

y

y

y

checks if the training of the given unit can start. In particular it checks:That the unit is available to the computer player's civilization.That the tech tree prerequisites for training the unit are met.That resources needed for training the unit are available when using escrow amounts.That there is enough housing headroom for the unit.That there is a building that is not busy and is ready to start training the unit.The fact allows the use of unit line wildcard parameters for the <unit>.

cc-players-building-count <player-number> <rel-op> <value>

y

y

A cheating version of players-building-count. For use in scenarios only.The fact checks the given player's building count. Both existing buildings and buildings under construction are included regardless of whether they have been seen – fog is ignored.The fact allows “any”/”every” wildcard parameters for the <player-number> and the use of building line wildcard parameters for the <building>.

cc-players-building-type-count <player-number> <building> <rel-op> <value>

y

y

y

A cheating version of players-building-type-count. For use in scenarios only.This fact checks the given player's building count. Both existing buildings and buildings under construction of the given type are included regardless of whether they have been seen – fog is ignored.The fact allows “any”/”every” wildcard parameters for the <player-number> and the use of building line wildcard parameters for the <building>.

cc-players-unit-count <player-number> <rel-op> <value>

y

y

A cheating version of players-unit-count. For use in scenarios only.This fact checks the given player's unit count. Only trained units are included and fog is ignored.The fact allows “any”/”every” wildcard parameters for the <player-number>.

cc-players-unit-type-count <player-number> <unit> <rel-op> <value>

y

y

y

A cheating version of players-unit-type-count. For use in scenarios only.This fact checks the given player's unit count. Only trained units of the given type are included and fog is ignored.The fact allows “any”/”every” wildcard parameters for the <player-number>.

cheats-enabled

y

y

fact checks whether the cheats have been enabled.

civilian-population <rel-op> <value>

y

y

y

checks the computer player’s civilian population. The civilian population is villagers, trade vehicles, fishing boats, etc.

civ-selected <civ>

y

y

y

checks the computer player’s civ.

commodity-buying-price <commodity> <rel-op> <value>

y

y

y

fact checks the current buying price for the given commodity.

commodity-selling-price <commodity> <rel-op> <value>

y

y

y

checks the current selling price for the given commodity.

current-age <rel-op> <age>

y

y

y

fact checks computer player’s current age.

current-age-time <rel-op> <value>

y

y

y

checks the computer player’s current age time -- time spent in the current age.

current-score <rel-op> <value>

y

y

checks the computer player’s current score.

death-match-game

y

y

checks if the game is a Death Match game.

defend-soldier-count <rel-op> <value>

y

y

y

Checks the computer player's defend soldier count.A defend soldier is a land-based military unit not assigned to attack groups.

defend-warboat-count <rel-op> <value>

y

y

y

checks the computer player's defend warboat count.A defend warboat is a boat capable of attacking and not assigned to attack groups.

difficulty <rel-op> <difficulty>

y

y

y

checks difficulty setting.

doctrine <value>

y

y

checks what the current doctrine is.

dropsite-min-distance <resource-type> <rel-op> <value>

y

y

y

checks computer player’s minimum dropsite walking distance for a given resource type. Long walking distances indicate a need for a new dropsite.It is not recommended to use this fact for building of first dropsites necessary for age advancement. If, at the beginning, the resources happen to be close enough to the Town Center, building of the first dropsites will be delayed, resulting in slower age progression

enemy-buildings-in-town

y

y

checks for enemy buildings in a computer player's town. This fact will return true if an enemy building is sighted within sn-maximum-town-size tiles of the AI's main town center.

enemy-captured-relics

y

y

y

Checks if the enemy has captured all relics. When this happens, tactical AI automatically starts targeting Monasteries and Monks (?). Use this fact to intensify attacks and combine it with the attack-now action to force attacks.

escrow-amount <resource-type> <rel-op> <value>

y

y

fact checks a computer player’s escrow amount for a given resource type.

event-detected <event-type> <event-id>

y

y

fact checks if the given event has been detected. The fact stays true until the event is explicitly disabled by the acknowledge-event action

food-amount <rel-op> <value>

y

y

y

checks a computer player’s food amount.

game-time <rel-op> <value>

y

y

y

checks the game time. The game time is given in seconds. The fact can be used to make rules time-specific. For example, the computer can become more aggressive after 15 minutes of game time.

game-type <game-type>

y

y

undocumented command that checks the game type.

gate-count <wall-perimeter> <rel-op> <value>

y

y

allows the script to check for the number of gates that are either being built or are completed.

goal <goal-id> <value>

y

y

y

checks what the given goal is.

gold-amount <rel-op> <value>

y

y

y

checks a computer player’s gold amount.

hold-relics

y

y

y

tells the script whether or not it (or its team) has all of the relics.

hold-koh-ruin

y

y

y

tells the script whether or not it (or its team)currently holds the monument in monument games.

housing-headroom <rel-op> <value>

y

y

y

fact checks computer player’s housing headroom. Housing headroom is the difference between current housing capacity and trained unit capacity. For example, a computer player has a Town Center (capacity 5), a House (capacity 5) and 6 villagers. In this case, housing headroom is 4.

idle-farm-count <rel-op> <value>

y

y

y

fact checks a computer player’s idle farm count – the number of farms with no farmers. It should be used before a new farm is built to make sure it is needed.

map-size <map-size>

y

y

checks map size.

map-type <map-type>

y

y

y

checks map type.

military-population <rel-op> <value>

y

y

y

checks computer player’s military population.

player-computer <player-number>

y

y

y

checks if the given player is a computer player.The fact allows “any”/”every” wildcard parameters for the <player-number>.

player-human <player-number>

y

y

y

checks if the given player is a human.The fact allows “any”/”every” wildcard parameters for the <player-number>.

player-in-game <player-number>

y

y

y

fact checks if the given player is a valid player and still playing.The fact allows “any”/”every” wildcard parameters for the <player-number>.

player-number <player-number>

y

y

fact checks computer player’s player number.

player-resigned <player-number>

y

y

fact checks if the given player has lost by resigning. Note that a player can lose without resigning, so this fact should not be used to check whether a player has lost a game. To check whether a player has lost a game use (not (player-in-game <player-number)).The fact allows “any”/”every” wildcard parameters for the <player-number>.

player-valid <player-number>

y

y

checks if the given player is a valid player. In games with more than 2 players, players that lost before the game is over are considered to be valid players. This is because although the player is not in the game, their units/buildings can still be in the game. To check whether the given player is still in the game use the player-in-game fact.The fact allows “any”/”every” wildcard parameters for the <player-number>.

players-achievements ??

y

undocumented. does not appear to work ?

players-building-count <player-number> <rel-op> <value>

y

y

checks the given player's building count. Both existing buildings and buildings under construction are included. The computer player relies only on what it has seen – no cheating.The fact allows “any”/”every” wildcard parameters for the <player-number> and the use of building line wildcard parameters for the <building>.

players-building-type-count <player-number> <building> <rel-op> <value>

y

y

y

checks the given player's building count. Both existing buildings and buildings under construction of the given type are included. The computer player relies only on what it has seen – no cheating.The fact allows “any”/”every” wildcard parameters for the <player-number> and the use of building line wildcard parameters for the <building>.

players-civ <player-number> <civ>

y

y

checks the given player’s civ.The fact allows “any”/”every” wildcard parameters for the <player-number>.

players-civilian-population <player-number> <rel-op> <value>

y

y

y

fact checks a given player’s civilian population.This is equivalent to a human player checking the timeline.The fact allows “any”/”every” wildcard parameters for the <player-number>.

players-current-age <player-number> <rel-op> <age>

y

y

y

checks the given player’s current age.This is equivalent to a human player checking the timeline.The fact allows “any”/”every” wildcard parameters for the <player-number>.

players-current-age-time <player-number> <rel-op> <value>

y

y

checks the given player’s current age time -- time spent in the current age.This is equivalent to a human player checking the timeline.The fact allows “any”/”every” wildcard parameters for the <player-number>.

players-military-population <player-number> <rel-op> <value>

y

y

y

fact checks the given player’s military population.This is equivalent to a human player checking the timeline.The fact allows “any”/”every” wildcard parameters for the <player-number>.

players-population <player-number> <rel-op> <value>

y

y

y

checks the given player’s population.This is equivalent to a human player checking the timeline.The fact allows “any”/”every” wildcard parameters for the <player-number>.

players-score <player-number> <rel-op> <score>

y

y

fact checks the given player’s current score.The fact allows “any”/”every” wildcard parameters for the <player-number>.

players-stance <player-number> <diplomatic-stance>

y

y

y

checks the given player’s diplomatic stance.The fact allows “any”/”every” wildcard parameters for the <player-number>.

players-tribute <player-number> <resource-type> <rel-op> <value>

y

y

y

checks the player's tribute given throughout the game. Only tribute for the given resource type is checked.The fact allows “any”/”every” wildcard parameters for the <player-number>.

players-tribute-memory <player-number> <resource-type> <rel-op> <value>

y

y

y

checks a player's tribute given since the player's tribute memory was cleared. Only tribute memory for the given resource type is checked.The fact allows “any”/”every” wildcard parameters for the <player-number>.

players-unit-count <player-number> <rel-op> <value>

y

y

checks the given player's unit count. The computer player relies only on what it has seen – no cheating. For allies and self only trained units are included.The fact allows “any”/”every” wildcard parameters for the <player-number>.

players-unit-type-count <player-number> <unit> <rel-op> <value>

y

y

checks the given player's unit count. The computer player relies only on what it has seen – no cheating. For allies and self only trained units of the given type are included.The fact allows “any”/”every” wildcard parameters for the <player-number>.

population <rel-op> <value>

y

y

y

checks the computer player’s population.

population-cap <rel-op> <value>

y

y

checks population cap setting.

population-headroom <rel-op> <value>

y

y

y

checks the computer player’s population headroom. Population headroom is the difference between the game’s population cap and current housing capacity. For example, in a game with a population cap of 75, the computer player has a town center (capacity 5) and a house (capacity 5). In this case population headroom is 65.

random-number <rel-op> <value>

y

y

y

checks random number value.

regicide-game

y

y

checks if the game is a regicide game.

research-available <research-item>

y

y

y

checks that the given research is available to the computer player's civ, and that the research is available at this time (tech tree prerequisites are met). The fact does not check that there are enough resources to start researching.

research-completed <research-item>

y

y

y

fact checks that the given research is completed.

resource-found <resource-type>

y

y

y

checks whether the computer player has found the given resource.The facts should be used at the beginning of the game. Once it becomes true for a certain resource it stays true for that resource. In this context, food refers to a forage site.

shared-goal <shared-goal-id> <value>

y

y

checks a given shared goal -- a goal that is shared among computer players. It is to be used only when all computer players are on the same team.

sheep-and-forage-too-far

y

y

y

checks whether the computer player has any forage site(s) and/or sheep within 8 tiles of the drop-off location (Mill or Town Center).

soldier-count <rel-op> <value>

y

y

y

fact checks the computer player’s soldier count. An attack soldier is a land-based military unit.

stance-toward <player-number> <diplomatic-stance>

y

y

y

checks the computer player’s stance toward a given player.The fact allows “any”/”every” wildcard parameters for the <player-number>.

starting-age <rel-op> <age>

y

y

checks the game's starting age. In addition to the regular age parameters, POST-IMPERIAL-AGE-START can be used.

starting-resources <rel-op> <starting-resources>

y

y

y

checks starting resources (low, medium, or high).

stone-amount <rel-op> <value>

y

y

y

checks a computer player’s stone amount.

strategic-number <strategic-number> <rel-op> <value>

y

y

y

checks a strategic number’s value.

taunt-detected <player-number> <taunt-id>

y

y

y

detects a given taunt. The check can be performed any number of times until the taunt is explicitly acknowledged. The fact allows “any”/”every” wildcard parameters for the <player-number>.

timer-triggered <timer-id>

y

y

y

checks whether a given timer has triggered. For disabled timers this fact is always false. The check can be performed any number of times until the timer is explicitly disabled.

town-under-attack

y

y

y

set to true when a computer player’s town is under attack. The town size is defined by sn-maximum-town-size

unit-available <unit>

y

y

checks that the unit is available to the computer player's civ, and that the tech tree prerequisites for training the unit are met.The fact does not check whether the unit training can start. This depends on resource availability, housing headroom, and whether the building needed for training is currently used for research/training of another unit.The fact allows the use of unit line wildcard parameters for the <unit>.

unit-count <rel-op> <value>

y

y

checks the computer player's unit count. Only trained units are included.

unit-count-total <rel-op> <value>

y

y

fact checks the computer player's total unit count. The total includes trained and queued units.

unit-type-count <unit> <rel-op> <value>

y

y

y

fact checks the computer player's unit count. Only trained units of the given type are included.The fact allows the use of unit line wildcard parameters for the <unit>.

unit-type-count-total <unit> <rel-op> <value>

y

y

y

fact checks the computer player's total unit count. The total includes trained and queued units of the given type.The fact allows the use of unit line wildcard parameters for the <unit>.

victory-condition <victory-condition>

y

y

checks the game victory condition.

wall-completed-percentage <perimeter> <rel-op> <value>

y

y

y

checks the completion percentage for a given perimeter wall. Trees and other destructible natural barriers are included and count as completed.

wall-invisible-percentage <perimeter> <rel-op> <value>

y

y

y

fact checks what percentage of the potential wall placement is covered with fog. If the invisible percentage is not equal to 0 we do not know if there is a hole or not. This is because the hidden tile(s) might have a tree(s).

warboat-count <rel-op> <value>

y

y

y

fact checks the computer player’s warboat count. A warboat is a boat capable of attacking.

wood-amount <rel-op> <value>

y

y

y

checks the computer player’s wood amount.