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, TkResourceDescriptorList*s are placed. The game will load ALL *TkResourceDescriptorList*s 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!