Entity Hierarchy (parenting): Difference between revisions
mNo edit summary |
(added info_constraint_anchor note) |
||
| Line 5: | Line 5: | ||
The child-parent relationship is always defined in the [[HammerObjectPropertiesDialog|object properties]] of the child-entity. The parent-entity doesn't have any say in choosing its children! | The child-parent relationship is always defined in the [[HammerObjectPropertiesDialog|object properties]] of the child-entity. The parent-entity doesn't have any say in choosing its children! | ||
Only certain entities can have parents. For example, a [[prop_physics]] cannot because it is its own physics object. In this case, a [[prop_dynamic]] or [[prop_dynamic_override]] | Only certain entities can have parents. For example, a [[prop_physics]] cannot because it is its own physics object. In this case, a [[prop_dynamic]] or [[prop_dynamic_override]] could be used instead, or use an [[info_constraint_anchor]] to link up with the [[constraint|physics constraint system]]. | ||
==Parentname== | ==Parentname== | ||
| Line 11: | Line 11: | ||
== KillHierarchy == | == KillHierarchy == | ||
If you fire a '''KillHierarchy input''' at the parent-entity, it Removes the parent-entity and all of its children from the world. By contrast, of you fire a '''Kill input''' at the parent-entity, it Removes only the parent-entity from the world and merely 'orphans' its children. | If you [[Inputs_and_Outputs|fire]] a '''KillHierarchy input''' at the parent-entity, it Removes the parent-entity ''and'' all of its children from the world. By contrast, of you fire a '''Kill input''' at the parent-entity, it Removes only the parent-entity from the world and merely 'orphans' its children. | ||
== SetParent == | == SetParent == | ||
Revision as of 12:08, 2 March 2008
When a group of entities are parented together, they form a movement hierarchy family which will move together as if all the entities were one physical object. Each child-entity will follow its parent's movement.
A simple example would be parenting a light_dynamic to a lamp prop so the light becomes part of the lamp and moves with it.
The child-parent relationship is always defined in the object properties of the child-entity. The parent-entity doesn't have any say in choosing its children!
Only certain entities can have parents. For example, a prop_physics cannot because it is its own physics object. In this case, a prop_dynamic or prop_dynamic_override could be used instead, or use an info_constraint_anchor to link up with the physics constraint system.
Parentname
To create a child-parent relationship between two objects, set the child-entity's parentname keyvalue to the parent-entity's targetname.
KillHierarchy
If you fire a KillHierarchy input at the parent-entity, it Removes the parent-entity and all of its children from the world. By contrast, of you fire a Kill input at the parent-entity, it Removes only the parent-entity from the world and merely 'orphans' its children.
SetParent
You can also fire a SetParent input at the child-entity to change it's child-parent relationship:
- If you leave the Setparent parameter blank, you will simply 'unparent' or 'detach' the child-entity from its current parent, so the child is then free to move (or not) independently of its former parent.
- Otherwise use the targetname of the new parent as the input parameter to make the child follow the new parent.
SetParentAttachment
You can also fire a SetParentAttachment input at the child-entity to attach it to a specific attachment point on its parent. Entities must be parented before being sent this input. The parameter passed in should be the name of the attachment point.
SetParentAttachmentMaintainOffset
You can also fire a SetParentAttachmentMaintainOffset input at the child-entity to attach it to a specific attachment point on it's parent. This works exactly the same as the SetParentAttachment input except the child-entity will maintain it's relative position to and distance from the parent at the time it is attached.