ContractTypeEscort Definition

From Space Engineers Wiki
Jump to navigation Jump to search

Requires an xsi:type attribute:

<ContractType xsi:type="MyObjectBuilder_ContractTypeEscortDefinition">

This contract has players defend a ship against waves of spawned enemy ships while it flies to a randomly chosen destination.

For more info visit Modding Contracts.

Formulas

First some variables:

  • Reward the amount of money player will get upon finishing the contract.
  • ContractTime is the time the player will have to finish the contract before it automatically fails, in seconds.
  • DeepStationBonus is 1 if the station is not a deep-space station, otherwise it's <DeepSpaceStationContractBonus> from economy session component.
  • ShipPathLength is the distance (meters) between the escort ship's spawn position to its destination position.

The ones surrounded by < and > are elements in this page.
The formulas:

Reward = (<MinimumMoney> * 3^Log10(ShipPathLength)) * DeepStationBonus

ContractTime = (<Duration_BaseTime> + ((<Duration_FlightTimeMultiplier> * ShipPathLength) / 30)) * <DurationMultiplier>

Elements

PrefabsEscortShips

<PrefabsEscortShips>
Type: MySerializableList<String>Defaultnull
List of Prefab Definition SubtypeIds from which it picks one randomly to use as the ship to be escorted.
Usage:
<PrefabsEscortShips>
  <string>Blue Drone MK1</string>
  <!-- ... -->
</PrefabsEscortShips>

If left null or defined empty it will instead use Eradicator_mk.1 prefab.


Prefab's blocks can use a specific color (360°, 100%, 100% in-game HSV or 1, 0.2, 0.55 inside the file) which gets replaced by the faction's <CustomColor> (from save file).

TravelDistanceMin

<TravelDistanceMin>
Type: DoubleDefault0
Minimum meters away from the station for the escort ship destination.

TravelDistanceMax

<TravelDistanceMax>
Type: DoubleDefault0
Maximum meters away from the station for the escort ship destination.

TriggerRadius

<TriggerRadius>
Type: DoubleDefault0
Escort ship's destination is a sphere with this meters in radius.
When the escort ship's AABB overlaps this sphere, the contract will be complete.

RewardRadius

<RewardRadius>
Type: DoubleDefault0
Contract owner must be within this (meters) + <TriggerRadius> from the escort's destination when it reaches it in order to receive the contract rewards.

Duration_BaseTime

<Duration_BaseTime>
Type: SingleDefault0
Affects contract duration:
ContractTime = <DurationMultiplier> * (<Duration_BaseTime> + (<Duration_FlightTimeMultiplier> * DistanceMeters / 30))

Duration_FlightTimeMultiplier

<Duration_FlightTimeMultiplier>
Type: SingleDefault0
Affects contract duration, see <Duration_BaseTime>.

InitialDelayInS

<InitialDelayInS>
Type: Int32Default0
Seconds before the escort ship starts going.

DroneFirstDelayInS

<DroneFirstDelayInS>
Type: Int32Default0
Seconds after the escort ship starts moving before spawning the first enemy wave.

DroneAttackPeriodInS

<DroneAttackPeriodInS>
Type: Int32Default0
Seconds between each subsequent enemy waves.

DronesPerWave

<DronesPerWave>
Type: Int32Default0
How many enemies (<PrefabsAttackDrones>) to spawn per wave, each being triggered every <DroneAttackPeriodInS>.

PrefabsAttackDrones

<PrefabsAttackDrones>
Type: MySerializableList<String>Defaultnull
List of Prefab Definition SubtypeIds from which it picks several randomly to spawn as enemies.
Usage:
<PrefabsAttackDrones>
  <string>Blue Drone MK1</string>
  <!-- ... -->
</PrefabsAttackDrones>

If left null or defined empty it will instead use Barb_mk.1 prefab.


Prefab's blocks can use a specific color (360°, 100%, 100% in-game HSV or 1, 0.2, 0.55 inside the file) which gets replaced by the faction's <CustomColor> (from save file).

DroneBehaviours

<DroneBehaviours>
Type: MySerializableList<String>Defaultnull
Optional. List of DroneBehavior Definition subtypeIds to pick randomly for each enemy (<PrefabsAttackDrones>) that is spawned.

If left null, defined empty or one is not found, it will fall back to a default behavior.

Usage:
<DroneBehaviours>
  <string>C_LongRangeGatlingDrone</string>
  <!-- ... -->
</DroneBehaviours>

(Top) | From ContractType Definition:

DurationMultiplier

<DurationMultiplier>
Type: DoubleDefault0
Multiplier to the determined duration for the contract.

How the contract duration is calculated to begin with depends on the contract type, refer to each one's page for the formula.

MinimumMoney

<MinimumMoney>
Type: Int64Default0
The base money reward for completing this contract.

The final reward depends on the specific contract type, refer there for each one's formula.

MinimumReputation

<MinimumReputation>
Type: Int32Default0
The reputation reward for completing this contract.

All contract types use this value exactly as it is with no variability.

FailReputationPrice

<FailReputationPrice>
Type: Int32Default0
Reputation to be subtracted (enter positive values) if the contract is failed.

All contract types use this value exactly as it is with no variability.

MinStartingDeposit

<MinStartingDeposit>
Type: Int64Default0
Optional. See <MaxStartingDeposit> for details.

MaxStartingDeposit

<MaxStartingDeposit>
Type: Int64Default0
Optional. Safety deposit (money) required by the player to take this contract.

However, this is bugged and it doesn't work as one would expect, it's instead this minus <MinStartingDeposit>, then a random value between 0 and that subtract result (bugreport). It's easier to leave MinStartingDeposit at 0 so it results in a random value between 0 and this.

Another issue, this will only display for ContractTypeDeliver (hauling), but it will function for all of them (bugreport).

Upon succesful completion, this deposit is refunded and it is not part of the displayed reward amount.

MoneyReputationCoeficient

<MoneyReputationCoeficient>
Type: Int64Default0
Only used by the ContractTypeHunt.

Multiplier to the <MinimumMoney> reward the lower the target's reputation is.

Full formula can be found in the respective contract type's page.

ChancesPerFactionType

<ChancesPerFactionType>
Type: MyContractChancePair[]Defaultnull
List of chances for this contract to appear for a given FactionType.

Each <ContractChance> element can have:

<DefinitionId>Type: SerializableDefinitionIdDefault(invalid)
Required. The full id of a FactionType definition (FactionTypes.sbc). Example syntax shown below.
<Value>Type: SingleDefault0
Required. The weight that this contract has against other contracts when a faction picks what contracts to present.
Weighted random does mean that each entry's number affects the chance of all the entries, because the weight from each is added up to a total and the random number chosen is between 0 and that total.

A visual example. We have 4 objects: red, green, purple, yellow, and each has its weight number:
WeightedRandom.png

The red object has a ~13.3% chance (1.0/7.5)*100, but if any other entry's number were to be changed or any object removed, then the red object's chance also changes and needs to be recalculated with the new total.
Usage:
<ChancesPerFactionType>
  <ContractChance>
    <DefinitionId Type="MyObjectBuilder_FactionTypeDefinition" Subtype="Military" />
    <Value>1.0</Value>
  </ContractChance>
  <!-- ... -->
</ChancesPerFactionType>

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