Entity Hierarchy (parenting): Difference between revisions
m (spam revert) |
(cleanup and added preliminary explainations of related object properties) |
||
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. | |||
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. | |||
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]] should be used instead. | The child-parent relationship is 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]] should be used instead. | |||
==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 [[Inputs_and_Outputs|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 [[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. | |||
== SetParentAttachmentMaintainOffset == | |||
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. | |||
{{otherlang:en}} | {{otherlang:en}} |
Revision as of 11:45, 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 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 should be used instead.
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.