The build flags serve two purposes: they tell the computer player under what conditions it's OK to build the object (the first eight flags), and they can mark an object for a special relationship with other objects (the last 10 flags).
First we'll look at the build flags that actually relate to building. Setting these flags only increases the chance that an object will get built under the right circumstances and are not by any means a guarentee that the computer player won't do something very stupid.
|build flag name||function|
|uncaputed base exists||does any base (objects with the "is destination" attribute flag set) that belongs to someone else exist?|
|sufficient escort exists||are there enough available escorts? for objects which are vulnerable and need escort; "sufficient" is determined by the objects "friend deficit"|
|this base needs protection||not used|
|friend up trend||not used|
|friend down trend||not used|
|foe up trend||not used|
|foe down trend||not used|
|matching foe exists||does an object owned by a different player and with matching level key flags exist?|
Special relationships mean objects that have specialized interactions with other objects. For example, transports have a secial relationship with planets -- transports can only land on planets; they can't land on carriers or missiles or asteroids or anything else.
To help define these relationships, you can set an object's level key flags. These flags are used in a variety of places and are refered to by their letters: key A, B, C, and D. Each letter can be set to be either on or off. The default setting for all four level key flags is off. There are fifteen additional combinations available. That means there's a maximum of fifteen "special relationships" possible per level.
Level key flags are used to define special relationships in three ways: by matching to the engage key flags, by matching to order key flags, or by matching to action inclusive filter flags. A match to a level key flag must be exact.
Order key flags and action inclusive filter flags will be described later.
The level key flags and the engage key flags are part of the build flag menu, even though they don't have mcuh to do with building. The last ten items of the build flag menu relate o the level key flags:
|build flag name||function|
|only engaged by||no other object will automatically consider this object a target, unless its engage key flags match this object's level key flags|
|can only engage||this object will only consider another object a target if the other object's level key flags match this object's engage key flags|
|engage key flag A||is engage key flag A set?|
|engage key flag B||is engage key flag B set?|
|engage key flag C||is engage key flag C set?|
|engage key flag D||is engage key flag D set?|
|level key flag A||is level key flag A set?|
|level key flag B||is level key flag B set?|
|level key flag C||is level key flag C set?|
|level key flag D||is level key flag D set?|
The relationship between astrominers and asteroids is a good example of the use of level key flags and engage key flags. The desired behavior is or all ships to ignore the asteroids, except astrominers. The astrominers should shoot at the asteroids.
To achieve this, the astrominer object has the engage key flags A, B, and D set, and all other build flags cleared. The asteroid object has the "only engaged by" flag set and the level key flags A, B, and D set.
Since the Cantharan cruiser, for example, has none of its engage key flags set, the Ares engine never allows the cruiser to consider the asteroids a target. Ares sees that the asteroid object's "only engaged by" flag is set, and that the cruiser's engage key flags don't match the asteroid's level key flags.
However, since the astrominer's engage key flags do match, it is allowed to consider the asteroid a target.