Data categories

From Star Ruler 2 Wiki
Jump to: navigation, search

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.


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 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.


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 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
       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.


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


  • Name
  • Description
  • Icon
  • Energy Cost
  • Cooldown: Cooldown between uses, in seconds
  • Range
  • Hotkey
  • Target: Type of target this ability can trigger on


Ability: GeneratePlanet
	Icon: PlanetType::2

	Energy Cost: 1400
	ReduceEnergyCostSystemFlag(0.75, CheapArtifacts)

	Target: dest = Point
	Cooldown: 1
	Range: 100
	Hotkey: A



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


  • Name
  • Description
  • Narrative
  • Frequency: How often this anomaly appears relevant to other anomalies
  • Scan Time
  • Unique: Only spawns once in the game


Anomaly: MiningOutpost
	Frequency: 2
	Scan Time: 65
	Unique: True
	Narrative: Narrative of mining outpost


		Model: Asteroid
		Material: Asteroid

		Choice: Mine
		Choice: Convert


		Model: Asteroid
		Material: Asteroid

		Choice: Mine
		Choice: Convert
		Choice: Explode

	Option: Mine
		Icon: ResourceIcons::7

		PricedAsteroid(10, Iron, AsteroidLabor, Water)

	Option: Convert
		Icon: ResourceIcons::12
		Chance: 50%

		PricedAsteroid(20, RareMetals, NativeGold)

	Option: Explode
		Icon: CardCategoryIcons::2

		Result: 50%
			PricedAsteroid(10, AsteroidAffinity)
		Result: 50%
			PricedAsteroid(20, Neutronium)


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


  • 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


Artifact: IonCannon
	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


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


  • 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


Biome: Volcanic
 	Description: Volcanic underground
	Temperature: 1
	Humidity: 0
	UseWeight: 0.01
	BuildCost: 4
	BuildTime: 3
	Frequency: 10
	Color: C70015
	Sprite: BiomeTiles::5


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


  • 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


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)