Entity Hierarchy (parenting): Difference between revisions

From Valve Developer Community
Jump to navigation Jump to search
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 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 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]] could be used instead, or use an [[info_constraint_anchor]] to link up with the [[constraint|physics constraint system]].
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]]'''.
== KillHierarchy ==
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 ==
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 Setparent parameter blank, it has the same effect as the ''ClearParent'' input (see below).
* 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. ''Entities must be parented before being sent this input''. The parameter passed in should be the name of the attachment point.  
{{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

Note.pngNote:Entities must be parented before being sent this input.

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

Note.pngNote:Entities must be parented before being sent this input.

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

Note.pngNote:This is the only movement hierarchy-related input that can be fired at the parent-entity.

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.


Template:Otherlang:en Template:Otherlang:en:jp