Movement hierarchy: Difference between revisions

From Valve Developer Community
Jump to navigation Jump to search
mNo edit summary
m (restored - my experiment failed!)
 
Line 1: Line 1:
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.
#REDIRECT [[Entity Hierarchy (parenting)]]
 
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 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 [[constraint|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 [[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.
* If you leave the parameter blank, it has the same effect as the ''ClearParent'' input (see below).
 
== SetParentAttachment ==
{{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 ==
{{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.
 
== 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.
 
== 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.
 
 
{{otherlang:en}}
{{otherlang:en:jp|Entity Hierarchy (parenting):jp}}
 
[[Category:Level Design]]

Latest revision as of 07:57, 2 April 2008