Estaĵa Hierarko (generintigo)

This page needs to be translated.
This page either contains information that is only partially or incorrectly translated, or there isn't a translation yet.
If this page cannot be translated for some reason, or is left untranslated for an extended period of time after this notice is posted, the page should be requested to be deleted.
Also, please make sure the article tries to comply with the alternate languages guide.

Kiam grupo da estaĵoj estas generintiĝis kune, ĝi formos malmola movo hierarkan familion kiu movos kune kvazaŭ se ĉiuj estaĵoj estis unu aĵon. Ĉiu estaĵido sekvos moviĝon de ĝian generinton.

Simpla ekzemplo estas generintigi light_dynamic(en) lampon rekvizito(en) do la lumo estiĝos parton en la lampo kaj moviĝos kun ĝi.

Noto:La ido-generinto rilataĵo ĉiame difinis en la aĵaj agordoj(en) de la estaĵido. La generinta estaĵo ne havas ajn povon en deĉidi ĝiajn idojn. Tiu ago kaŭzos mundan uzon de 'parenting' tiel refleksivan verbon tra priskribo, ekz. "must be parented", "parent the child to the parent", "entities can have parents", cetera. (en nur )

Ĉiaj estaĵoj povas havi generinton, kvankam multaj estaĵoj ne inkludas ĝiaron en siaj tajpaĵoj de FGD(en) kaj ĝi eble ne funktus korekte.

Ekzemplo:prop_physics(en) behave oddly when parented because they are physically simulated objects, and a logic_relay(en) for example isn't visible or moves on its own, so parenting it would have little effect. For prop_physics, it's generally better to use a prop_dynamic(en) or prop_dynamic_override(en) instead or use the physics constraint system(en).

Averto:Ekzistas limo de 512 estaĵoj permesitaj en 1 generinta hierarko/ĉeno.

Faru: Kio okazos se tiu ĉi limo pasita?

Ida Funkto

• The Offset is the distance (and any rotational offset) between the Child and Parent entities at the time the relationship is activated. Whilst the offset is maintained, the Child will move parallel to its parent's movements, and "orbit" the parent's origin at the offset distance when the parent rotates. Only the SetParentAttachment input changes the offset; it instantly "teleports" the child to the parent's attachment point and holds it there instead.

• Collision : Physics simulation will no longer occur for children, causing them to potentially pass through walls or other solid objects if the parent moves them there. Scripted movements such as animations or brush-based entities will still occur, so you can chain different brush entities together to form a complex moving contraption.

• Se la generinto mortita, ĉiu ido ĝia nuna ankaŭ malkreota.

• Se ido ne difinis funkton por enluda interago (+USE) aŭ tuŝigo tiujn resendiĝos al la generinto. Tiu ago povigas vin generintigi prop_dynamic(en) al func_button(en) kaj kapablos la ludiston uzu +USE al la modelo interagi kun ekz-e butono.

Parentname

Krei rilateco ida-generinta inter du estaĵoj, asigni la ŝlosilasignaĵon parentname de ido-estaĵo al targetname(en) de la generinta estaĵo. La generinto povas ankaŭ esti ŝlosvorton kvazaŭ !activator(en).

• Maintains offset.

Erareto:The parent field does not work correctly for some entities in CS:S(en). Instead, use a logic_auto(en) and call SetParent at the start of the map  [todo tested in?]

Erareto:Children may lose their parents on HL2:DM(en) Linux Dedicated Server. It is highly recommended to use a logic_auto(en) with the output OnMapSpawn child SetParent parent instead.  [todo tested in?]

• Additionally, an attachment(en) point can be set by setting the value to parent,attachment. This can be used to have an entity follow an animated part of the model, such as the Howitzer handle in . It behaves like SetParentAttachmentMaintainOffset.
  For example: Howitzer_prop,Handle

The Howitzer handle, as separate prop, following the "Handle" $attachment(en) of the Howitzer model.

SetParent

You can also fire(en) a SetParent input at the child-entity to change its 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).
• Maintains offset.

SetParentAttachment

You can also fire a SetParentAttachment input at the child-entity to attach it to a specific attachment(en) point on its parent. The parameter is the name of the attachment point.
Entities must be parented before being sent this input. Use at least a 0.02 second delay between SetParent and SetParentAttachment input, to ensure they run in the right order.

• The child entity will automatically copy location and rotation of the attachment point.

Your child entity will align its location and axis with the parent models attachment location and axis. You can find out the attachment location and axis by loading the model in HLMV(en).
The only way to change this is by either recompiling the parent model to change its attachments, or recompiling the child model to change its entire rotation.

A Personality core in Portal following an $attachment(en) of the GLaDOS model using SetParentAttachment.
As you can see, the Sphere has its axis shown in hammer, GLaDOS has her attachments axis shown in HLMV.
The sphere aligns its axis with the axis of GLADOS' Attachment point.

SetParentAttachmentMaintainOffset

Noto:Entities must be parented before being sent this input. Use at least a 0.02 second delay between SetParent and SetParentAttachmentMaintainOffset inputs, to ensure they run in the right order and attach at the right spot. Shorter delays cause the entities to not have the proper offset.

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.

• Maintains offset, but the Child shadows/orbits the attachment point position instead of the parent's EntityOrigin(en).

ClearParent

You can also fire a ClearParent input at the child-entity to remove its 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

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

If you fire(en) a KillHierarchy input at the parent-entity, it removes the parent-entity and all of its children from the world.

• If you fire a Kill input at the parent-entity, its children will be detected and eventually also destroyed, logging a warning in the console. This happens almost immediately, but it may be possible for other logic or outputs to be executed before they're fully cleaned up.

Erareto:If you have a point_spotlight(en) child of another entity, and you kill the parent entity without removing the point_spotlight using an input, it will spawn in the center of the map (0,0,0) facing north.  [todo tested in?]

Alternatives

A few "alternatives" exist to the standard entity hierarchy system. They may be suitable for specific purposes or are specialized to a particular set of entities.

• Physics Constraints(en) are designed to constrain physically simulated entities like prop_physics. They can wobble, break, and do various other cool things.
• logic_measure_movement(en) causes an entity to mimic the movements of another with room for flexibility. You could use this to move entities that cannot usually be parented, like logic entities or physics props.
• prop_dynamic_ornament(en) takes advantage of bonemerging, the same system weapons use to attach to their owners' hands. This still uses parenting under the hood.

Programmers can also use FollowEntity()(en) to take advantage of bonemerging without having to use prop_dynamic_ornament.