Flare Definition

From Space Engineers Wiki
Jump to navigation Jump to search

Requires an xsi:type attribute:

<Definition xsi:type="FlareDefinition">

All flare intensities are multiplied by the player's Flares intensity in graphics options, recommended to tweak with that set to 1.0.

Wrapper & Entry Example

<?xml version="1.0" encoding="utf-8"?>
<Definitions xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Flares>
    <!-- One or more flare entries are placed here. -->
  </Flares>
</Definitions>
A typical flare entry
    <Definition xsi:type="FlareDefinition">
      <Id>
        <TypeId>FlareDefinition</TypeId>
        <SubtypeId>InteriorLight</SubtypeId>
      </Id>
      <Intensity>3</Intensity>
      <SubGlares>
        <SubGlare>
          <Material>LightGlare</Material>
          <Type>Rotated</Type>
          <Color>
            <X>1</X>
            <Y>1</Y>
            <Z>1</Z>
            <W>1</W>
          </Color>
          <Size>
            <X>0.1</X>
            <Y>0.1</Y>
          </Size>
          <ScreenIntensityMultiplierCenter>1</ScreenIntensityMultiplierCenter>
          <ScreenIntensityMultiplierEdge>1</ScreenIntensityMultiplierEdge>
          <ScreenCenterDistance>
            <X>0</X>
            <Y>0</Y>
          </ScreenCenterDistance>
        </SubGlare>
      </SubGlares>
    </Definition>

Elements

Intensity

<Intensity>
Type: Nullable<Single>Default1.0
Optional overall intensity multiplier.

Size

<Size>
Type: Nullable<Vector2>Default1.0, 1.0
Optional overall size multiplier, can be ignored by individual glares with <FixedSize>.
Syntax:
<Size>
  <X>0.5</X>
  <Y>0.5</Y>
</Size>

SubGlares

<SubGlares>
Type: MySubGlare[]Defaultnull
List of glares, some can be off-set from the main one which would result in lens-flare effects.

The list is optional meaning it can be declared empty (but not left out entirely, that will probably crash), which is only useful for flares that are hardcodedly pointed to (like Sun), for anywhere else where you can input a flare it's recommended to use the game's NoFlare flare subtypeId instead.

Each <SubGlare> can contain:

Material

<Material>
Type: stringDefaultnull
Transparent material's <SubtypeId> to render as this glare.
Required to be a valid material or the game will crash.

Type

<Type>
Type: SubGlareTypeDefaultOriented
Available options:
  • Oriented - Texture aligned to camera.
  • Rotated - Maintains its rotation but can rotate on its own depending on world position relative to light source.
  • Anamorphic - Texture aligned to camera and its width is shrunk the more you look away.
    The formula: X * (1 - Abs(X)) and capped to a minimum of 0.0001.
  • AnamorphicInverted - Texture aligned to camera and its width starts very thin and widens the more you look away.
    The formula: X * Abs(X) and capped to a minimum of 0.0001.

Color

<Color>
Type: Vector4Default0, 0, 0, 0
Color and alpha multiplier to the attached light's color, in sRGB.

Usually numbers between 0.0 and 1.0 but it can go past 1 to have glow/bloom.

Example:
<Color>
  <X>1.0</X>
  <Y>1.0</Y>
  <Z>1.5</Z>
  <W>0.05</W>
</Color>
The X/Y/Z/W represent R/G/B/A.

FixedSize

<FixedSize>
Type: BooleanDefaultfalse
If true this subglare ignores the overall <Size> multiplier (not the subglare's one from below).
<Size>Type: Vector2Default0, 0
Size multiplier for this subglare.
Syntax:
<Size>
  <X>0.4</X>
  <Y>0.4</Y>
</Size>

ScreenCenterDistance

<ScreenCenterDistance>
Type: Vector2Default0,0
Offset this flare as you look away from the source, for making lens-flares. Leave undefined or set to 0 and 0 to not use.

If used, it also makes this flare vanish when looking directly at the glare source.
Values at exactly 1.0 would make the glare stick to the center of the screen (not recommended), use either lower or higher.
Positive values interpolate towards camera's view, while negative interpolate away - when looking away from the light source.

Example:
<ScreenCenterDistance>
  <X>0.3</X>
  <Y>0.3</Y>
</ScreenCenterDistance>

ScreenIntensityMultiplierCenter

<ScreenIntensityMultiplierCenter>
Type: SingleDefault0
Intensity multiplier when the flare is near the center of the screen.
See <ScreenIntensityMultiplierEdge> for more details.

ScreenIntensityMultiplierEdge

<ScreenIntensityMultiplierEdge>
Type: SingleDefault0
Intensity multiplier when the flare is near the edge of the screen.

The <ScreenIntensityMultiplierCenter> is linearly interpolated towards this as the flare source moves away from the screen center, that means one of these can have negative values to weigh the interpolation. KSH themselves use this trick as well.

For example a -5 set to this will make it fade out pretty much as soon as you move your crosshair away from it.

OcclusionToIntensityCurve

<OcclusionToIntensityCurve>
Type: KeyPoint[]Defaultnull
Optional list of points on a graph that configure how the occlusion factor of the flare affects its intensity.

Values are interpolated therefore it can function with at least 2 keys.
This can also be used to make the glare see-through-walls by setting non-0 intensity at higher occlusion.

Each <KeyPoint> can have:

Occlusion

<Occlusion>
Type: SingleDefault0.0
Occlussion factor, 0.0 to 1.0.

Intensity

<Intensity>
Type: SingleDefault0.0
Sub-flare intensity at this occlusion ratio.
Example:
<OcclusionToIntensityCurve>
  <KeyPoint>
    <Occlusion>0</Occlusion>
	<Intensity>1</Intensity>
  </KeyPoint>
  <KeyPoint>
    <Occlusion>0.35</Occlusion>
    <Intensity>0</Intensity>
  </KeyPoint>
  <!-- ... -->
</OcclusionToIntensityCurve>
Subglare example:
<SubGlare>
  <Material>GlareLsInteriorLight</Material>
  <Type>Oriented</Type>
  <Color>
    <X>1.0</X>
    <Y>1.0</Y>
    <Z>1.0</Z>
    <W>1.0</W>
  </Color>
  <FixedSize>false</FixedSize>
  <Size>
    <X>1.0</X>
    <Y>1.0</Y>
  </Size>
  <ScreenCenterDistance>
    <X>0.0</X>
    <Y>0.0</Y>
  </ScreenCenterDistance>
  <ScreenIntensityMultiplierCenter>1.0</ScreenIntensityMultiplierCenter>
  <ScreenIntensityMultiplierEdge>1.0</ScreenIntensityMultiplierEdge>
  <OcclusionToIntensityCurve>
    <KeyPoint>
      <Occlusion>0</Occlusion>
      <Intensity>1</Intensity>
    </KeyPoint>
	<KeyPoint>
      <Occlusion>0.5</Occlusion>
      <Intensity>0</Intensity>
    </KeyPoint>
  </OcclusionToIntensityCurve>
</SubGlare>

(Top) | From DefinitionBase:

Common

Id

<Id>
Type: SerializableDefinitionIdDefault(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>Type: stringDefault(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>Type: stringDefault(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 (attribute[1])Type: stringDefault(invalid)
Same behavior as <TypeId>, do not define both.
Subtype (attribute[1])Type: stringDefault(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

<DisplayName>
Type: StringDefaultnull
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:

Description

<Description>
Type: StringDefaultnull
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:

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

<DescriptionArgs>
Type: StringDefaultnull
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

<Icon>
Type: String[]Defaultnull
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

<DLC>
Type: String[]Defaultnull
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

<AvailableInSurvival>
Type: BooleanDefaulttrue
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:

Public

<Public>
Type: BooleanDefaulttrue
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

Enabled (attribute[1])
Type: BooleanDefaulttrue
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

xsi:type (attribute[1])
Type: stringDefaultnull

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.