Entity Hierarchy (parenting): Difference between revisions
mNo edit summary |
m (Clean-up) |
||
Line 3: | Line 3: | ||
A simple example would be parenting a [[light_dynamic]] to a lamp [[prop_physics|prop]] so the light becomes part of the lamp and moves with it. | A simple example would be parenting a [[light_dynamic]] to a lamp [[prop_physics|prop]] so the light becomes part of the lamp and moves with it. | ||
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 | 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 followers! This leads to the rather awkward use of 'parenting' as a reflexive verb throughout the documentation, eg "must be parented", "parent the child to the parent", "entities can have parents", etc. Hey ho. | ||
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 (see [[:Category:Parentable Entities]] for a list). For example, a [[prop_physics]] cannot because it is its own physics object. In this case, use a [[prop_dynamic]] or [[prop_dynamic_override]] instead, or use an [[info_constraint_anchor]] to link up with the [[constraint|physics constraint system]]. | ||
==Parentname== | ==Parentname== | ||
To create a child-parent relationship between two entities, set the ''child''-entity's '''parentname keyvalue''' to the parent-entity's '''[[targetname]]'''. | To create a child-parent relationship between two entities, set the ''child''-entity's '''parentname keyvalue''' to the parent-entity's '''[[targetname]]'''. | ||
== SetParent == | == SetParent == | ||
You can also [[Inputs_and_Outputs|fire]] a '''SetParent input''' at the child-entity to change it's child-parent relationship | You can also [[Inputs_and_Outputs|fire]] a '''SetParent input''' at the child-entity to change it's child-parent relationship. | ||
* Use the ''targetname'' of the new parent as the input parameter to make the child follow the new parent. | * Use the ''targetname'' of the new parent as the input parameter to make the child follow the new parent. | ||
* If you leave the | * If you leave the parameter blank, it has the same effect as the ''ClearParent'' input (see below). | ||
== SetParentAttachment == | == SetParentAttachment == | ||
You can also [[Inputs_and_Outputs|fire]] a '''SetParentAttachment input''' at the child-entity to attach it to a specific [[attachment point]] on its parent. | {{note|Entities must be parented before being sent this input.}} | ||
You can also [[Inputs_and_Outputs|fire]] a '''SetParentAttachment input''' at the child-entity to attach it to a specific [[attachment point]] on its parent. | |||
* The parameter passed in should be the name of the attachment point. | |||
== SetParentAttachmentMaintainOffset == | == SetParentAttachmentMaintainOffset == | ||
{{note|Entities must be parented before being sent this input.}} | |||
You can also [[Inputs_and_Outputs|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. | You can also [[Inputs_and_Outputs|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. | ||
== ClearParent == | == ClearParent == | ||
You can also [[Inputs_and_Outputs|fire]] a '''ClearParent input''' at the child-entity to remove it's child-parent relationship. This simply 'unparents' or 'detaches' the child-entity from its current parent, so the child is then free to move (or not) independently of its former parent. | You can also [[Inputs_and_Outputs|fire]] a '''ClearParent input''' at the child-entity to remove it's child-parent relationship. This simply 'unparents' or 'detaches' the child-entity from its current parent, so the child is then free to move (or not) independently of its former parent. | ||
== KillHierarchy == | |||
{{note|This is the only ''movement hierarchy''-related input that can be fired at the '''parent'''-entity.}} | |||
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; the 'orphaned' children remain in the world to fend for themselves. | |||
Revision as of 13:07, 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 followers! This leads to the rather awkward use of 'parenting' as a reflexive verb throughout the documentation, eg "must be parented", "parent the child to the parent", "entities can have parents", etc. Hey ho.
Only certain entities can have parents (see Category:Parentable Entities for a list). For example, a prop_physics cannot because it is its own physics object. In this case, use a prop_dynamic or prop_dynamic_override instead, or use an info_constraint_anchor to link up with the physics constraint system.
Parentname
To create a child-parent relationship between two entities, set the child-entity's parentname keyvalue to the parent-entity's targetname.
SetParent
You can also fire a SetParent input at the child-entity to change it's child-parent relationship.
- Use the targetname of the new parent as the input parameter to make the child follow the new parent.
- If you leave the parameter blank, it has the same effect as the ClearParent input (see below).
SetParentAttachment

You can also fire a SetParentAttachment input at the child-entity to attach it to a specific attachment point on its parent.
- 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.
ClearParent
You can also fire a ClearParent input at the child-entity to remove it's child-parent relationship. This simply 'unparents' or 'detaches' the child-entity from its current parent, so the child is then free to move (or not) independently of its former parent.
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; the 'orphaned' children remain in the world to fend for themselves.