Parachute Definition

From Space Engineers Wiki
Jump to navigation Jump to search
Overview
Inherits

Used by the Parachute type, refer to its page for more information.

Requires an xsi:type attribute:

<Definition xsi:type="MyObjectBuilder_ParachuteDefinition">

Elements

PowerConsumptionIdle

<PowerConsumptionIdle>
Type: SingleDefault0
Constant electricity usage in megawatts while turned on and regardless of what it's doing.

ResourceSinkGroup

<ResourceSinkGroup>
Type: StringDefaultnull
SubtypeId of a sink resource group.

MaterialSubtype

<MaterialSubtype>
Type: StringDefaultnull
The SubtypeId of a Component-type item required to deploy the parachute.

MaterialDeployCost

<MaterialDeployCost>
Type: Int32Default0
How many of the <ConstructionItemName> item to require in order to deploy the parachute.

MinimumAtmosphereLevel

<MinimumAtmosphereLevel>
Type: SingleDefault0.2
Minimum air density ratio (usually 0.0 to 1.0) required for the parachute to be able to deploy at all.

DragCoefficient

<DragCoefficient>
Type: SingleDefault0
Required. Effectively a drag force multiplier, therefore should not be the default 0.

RadiusMultiplier

<RadiusMultiplier>
Type: SingleDefault8
Scales the radius of the parachute subpart. Multiplied by grid cell size (0.5 or 2.5).

ReefAtmosphereLevel

<ReefAtmosphereLevel>
Type: SingleDefault0.6

ParachuteSubpartName

<ParachuteSubpartName>
Type: StringDefaultnull
Defines the deployed parachute model either as a subpart or as the filename.

First this looks for a subpart with this exact name (without the subpart_ prefix).

If that's not found it will then create a subpart entity and then told to use as model the ParachuteSubpartName's value with .mwm appended at the end, in the same folder as the block's current model. Reminder that construction models change the block's model, and in fact this does execute these during construction stage too, but since it's meant to be hidden it might not be a problem.

(Top) | From FunctionalBlock Definition:

ScreenAreas

<ScreenAreas>
Type: List<ScreenArea>Defaultnull
List of screens for this block, however it only works if the block TypeId supports it. See the CubeBlocks page for LCD support.

The order they're declared here will also affect the order they show up in the terminal (and also their index when retrieved by programmable blocks and mods).

For a more detailed guide on how to set up screens, see the Screens Tutorial.

Each <ScreenArea> element inside this can have:

Name (attribute[1])Type: stringDefaultnull
Required. The name of a material inside the model.

The material's ColorMetal texture will be replaced with the generated one.

The original texture can still be seen in the block preview.
DisplayName (attribute[1])Type: stringDefaultnull
Required. The visual name of the screen shown in the terminal.
Can be plain-text or a localization key (from .resx files).
ScreenWidth (attribute[1])Type: Int32Default1
Optional. See <ScreenHeight>.
ScreenHeight (attribute[1])Type: Int32Default1
Optional. <ScreenWidth> and this get divided to determine the aspect ratio.

If ScreenWidth is larger then it will be a landscape screen, otherwise it'll be a portrait screen. If they're equal then it results in a square screen.

To accurately define this, measure the width and height of your UV'd surface and input them directly here (rounded to nearest integer).
TextureResolution (attribute[1])Type: Int32Default512
Optional. A suggested resolution of the screen.

The actual resolution can be larger or smaller depending on the aspect ratio (e.g. 16:9 would be 256x144 but 6:2 would be 512x170.6667).

Formulas
  • Width equals height: this used for both dimensions (e.g. for 512 results in a 512x512 texture)
  • Width larger than height: ResolutionX=TextureResolution*2ScreenWidthScreenHeightlog2 and ResolutionY=TextureResolution
  • Height larger than width: ResolutionX=TextureResolution and ResolutionY=TextureResolution*2ScreenHeightScreenWidthlog2
Alternatively, the Build Info mod has a chat command /bi lcdres <width> <height> <resolution> (notation) where you can input your values to see the actual resolution. With that mod you can also equip the block to see its LCD screen resolutions.
Script (attribute[1])Type: stringDefaultnull
Optional. LCD App ID to show by default. Can still be changed by the player afterwards.

List of built-in LCD apps

Mods that add LCD apps (also known as TSS or Text Surface Scripts) can also be used here, you'll have to ask the author for the ID or look at the script for MyTextSurfaceScript, the first argument is the ID.
Example:
<ScreenAreas>
    <ScreenArea Name="MaterialNameHere" DisplayName="Screen name in terminal" ScreenWidth="1" ScreenHeight="1" TextureResolution="256" Script="" />
    <!-- more of the above if needed -->
</ScreenAreas>

(Top) | From CubeBlock Definition:

General

<Id>, <PhysicalMaterial>, <DisplayName>, <Description> and <Icon> from the inherited definitions are also relevant here.

BlockPairName

<BlockPairName>
Type: StringDefault(DisplayName's value)
Expects a made up identifier that can be used on exactly 1 smallgrid block and 1 largegrid block. Allows the player to swap between the sizes using the R key (or by pressing the same number where the block is in the toolbar).

Recommended to be the same as <SubtypeId> but without grid size notations. If you only have one size then this can be identical to the SubtypeId.

Warning: When creating a new block from a copy of a vanilla one, this is as important to change as <SubtypeId> to not cause problems.

If not declared at all, it will use <DisplayName>'s value.

This value is also used by server admins when configuring block limits.

BlockTopology

<BlockTopology>
Type: MyBlockTopologyDefaultCube
Can be one of:
  • TriangleMesh - regular block
  • Cube - deformable armor
Important: Ensure this node is declared otherwise you can get invisible model from the default.

Size

<Size>
Type: SerializableVector3IDefaultX:0, Y:0, Z:0
Required and must be 1 or larger on all axis.

Defines the size (in grid cells) this block occupies.

Example usage:
<Size x="1" y="1" z="1" />

Where X/Y/Z correspond to Right/Up/Back axis, and in this case the numbers must be integers.

Warning: Heavy performance impact the larger the resulting cell count! For example at 20x20x20 it freezes the game for a few seconds when the block is removed or deformable armor is placed on it.

CubeSize

<CubeSize>
Type: MyCubeSizeDefaultLarge
The grid size the block is for. Can be either Small or Large.
Blocks can still be used on the wrong grid size if the world has the Supergriding setting enabled (it's off by default), but requires editing blueprints manually in order to place them on the other grid size.

Build

BuildTimeSeconds

<BuildTimeSeconds>
Type: SingleDefault10
How many seconds to take to weld this block from 0% to 100% with the standard hand-welder at 1x world welder speed.

DisassembleRatio

<DisassembleRatio>
Type: SingleDefault1.0
A multiplier to grinding time, meaning higher values make the grinding take longer. Grind time is inherently half the weld time, therefore entering 2 here would make them identical.

Components

<Components>
Type: CubeBlockComponent[]Defaultnull
Required. Defines the items needed to fully build this block which also determines the final mass and health of the block (component's <Mass> and <MaxIntegrity>).

Items can only be of Component type, it cannot accept any other item type.

The first component is the one required to place the initial construction stage. This also means the first here is the bottom item in the HUD (the visual order is flipped).

If a "Computer" component (exact name) exists, the block will have ownership and the position defines the blue line in the HUD. Some block types require ownership to function or not crash the game.

Note: All components need a blueprint even if not used by anything, see ZoneChip's blueprint for example.

Options for each <Component> element:

Subtype (attribute[1])Type: stringDefaultnull
The <SubtypeId> for a Component item definition (Components.sbc).
Count (attribute[1])Type: Int16Default0
Up to 65535, how many components to require.
<DeconstructId>Type: SerializableDefinitionIdDefault(component itself)
Optional. Defines what is returned when grinding this component. If undefined, it will default to the component itself.

Can be any item.

Example:
<DeconstructId Type="Ore" Subtype="Scrap" />
Note: Mind that this is an element therefore you need to change the self-closing <Component ... /> into an open+close tag one: <Component ...> elements... </Component>.
Example:
<Components>
  <Component Subtype="SteelPlate" Count="5" />
  <Component Subtype="Construction" Count="30" />
  <Component Subtype="Computer" Count="3" />
  <Component Subtype="Display" Count="10">
    <DeconstructId Type="Ore" Subtype="Scrap" />
  </Component>
  <Component Subtype="SteelPlate" Count="10" />
</Components>

CriticalComponent

<CriticalComponent>
Type: CriticalPartDefaultnull
Required. The item from <Components> that defines the red line - which is when the block becomes functional, no longer in construction stage, etc.

For the build level to reach the red line, all other components above this one (in the <Components>) are also critical/required, and the ones below are optional but they still contribute to block health if welded to that point.

Subtype (attribute[1])Type: stringDefaultnull
The <SubtypeId> for a component that is present in the block's <Components>, game crashes otherwise.
Index (attribute[1])Type: Int32Default0
Index for the rare case you have multiple stacks of the said Subtype in <Component...> and you wish to not use the first one.
In the majority of cases this should be left as 0.
Example:
<CriticalComponent Subtype="Computer" Index="0" />

BuildProgressModels

<BuildProgressModels>
Type: List<BuildProgressModel>Defaultnull
Optional but recommended. Defines a list of models that are used when the block is under construction (below the red line on the HUD, refer to <CriticalComponent> to set that).

Each <Model> element inside this can contain:

BuildPercentUpperBound (attribute[1])Type: SingleDefault0
The built proportion (0.0 to 1.0) up to where this model is used.

To function properly, the <Model.../> entries must be declared in ascending order by this value.

The 1.0 value is normally the last entry, or the only entry if you have a single build stage model.
File (attribute[1])Type: stringDefaultnull
Path to a .mwm file to use as the visual and physical model during this construction stage.

Relative path to current mod's folder. Falls back to game folder if not found in current mod.

Warning: This model's collision is used too, and because of how weirdly designed the change is (it doesn't change in realtime, only on world load or paste), it should be identical to the one from the main model to avoid issues.
RandomOrientation (attribute[1])Type: boolDefaultfalse
Optional. If true, will make this construction model be rotated pseudo-randomly based on its position on the grid.
<MountPointOverrides>Type: MountPoint[]Defaultnull
Optional. Allows customizing mountpoints for this particular build stage.
Refer to MountPoints - Build Stage Mountpoints for details.
Example:
<BuildProgressModels>
  <Model BuildPercentUpperBound="0.5" File="Models\Cubes\SomeBlock_Build1.mwm" RandomOrientation="false" />
  <Model BuildPercentUpperBound="1.0" File="Models\Cubes\Someblock_Build2.mwm" RandomOrientation="false" />
  <!-- ... -->
</BuildProgressModels>

Placement

Enabled, <Public>, <DLC> and <AvailableInSurvival> from the base definition are also relevant here.

MountPoints

<MountPoints>
Type: MountPoint[]Defaultnull

Defines the surfaces where this block can attach to other blocks and vice-versa.
If <IsAirTight> is not set, then these mount points are also used to determine which cell faces are airtight.

More details on mountpoints and airtightness on the dedicated Mount Points page.

Mount points can only be on the block's boundingbox exterior surface, therefore you're effectively declaring one or more 2D rectangle(s) per side (Front, Back, Left, Right, Bottom, Top).

Example usage:
<MountPoints>
  <MountPoint Side="Right" StartX="0" StartY="0" EndX="0" EndY="0" Default="false" Enabled="true" PressurizedWhenOpen="true" PressurizedWhenClosed="true" PropertiesMask="0" ExclusionMask="0" CouplingTag="" AllowCouplingWithItself="false" />
  <MountPoint Side="Front" StartX="0.45" StartY="0.35" EndX="0.55" EndY="0.5" />
  <MountPoint Side="Front" StartX="0.45" StartY="0" EndX="0.55" EndY="0.20" />
  <MountPoint Side="Bottom" StartX="0.45" StartY="0" EndX="0.55" EndY="0.15" Default="true" />
  <!-- .... -->
</MountPoints>
The first element in the example shows all attributes and their defaults, the next 3 show a normal set of mountpoints.

GuiVisible

<GuiVisible>
Type: BooleanDefaulttrue
Decides if the block shows up in All Blocks.
Note: If the block is part of a BlockVariantGroup, then this element's value will be overwritten by the BVG.

PCU

<PCU>
Type: Int32Default1
The PCU for this block.

Highly recommended to start from the value of the original version and tweak it depending on computation added or removed from the block.
If unsure then leave it as it is in vanilla counterpart.

For example, making a sensor with a larger range should also increase PCU by a lot.

This is not a value you should be balancing based on gameplay, it is purely for its performance impact.
Server admins should use DS's block limits for gameplay balance instead.

Note: Gets overwritten to 2 if the world enables <UseConsolePCU> and this block's <CubeDefinition> is assigned with any Topology except StandaloneBox

Center

<Center>
Type: Nullable<SerializableVector3I>Defaultnull
Defines the cell where the block is pivoted from when placing.

If left undefined it will get calculated to a center-enough cell.

Example usage:
<Center x="0" y="0" z="0" />

Where +X/Y/Z correspond to Right/Up/Back directions, and in this case the numbers must be integers.
Range Warning: It should not be equal or larger than <Size>'s respective X/Y/Z values, or you end up with very strange bugs.

Cached Warning: For conveyor-supporting blocks, this value gets used to calculate relative ports and they remain cached until the game is closed entirely.

AutorotateMode

<AutorotateMode>
Type: MyAutorotateModeDefaultOneDirection
Not tested if it functions as it says, however here's the values and their game code documentation:
  • OneDirection - When block has mount points only on one side, it will autorotate so that side is touching the surface. Otherwise, full range of rotations is allowed.
  • OppositeDirections - When block has mount points only on two sides and those sides are opposite each other (eg. Top and Bottom), it will autorotate so that one of these sides is touching the surface. Otherwise, full range of rotations is allowed.
  • FirstDirection - When block has mountpoint on at least one side, it will autorotate so that this side is touching the surface. Otherwise, full range of rotations is allowed.

Rotation

<Rotation>
Type: MyBlockRotationDefaultBoth
Untested, game docs say "Allowed cube block rotations".
Available values: None, Horizontal, Vertical, Both.

Direction

<Direction>
Type: MyBlockDirectionDefaultBoth
Affects how the block is rotated, unclear exactly how.
Available values: Horizontal, Vertical, Both.

RandomRotation

<RandomRotation>
Type: BooleanDefaultfalse
Seems to only be used when dragging to build blocks in a line or plane.

UseModelIntersection

<UseModelIntersection>
Type: BooleanDefaultfalse
Affects multiple things:
  • Placing this block: false would collide with nearby objects using the boundingbox; true would use the visual model which allows tighter fit.
  • Placing on this block: false would use a mix of collider+model to determine if you're aiming at it; true uses only the visual model.

Downside of true is that you'll have a harder time aiming at some models (e.g. conveyor tube being hollow will require you to aim at the frame).

Also causes a fake model error in log/F11 debug menu which you can ignore: "There was error during loading of model, please check log file."

UseVanillaPlacementDetection

<UseVanillaPlacementDetection>
Type: BooleanDefaultfalse
Block placement code was changed at some point (to what is unclear).
This node chooses between the older version with true or newer version with false.

VoxelPlacement

<VoxelPlacement>
Type: Nullable<VoxelPlacementOverride>Defaultnull
Optional. Rules on how the block can be placed inside and outside voxels.

If null, it uses the defaults from CubeBuilder's <BuildingSettings>.

<StaticMode>Type: VoxelPlacementSettingsDefault(see deeper)
Used when placement is locked to a positional grid (not just a blocks grid).
<PlacementMode>Type: VoxelPlacementModeDefaultNone
Available values:
  • None - can't be placed regardless of voxels.
  • Both - fully permissive, allowed both inside and outside of voxels.
  • InVoxel - can only be placed if any boundingbox corner is inside voxels.
  • OutsideVoxel - can only be placed if none of its boundingbox corners are inside voxels.

Note: it can still be placed inside with its middle if the block is large enough, if you wish for any part to not touch voxels use Volumetric with both min and max as 0 instead.

<MinAllowed>Type: SingleDefault0
Only works if <PlacementMode> is set to Volumetric.
Volume ratio required inside voxels to allow placement.
Values from 0.0 to 1.0 but realistically up to 0.5-ish with how placement works.
<MaxAllowed>Type: SingleDefault0
Only works if <PlacementMode> is set to Volumetric.
Volume ratio limit inside voxels where if passed it won't allow placement.
Values from 0.0 to 1.0 but realistically up to 0.5-ish with how placement works.
<DynamicMode>Type: VoxelPlacementSettingsDefault(same as above)
Used for placement mid-air and aiming at a surface that doesn't lock your block ghost to a positional grid (like aiming at voxels).

This does mean this is used for static block placement too.
This has the same syntax as <StaticMode>.

Warning: It's highly recommended to use the same settings in both this and <StaticMode> to avoid any bugs or misunderstandings from the difference between these modes.
Example:
<VoxelPlacement>
  <StaticMode>
    <PlacementMode>Volumetric</PlacementMode>
    <MinAllowed>0</MinAllowed>
    <MaxAllowed>0.2</MaxAllowed>
  </StaticMode>
  <DynamicMode>
    <PlacementMode>Volumetric</PlacementMode>
    <MinAllowed>0</MinAllowed>
    <MaxAllowed>0.2</MaxAllowed>
  </DynamicMode>
</VoxelPlacement>
Explained in more depth: https://github.com/THDigi/SE-ModScript-Examples/wiki/Hidden-SBC-tags-features#block-voxelplacement-explained

MechanicalTopInitialPlacementOffset

<MechanicalTopInitialPlacementOffset>
Type: Nullable<SerializableVector3>Defaultnull
Used only by blocks (like wheels) that can be top-parts of other blocks (rotors, pistons, suspensions).

It was added for 2x2 wheels in particular.

Usage:
<MechanicalTopInitialPlacementOffset x="0.0" y="0.0" z="0.0" />
X/Y/Z are Right/Up/Back for positive values, and they're in meters.
(Added in SE v1.202)

MirroringBlock

<MirroringBlock>
Type: StringDefaultnull
SubtypeId of another block of the same type as this one, which will be placed on the other side of the mirroring plane(s).

MirroringCenter

<MirroringCenter>
Type: Nullable<SerializableVector3I>Defaultnull
Optional. Changes the pivoting cell position for the mirrored block ghosts.

If undefined it will use <Center>'s value (defined or calculated).
Warning: It should not be equal or larger than <Size>'s respective X/Y/Z values, or you end up with strange bugs.

Example usage:
<MirroringCenter x="0" y="0" z="0" />
Where +X/Y/Z correspond to Right/Up/Back directions, and in this case the numbers must be integers.
(Added in SE v1.201)

MirroringX

<MirroringX>
Type: MySymmetryAxisEnumDefaultNone
How mirroring behaves on this axis (only usable in creative mode with mirroring enabled).
Available values: None, X, Y, Z, XHalfY, YHalfY, ZHalfY, XHalfX, YHalfX, ZHalfX, XHalfZ, YHalfZ, ZHalfZ, MinusHalfX, MinusHalfY, MinusHalfZ, HalfX, HalfY, HalfZ, XMinusHalfZ, YMinusHalfZ, ZMinusHalfZ, XMinusHalfX, YMinusHalfX, ZMinusHalfX, ZThenOffsetX, YThenOffsetX, OffsetX, ZThenOffsetXOdd, YThenOffsetXOdd, OffsetXOddTest.

MirroringY

<MirroringY>
Type: MySymmetryAxisEnumDefaultNone
See <MirroringX>.

MirroringZ

<MirroringZ>
Type: MySymmetryAxisEnumDefaultNone
See <MirroringX>.

NewsletterSubscriptionNeeded

<NewsletterSubscriptionNeeded>
Type: BooleanDefaultfalse
This requires the player to've subscribed to the Keen newsletter to be able to use the block.
Only works for the Steam version, other platforms will ignore this and will be allowed use the block regardless.
(Added in SE v1.205)

Combat

See also: CubeBlock (section Damage behaviors)

GeneralDamageMultiplier

<GeneralDamageMultiplier>
Type: SingleDefault1.0
A multiplier to all damage dealt to this block, including explosive, impact and anything from mod scripts too.

DamageMultiplierExplosion

<DamageMultiplierExplosion>
Type: SingleDefault7.0
A multiplier to explosion damage this block receives.

Note: Does nothing for deformable armor blocks (the code requires this to have a fatblock/entity, which only has if <Model> is assigned).

Also see the explanation on <DeformationRatio> regarding explosions.
(Added in SE v1.200)

DeformationRatio

<DeformationRatio>
Type: SingleDefault1.0
This is one of those that has multiple purposes:
  • Damage from other thrusters: if it's <= 0.25 then the block doesn't get damaged by SmallGrid thrusters (LargeGrid ones damage everything).
  • For armor deformations: gets used as a multiplier of sorts, needs more research.
  • For explosions: affects if deformable armor gets instantly wiped, in detail:
    • First it multiplies DeformationRatio by all the general damage stuff (from <GeneralDamageMultiplier>, from block&grid instances, etc; but not <DamageMultiplierExplosion>).
    • Then block's current health is divided by the above value, and if the resulting number is smaller than the damage, the block is erased.
    • Only if the block survives all this, then the damage is multiplied by <DamageMultiplierExplosion> and applied to the block.
    • Note that direct hits and some other unclear cases also erase blocks, Explosions might have more info.

TargetingGroups

<TargetingGroups>
Type: String[]Defaultnull
Optional. List of SubtypeIds for TargetingGroup Definition to set (which overrides the defaults mentioned below).

If not defined or defined null, the block might still be part of a targeting group automatically if its TypeId is in any TargetingGroup definition's <DefaultBlockTypes> (TargetGroups.sbc).
Can be declared empty (<TargetingGroups></TargetingGroups>) to force no targeting groups regardless of the defaults.
Note: Blocks can only be targeted by turrets if they're part of at least one targeting group. However, blocks that do not, can still be accidentally shot if they're in the way of a target.

Usage:
<TargetingGroups>
  <string>PowerSystems</string>
  <!-- ... -->
</TargetingGroups>
It can have multiple <string>...</string> elements, making the block be a target for all of those.
(Added in SE v1.200)

PriorityModifier

<PriorityModifier>
Type: SingleDefault1
Priority for this block to get preferential targeting over other targetable blocks of the same group that the turret is targeting.

For example, decoy has 10 priority and is part of all 3 vanilla targeting groups.
If this is set to 0 then the block becomes not targetable regardless of <TargetingGroups>.

See <TargetingGroups> for more info.
(Added in SE v1.200)

NotWorkingPriorityMultiplier

<NotWorkingPriorityMultiplier>
Type: SingleDefault0.5
Multiplier to <PriorityModifier> when the block is not working (damaged below red line or unpowered or turned off).
(Added in SE v1.200)

AimingOffset

<AimingOffset>
Type: Nullable<Vector3>Defaultnull
Turrets normally aim at a block's center, this node exists for blocks that can't be hit at their center.
Usage:
<AimingOffset>
  <X>0.0</X>
  <Y>0.0</Y>
  <Z>0.0</Z>
</AimingOffset>

X/Y/Z represent Right/Up/Back for positive values, and are in meters.

Note: <ModelOffset> moves the block center therefore this AimingOffset will be in addition to that.
(Added in SE v1.200)

Visuals and Sound

The primary model is defined by the <Model> element from the inherited definition.

ModelOffset

<ModelOffset>
Type: SerializableVector3Default0,0,0
Offset the model and world block center, meaning it can affect other things than just the model.

Ore Detector's scanning sphere, for example, is centered at world block center, which this moves.

Usage:
<ModelOffset x="0.0" y="0.0" z="0.0" />
X/Y/Z are Right/Up/Back for positive values, and they're in meters.

PlaceDecals

<PlaceDecals>
Type: BooleanDefaulttrue
Whether this block allows dynamic decals (bullet holes, footprints, etc) to be placed on it from any source.

Recommended false for blocks that have subparts which don't have their own collisions, for example: turrets, drills, etc. The reason is that a decal would attach to the block, and when the subpart moves, the decal will stay in place which will look weirder than no decals at all.

EmissiveColorPreset

<EmissiveColorPreset>
Type: StringDefaultnull
A subtypeId of an EmissiveColorStatePreset Definition (EmissiveColors.sbc) which controls what colors are given to certain in-model materials based on various block states. For more details see CubeBlock (section Emissive Presets).

If undeclared it will not be used for most block types, however certain block types will have a different default! See your desired block type's modding page in the CubeBlocks list.

PrimarySound

<PrimarySound>
Type: StringDefaultnull
SubtypeId (without Arc or Real prefix) of an audio definition (Audio_*.sbc).

Plays when the block is idle but functional.
All block types that can turn on/off seem to be able to use this, however it was not tested on all of them.

Some block types will override this to:

  • GravityGenerator* - BlockGravityGen
  • SpaceBall - BlockArtMass

ActionSound

<ActionSound>
Type: StringDefaultnull
SubtypeId (without Arc or Real prefix) of an audio definition (Audio_*.sbc).

Plays when the block is actively doing something, however only a few block types use it.

Current known ones to use it: Assembler, Refinery, SolarPanel, OxygenFarm, SafeZone, ShipConnector, Collector, Sensor, VendingMachine.

SilenceableByShipSoundSystem

<SilenceableByShipSoundSystem>
Type: BooleanDefaultfalse
Will "silence" the block if the ship sound system considers the grid as "debris".
Not very clear what any of that means, likely only mutes the generic sounds from above. Test it out.

DepressurizationEffectOffset

<DepressurizationEffectOffset>
Type: Nullable<SerializableVector3>Defaultnull
Offsets the air wooshing particle effect from block center (affected by <ModelOffset>).

Only used when the block is still present which caused a leak by either being a door and opening or by being grinded below functional line (red line in right side HUD).

Note: This is currently buggy being relative to the grid it's on therefore it's not recommended. See the bug report for details.

Usage:
<DepressurizationEffectOffset x="0.0" y="0.0" z="0.0" />
X/Y/Z are Right/Up/Back for positive values, and they're in meters.

DamageEffectName

<DamageEffectName>
Type: StringDefault(empty)
SubtypeId of a ParticleEffect definition (Particles_*.sbc). Spawned when the block is damaged below function (red line).

DamageEffectOffset

<DamageEffectOffset>
Type: Nullable<Vector3>Defaultnull
Relative offset for the DamageEffectName particle.

Note: The starting point of the particle is in the center of the model's boundingbox (not the block's boundingbox) then this node is an offset off that.

Usage:
<DamageEffectOffset>
  <X>0.0</X>
  <Y>0.0</Y>
  <Z>0.0</Z>
</DamageEffectOffset>
X/Y/Z are Right/Up/Back for positive values, and they're in meters.
(Added in SE v1.200)

DamagedSound

<DamagedSound>
Type: StringDefaultnull
Audio definition subtypeId to be played when block is damaged below function (red line).

DestroyEffect

<DestroyEffect>
Type: StringDefault(empty)
SubtypeId of a ParticleEffect definition (Particles_*.sbc).

Spawns when the block is destroyed by damage.

If undefined or empty, it game uses ArmorDestroyed_Large for largegrid or ArmorDestroyed_Small for smallgrid.

DestroyEffectOffset

<DestroyEffectOffset>
Type: Nullable<Vector3>Defaultnull
Offset for the DestroyEffect particle relative to block's boundingbox center + ModelOffset.
Usage:
<DestroyEffectOffset>
  <X>0.0</X>
  <Y>0.0</Y>
  <Z>0.0</Z>
</DestroyEffectOffset>
X/Y/Z are Right/Up/Back for positive values, and they're in meters.

DestroyEffectScale

<DestroyEffectScale>
Type: SingleDefault1
DestroyEffect's particle effect is first scaled based on the boundingbox volume of the block.
This node is multiplied with that calculated scale, best to first see how it looks without it and then decide how much percentage you need larger or smaller.
(Added in SE v1.201)

DestroySound

<DestroySound>
Type: StringDefaultPoofExplosionCat1
SubtypeId (without Arc or Real prefix) of an audio definition (Audio_*.sbc). Played when block is destroyed.

AmmoExplosionEffect

<AmmoExplosionEffect>
Type: StringDefault(empty)
SubtypeId of a ParticleEffect definition (Particles_*.sbc). Spawns when the block is destroyed while its inventory contained explosive items.
(Added in SE v1.200)

AmmoExplosionSound

<AmmoExplosionSound>
Type: StringDefault(empty)
SubtypeId (without Arc or Real prefix) of an audio definition (Audio_*.sbc). Played when the block is destroyed while its inventory contained explosive items.
(Added in SE v1.200)

Effects

<Effects>
Type: CubeBlockEffectBase[]Defaultnull
Game code does not seem to use this (besides "Damage" as mentioned below).

ModAPI however can trigger these (IMyCubeBlock has 2 SetEffect() and RemoveEffect()).

Hosts a list of <Effect> elements, each can have:

Name (attribute[1])Type: stringDefaultnull
The identifier that the code would trigger.
Only option used by vanilla game is "Damage". Mod scripts can trigger whichever ones they wish.
ParameterMin (attribute[1])Type: SingleDefault-3.40282347E+38
Determines if the effect triggers depending on what is fed as parameter, which is up to the modder implementing the effect.
For the "Damage" effect, the parameter is the block integrity percent (0.0 to 1.0).
ParameterMax (attribute[1])Type: SingleDefault3.40282347E+38
See ParameterMin
<ParticleEffects>Type: CubeBlockEffect[]Defaultnull
List of <ParticleEffect> elements, each having:
Name (attribute[1])Type: stringDefault(empty)
SubtypeId of a ParticleEffect definition (Particles_*.sbc).
Origin (attribute[1])Type: stringDefault(empty)
Optional name of a dummy from the model to use as both position and orientation for the particle effect, otherwise uses block's center (affected by ModelOffset).
Duration (attribute[1])Type: SingleDefault0.0
How many seconds the whole effect lasts.
Loop (attribute[1])Type: boolDefaultfalse
Whether the effect triggers again after it ends (does not affect the particle definition's loop).
Delay (attribute[1])Type: SingleDefault0.0
How many seconds to wait until spawning the particle.
SpawnTimeMin (attribute[1])Type: SingleDefault0.0
Random range of seconds to be added to Delay on first spawn and then it acts as the sole delay (randomized again) on each loop.
SpawnTimeMax (attribute[1])Type: SingleDefault0.0
See SpawnTimeMin.
Example:
<Effects>
  <Effect Name="" ParameterMin="-3.40282347E+38" ParameterMax="3.40282347E+38">
    <ParticleEffects>
      <ParticleEffect Name="" Origin="" Duration="0.0" Loop="false" Delay="0.0" SpawnTimeMin="0.0" SpawnTimeMax="0.0" />
      <!-- ... -->
    </ParticleEffects>
  </Effect>
  <!-- ... -->
</Effects>

SimpleUpdateVisualOnSkinChange

<SimpleUpdateVisualOnSkinChange>
Type: BooleanDefaultfalse
Game's documentation: Set to true if you dont want to reset subpart positions or reload the whole model on skin change.
(Added in SE v1.205)

Deformable Armor

The <BlockTopology> and <DeformationRatio> are also relevant to deformable armor.

UsesDeformation

<UsesDeformation>
Type: BooleanDefaulttrue
Only used if <BlockTopology> is set to Cube.
If set to false, it disables the deformation feature but leaves the other features of deformable armor intact.

CubeDefinition

<CubeDefinition>
Type: PatternDefinitionDefaultnull
Only used if <BlockTopology> is set to Cube.

Characteristics of a deformable armor block. The Deformable Armor page has more details on the system.
Contains complex structure:

<CubeTopology>Type: MyCubeTopologyDefaultBox
Defines the physical shape and also which sides would be used.
Available values: Box, Slope, Corner, InvCorner, StandaloneBox, RoundedSlope, RoundSlope, RoundCorner, RoundInvCorner, RotatedSlope, RotatedCorner, Slope2Base, Slope2Tip, Corner2Base, Corner2Tip, InvCorner2Base, InvCorner2Tip, HalfBox, HalfSlopeBox, HalfSlopeInverted, HalfSlopeCorner, HalfSlopeCornerInverted, SlopedCornerTip, SlopedCornerBase, SlopedCorner, HalfSlopedCornerBase, HalfCorner, CornerSquare, CornerSquareInverted, HalfSlopedCorner, RaisedSlopedCorner, SlopeTransition, SlopeTransitionBase, SlopeTransitionBaseMirrored, SlopeTransitionMirrored, SlopeTransitionTip, SlopeTransitionTipMirrored, SquareSlopedCornerBase, SquareSlopedCornerTip, SquareSlopedCornerTipInv.
<ShowEdges>Type: BooleanDefaultfalse
Whether armor edges are shown for this.
Which edges are used however are defined by <EdgeType>.
<Sides>Type: Side[]Defaultfalse
List of panels in the order of the expected sides: Right, Top, Forward, Left, Bottom, Back.

Some topologies can have less than 6 sides and might have a different order too, refer to a vanilla armor sbc files for the exact configuration.
Each <Side> can have:

PatternWidth (attribute[1])Type: Int32Default0
Affects the armor texture covering multiple blocks, unclear exactly how it works, needs research.
PatternHeight (attribute[1])Type: Int32Default0
Affects the armor texture covering multiple blocks, unclear exactly how it works, needs research.
ScaleTileU (attribute[1])Type: Int32Default1
ScaleTileV (attribute[1])Type: Int32Default1
Example with all the options:
<CubeDefinition>
  <CubeTopology>Box</CubeTopology>
  <ShowEdges>false</ShowEdges>
  <Sides>
    <Side Model="Models\Cubes\Large\Armor\SquarePlate.mwm" PatternWidth="4" PatternHeight="2" ScaleTileU="1" ScaleTileV="1" />
    <Side Model="Models\Cubes\Large\Armor\SquarePlate.mwm" PatternWidth="4" PatternHeight="2" ScaleTileU="1" ScaleTileV="1" />
    <Side Model="Models\Cubes\Large\Armor\SquarePlate.mwm" PatternWidth="4" PatternHeight="2" ScaleTileU="1" ScaleTileV="1" />
    <Side Model="Models\Cubes\Large\Armor\SquarePlate.mwm" PatternWidth="4" PatternHeight="2" ScaleTileU="1" ScaleTileV="1" />
    <Side Model="Models\Cubes\Large\Armor\SquarePlate.mwm" PatternWidth="4" PatternHeight="2" ScaleTileU="1" ScaleTileV="1" />
    <Side Model="Models\Cubes\Large\Armor\SquarePlate.mwm" PatternWidth="4" PatternHeight="2" ScaleTileU="1" ScaleTileV="1" />
  </Sides>
</CubeDefinition>

EdgeType

<EdgeType>
Type: StringDefaultnull
Only used if <BlockTopology> is set to Cube and <ShowEdges> is set to true.
Enter the SubtypeId of an Edges Definition (Edges.sbc) which defines the set of models to use for armor edges.

Skeleton

<Skeleton>
Type: List<BoneInfo>Defaultnull
List of bone positions and offsets, unclear how it exactly works, the Deformable Armor page might have more info.

Each <BoneInfo> can have:

<BonePosition>Type: SerializableVector3IDefault0,0,0
Usage:
<BonePosition x="0" y="0" z="0" />
Where +X/Y/Z are Right/Up/Back directions, and in this case the numbers must be integers.
<BoneOffset>Type: SerializableVector3UByteDefault0,0,0
Usage:
<BoneOffset x="0" y="0" z="0" />
Where +X/Y/Z are Right/Up/Back directions, and in this case the numbers must be integers between 0 and 255.
Example usage:
<Skeleton>
  <BoneInfo>
    <BonePosition x="0" y="0" z="0" />
    <BoneOffset x="127" y="127" z="127" />
  </BoneInfo>
  <!-- ... -->
</Skeleton>

Misc

IsAirTight

<IsAirTight>
Type: Nullable<Boolean>Defaultnull
If undeclared (or set to null via <IsAirTight xsi:nil="true" />), it uses <MountPoints> for airtightness, where a mount point has to cover an entire cell face to make it airtight.

Otherwise, if set to true or false, it will force all the exterior faces of the block to be either airtight (true) or not airtight (false).

True or false have a tiny performance benefit when airtightness is computed compared to the mountpoint way.

PhysicsOption

<PhysicsOption>
Type: MyPhysicsOptionDefaultBox
Available values:
  • None - disables collisions on the block but still adds its mass to the grid (unlike <HasPhysics>). If used, recommended to also set <IsStandAlone> to false.
  • Box - only for deformable armor (<BlockTopology> set to Cube) and unclear how it's used. Recommended to use the same value that the vanilla sbc does for a given <CubeTopology>.
  • Convex - same as Box.

HasPhysics

<HasPhysics>
Type: BooleanDefaulttrue
If set to false, makes the block not have any collision and also have 0 mass.
Because of this behavior, if set to false then you should also set <IsStandAlone> to false.

IsStandAlone

<IsStandAlone>
Type: BooleanDefaulttrue
If set to false and a grid is made entirely of blocks that have this set to false, then said grid will vanish (most relevant when splitting grids by removing connecting blocks).
If using <PhysicsOption> set to None or <HasPhysics> set to false, it's highly recommended for this to be false because a grid with only physicsless blocks will have no collision at all and cannot be grinded.

WheelPlacementCollider

<WheelPlacementCollider>
Type: WheelPlacementColliderSettingsDefaultnull
Only used by blocks attached to suspensions (the wheels).

Defines a fake cylinder that is used to test if block placement is allowed near it. This offers a more accurate representation to the visual look of a wheel compared to using its actual physical shape which is a sphere.
Contains more elements:

<ColliderDiameter>Type: SingleDefault1.0
Fake wheel diameter, ratio of largest between X and Z from the metric boundingbox.
<ColliderHeight>Type: SingleDefault1.0
Fake wheel thickness, ratio of Y from the metric boundingbox.
<ColliderOffset>Type: SingleDefault0.0
Fake wheel offset on Y axis, ratio of Y from the metric boundingbox.
Example:
<WheelPlacementCollider>
  <ColliderDiameter>1.0</ColliderDiameter>
  <ColliderHeight>1.0</ColliderHeight>
  <ColliderOffset>0.0</ColliderOffset>
</WheelPlacementCollider>
In more depth: https://github.com/THDigi/SE-ModScript-Examples/wiki/Hidden-SBC-tags-features#WheelPlacementCollider
(Added in SE v1.203)

YesNoToolbarBackground

<YesNoToolbarBackground>
Type: BooleanDefaultfalse
Adds an explanation box to this block's toolbar.

Requires it to have a toolbar with exactly 2 slots, but can have any amount of pages.

It also requires <DisplayName> to be a localization key (either directly or containing {LOC:key}), for some reason (bugreport).
(Added in SE v1.206)

YesNoToolbarYesTooltip

<YesNoToolbarYesTooltip>
Type: StringDefaultnull
Only used if <YesNoToolbarBackground> is enabled and has its requirements fulfilled.

Can be plain-text or a localization key (from .resx files) and is shown in the small explanation box to describe the left slot's purpose.

If null or empty, it falls back to "When true" (localized).
(Added in SE v1.206)

YesNoToolbarNoTooltip

<YesNoToolbarNoTooltip>
Type: StringDefaultnull
Only used if <YesNoToolbarBackground> is enabled and has its requirements fulfilled.

Can be plain-text or a localization key (from .resx files) and is shown in the small explanation box to describe the right slot's purpose.

If null or empty, it falls back to "When false" (localized).
(Added in SE v1.206)

AllowInteractionThroughBlock

<AllowInteractionThroughBlock>
Type: BooleanDefaultfalse
Game's documentation: Used when block has see-through parts (like holodisplay) that you want to be able to interact through.

EnableUseObjectSimpleTargeting

<EnableUseObjectSimpleTargeting>
Type: BooleanDefaultfalse
Changes how subparts are targetted by using mostly detector area for line intersection... easier to see it in action in game.
(Added in SE v1.202)

TieredUpdateTimes

<TieredUpdateTimes>
Type: MySerializableList<UInt32>Default0 entries
Note: This impacts performance of the block, recommended to not set at all because the game has proper defaults for each block type.

Defines how fast the block updates depending on "nearby" players, only used by certain block types.

Example usage:
<TieredUpdateTimes>
  <unsignedInt>60</unsignedInt>
  <unsignedInt>120</unsignedInt>
  <unsignedInt>240</unsignedInt>
</TieredUpdateTimes>

The <unsignedInt> elements in order are the tiers:
1. Normal - local player is nearby or grid streamed to at least one player.
2. Tier1 - local player not nearby and grid is not streamed to anyone.
3. Tier2 - same as Tier1 but 10 minutes passed since it was set to Tier1.

In more detail: https://github.com/THDigi/SE-ModScript-Examples/wiki/Hidden-SBC-tags-features#tieredupdatetimes-explained


(Top) | From PhysicalModel Definition:

Mass

<Mass>
Type: SingleDefault0
Mass in kg.
This does not work for blocks, it is overwritten by the cumulative mass of all the <Components> that are required to build it, unless <HasPhysics> is false in which case it contributes 0 mass to the grid.

Model

<Model>
Type: StringDefaultnull
The visual and physical model.

Path to a .mwm file relative to current mod's folder. Falls back to game folder if not found in current mod.

Referencing assets in other mods

PhysicalMaterial

<PhysicalMaterial>
Type: StringDefaultnull
SubtypeId of a PhysicalMaterial Definition (PhysicalMaterials.sbc). Visit Collision Effects for more details on what it's used for in general.

UseInstanceRender

<UseInstanceRender>
Type: BooleanDefaulttrue
Only when used by planetary environment items.
Unclear exactly how it works, however the vanilla game turns this off for its forageable plants, which a guess would be that it being set to true would be faster if the model is decorative, but for interactive models that need to have their own highlight/etc it needs to be turned off.
(Added in SE v1.207)

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

Obsolete Elements

Elements that exist in the game code or vanilla SBC, but do nothing

Note: this list only contains root-level from this definition only, nothing from inherited ones.

<PowerConsumptionMoving>Type: SingleDefault0
Not used in the power callback which is the decider for how much it consumes.
<Subparts>Type: SubpartDefinition[]Defaultnull
Not used anymore.
<OpeningSequence>Type: Opening[]Defaultnull
Not used anymore.