Skip to content
OpenTS Manual

Rules registration lists

Formats

Changed in 0.2.0

Lists in the rules files that register each kind of rules type and assign countries to sides.

Format
Kind
Registry
File
RULES.INI, LANGRULE.INI, FIRESTRM.INI, LANGFS.INI, MPLAYER.INI, MPLAYERFS.INI

Registration sections

SectionID fromDefinition
[InfantryTypes]Value[<InfantryType ID>]
[Houses]Value[<HouseType ID>]
[VehicleTypes]Value[<UnitType ID>]
[AircraftTypes]Value[<AircraftType ID>]
[Sides]KeyComma-separated HouseType IDs
[Theaters]Value[<Theater ID>]
[SuperWeaponTypes]Value[<SuperWeaponType ID>]
[BuildingTypes]Value[<BuildingType ID>]
[TerrainTypes]Value[<TerrainType ID>]
[SmudgeTypes]Value[<SmudgeType ID>]
[OverlayTypes]Value[<OverlayType ID>]
[Animations]Value[<AnimType ID>]
[VoxelAnims]Value[<VoxelAnimType ID>]
[Weapons]Value[<WeaponType ID>]
[Warheads]Value[<WarheadType ID>]
[Particles]Value[<ParticleType ID>]
[ParticleSystems]Value[<ParticleSystemType ID>]
[Tiberiums]Value[<Tiberium ID>]

Every registration section except [Sides] lists one ID per line, written as the value. The key only labels the line, but a repeated key drops the earlier line, as described below. The ID also names the section that defines the type:

rules.ini
[InfantryTypes]
0=MYINF


[MYINF]
Name=Example infantry
Strength=100

This registers an infantry type MYINF and reads its settings from [MYINF].

Types are registered in the order their lines appear, and each rules file adds to the types that earlier files registered. The rules files are read in the order Multiplayer rules lists, and the scenario’s own overrides come last.

A line registers nothing in these cases:

  • Its value names an ID that is already registered, by an earlier line or an earlier file. The existing type keeps its place.
  • Its value is empty, none or <none>.
  • Another line later in the same section uses the same key. Only the later line’s ID is registered, at the later line’s place. This also applies when the section heading appears twice in one file.

Keep each ID to 24 characters or fewer. A longer ID is stored cut to its first 24 characters, and its settings are read from the section named by that shortened ID. A later reference that spells out the full ID does not find the stored type and creates another one.

Registering an ID creates the type with the built-in defaults for its kind, and its section is read afterwards. An ID with no section of its own is still registered and keeps those defaults.

[Sides] uses its keys. The key is the Side ID, and the value lists the countries on that side as HouseType IDs separated by commas. Each country must be registered by the same rules file or an earlier one. Write the list without spaces after the commas: a name that matches no registered country, including one with a leading space, is skipped, and that country does not join the side.

A later file that lists an existing side replaces that side’s country list, so repeat every country the side should keep. A country left out of the new list keeps the side it had.

[Tiberiums] registers at most four types, as Tiberium types explains.

Theaters

Section titled “Theaters”

[Theaters] is read once, as the game starts, and only from RULES.INI and from FIRESTRM.INI. FIRESTRM.INI counts whenever it is installed, even when Firestorm is not enabled; Game data covers what makes it count as installed. A map, the language rules files and the multiplayer rules files cannot add a theater. Saves record each theater by its position in the list, so the list has to stay the same from one game to the next.

When neither file registers a theater, the game uses the two theaters Tiberian Sun shipped, TEMPERATE and SNOW, in that order. Unmodified rules files get this list. A [Theaters] list that registers at least one theater replaces those two completely: it may drop SNOW, reorder the pair, or replace both, so a list that means to keep them has to name them.

A listed TEMPERATE or SNOW starts from that theater’s original settings, and its section in the rules overrides them. Naming a theater again, later in the list or in FIRESTRM.INI, reuses the one already registered.

Types named by other keys

Section titled “Types named by other keys”

Projectiles have no registration section. A projectile is created the first time a key names it, usually a weapon’s Projectile=. A projectile a weapon names reads its settings from the section matching its name, as for a registered type.

A weapon that [Weapons] does not list is created the same way, the first time one of these keys names it: Primary=, Secondary=, Elite=, WeaponType=, DropPodWeapon= or AirburstWeapon=.

Register in [Weapons] any weapon that only a projectile’s AirburstWeapon= names. Each rules file reads its weapon sections in one pass, and AirburstWeapon= is read after that pass. A weapon it creates therefore misses its section in that file, and keeps the built-in defaults unless a later rules file contains its section.

Source files

Linked at revision 51b52aa38392.

History

  1. Changed0.2.0In development

    Detect Firestorm from its rules file alone

  2. Changed0.2.0In development

    Read multiplayer rules from MPLAYER.INI

  3. Changed0.2.0In development

    Declare sides in the side list alone

  4. Changed0.2.0In development

    Declare extra theaters in the rules

  5. Changed0.2.0In development

    Register Tiberium types by name

  6. Changed0.2.0In development

    Declare weapons in the rules