DroneBehavior Definition

HomeModdingReferenceSBCDroneBehavior Def

Overview

Inherits

• DefinitionBase

Requires an xsi:type attribute:

<DroneBehavior xsi:type="MyObjectBuilder_DroneBehaviorDefinition">

Found in DroneBehaviors.sbc and used by Remote Control blocks, more details there.

The vanilla game mostly stopped using these, in favor of the AI blocks.

Maneuvering

 ↑   🔗 

AvoidCollisions <AvoidCollisions>	Type: Boolean	Default: true
Whether the drone is careful about bumping into nearby things while flying, except when ramming.
SpeedLimit <SpeedLimit>	Type: Single	Default: 50
The drone's maximum flight speed in m/s. Ignored when ramming.
RotateToPlayer <RotateToPlayer>	Type: Boolean	Default: true
If true, the ship will use its gyros to rotate the ship towards the target.
PlayerYAxisOffset <PlayerYAxisOffset>	Type: Single	Default: 0.9
When the target is a character, offset the target vector upwards (relative to the character) by this many meters, because their pivot is at their feet. It gets doubled when the ramming behavior is engaged, unclear why.
MaxManeuverDistance <MaxManeuverDistance>	Type: Single	Default: 250
Distance in meters past which the target is considered too far to do a strafe maneuver.
TargetDistance <TargetDistance>	Type: Single	Default: 200
When too far away (as per <MaxManeuverDistance>), this TargetDistance will be the distance (in meters) at which the next waypoint is set.
StrafeWidth <StrafeWidth>	Type: Single	Default: 10
Used for strafing maneuver. A value between this and its negative is randomly chosen, for example, if using 10 it results in a random range of -10 to 10. That value is how many meters it will offset to the right (or left if negative) relative to the direction between this ship and the target ship. The same will be done for <StrafeHeight> and <StrafeDepth> and all together will make a new vector, and if that is closer than <MinStrafeDistance> meters from the RC block then it will re-roll until it's not up to 10 times until it gives up.
StrafeHeight <StrafeHeight>	Type: Single	Default: 10
Same as <StrafeWidth> but for up/down axis instead.
StrafeDepth <StrafeDepth>	Type: Single	Default: 5
Same as <StrafeWidth> but for forward/backward axis instead.
MinStrafeDistance <MinStrafeDistance>	Type: Single	Default: 2
Minimum meters for the randomly created waypoint for the strafing maneuver. See <StrafeWidth> for details on how that point is calculated and how this value is involved.
UsePlanetHover <UsePlanetHover>	Type: Boolean	Default: false
If true, this affects the strafing and far-away maneuvers only if there's a planet nearby. First, it gets the altitude of the current waypoint relative to original heightmap (meaning voxel changes or grids would be ignored). If that altitude is lower than <PlanetHoverMin> or higher than <PlanetHoverMax>, then the waypoint is overwritten to keep the ship within those altitudes.
PlanetHoverMin <PlanetHoverMin>	Type: Single	Default: 2
Only used if <UsePlanetHover> is true. The altitude in meters that the ship won't go below (details in <UsePlanetHover>). Can be negative to specify under the surface.
PlanetHoverMax <PlanetHoverMax>	Type: Single	Default: 25
Only used if <UsePlanetHover> is true. The altitude in meters that the ship won't go above (details in <UsePlanetHover>). Can be negative to specify under the surface.
UseRammingBehavior <UseRammingBehavior>	Type: Boolean	Default: false
If this is enabled and the drone is no longer operational (weapons and tools broken) and the target is within <RammingBehaviorDistance> meters, then the drone will begin its ramming mode and fly towards the target at 100m/s (ignoring <SpeedLimit>).
RammingBehaviorDistance <RammingBehaviorDistance>	Type: Single	Default: 75
See <UseRammingBehavior>.
LostTimeMs <LostTimeMs>	Type: Int32	Default: 20000
WaypointDelayMsMin <WaypointDelayMsMin>	Type: Int32	Default: 1000
WaypointDelayMsMax <WaypointDelayMsMax>	Type: Int32	Default: 3000
WaypointMaxTime <WaypointMaxTime>	Type: Int32	Default: 15000
WaypointThresholdDistance <WaypointThresholdDistance>	Type: Single	Default: 0.5

Equipment

 ↑   🔗 

SoundLoop <SoundLoop>	Type: String	Default: (empty)
Optional. Plays continuously from the RC block while the drone operates. SubtypeId (without Arc or Real prefix) of an audio definition (Audio_*.sbc).
AlternativeBehavior <AlternativeBehavior>	Type: String	Default: (empty)
Optional. SubtypeId of another drone behavior definition which the drone will change to when its weapon configuration is no longer valid. For example, a drone with static weapons can switch to a ramming behavior when it loses its weapons in a firefight.
UseTools <UseTools>	Type: Boolean	Default: true
Whether the tools from the drone are controlled by this.
ToolsUsage <ToolsUsage>	Type: Single	Default: 8
Tools are engaged if the target is within this many meters from the RC block.
UseStaticWeaponry <UseStaticWeaponry>	Type: Boolean	Default: true
Whether stationary weapons from the drone are controlled by this.
StaticWeaponryUsage <StaticWeaponryUsage>	Type: Single	Default: 300
Stationary weapons are engaged if the target is within this many meters from the RC block.
UsesWeaponBehaviors <UsesWeaponBehaviors>	Type: Boolean	Default: false
Weapon behaviors are used if this is true and <WeaponBehaviors> has at least one entry and <UseStaticWeaponry> is also true.
WeaponBehaviorNotFoundDelay <WeaponBehaviorNotFoundDelay>	Type: Single	Default: 3
Cooldown in seconds before checking weapons again after not finding a target or not finding any valid weapons.
WeaponBehaviors <WeaponBehaviors>	Type: List<MyWeaponBehavior>	Default: null
Optional. Each <WeaponBehavior> can contain: Name <Name> Type: String Default: null Not used by the game, define only for your information. Priority <Priority> Type: Int32 Default: 10 Additional weight to this weapon behavior when it randomly picks one of them to use. Cannot be lower than 0. TimeMin <TimeMin> Type: Single Default: 2 Cooldown in seconds between firing volleys, random between this and <TimeMax>. TimeMax <TimeMax> Type: Single Default: 4 Cooldown in seconds between firing volleys, random between <TimeMin> and this. IgnoresVoxels <IgnoresVoxels> Type: Boolean Default: false Whether it's allowed to shoot through voxels that are in the way of the drone's target. IgnoresGrids <IgnoresGrids> Type: Boolean Default: false Whether it's allowed to shoot through other grids that are in the way of the drone's target. RequirementsIsWhitelist <RequirementsIsWhitelist> Type: Boolean Default: false Changes the meaning of <Requirements>, if left false the list will be disallowed weapons, otherwise for true it's required weapons. If this is false and <Requirements> is empty, then the stationary weapon check is skipped which might mean turrets can be assigned to <WeaponRules>, needs testing. Requirements <Requirements> Type: List<string> Default: null Only works if <WeaponRules> has at least 1 entry. List of block weapon TypeId that are either required or disallowed, depending on the value of <RequirementsIsWhitelist>. Only stationary weapons are considered, meaning the available options are: SmallGatlingGun, SmallMissileLauncher, SmallMissileLauncherReload. Example: <Requirements> <Weapon>SmallGatlingGun</Weapon> <!-- ... --> </Requirements> WeaponRules <WeaponRules> Type: List<MyWeaponRule> Default: null Each <WeaponRule> can contain: Weapon <Weapon> Type: String Default: null Optional. Limits this rule to a specific block weapon TypeId. Does nothing if null or empty. TimeMin <TimeMin> Type: Single Default: 2 Seconds to continuously fire, randomly chosen between this and <TimeMax>. TimeMax <TimeMax> Type: Single Default: 3 Seconds to continuously fire, randomly chosen between <TimeMin> and this. FiringAfterLosingSight <FiringAfterLosingSight> Type: Boolean Default: true Requires <UsesWeaponBehaviors> to be true. If set to true, once it starts firing it will not stop if the drone is no longer rotated towards the target. CanGoThroughVoxels <CanGoThroughVoxels> Type: Boolean Default: false Requires <UsesWeaponBehaviors> to be true. If set to true, will continue firing if voxels are in the way. Example: <WeaponRules> <WeaponRule> <Weapon/> <TimeMin>3</TimeMin> <TimeMax>5</TimeMax> <FiringAfterLosingSight>false</FiringAfterLosingSight> <CanGoThroughVoxels>false</CanGoThroughVoxels> </WeaponRule> <!-- ... --> </WeaponRules> Example: <WeaponBehaviors> <WeaponBehavior> <Name>Gatling Burst</Name> <Priority>30</Priority> <TimeMin>1</TimeMin> <TimeMax>3</TimeMax> <IgnoresVoxels>false</IgnoresVoxels> <IgnoresGrids>false</IgnoresGrids> <RequirementsIsWhitelist>true</RequirementsIsWhitelist> <Requirements> <Weapon>SmallGatlingGun</Weapon> <!-- ... --> </Requirements> <WeaponRules> <WeaponRule> <Weapon></Weapon> <TimeMin>2</TimeMin> <TimeMax>3</TimeMax> <FiringAfterLosingSight>true</FiringAfterLosingSight> <CanGoThroughVoxels>true</CanGoThroughVoxels> </WeaponRule> <!-- ... --> </WeaponRules> </WeaponBehavior> <!-- ... --> <WeaponBehaviors>

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

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.

<CanBeDisabled>	Type: Boolean	Default: true
Not used.

---