RotatingSubpartComponent Definition
Requires an xsi:type attribute:
<EntityComponent xsi:type="MyObjectBuilder_RotatingSubpartComponentDefinition">
This is part of an entity component, see EntityComponents for usage details.
An entity component that provides continuous rotation of a subpart.
Elements
SubpartName<SubpartName> | Type: String | Default: null |
The name of the subpart dummy from the model, without the subpart_ prefix. Not case sensitive. | ||
Axis<Axis> | Type: Int32 | Default: 1 |
Defines the axis this rotates around:
| ||
Direction<Direction> | Type: Boolean | Default: true |
Internally called RotationDynamicDirectionOverrideDirection. | ||
Speed<Speed> | Type: Single | Default: 1 |
| Top rotation speed in radians per second. Math to convert: . | ||
Spinup<Spinup> | Type: Single | Default: 1 |
| Rotation speed acceleration in radians per second, per second. | ||
Spindown<Spindown> | Type: Single | Default: 1 |
| Rotation speed deacceleration in radians per second, per second. | ||
PropagateRotationToChildernSubparts<PropagateRotationToChildernSubparts> | Type: Boolean | Default: false |
| Affects parenting in some way, if false seems to parent it to the grid, otherwise to block. | ||
NeedsEnergyToRotate<NeedsEnergyToRotate> | Type: Boolean | Default: false |
| If true, subpart will stop rotating when block is turned off or unpowered. It does not consume any power. Requires a block that has on/off in terminal. | ||
AnimateWhenBlockNotFunctional<AnimateWhenBlockNotFunctional> | Type: Boolean | Default: true |
| If true, it animates even if the block health is below the red line (regardless of construction stage or not). (Added in SE v1.208) | ||
RemoveExistingComponentOnNewInsert<RemoveExistingComponentOnNewInsert> | Type: Boolean | Default: false |
| Setting it to false allows this component to exist multiple times on the same entity. | ||
(Top) | From ComponentDefinitionBase:
(Nothing)
(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.
<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.
| ||||||||||||||||||||||||||
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.
{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. | ||||||||||||||||||||||||||
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
| ||||||||||||||||||||||||||
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. | ||||||||||||||||||||||||||
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:
| ||||||||||||||||||||||||||
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. | ||||||||||||||||||||||||||
EnabledEnabled (attribute[1]) | Type: Boolean | Default: true | ||||||||||||||||||||||||
If set to false it will remove the definition after it's been loaded.Example usage: <Definition Enabled="false">
The "Definition" above is the opening element that for the entire definition, not an inner node like <Component>, <Blueprint>, etc. | ||||||||||||||||||||||||||
xsi:typexsi:type (attribute[1]) | Type: string | Default: null | ||||||||||||||||||||||||
Name of an object that this definition will be deserialized as. 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 For more details on how this relates to the TypeId, and usage examples, see: Things to know about SBC - TypeId vs xsi:type. | ||||||||||||||||||||||||||