Data categories
General knowledge
Localization Strings
Starting with the hash symbol (#), these special strings tell the game engine to go look up a value in a text file and use that instead of the localization string. This is good because WHICH text file it uses depends on the game's language setting.
For example, if you set the name of your new weapon to "Plasma Cannonade" then it will always show up as "Plasma Cannonade" whether the game is in English, Russian, Japanese or Nylli. If you set the name to "#PLASMA_CANNONADE", the game will look up the correct language's entry for #PLASMA_CANNONADE, which you would set to be "Plasma Cannonade" in English. Then people who translate your mod can easily translate all of the names and descriptions. The in-game mod editor automatically handles these localization strings for you (which is amazingly awesome - you won't know how awesome unless you've had to work on a software project that doesn't autodefine them like this!) so you can just type a new one into a name or description field, press Change, and it will bring up an editor letting you set the string. This also means description fields can have long descriptions with lots of formatting, all nicely edited, and it will show up on tooltips in the editor.
Color Filters
When specifying an icon or graphic for pretty much anything, you need to give a material name which will look up the graphic from the game's list of materials. These can be modded separately, but there is also the facility to dynamically recolor any of these on the fly. To do this put "* #[hexcode]" after the graphic name, where [hexcode] denotes you should put a standard web hexadecimal color code. For example, the ComputerCore icon has various colors, but if I set an icon to "ComputerCore * #ff0000" it will be filtered to only red.
Because this is a multiplicative filter rather than a true colourize, some things will look better than others, and icons with lots of white in them tend to look best. If an icon is already strongly one color, attempting to filter it to another color can produce odd or bad looking results, but most of the time this lets you reuse graphics very quickly and easily without them looking identical.
Subsystems
Ship design components, including hulls and the basic ship types themselves. Subsystems make up everything to do with ships except the 3d model, and are put together in-game in the ship designer to produce a ship blueprint.
Tags
Tags can be applied to subsystems and can then be referenced by templates, the AI, or other parts of the engine. Some tags have special behavior this way, but in the end all tags are just an arbitrary text value other things might or might not look at.
Modifiers
A modifier updates the value of a variable in a subsystem based on a formula and input. These do not automatically apply, but if they are called it is always after initialization of the subsystem. Think of adding a modifier as saying "Other things can modify this subsystem later, here is a specific way it can be changed."
A good example of how this works are RangeFactor(fac) modifiers, where fac is defined by whatever calls the modifier. Technology items in the tech tree that increase weapon range then call the RangeFactor modifier on all applicable subsystems, with an argument for fac that changes depending on how big a boost the tech wants to apply.
Templates
Templates are a way to change other subsystems dynamically, based on tags or other conditions. You can add default variables and modifiers that will be added to any subsystem with a tag, but these values get added AFTER the subsystem is compiled - defaults will fill in for anything the subsystem doesn't already have. This means that you -won't- be able to do something like this in a subsystem definition, because when the subsystem is checked 'Range' is undefined:
Template: tag/MyBaseType
Defaults:
Range := 100.0
Subsystem: MySubSystem Tags: MyBaseType FullRange := Range * 2.0 // Does not work. (Also I don't know if you can have comments in subsystem files.)
FullRange will not work as Range is not defined when the subsystem is compiled, but then after the template pass which happens later, Range will be defined as 100 since MySubSystem doesn't already have a Range.
Templates can also add Modifiers (see above) but will not necessarily activate a given modifier - it just creates it so that other things can activate it with a given value. For example, you can add a RangeFactor(fac) modifier through a template that applies to all railguns (via tag/IsRailgun, perhaps) and then later something else (a boost tech for example) can safely call RangeFactor(2.0) to double the range of every railgun, despite RangeFactor not being defined in each individual railgun subsystem definition.
Abilities
Special actions a player can perform in the game. These can be customized to do anything by means of script hooks that perform logical actions.
Parent folder
<game root>/data/abilities
Fields
- Name
- Description
- Icon
- Energy Cost
- Cooldown: Cooldown between uses, in seconds
- Range
- Hotkey
- Target: Type of target this ability can trigger on
Example
Ability: GeneratePlanet Name: #ABL_GENERATE_PLANET Description: #ABL_GENERATE_PLANET_DESC Icon: PlanetType::2 Energy Cost: 1400 ReduceEnergyCostSystemFlag(0.75, CheapArtifacts) Target: dest = Point Cooldown: 1 Range: 100 Hotkey: A TargetFilterInSystem(dest) SpawnPlanetAt(dest)
Anomalies
Random objects a player can find while exploring. They consist out of two major parts. Each exists in a certain state. This state then offers several choices when a player interacts with them. These choices are declared as options who have either script hooks or results. Results are defined by script hooks themselves. It's not quite clear why you would add hooks to an option directly instead of always working with a result.
Parent folder
<game root>/data/anomalies
Fields
- Name
- Description
- Narrative
- Frequency: How often this anomaly appears relevant to other anomalies
- Scan Time
- Unique: Only spawns once in the game
Example
Anomaly: MiningOutpost Name: #ANOMALY_DEBRIS_FIELD Description: #ANOMALY_NAR_DEBRIS Frequency: 2 Scan Time: 65 Unique: True Narrative: Narrative of mining outpost State: Narrative: #ANOMALY_NAR_MINING_OUTPOST Model: Asteroid Material: Asteroid Choice: Mine Choice: Convert State: Narrative: #ANOMALY_NAR_MINING_OUTPOST_VOLAT Model: Asteroid Material: Asteroid Choice: Mine Choice: Convert Choice: Explode Option: Mine Icon: ResourceIcons::7 Description: #ANOMALY_MINING_OUTPOST_MINE PricedAsteroid(10, Iron, AsteroidLabor, Water) Option: Convert Icon: ResourceIcons::12 Description: #ANOMALY_MINING_OUTPOST_CONVERT Chance: 50% PricedAsteroid(20, RareMetals, NativeGold) Option: Explode Icon: CardCategoryIcons::2 Description: #ANOMALY_MINING_OUTPOST_EXPLODE Result: 50% PricedAsteroid(10, AsteroidAffinity) Result: 50% PricedAsteroid(20, Neutronium)
Artifacts
Items left behind by old civilizations. Each artifact has an ability attached to it so it can be interacted with in the game world.
Parent folder
<game root>/data/artifacts
Fields
- Name
- Description
- Icon
- Strategic Icon
- Icon Size
- Model
- Material
- Physical Size
- Mass: Affects tractor beams
- Frequency: How often this artifact appears relevant to the others
- Time Frequency: How frequent this artifact can spawn every twenty minutes of gametime
- Single Use
- Orbit: Does the artifact orbits or stays in a static location
- Unique
- Natural: When true the artifact will only spawn at game start and will not be brought by a seed ship
- Collapses: Determines if multiple instances of the artifact are the same and will collapse in the left group selection screens
- Can Donate: Can you donate this to another player
- Can Own: Can a player get exclusive access to this artifact
- Require Contestation: If non zero this artifact can only spawn in systems with a certain contestation value. Contestation is an abstract value based on how many empires are close enough to potentially contest the system
- Spread Variable: Unclear about the exact meaning but seems if this is filled in you will only get one instance of this variable
Example
Artifact: IonCannon Name: #ART_ION_CANNON Description: #ART_ION_CANNON_DESC Model: Artifact Material: VolkurGenericPBR Frequency: 0.5 Icon Size: 0.03 Physical Size: 5.1 Mass: 301 Time Frequency: 1 Single Use: False Single Use: False Orbit: True Unique: True Natural: True Collapses: False Can Donate: False Can Own: False Require Contestation: 1 Spread Variable: 1 Icon: emp_bg_reddish Strategic Icon: emp_flag_flag9 Ability: EquipIonCannon
Biomes
Each planet consist of several squares of a certain biome. These determine how much it will cost and how long it will take to put a building on these squares. There is also a temperature and humidity field which is unclear what purpose they serve in the game simulation.
Parent folder
<game root>/data/biomes
Fields
- Name
- Description
- Temperature: relative temperature range 0 - 1
- Humidity: relative humidity range 0 - 1
- UseWeight: Relative weight for civilians to develop this biome in comparison with others
- BuildCost: multiplier to the build cost for empire buildings on this biome
- BuildTime: multiplier to the build time for civilian buildings on this biome
- Frequency: Relative frequency of this biome
- Color
- Sprite
Example
Biome: Volcanic Name: #BIOME_VOLCANIC Description: Volcanic underground Temperature: 1 Humidity: 0 UseWeight: 0.01 BuildCost: 4 BuildTime: 3 Frequency: 10 Color: C70015 Sprite: BiomeTiles::5
Buildings
Any building that can be build on a planet imperial or civilian. On top of their default fields there are a number of extra fixed properties that can be added to them:
- Saturation
- Production
- Pressure cap
- Build affinity
- Maintenance affinity
- Hooks
Parent folder
<game root>/data/buildings
Fields
- Name
- Description
- Sprite
- City: Whether this is a city. If it is, civilians will build one per population which takes up space on the planet. Unknown if larger cities than 1x1 work, but conceptually they should do.
- Category: Category under which this building is listed in the build list
- Size: Size of the building in dimensions fe: 1x1
- Base Cost: Base cost to build this if it's an imperial building
- Tile Cost: Extra cost added for every undeveloped tile it is placed on
- Base Maintenance: Base maintenance cost
- Tile Maintenance: Extra maintenance cost for every tile that is not developed
- Labor Cost: How much labor it takes to construct this building (do not also specify a build time)
- Build Time: How much time it takes to build a building (do not also specify a labor cost)
- Civilian: Is this building civilian or imperial
- Upgrades From: Previous building this building has to evolve from
- Saturation: How much pressure it takes for this building to be build
- Production: Amount of resource this civilian building generates
- Pressure Cap: Amount of pressure this building consumes from the pressure pool
- Build Affinity: Undeveloped tiles of this selected biome do not take up extra cost
- Maintenance Affinity: Undeveloped tiles of this selected biome do not take up extra maintenance cost
Example
Building: SpecialCity Name: #BLD_CITY Description: #BLD_CITY_DESC Sprite: BuildingSprites::0 City: True Saturation: 1 Money Production: 1 Money Pressure Cap: 2 Build Affinity: Forest Maintenance Affinity: Forest Category: Test Size: 1x2 Base Cost: 100 Tile Cost: 1 Base Maintenance: 1 Tile Maintenance: 1 Labor Cost: 1 Build Time: 10 Civilian: True Upgrades From: City AddResource(Energy, 1)
