LCDPanelsBlock Definition

HomeModdingReferenceSBCCubeBlocksLCDPanels.Def

Overview

Inherits

• FunctionalBlock Definition
• CubeBlock Definition
• PhysicalModel Definition
• DefinitionBase

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

Requires an xsi:type attribute:

<Definition xsi:type="MyObjectBuilder_LCDPanelsBlockDefinition">

Elements

 ↑   🔗 

RequiredPowerInput <RequiredPowerInput>	Type: Single	Default: 0
Constant electricity usage in megawatts.
ResourceSinkGroup <ResourceSinkGroup>	Type: String	Default: null
SubtypeId of a sink resource group.

(Top) | From FunctionalBlock Definition:

ScreenAreas <ScreenAreas>	Type: List<ScreenArea>	Default: null
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 Name (attribute) Type: string Default: null 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 DisplayName (attribute) Type: string Default: null Required. The visual name of the screen shown in the terminal. Can be plain-text or a localization key (from .resx files). ScreenWidth ScreenWidth (attribute) Type: Int32 Default: 1 Optional. See <ScreenHeight>. ScreenHeight ScreenHeight (attribute) Type: Int32 Default: 1 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 TextureResolution (attribute) Type: Int32 Default: 512 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: $\text{ResolutionX}=\text{TextureResolution}*2^{\lfloor \frac{\text{ScreenWidth}}{\text{ScreenHeight}}{\log }_2\rfloor }$ and $\text{ResolutionY}=\text{TextureResolution}$ Height larger than width: $\text{ResolutionX}=\text{TextureResolution}$ and $\text{ResolutionY}=\text{TextureResolution}*2^{\lfloor \frac{\text{ScreenHeight}}{\text{ScreenWidth}}{\log }_2\rfloor }$ 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 Script (attribute) Type: string Default: null 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: String	Default: (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: MyBlockTopology	Default: Cube
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: SerializableVector3I	Default: X: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: MyCubeSize	Default: Large
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: Single	Default: 10
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: Single	Default: 1.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[]	Default: null
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 Subtype (attribute) Type: string Default: null The <SubtypeId> for a Component item definition (Components.sbc). Count Count (attribute) Type: Int16 Default: 0 Up to 65535, how many components to require. DeconstructId <DeconstructId> Type: SerializableDefinitionId Default: (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: CriticalPart	Default: null
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 Subtype (attribute) Type: string Default: null The <SubtypeId> for a component that is present in the block's <Components>, game crashes otherwise. Index Index (attribute) Type: Int32 Default: 0 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>	Default: null
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 BuildPercentUpperBound (attribute) Type: Single Default: 0 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 File (attribute) Type: string Default: null 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 RandomOrientation (attribute) Type: bool Default: false Optional. If true, will make this construction model be rotated pseudo-randomly based on its position on the grid. MountPointOverrides <MountPointOverrides> Type: MountPoint[] Default: null 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[]	Default: null
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: Boolean	Default: true
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: Int32	Default: 1
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>	Default: null
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: MyAutorotateMode	Default: OneDirection
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: MyBlockRotation	Default: Both
Untested, game docs say "Allowed cube block rotations". Available values: None, Horizontal, Vertical, Both.
Direction <Direction>	Type: MyBlockDirection	Default: Both
Affects how the block is rotated, unclear exactly how. Available values: Horizontal, Vertical, Both.
RandomRotation <RandomRotation>	Type: Boolean	Default: false
Seems to only be used when dragging to build blocks in a line or plane.
UseModelIntersection <UseModelIntersection>	Type: Boolean	Default: false
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: Boolean	Default: false
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>	Default: null
Optional. Rules on how the block can be placed inside and outside voxels. If null, it uses the defaults from CubeBuilder's <BuildingSettings>. StaticMode <StaticMode> Type: VoxelPlacementSettings Default: (see deeper) Used when placement is locked to a positional grid (not just a blocks grid). PlacementMode <PlacementMode> Type: VoxelPlacementMode Default: None 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. Volumetric - determines how much inside or outside voxels it can be, configured using <MinAllowed>&<MaxAllowed>. MinAllowed <MinAllowed> Type: Single Default: 0 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 <MaxAllowed> Type: Single Default: 0 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 <DynamicMode> Type: VoxelPlacementSettings Default: (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>	Default: null
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: String	Default: null
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>	Default: null
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: MySymmetryAxisEnum	Default: None
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: MySymmetryAxisEnum	Default: None
See <MirroringX>.
MirroringZ <MirroringZ>	Type: MySymmetryAxisEnum	Default: None
See <MirroringX>.
NewsletterSubscriptionNeeded <NewsletterSubscriptionNeeded>	Type: Boolean	Default: false
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: Single	Default: 1.0
A multiplier to all damage dealt to this block, including explosive, impact and anything from mod scripts too.
DamageMultiplierExplosion <DamageMultiplierExplosion>	Type: Single	Default: 7.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: Single	Default: 1.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[]	Default: null
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: Single	Default: 1
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: Single	Default: 0.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>	Default: null
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: SerializableVector3	Default: 0,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: Boolean	Default: true
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: String	Default: null
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: String	Default: null
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: String	Default: null
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: Boolean	Default: false
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>	Default: null
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: String	Default: (empty)
SubtypeId of a ParticleEffect definition (Particles_*.sbc). Spawned when the block is damaged below function (red line).
DamageEffectOffset <DamageEffectOffset>	Type: Nullable<Vector3>	Default: null
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: String	Default: null
Audio definition subtypeId to be played when block is damaged below function (red line).
DestroyEffect <DestroyEffect>	Type: String	Default: (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>	Default: null
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: Single	Default: 1
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: String	Default: PoofExplosionCat1
SubtypeId (without Arc or Real prefix) of an audio definition (Audio_*.sbc). Played when block is destroyed.
AmmoExplosionEffect <AmmoExplosionEffect>	Type: String	Default: (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: String	Default: (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[]	Default: null
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 Name (attribute) Type: string Default: null The identifier that the code would trigger. Only option used by vanilla game is "Damage". Mod scripts can trigger whichever ones they wish. ParameterMin ParameterMin (attribute) Type: Single Default: -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 ParameterMax (attribute) Type: Single Default: 3.40282347E+38 See ParameterMin ParticleEffects <ParticleEffects> Type: CubeBlockEffect[] Default: null List of <ParticleEffect> elements, each having: Name Name (attribute) Type: string Default: (empty) SubtypeId of a ParticleEffect definition (Particles_*.sbc). Origin Origin (attribute) Type: string Default: (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 Duration (attribute) Type: Single Default: 0.0 How many seconds the whole effect lasts. Loop Loop (attribute) Type: bool Default: false Whether the effect triggers again after it ends (does not affect the particle definition's loop). Delay Delay (attribute) Type: Single Default: 0.0 How many seconds to wait until spawning the particle. SpawnTimeMin SpawnTimeMin (attribute) Type: Single Default: 0.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 SpawnTimeMax (attribute) Type: Single Default: 0.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: Boolean	Default: false
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: Boolean	Default: true
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: PatternDefinition	Default: null
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 <CubeTopology> Type: MyCubeTopology Default: Box 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 <ShowEdges> Type: Boolean Default: false Whether armor edges are shown for this. Which edges are used however are defined by <EdgeType>. Sides <Sides> Type: Side[] Default: false 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 PatternWidth (attribute) Type: Int32 Default: 0 Affects the armor texture covering multiple blocks, unclear exactly how it works, needs research. PatternHeight PatternHeight (attribute) Type: Int32 Default: 0 Affects the armor texture covering multiple blocks, unclear exactly how it works, needs research. ScaleTileU ScaleTileU (attribute) Type: Int32 Default: 1 ScaleTileV ScaleTileV (attribute) Type: Int32 Default: 1 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: String	Default: null
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>	Default: null
List of bone positions and offsets, unclear how it exactly works, the Deformable Armor page might have more info. Each <BoneInfo> can have: BonePosition <BonePosition> Type: SerializableVector3I Default: 0,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 <BoneOffset> Type: SerializableVector3UByte Default: 0,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>	Default: null
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: MyPhysicsOption	Default: Box
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: Boolean	Default: true
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: Boolean	Default: true
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: WheelPlacementColliderSettings	Default: null
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 <ColliderDiameter> Type: Single Default: 1.0 Fake wheel diameter, ratio of largest between X and Z from the metric boundingbox. ColliderHeight <ColliderHeight> Type: Single Default: 1.0 Fake wheel thickness, ratio of Y from the metric boundingbox. ColliderOffset <ColliderOffset> Type: Single Default: 0.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: Boolean	Default: false
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: String	Default: null
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: String	Default: null
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: Boolean	Default: false
Game's documentation: Used when block has see-through parts (like holodisplay) that you want to be able to interact through.
EnableUseObjectSimpleTargeting <EnableUseObjectSimpleTargeting>	Type: Boolean	Default: false
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>	Default: 0 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: Single	Default: 0
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: String	Default: null
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: String	Default: null
SubtypeId of a PhysicalMaterial Definition (PhysicalMaterials.sbc). Visit Collision Effects for more details on what it's used for in general.
UseInstanceRender <UseInstanceRender>	Type: Boolean	Default: true
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: 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) Type: string Default: (invalid) Same behavior as <TypeId>, do not define both. Subtype Subtype (attribute) 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 <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 <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 <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 <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 <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 <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 <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 Enabled (attribute)	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 xsi:type (attribute)	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.

---