BlockCategories

HomeModdingReferenceSBCCategory Def

Overview

Inherits

• DefinitionBase

A category for the Toolbar Config shown on the left side.

Can contain not only blocks to be built but also blocks from a ship to be used with clicks, hand-held items and emotes too.

For a more guided approach see the Block Categories tutorial.

SubtypeId is not used at all, it instead uses <Name> as the identifier.
If one already exists it will append the <ItemIds> to the existing one and any other elements will be ignored.

Wrapper & Entry Example

 ↑   🔗 

<?xml version="1.0"  encoding="utf-8"?>
<Definitions xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <CategoryClasses>
        <!-- One or more BlockCategory entries are placed here. -->
    </CategoryClasses>
</Definitions>

A typical BlockCategories.sbc entry

This is the entry for the BlockCategory Production, containing Refineries, Assemblers, O2 Generators, etc.

<Category xsi:type="MyObjectBuilder_GuiBlockCategoryDefinition">
    <Id>
        <TypeId>GuiBlockCategoryDefinition</TypeId>
        <SubtypeId/>
    </Id>
    <Name>Section1_Position3_Production</Name>
    <DisplayName>DisplayName_Category_Production</DisplayName>
    <StrictSearch>true</StrictSearch>
    <ItemIds>
        <string>Assembler/BasicAssembler</string>
        <string>Assembler/LargeAssembler</string>
        <string>Assembler/LargeAssemblerIndustrial</string>
        <string>Assembler/LargePrototechAssembler</string>
        <string>OxygenFarm/LargeBlockOxygenFarm</string>
        <string>OxygenGenerator/OxygenGeneratorSmall</string>
        <string>OxygenGenerator/</string>
        <string>Refinery/Blast Furnace</string>
        <string>Refinery/LargePrototechRefinery</string>
        <string>Refinery/LargeRefinery</string>
        <string>Refinery/LargeRefineryIndustrial</string>
        <string>Refinery/SmallPrototechRefinery</string>
        <string>SurvivalKit/SurvivalKit</string>
        <string>SurvivalKit/SurvivalKitLarge</string>
        <string>UpgradeModule/LargeEffectivenessModule</string>
        <string>UpgradeModule/LargeEnergyModule</string>
        <string>UpgradeModule/LargeProductivityModule</string>
    </ItemIds>
</Category>

Adding something to an existing category

Using the same vanilla Production category exampled above to show that the existing IDs should not be included.

<Category xsi:type="MyObjectBuilder_GuiBlockCategoryDefinition">
    <Id>
        <TypeId>GuiBlockCategoryDefinition</TypeId>
        <SubtypeId />
    </Id>
    <Name>Section1_Position3_Production</Name>
    <ItemIds>
        <string>Refinery/ExtremeFurnanceMark55</string>
    </ItemIds>
</Category>

Elements

 ↑   🔗 

Name <Name>	Type: String	Default: null
The unique identifier for this category because the <SubtypeId> is not used at all. If another category with the same name exists, then only the <ItemIds> is read and added to the existing one. There is a special condition for "VoxelHands" (exact name) where it requires EnableVoxelHand world setting to be enabled enabled, and either creative mode or creative tools.
IsAnimationCategory <IsAnimationCategory>	Type: Boolean	Default: false
Designates category for character emotes. If <IsShipCategory> is also true, then this category will be for both block and character toolbars.
IsBlockCategory <IsBlockCategory>	Type: Boolean	Default: true
Designates category for blocks that can be placed.
IsToolCategory <IsToolCategory>	Type: Boolean	Default: false
Designates category for things that can be equipped and then triggered using primary/secondary/etc actions. If <IsShipCategory> is true, then the category becomes exclusive to equippable block weapons and tools that are already built on a ship, otherwise it's exclusive to hand-held weapons and tools.
IsShipCategory <IsShipCategory>	Type: Boolean	Default: false
If the category shows up in block toolbars (cockpit, remote control, seat, etc). Depending on the other settings, it can become exclusive to block toolbars.
SearchBlocks <SearchBlocks>	Type: Boolean	Default: true
Whether the contents of the category should show up as search results or not.
StrictSearch <StrictSearch>	Type: Boolean	Default: false
By default, if a block is part of a BlockVariantGroup, it will be displayed in any category the first block in the group is part of. If this element is set to true, this is prevented.
ShowInCreative <ShowInCreative>	Type: Boolean	Default: true
If this category is visible in creative mode (no special cases for admins). <AvailableInSurvival> also works for these to decide if they're shown in survival mode, however it is ignored if user is admin and always seen by them.
ShowAnimations <ShowAnimations>	Type: Boolean	Default: false
Whether this category should automatically include all things containing "AnimationDefinition" (exact case) in their full ID (TypeId/SubtypeId). This does mean it will include things that are not animations if the subtype happens to contain that text.
ItemIds <ItemIds>	Type: String[]	Default: null
The list of definitionIds to add to this category, see <Name>. For this reason, you should not include the existing IDs when trying to add your own to existing ones. Refer to examples above if still uncertain. Look at your PhysicalItem's or CubeBlock's <Id> element and enter the TypeId followed by a / and then the SubtypeId. If the SubtypeId is empty then add (null) after the /. Do not use the xsi:type. An ID can be part of multiple categories and it's used like that by the game too (like the Small Blocks and Large Blocks having all the blocks that other categories do). Usage: <ItemIds> <string>TypeId/SubtypeId</string> <!-- ... --> </ItemIds> The <string>...</string> can be repeated as many times as you want.

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

---