ProceduralWorldEnvironment

From Space Engineers Wiki
Jump to navigation Jump to search

Requires an xsi:type attribute:

<Definition xsi:type="VR.ProceduralWorldEnvironment">

An optional and more advanced way of configuring planet environment, linked to a planet through its <Environment>.

This is normally generated when that <Environment> element is not set, those defaults are mentioned below in the elements as well as in the below SBC example:

SBC file example with generated defaults

Last checked in SE v207.

<?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">
  <Definition xsi:type="VR.ProceduralWorldEnvironment">
    <Id Type="MyObjectBuilder_ProceduralWorldEnvironment" Subtype="YourCustomSubtypeHere"/>
    <SectorSize>200</SectorSize>
    <ItemsPerSqMeter>0.0034</ItemsPerSqMeter>
    <MaxSyncLod>0</MaxSyncLod>
    <ItemTypes>
      <Item Name="Tree">
        <LodFrom>-1</LodFrom>
        <LodTo>1</LodTo>
        <Provider Type="MyObjectBuilder_ProceduralEnvironmentModuleDefinition" Subtype="Static"/>
        <Proxy Type="MyObjectBuilder_EnvironmentModuleProxyDefinition" Subtype="Breakable"/>
      </Item>
      <Item Name="Bush">
        <LodFrom>0</LodFrom>
        <LodTo>-1</LodTo>
        <Provider Type="MyObjectBuilder_ProceduralEnvironmentModuleDefinition" Subtype="Static"/>
        <Proxy Type="MyObjectBuilder_EnvironmentModuleProxyDefinition" Subtype="Breakable"/>
      </Item>
      <Item Name="Forageable">
        <LodFrom>-1</LodFrom>
        <LodTo>1</LodTo>
        <Provider Type="MyObjectBuilder_ProceduralEnvironmentModuleDefinition" Subtype="Static"/>
        <Proxy Type="MyObjectBuilder_EnvironmentModuleProxyDefinition" Subtype="Forageable"/>
      </Item>
      <Item Name="VoxelMap">
        <LodFrom>0</LodFrom>
        <LodTo>-1</LodTo>
        <Provider Type="MyObjectBuilder_ProceduralEnvironmentModuleDefinition" Subtype="Memory"/>
        <Proxy Type="MyObjectBuilder_EnvironmentModuleProxyDefinition" Subtype="VoxelMap"/>
      </Item>
      <Item Name="Bot">
        <LodFrom>0</LodFrom>
        <LodTo>-1</LodTo>
        <Provider xsi:nil="true"/>
        <Proxy Type="MyObjectBuilder_EnvironmentModuleProxyDefinition" Subtype="BotSpawner"/>
      </Item>
    </ItemTypes>
    <EnvironmentMappings>
	  <!-- no static default, it's generated from planet's <EnvironmentItems>; see syntax examples in the element docs below -->
    </EnvironmentMappings>
  </Definition>
</Definitions>

Elements

MaxSyncLod

<MaxSyncLod>
Type: Int32Default1
Default for generated: 0
Affects multiplayer synchronization of sectors in some way related to the LOD of this sector. Needs more research.

SectorSize

<SectorSize>
Type: DoubleDefault64.0
Default for generated: 200

Impacts sectors in some way, can affect LOD transition distances too and consequently performance. Needs more research.

Also see <ItemsPerSqMeter>.

ItemsPerSqMeter

<ItemsPerSqMeter>
Type: DoubleDefault0.0017
Default for generated: 0.0034
This combined with <SectorSize> affect the density for spawning <EnvironmentMappings>. Needs more research.

EnvironmentMappings

<EnvironmentMappings>
Type: MyProceduralEnvironmentMapping[]Defaultnull
Default for generated: from planet's <EnvironmentItems>

The list of environment items to spawn with a set of rules.
Each <Mapping> can contain:

<Biome>Type: int[]Defaultnull
Green pixel intensity to use from the planet's _mat maps as locations for this set of spawnables.

If not defined, it will have a single entry with 0.
Note: this element can be repeated to add more values to an internal list.

Example:
<Biome>25</Biome>
<!-- ... -->
<Material>Type: string[]Defaultnull
Required. SubtypeId of VoxelMaterial Definition to restrict to for this set of spawnables.

Note: this element can be repeated to add more values to an internal list.

Example:
<Material>Sand_02</Material>
<!-- ... -->
<Item>Type: MyEnvironmentItemInfo[]Defaultnull
Note: this element can be repeated to add more values to an internal list.

Contains more elements:

<Type>Type: StringDefaultnull
Refers to a Name from <ItemTypes> which is what provides the functionality.

For the default ones they look for these definitions:

<Subtype>Type: StringDefaultnull
SubtypeId for the definition mentioned at Type.
<Density>Type: SingleDefault0
This can behave differently depending on the total value that all of the items' Density adds up to:
  • If they total at or below 1.0, then this is a chance ratio, values from 0.0 to 1.0 which represent 0% to 100%.
  • Otherwise if they total above 1, this is a weight and the actual chance depends on the resulting total.

In other words: both are the same system, but if the tallied Density total is below 1.0 then the game will add a blank entry with the remaining Density to reach a total of 1.0.

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.
Obsolete elements
<Offset>Type: SingleDefault0
Not used.
Example:
<Item Type="Tree" Subtype="SomeModelCollection" Density="1" />
<!-- ... -->
Note: this element can be repeated to add more values to an internal list.
<Height>Type: SerializableRangeDefault-1
The minimum and maximum relative height to allow within.

The values ratios between the planet <HillParams>'s Min and Max, where 0 here represents the HillParams's Min, and 1 represents HillParams's Max, and decimals in-between allowed of course.

Example:
<Height Min="0.4" Max="0.7" />
<Latitude>Type: SymmetricSerializableRangeDefault-90, 90, true
Angles away from the equator in degrees.

0 is at the equator and 90 is at either pole. If the Mirror attribute is set to false, then the world-up planet side is -90 and the world-down side is 90.

Example:
<Latitude Min="-90" Max="90" Mirror="true" />
<Longitude>Type: SerializableRangeDefault-1
Angles around the world-up axis, where 0 is on the world-back side of the planet, and 90 is on the world-right side.
Example:
<Longitude Min="-180" Max="180" />
<Slope>Type: SerializableRangeDefault-1
Angles in degrees of terrain slope.
Example:
<Slope Min="0" Max="90" />
Full example:
<Mapping>
  <Material>Sand_02</Material>
  <!-- ... -->
  
  <Biome>0</Biome>
  <!-- ... -->
  
  <Item Type="Tree" Subtype="SomeModelCollection" Density="1" />
  <!-- ... -->
  
  <Height Min="0" Max="1" />
  <Latitude Min="0" Max="90" Mirror="true" />
  <Longitude Min="-180" Max="180" />
  <Slope Min="0" Max="50" />
</Mapping>

ItemTypes

<ItemTypes>
Type: MyEnvironmentItemTypeDefinition[]Defaultnull
Default for generated: (see at the top of this page).

List of environment modules and proxies for the planet to use which provide functionality for <EnvironmentMappings> and possibly other things.
Recommended to use the template from the top of the page for this element.

Each <Item> can contain:

Name (attribute[1])Type: StringDefaultnull
Must be a unique name that will later be used in <EnvironmentMappings> as the "Type" to refer to.
<LodFrom>Type: Int32Default-1
<LodTo>Type: Int32Default-1
<Provider>Type: SerializableDefinitionId?Defaultnull
Optional. Id of a ProceduralEnvironmentModule Definition (Environment\EnvironmentModules.sbc).
Example:
<Provider Type="MyObjectBuilder_ProceduralEnvironmentModuleDefinition" Subtype="Memory"/>
<Proxy>Type: SerializableDefinitionId[]Defaultnull
Id of a EnvironmentModuleProxy Definition (Environment\EnvironmentModules.sbc).
Example:
<Proxy Type="MyObjectBuilder_EnvironmentModuleProxyDefinition" Subtype="BotSpawner"/>
<!-- ... -->
Note: this element can be repeated in order to add more to an internal list.

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

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.

<ScanningMethod>Type: MyProceduralScanningMethodDefaultRandom
Default for generated: Random

Available values: Random, Grid.

Not used by anything.