Whenever you want to add an object to a mission, you have to find it in the Object Hierarchy. One useful feature of the hierarchy is that it makes things easy to find. If you want to create a barrel, you know it won’t be in the Creature branch, or Projectile. The other useful feature, which is the subject of this document, is that the hierarchy allows properties to be inherited. This means you can have a “parent” with a good set of default properties, and “children” that each have just a few properties, giving the children the same basic characteristics as the parent, plus a few small changes.

Consider the sword guard. You have to go to the Object Hierarchy and expand Physical, then Creature, then Animal, Human, Guard, swordsman and Grunts before you can get to the sword guard archetype. You’ll notice that Physical is very generic, whereas Human is more specific, and swordsman is even more specific.

Double click on Physical to look at its properties. You’ll notice that there aren’t many properties because it’s a parent of many types of object. Look at the properties of Creature. That’s more like it. There are lots of things there, most of which are needed by all the AI objects, whether they’re zombies, humans, or treebeasts.

If you look at the sword guard archetype, it looks like there are only two properties, but really, that’s because it inherits the properties from its parent archetypes, starting from Object and finishing with Grunts, before adding its own.

Create a sword guard in a mission, and look at the properties. You’ll notice that it has more properties than its archetype. Those have been added automatically because the game needs them there. Since those properties don’t exist on sword guard itself, their values have been inherited from further up the hierarchy.

So a sword guard is essentially the sum of all the properties starting from Object and finishing with the individual sword guard.

In general, if a property exists on a parent, with value 1, and the same property is on the child with value 2, and the child is created in your mission, value 2 is used. Inheritance only works in one direction, so if you were to create the parent, value 1 would be used.

For example, look at the properties of swordguard2. It has Model Name and Inventory - > Render Type. One of the parent archetypes, swordsman, also has the Model Name. The value is SWGard01, whereas for swordguard2 the value is SWGard02. If you create a swordguard2 in your mission, you’ll see the model SWGard02 because the properties of the child archetype override the properties of any of the parents. Similarly, a property on a concrete object will override the same property from any of the parents.

When you add a metaproperty, it’s like adding a new archetype between the parent and the child. Properties in the metaproperty will override (or add to) those of the parents, and properties on the current archetype/concrete object will override those.

Create a GateSmall in your mission. It lights up and can be used because it inherits the FrobInfo property. Add the metaproperty FrobInert (-1629) (to the concrete object, not the archetype). FrobInert contains a different FrobInfo property, which is overriding the one inherited from the hierarchy.

Now add the FrobInfo property directly to the gate (be careful not to accidentally add it to the metaproperty), and change the WorldAction value to Script. The gate will now light up again, despite the FrobInert metaproperty. That’s because the property on the gate overrides the one in the metaproperty.

This works a little differently. Go back to the sword guard you created (or make another if you deleted it), and add the property S → Scripts. There will be four scripts in there, because they are being inherited from somewhere in the hierarchy. This is where it acts differently to other properties. Have a look at the Human archetype, and you’ll see those four scripts again. Now have a look at Animal and you’ll see another script. However, the property on Human does not override the property on Animal - it adds to it. Have a look at Creature and you’ll see two more scripts. The scripts on Animal also add to the scripts on Creature. Therefore, the sword guard doesn’t just have four scripts, it has seven.

You will have noticed a checkbox called Don’t inherit. If you go back to Animal and select the checkbox, Animal and all its child archetypes will be unable to access the scripts on Creature. E.g. the sword guard will not inherit NoPingBack or AICheatScript, but will still inherit ReactsNoisemakers.

These also add to each other, but when you add either property to an object, you won’t see what’s being inherited. A torch inherits three receptrons from Extinguishable. Receptrons can be blocked on a per stim basis - e.g. give a torch a receptron for WaterStim whose effect is Abort, and no WaterStim receptrons will be inherited. KOGas and FireStimm will still be inherited.

Sources are also inherited from parent archtypes. You can effectively stop it by setting the Act/React → Source Scale property to 0. This doesn’t really stop the inheritance, it just multiplies all inherited intensities by 0.

The above has dealt with Archetypes, but there are other hierarcies (accessible via the Show Tree menu). A metaproperty will inherit from its parents. In this case it’s best to think of the the parent and the child as one. Therefore when you add the metaproperty to an object, it’s like adding the properties of the parent metaprop, then the properties of the child metaprop.

PokeStim, SlashStim and BashStim all children of WeaponStim (and BugPoke is a child of PokeStim). If an object has a receptron for WeaponStim, it will be activated by any of the child stimuli.

Rooms can also be arranged in a hierarchy. You can add Weather → Local Weather and/or Room → Automap to a parent Room with lots of children that can inherit the property.

Textures have parents such as MetalTex, CarpetTex etc which have the important properties, and the individual textures simply inherit those properties.

By default there are two parents in Flow Groups, water and lava. This is how lava is made to be so deadly. Children of the water group are blue, green and red, which is also poisonous. Look at their properties to see how.

Inheritance is a useful feature, making it easy to create lots of objects which all have the same basic characteristics. If an object is behaving strangely, it could be because of some property it’s inheriting. Hopefully this document should make it easier to understand the Object Hierarchy.