NoMansSky:Reference Guides/DESCRIPTOR Files

 

Home

Tutorials

Tool Downloads

Reference Guides

Game Structure

Index

Join us on Discord!

 

DESCRIPTOR Files

DESCRIPTOR MBIN's are used to enable procedural generation on an existing SCENE file. DESCRIPTOR MBIN's tend to have a 1:1 mapping of object names and hierarchies as to what is found also in the corresponding SCENE file - the idea is that by attaching SCENES onto each other, you can use DESCRIPTORs to allow only certain child SCENEs to appear.

Example

Suppose you want to procedurally generate a SCENE involving a house. This house has three components - a door, walls, and some roofs. Suppose you modeled three versions of doors, walls, and roofs. You would have the following SCENE hierarchy:

• HOUSE
  • _ROOF_
    • _ROOF_1
    • _ROOF_2
    • _ROOF_3
  • _WALLS_
    • _WALLS_1
    • _WALLS_2
    • _WALLS_3
  • _DOORS_
    • _DOORS_1
    • _DOORS_2
    • _DOORS_3

By following the same hierarchy of names and ID's in your DESCRIPTOR file, you can make it so the game will choose only one type of roof, one type of wall, and one type of door each time a house is spawned on a planet. Bear in mind that all objects on the same planet use the same seed - the seed will only change on when the house spawns in another planet.

It is also important to take note of the presence of UNDERSCORES on the object's name and ID.

Technicalities of how parts are selected

Within a DESCRIPTOR file there are 2 different Properties nested within lists that act differently. These are TkResourceDescriptorList and TkResourceDescriptorData.

These two properties act in different ways.

Inside the List within the TkModelDescriptorList, TkResourceDescriptorLists are placed. The game will load ALL TkResourceDescriptorLists that are specified. Each TkResourceDescriptorList contains a list of TkResourceDescriptorData within the Descriptor Property.

The game will only pick ONE of these TkResourceDescriptorData nodes (and its associated children if any) with the specified chance. If the Chance is 0 then all are given equal probabilities, but if a chance is specified then that chance will be used (make sure all add to 1 within the scope (i.e. all Chances for each TkResourceDescriptorData within a Descriptor's Property should add to 1)).

This process repeats for any children of the selected TkResourceDescriptorData.

In this way the entire tree is traversed to create a procedurally generated model.

Important Notes

Within Descriptor files, DescriptorData nodes include the following headings:

<Property value="TkResourceDescriptorData.xml">
          <Property name="Id" value="[varies]" />
          <Property name="Name" value="[varies]" />

The ID has a limit of 16 characters. Exceed this, and the MBINCompiler will remove the excess characters. So an ID like:

<Property name="Id" value="_HalloweenTownsLoveliest" />

Would become:

<Property name="Id" value="_HalloweenTownsL" />

This would then break any connections between the Descriptor entry and your Scene file. This brings us to the next important point. It is absolutely necessary for IDs and names to match between entries in both the Descriptor file and the Scene file. Which is to say, if your DescriptorData node looks like this:

<Property value="TkResourceDescriptorData.xml">
          <Property name="Id" value="_EXAMPLE_1" />
          <Property name="Name" value="_Example_1" />

Your SceneNodeData should look like this:

<Property value="TkSceneNodeData.xml">
      <Property name="Name" value="_Example_1" />

If they mismatch in any way, you may continue to see the objects you added to the scene, particularly all of them, but you will never see only some of them, as would be desired from modifying the Descriptor file. So keep an eye out as you adjust your files, and try to ensure your names & IDs match across Descriptors & Scenes!