Sophie: xconq-7.5.0-1.20050612.5mdv2009.1 i586

xconq-7.5.0-1.20050612.5mdv2009.1.i586.rpm

<HTML>
<HEAD>
<!-- This HTML file has been created by texi2html 1.39
     from ./xconq.texi on 12 June 2005 -->

<TITLE>Xconq - Automating the Units</TITLE>
</HEAD>
<BODY>
Go to the <A HREF="xconq_1.html">first</A>, <A HREF="xconq_17.html">previous</A>, <A HREF="xconq_19.html">next</A>, <A HREF="xconq_66.html">last</A> section, <A HREF="xconq_toc.html">table of contents</A>.
<HR>


<H2><A NAME="SEC39" HREF="xconq_toc.html#SEC39">Automating the Units</A></H2>

<P>
<A NAME="IDX126"></A>
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, <I>Xconq</I> includes several levels of
automation for human players.

</P>
<P>
The elements of automation are the <I>task</I>, the <I>plan</I>, and the
<I>doctrine</I>.  These are related to each other by <I>goals</I>.

</P>
<P>
<A NAME="IDX127"></A>
<STRONG>Tasks</STRONG> 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.

</P>
<P>
<A NAME="IDX128"></A>
<A NAME="IDX129"></A>
A <STRONG>plan</STRONG> is the unit's object that expresses its decided-upon
behavior.  Elements of a plan include a type, possibly one or more
goals, a <STRONG>task agenda</STRONG>, 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.

</P>
<P>
<A NAME="IDX130"></A>
The <STRONG>doctrine</STRONG> 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.

</P>

<P>
Of all these types of objects, only the doctrine can be manipulated
directly; all others are implicitly changed as a result of your
commands.

</P>
<P>
The <STRONG>Standing order</STRONG> command allows you to set up conditions for
execution of tasks.

</P>

<UL>
<LI><A HREF="xconq_18.html#SEC40">Doctrine</A>
<LI><A HREF="xconq_18.html#SEC41">Plans</A>
<LI><A HREF="xconq_18.html#SEC42">Tasks</A>
<LI><A HREF="xconq_18.html#SEC43">Standing Orders</A>
</UL>



<H3><A NAME="SEC40" HREF="xconq_toc.html#SEC40">Doctrine</A></H3>

<P>
<A NAME="IDX131"></A>
<A NAME="IDX132"></A>
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.

</P>
<DL COMPACT>

<DT><CODE>resupply</CODE>
<DD>
<A NAME="IDX133"></A>
This is the percent of supply at which a unit wakes up and wants to
return for resupply.  The default is usually around 50%, but for
instance aircraft that go all the way out to the halfway point will
sometimes be run out of fuel and be lost if they run into obstacles
(such as enemy aircraft).  If you want to be more conservative, set
the resupply percent to be, say, 60%.  Resupply applies to materials
that are part of base or movement consumption.

<DT><CODE>rearm</CODE>
<DD>
<A NAME="IDX134"></A>
This is similar to resupply doctrine, but applies to materials used
in combat, aka the ammo.

<DT><CODE>repair</CODE>
<DD>
<A NAME="IDX135"></A>
This is the damage percentage at which the unit will wake up and
want to return for repairs.

<DT><CODE>run</CODE>
<DD>
<A NAME="IDX136"></A>
This specifies the number of a type of unit to build by default.  You
can override this by using a prefix argument to the build command.

</DL>



<H3><A NAME="SEC41" HREF="xconq_toc.html#SEC41">Plans</A></H3>

<P>
<A NAME="IDX137"></A>
<A NAME="IDX138"></A>
The <STRONG>plan type</STRONG> of a unit's plan defines the unit's overall
class of behavior.

</P>
<DL COMPACT>

<DT><CODE>none</CODE>
<DD>
Units with this type of plan do absolutely nothing.

<DT><CODE>passive</CODE>
<DD>
<A NAME="IDX139"></A>
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.

<DT><CODE>offense</CODE>
<DD>
<A NAME="IDX140"></A>
Units with an offensive plan will look for favorable combat
opportunities, usually within an area specified as their goal to hold.

<DT><CODE>defense</CODE>
<DD>
<A NAME="IDX141"></A>
Units with a defensive plan will seek to preserve the status quo.

<DT><CODE>explore</CODE>
<DD>
<A NAME="IDX142"></A>
Exploratory units will seek to collect information about unknown parts
of the world.

<DT><CODE>colonizing</CODE>
<DD>
<DT><CODE>improving</CODE>
<DD>
<DT><CODE>random</CODE>
<DD>
<A NAME="IDX143"></A>
Units with a random plan will literally try to do anything.

</DL>



<H3><A NAME="SEC42" HREF="xconq_toc.html#SEC42">Tasks</A></H3>

<P>
<A NAME="IDX144"></A>
<A NAME="IDX145"></A>
A task has several standard properties and may have additional
properties specific to the task's type.  <I>Xconq</I> 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.

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

</P>
<DL COMPACT>

<DT><CODE>none</CODE>
<DD>
Do nothing.

<DT><CODE>sentry <VAR>turns</VAR></CODE>
<DD>
Stand sentry at the present location for a given number of turns.  This
is not the same as sleeping, since the task is only for a definite
period of time, while a sleeping unit will sleep indefinitely.

<DT><CODE>move-dir <VAR>direction</VAR> <VAR>distance</VAR></CODE>
<DD>
Move in the given direction up to the given distance.

<DT><CODE>move-to <VAR>location</VAR> <VAR>distance</VAR></CODE>
<DD>
Move to within a given distance of the given location.

<DT><CODE>occupy <VAR>unit</VAR></CODE>
<DD>
Occupy a unit.  Move towards a given unit and attempt to enter it.

<DT><CODE>pickup <VAR>unit</VAR></CODE>
<DD>
Pick up a unit.  Move towards the given unit and wait for it to enter.

<DT><CODE>build <VAR>unit-type</VAR> <VAR>n</VAR></CODE>
<DD>
Build a given number of units of a given type.  This task will do
development 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.

<DT><CODE>develop <VAR>unit-type</VAR> <VAR>n</VAR></CODE>
<DD>
Do development to increase the tech for a given type up to a given
level.

<DT><CODE>hit-position <VAR>location</VAR></CODE>
<DD>
Attempt to hit any units at the given position, using attack or fire
as appropriate.  The unit will move to get within range as necessary.

<DT><CODE>hit-unit <VAR>unit</VAR></CODE>
<DD>
Attempt to hit a given unit.  The attacking unit will move to get within range as necessary.

<DT><CODE>capture <VAR>location</VAR> <VAR>unit-type</VAR> <VAR>side</VAR></CODE>
<DD>
Attempt to capture a unit at a given location, optionally of a given
type and on a given side.

<DT><CODE>resupply <VAR>material-type</VAR></CODE>
<DD>
Resupply with the given material.  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.

<DT><CODE>collect <VAR>material-type</VAR> <VAR>location</VAR></CODE>
<DD>
Extract the given type of material from the given location (or nearby)
and optionally deliver it to a unit that can transfer it to the side's
treasury.

<DT><CODE>product <VAR>material-type</VAR></CODE>
<DD>
<DT><CODE>repair <VAR>unit</VAR></CODE>
<DD>
Repair damage to the given unit.

<DT><CODE>disband</CODE>
<DD>
Disband self.  If a unit cannot disband itself with a single action,
this task runs the multiple actions necessary.

</DL>



<H3><A NAME="SEC43" HREF="xconq_toc.html#SEC43">Standing Orders</A></H3>

<P>
<A NAME="IDX146"></A>
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

<PRE>
if <VAR>type</VAR> <VAR>test</VAR> <VAR>task</VAR>
</PRE>

<P>
where <VAR>type</VAR> is a name of a unit type, <VAR>test</VAR> is some sort of
condition, and <VAR>task</VAR> is a task, as described previously.

</P>
<P>
Possible tests include <CODE>at <VAR>location</VAR></CODE>, <CODE>in <VAR>unit</VAR></CODE>,
and <CODE>near <VAR>location</VAR> <VAR>dist</VAR></CODE>.

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

</P>
<P>
The <CODE>near</CODE> test is similar to <CODE>at</CODE>, 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.

</P>
<P>
The <CODE>in</CODE> test applies to the unit if it is an occupant of the given
unit.  The unit must be designated by name currently.

</P>
<P>
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
(<CODE>passive</CODE> plan), not have any tasks on its agenda, and cannot be
asleep or in reserve.

</P>

<PRE>
if armor in Paris move-to Antwerp

if bomber in London move-to 33,54

if bomber at 33,54 hit-position 34,60
</PRE>

<P>
The second and third example commands show how you can use several
standing orders together to route units around obstacles or dangerous
areas.

</P>
<HR>
Go to the <A HREF="xconq_1.html">first</A>, <A HREF="xconq_17.html">previous</A>, <A HREF="xconq_19.html">next</A>, <A HREF="xconq_66.html">last</A> section, <A HREF="xconq_toc.html">table of contents</A>.
</BODY>
</HTML>