An initial is a procyon value with the following fields:
|base||yes||remapped name of an object|
|owner||no||index of a player|
|target.initial||no||index of an initial|
|override.sprite||no||name of a sprite|
|build||no||array of remapped names of objects|
This feature is used in net levels. If an initial specifies base: "hvd", and the player chooses to play Ishimans (ish), then it will be an Ishiman heavy destroyer (ish/hvd). If the player chooses Cantharans (can), then it will be a Cantharan heavy destroyer (can/hvd). The net level must not allow the player to choose Elejeetians, as no object named ele/hvd or hvd exists.
In solo levels, player races are fixed, so it’s recommended (but not required) to use base: "ish/hvd" or base: "can/hvd" for clarity.
The index of the player that initially owns the object. If null, the object is neutral.
The point at which to create the object. Most levels are randomly rotated, and the level’s rotation is applied to this location.
If true, then the object won’t be created at the beginning of the level. It can be explicitly created later by the reveal action.
If true, then this object is its owner’s flagship. Every human player must have exactly one flagship. Non-human players should not have a flagship.
If true, then it is not possible for a player to order this object to a new target. This should typically be used with target.initial. Together, they lock the object into guard or escort duty.
A replacement name for the object. Most planets and stations have their names overridden, so that the player can easily tell them apart. Typical names from the factory scenario would be:
|Planet||Regulus Alpha, Regulus Beta, Regulus Gamma|
|Moon||Regulus Alpha 1, Regulus Alpha 2|
|Bunker Station||Bunker Station 1, Bunker Station 2|
|Power Station||Power Station R-1, Power Station R-2|
|Outpost||Outpost 1, Outpost 2, Outpost 3|
Names should be at most 25 characters. Longer names won’t fit in the computer.
A replacement sprite for the object. Most planets and moons have their sprites overridden.
The override sprite must have the same number of frames as the original sprite.
There are a large number of override sprites available for planets and moons:
Typical values from the factory scenario are:
When determining what objects an initial can build, Antares first maps each entry base according to the initial’s owner’s race:
build: * "cruiser" * "hvc" * "can/defdrone" * "gro/gateship"
In this case: