Font Definition

HomeModdingReferenceSBCFont Def

Defines a text font style. Requires a font resource (.xml) file which points to textures, declares each character on those textures and optional kerning pairs.

Elements

↑ 🔗

<ColorMask>

Type: Nullable<Color>

Default: {R:255 G:255 B:255 A:255}

Optional color multiplier for the texture.

Values can be from 0 to 255.

Usage:

<ColorMask>
  <R>255</R>
  <G>255</G>
  <B>255</B>
</ColorMask>

While it is nullable, if nulled it would still be white.

<ColorMaskAlpha>

Type: Nullable<Color>

Default: {R:255 G:255 B:255 A:255}

Same as <ColorMask> but can specify alpha too. These both affect the same data, do not include both.

<ColorMaskAlpha>
  <R>255</R>
  <G>255</G>
  <B>255</B>
  <A>255</A>
</ColorMaskAlpha>

<Default>

Type: Boolean

Default: False

If enabled, this font will be the fallback font for when anything asks for a font that does not exist.
Not recommended to enable for new fonts.

<Path>

Type: String

Default: null

Path to a single font resource (.xml file), relative to game or mod folder.
If defined, the <Resources> and <LanguageSpecificDefinitions> will be ignored.

<Resources>

Type: List<MyObjectBuilder_FontData>

Default: null

List of font resources to use for all languages.

It is unclear why it is a list because it always picks first (after being sorted by the Size attribute).

Path Path (attribute^[1])	Type: string	Default: `null`
Path to a font resource (.xml) file, relative to game folder only. Warning: only paths in game folder function, for path inside a mod use the `<Path>` element instead.
SwappedPath SwappedPath (attribute^[1])	Type: string	Default: `null`
Same as `Path` but used if the client OS has "Enter and Back buttons swapped", likely only for PlayStation. Windows never has them swapped. (Added in SE v1.202)
Size Size (attribute^[1])	Type: UInt32	Default: `0`
The resource list is sorted by this, ascending.

Usage:

<Resources>
  <Resource Path="Fonts\SomeFont\SomeFile.xml" SwappedPath="Fonts\SomeFont\SomeFileSwapped.xml" Size="0" />
  <!-- ... -->
</Resources>

<LanguageSpecificDefinitions>

Type: List<LanguageResources>

Default: null

Optional list of resource overrides for specific languages.

Language Language (attribute^[1])	Type: string	Default: `null`
Available values: English, Czech, Slovak, German, Russian, Spanish_Spain, French, Italian, Danish, Dutch, Icelandic, Polish, Finnish, Hungarian, Portuguese_Brazil, Estonian, Norwegian, Spanish_HispanicAmerica, Swedish, Catalan, Croatian, Romanian, Ukrainian, Turkish, Latvian, ChineseChina, Japanese.
Resources <Resources>	Type: List<MyObjectBuilder_FontData>	Default: `null`
Same format and sorting as `<Resources>`.

Usage:

<LanguageSpecificDefinitions>
  <LanguageDefinition Language="Italian">
    <Resources>
      <Resource Path="Fonts\SomeFont\Its-a_file.xml" SwappedPath="Fonts\SomeFont\Its-a_file_Swappisimo.xml" Size="0" />
      <!-- ... -->
    </Resources>
  </LanguageDefinition>
  <!-- ... -->
</LanguageSpecificDefinitions>

(Top) | From DefinitionBase:

Common

↑ 🔗

<Id>

Type: SerializableDefinitionId

Default: (invalid)

The type and subtype combined make up a unique identifier for this definition.

If two definitions use the same Type+Subtype (Subtypes are only unique per Type), then the last to load will override the first one(s). For more details see Things to know about SBC.

TypeId <TypeId>	Type: string	Default: `(invalid)`
Must be an existing type with or without the "MyObjectBuilder_" prefix. Some types require an xsi:type, refer to the vanilla files for the exact pairing. TypeId vs xsi:type
SubtypeId <SubtypeId>	Type: string	Default: `(empty)`
This can be invented and only needs to be unique per TypeId. Vanilla game re-uses some subtypes over multiple types (e.g. Iron is used for Ore type and Ingot type). An empty value is also a valid subtype (which vanilla also uses on at least 5 blocks).
Type Type (attribute^[1])	Type: string	Default: `(invalid)`
Same behavior as <TypeId>, do not define both.
Subtype Subtype (attribute^[1])	Type: string	Default: `(empty)`
Same behavior as <SubtypeId>, do not define both.

Example:

<Id>
  <TypeId>CubeBlock</TypeId>
  <SubtypeId>FancyTable</SubtypeId>
</Id>

Because it has attribute alternatives it can also be declared as:

<Id Type="CubeBlock" Subtype="FancyTable" />

<DisplayName>

Type: String

Default: null

If the object defined here is visible anywhere in the game GUI, this would be the name shown for it. In cases where it is used, it is very much required.

Can be plain-text.
If the text contains DisplayName_ then:

A localization key (from .resx files) will be searched for.
It will scan for text variables to replace.

<Description>

Type: String

Default: null

Optional. If the object defined here is shown with a description in the game GUI (Hotbar/G-menu, HUD, etc) then this is the place to write it.

Can be plain-text.
If the text contains Description_ then:

A localization key (from .resx files) will be searched for.
It will scan for text variables to replace.

If the final text (plain, localized or variable-replaced) contains {0}, {1}, etc, then they will replaced by kb&m control binds defined in <DescriptionArgs>.

<DescriptionArgs>

Type: String

Default: null

Optional. A comma-separated list of control IDs which are referenced in <Description> by {number} tags, which then get replaced by the keyboard or mouse bind that the viewer has for those controls.
Example:

<Description>Press {0} to fire, {1} to change color, {2} to interact.</description>
<DescriptionArgs>PRIMARY_TOOL_ACTION,CUBE_COLOR_CHANGE,USE</DescriptionArgs>

And each player will see their current binds for those actions.

The control IDs can be found in your %appdata%/SpaceEngineers/SpaceEngineers.cfg at the ControlsButtons section.

<Icon>

Type: String[]

Default: null

Icon(s) for the definition which may or may not be used depending on the definition type.

Path to a .dds or .png file relative to current mod's folder. Falls back to game folder if not found in current mod. Referencing assets in other mods

Can be declared multiple times which will stack icons on top of eachother, however it will not work for all definitions.

Known definitions to work or not work with multiple icons

Working: Blocks, BlockVariantGroups and component items seen in G-menu, BlockInfo (HUD right side) and toolbars; Blueprints in terminal production tab; Blocks and PhysicalItems in gamepad HUD.
Partial: Blocks seen in terminal.
Not working: HandItems (uses PhysicalItem's icon instead); Blocks and BlockVariantGroups seen in build planner, radial menu and some economy GUIs; PhysicalItems in economy GUIs and stores; Prefabs in stores; BlueprintClass (tabs) in terminal production tab; BankingSystemDefinition (Game\BankingSystem.sbc); Emotes (both kinds of definitions) in gamepad HUD; Block skins; RespawnShips.
Special cases: Economy contracts, FactionIcons Definition.

<DLC>

Type: String[]

Default: null

Optional. The DLC subtypeId that this definition will require.

For the IDs, refer to <SE>\Content\Data\Game\DLCs.sbc.
Can be declared multiple times to require multiple DLCs.

Most definition types won't check for this, the ones that do: blocks, emotes and possibly anything else that can be placed in the toolbar.

<AvailableInSurvival>

Type: Boolean

Default: true

Depends on the definition if it uses this, and if it does then this determines whether it can be accessible in survival game mode.

Currently known definitions that do use this:

Blocks, BlockVariantGroups, BlockCategories and any definition that can show up in a toolbar.
EntityStatComponent Definition and EntityStat Definition.

<Public>

Type: Boolean

Default: true

If the definition is visible or accessible in some cases.
For blocks, this only hides them and they can still be built using projectors and other means.

Enabled (attribute^[1])

Type: Boolean

Default: true

If set to false it will remove the definition after it's been loaded.
Example usage:

<Definition Enabled="false">

The "Definition" above is the opening element that for the entire definition, not an inner node like <DisplayName> is.

The opening node can have a different name for other definitions, some examples <Component>, <Blueprint>, etc.

xsi:type (attribute^[1])

Type: string

Default: null

Name of an object that this definition will be deserialized as.
Sometimes required, depends on the definition. The wiki page for any given definition will mention at the top what xsi:type it requires, if any. The game's sbc files are also a reference on what xsi:types are required for a given definition.

This attribute is available on all elements and comes from the XML specification. This game relies on this attribute to change which sub-definition object is used to deserialize that element's contents. It's what allows, for example, a thruster to have unique elements (such as <MinPlanetaryInfluence>) that no other block definitions have.

For more details on how this relates to the TypeId, and usage examples, see: Things to know about SBC - TypeId vs xsi:type.

↑ ^1.0 ^1.1 ^1.2 ^1.3 ^1.4 ^1.5 ^1.6 ^1.7 What are XML attributes?

[xmlattribute-1] 1.0 ^1.1 ^1.2 ^1.3 ^1.4 ^1.5 ^1.6 ^1.7 What are XML attributes?

[1]

Navigation menu

Namespaces

Views

Navigation

Game

Learn

Modding

Portals

Tools

Font Definition

Contents

Elements

ColorMask

ColorMaskAlpha

Default

Path

Resources

Path

SwappedPath

Size

LanguageSpecificDefinitions

Language

Resources

Common

Id

TypeId

SubtypeId

Type

Subtype

DisplayName

Description

DescriptionArgs

Icon

DLC

AvailableInSurvival

Public

Enabled

xsi:type

Navigation menu

Namespaces

Views

Search

Navigation

Game

Learn

Modding

Portals

Tools

Font Definition

Elements

ColorMask

ColorMaskAlpha

Default

Path

Resources

Path

SwappedPath

Size

LanguageSpecificDefinitions

Language

Resources

Common

Id

TypeId

SubtypeId

Type

Subtype

DisplayName

Description

DescriptionArgs

Icon

DLC

AvailableInSurvival

Public

Enabled

xsi:type