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, and the doctrine. 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.
Of all these types of objects, only the doctrine can be manipulated directly; all others are implicitly changed as a result of your commands.
The Standing order command allows you to set up conditions for execution of tasks.
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. The game design oftens sets default values for doctrine, based on what the designer thought would be convenient values.
The plan type of a unit's plan defines the unit's overall class of behavior.
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 plan's 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.
move-dir direction distance
move-to location distance
build unit-type n
develop unit-type n
capture location unit-type side
collect material-type location
Standing orders are basically a combination of a test or condition and a task to be performed when the condition is met. Some interfaces may provide a dialog to guide you through order setup, but all support the textual form of the command, which 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
near location dist.
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.
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.
in test applies to the unit if it is an occupant of the given
unit. The unit must be designated by name currently.
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 and third example commands show how you can use several standing orders together to route units around obstacles or dangerous areas.