Latest Posts

Changes in ProductionsiteProgramReference

Revision Differences of Revision 1

Productionsites can have programs that will be executed by the game engine. Each productionsite must have a program named_work_, which will be started automatically when the productionsite is created in the game, and then repeated until the productionsite is destroyed. Each program must be declared with program=_<name>_in the [_global_] section of the productionsite's definition. A program can call another program, which must have been declared earlier. A program is defined in the section that has the same name as the program (the order of program definitions does not matter). A program consists of a sequence of commands. A command is written as_<type>=<parameters>_. The different command types and the parameters that they take are explained below. ¶

# command types ¶

## return ¶

Returns from the program. ¶

Parameter syntax: ¶

parameters &nbsp;::= return_value [condition_part] ¶
return_value &nbsp;::= Failed | Completed | Skipped ¶
Failed &nbsp;::= ¶
Parameter semantics: ¶

return_value: ¶
If return_value is Failed or Completed, the productionsite's ¶
statistics is updated accordingly. If return_value is Skipped, the ¶
statistics are not affected. ¶
condition: ¶
A boolean condition that can be evaluated to true or false. ¶
condition_part: ¶
If omitted, the return is unconditional. ¶
when_condition: ¶
This will cause the program to return when all conditions are true. ¶
unless_condition: ¶
This will cause the program to return unless some condition is true. ¶

Aborts the execution of the program and sets a return value. Updates the ¶
productionsite's statistics depending on the return value. ¶

Note: If the execution reaches the end of the program. the return value is ¶
implicitly set to Completed. ¶

## call ¶

Calls a program of the productionsite. ¶

Parameter syntax: ¶

parameters &nbsp;::= program [failure_handling_directive] ¶
failure_handling_directive&nbsp;::= ¶
Parameter semantics: ¶

program: ¶
The name of a program defined in the productionsite. ¶
failure_handling_method: ¶
Specifies how to handle a failure of the called program. ¶
* If failure_handling_method is Fail, the command fails (with the ¶
same effect as executing ¶
## worker ¶

Calls a program of the productionsite's main worker. ¶

Parameter syntax: ¶

parameters&nbsp;::= ¶
Parameter semantics: ¶


## sleep ¶

Does nothing. ¶

Parameter syntax: ¶

parameters&nbsp;::= ¶
Parameter semantics: ¶


Blocks the execution of the program for the specified duration. ¶

## animate ¶

Runs an animation. ¶

Parameter syntax: ¶

parameters&nbsp;::= ¶
Parameter semantics: ¶


Starts the specified animation for the productionsite. Blocks the execution ¶
of the program for the specified duration. (The duration does not have to ¶
equal the length of the animation. It will loop around. The animation will ¶
not be stopped by this command. It will run until another animation is ¶
started.) ¶

## consume ¶

Consumes wares from the input storages. ¶

Parameter syntax: ¶

parameters&nbsp;::= group {group} ¶
group &nbsp;::= ¶
Parameter semantics: ¶


For each group, the number of wares specified in count is consumed. The ¶
consumed wares may be of any type in the group. ¶

If there are not enough wares in the input storages, the command fails ¶
(with the same effect as executing__return<b>=<b>failed__). Then no wares will be ¶
consumed. ¶

Selecting which ware types to consume for a group so that the whole command ¶
succeeds is a constraint satisfaction problem. The implementation does not ¶
implement an exhaustive search for a solution to it. It is just a greedy ¶
algorithm which gives up instead of backtracking. Therefore The command may ¶
fail even if there is a solution. ¶

However it may be possible to help the algorithm by ordering the groups ¶
carefully. Suppose that the input storage has the wares a:1, b:1 and a ¶
consume command has the parameters_a___,___b___:__1_a___:__1". The algorithm tries to ¶
consume its input wares in order. First it consumes wares of type a. It ¶
starts with the first group and consumes 1 (the group becomes satisfied). ¶
Then it proceeds with the second group, but there are no_a'_s left to ¶
consume. Since there is no other ware type that can satisfy the group, the ¶
command will fail. If the groups are reordered so that the parameters ¶
become_a___:__1_a___,___b___:__1", it will work. When the algorithm consumes wares of ¶
type a, it will consume 1 for the first group. When it proceeds with the ¶
second group, it will not have any_a'_s left. Then it will go on and ¶
consume wares of type_b_. it will consume 1 for the second group (which ¶
becomes satisfied) and the command succeeds. ¶

__Note:__It is not possible to reorder ware types within a group._a___,___b_" is ¶
equivalent to_b__,__a_because in the internal representation the ware types ¶
of a group are sorted. ¶

## produce ¶

Produces wares. ¶

Parameter syntax: ¶

parameters&nbsp;::= group {group} ¶
group &nbsp;::= ¶
Parameter semantics: ¶


For each group, the number of wares specified in count is produced. The ¶
produced wares are of the type specified in the group. How the produced ¶
wares are handled is defined by the productionsite. ¶

## mine ¶

Takes resources from the ground. This command type is subject to change. ¶

## check_soldier ¶

Returns failure unless there are a specified amout of soldiers with ¶
specified level of specified properties. This command type is subject to ¶
change. ¶

## train ¶

Increases the level of a specified property of a soldier. No further ¶
documentation available. ¶

## playFX ¶

Plays a soundFX. ¶

Parameter syntax: ¶

parameters&nbsp;::= ¶
Parameter semantics: ¶


Plays the specified soundFX with the specified priority. Whether the ¶
soundFX is actually played is determined by the sound handler. ¶