Go to the first, previous, next, last section, table of contents.

## Automation of Units and Sides

Specifying the exact sequence of actions and their operands for every single unit would be mind-numbingly complex, and, for that matter, not very realistic either. Therefore, Xconq includes several levels of automation for human players.

The elements of automation are the task, the plan, the doctrine, and the strategy. These are related to each other by goals.

Tasks are single activities of a unit that require one or more actions to accomplish. Examples of tasks include moving to a given position, or waiting 15 turns to be picked up by a transport. Most of the commands that you give while playing actually set up tasks rather than individual actions.

A plan is the unit's object that expresses its decided-upon behavior. Elements of a plan include a type, possibly one or more goals, a task agenda, plus some assorted flags and properties. All units that can act and that are on a side will have a plan, while independent units that can do actions may have a plan that is preset by a scenario. Plans primarily govern individual behavior, in many cases allowing the unit to act on its own, without needing any explicit direction from the player.

The doctrine is the set of parameters governing how the side will play and how its units should work generally. For instance, per-unit doctrine specifies the point which a unit low on supply should start to look for a place to replenish itself.

The strategy and associated subobjects is what an AI uses to make all the decisions about what to do. This object is not directly visible, unless the AI is acting as your assistant and the interface includes a display of its strategy.

Of all these types of objects, only the doctrine can be manipulated directly; all others are implicitly changed as a result of player commands, which are different for each interface.

The Standing order command allows you to set up conditions for execution of tasks.

- Using Doctrine
- Plans
- Tasks
- Standing Orders

### Using Doctrine

There is a doctrine for each type of unit on your side. Several types may share a single doctrine, so that changes to it will affect all types equally.

- construction-run

[more doctrine info]

### Plans

A unit's plan must be one of the types listed here.

- None (`none`). Units with this type of plan do absolutely nothing.
- Passive (`passive`). Units with a passive plan will execute any tasks they have been given, but will not add to the task agenda on their own. By default, if you are running the side by yourself, with no AI assistant, your units will have this type of plan.
- Offensive (`offense`). Units with an offensive plan will look for favorable combat opportunities, usually within an area specified as their goal to hold.
- Defensive (`defense`). Units with a defensive plan will seek to preserve the status quo.
- Exploratory (`explore`). Exploratory units will seek to collect information about unknown parts of the world.

### Tasks

A task has several standard properties and may have additional properties specific to the task's type. Xconq keeps track of how many times a task has been executed and how many times it has failed to execute a step correctly. For example, a movement task to a distant location may need to execute 100 times, but it will only fail if the unit is actually blocked from moving. If a task fails too many times, the plan or the AI may decide to remove the task from its agenda. If a task succeeds, it will always be removed.

Each task in a plan's task agenda must be one of the types listed here.

- Do nothing (`none`).
- Sentry (`sentry turns`). Stand sentry at the present location for a given number of turns. This is not the same as sleeping, since it is for a definite period of time.
- Move in a direction (`move-dir direction`). Move in the given direction up to the given distance.
- Move to a location (`move-to location`). Move to within a given distance of the given location.
- Occupy a unit (`occupy unit`). Move towards a given unit and attempt to enter it.
- Pick up a unit (`pickup unit`). Move towards the given unit and wait for it to enter.
- Build (`build unit-type n`). Build a given number of units of a given type. This task will do research actions if necessary and possible, and toolup actions if necessary. Also, if there is an incomplete unit of the given type nearby, this task will complete it before creating a new unit.
- Research (`research unit-type n`). Do research to increase the tech for a given type up to a given level.
- Hit a position (`hit-position location`). Attempt to attack or fire on any units at the given position.
- Hit a unit (`hit-unit unit`). Attempt to attack a given unit.
- Capture a unit (`capture location`). Attempt to capture a unit at a given location, optionally of a given type and on a given side.
- Resupply (`resupply material-type`). Replenish depleted supplies. This may be accomplished by production actions, moving to higher-productivity terrain, or by moving within supply range of a unit with the desired supplies.
- Repair (`repair unit`). Repair damage to the given unit.
- Do a specific action (`do-action action-parms...`).

### Standing Orders

Standing orders are basically a combination of a test or condition and a task to be performed when the condition is met. The textual form of the command is "if <type> <test> <task>", where <type> is a name of a unit type, <test> is some sort of condition, and <task> is a task, as described previously.

Possible tests include `at location`, `in unit`, and `near location dist`.

The `at` test applies to the unit if it comes to be in a particular cell, for whatever reason. The location may be either a comma-separated pair of coordinates, or the name of a unit.

The `near` test is similar to `at`, but you give an additional argument that says how close, in cells, the unit must be for the order to apply. For instance, a distance of 1 means that the order applies to units at the given location and to all adjacent units. This is useful if you want to have several kinds of units use a rendezvous point that is on a type of terrain that some of the kinds can't use, or if there are stacking limits and requiring all units to converge on a single cell would result in traffic jams.

The `in` test applies to the unit if it is an occupant of the given unit.

If a unit is already performing another task, it will ignore any standing orders in any location that it happens to be passing over; so it is not possible for the standing order to waylay the unit and send off doing something else. The unit must be under your orders ("passive" plan), not have any tasks on its agenda, and cannot be asleep or in reserve.

    if armor in Paris move-to Antwerp

    if bomber in London move-to 33,54
    if bomber at 33,54 hit-position 34,60

The second example shows how you can use several standing orders together to route units around obstacles or dangerous areas.

Go to the first, previous, next, last section, table of contents.