[Chdata]

In retrospect, the reason the valve wiki says to wait "a frame" is probably directed at mappers firing inputs via entities... who knows what order those actually get fired in when you have a list of different inputs that happen on the same trigger.

In sourcepawn... you can actually control that. ;p

I still have no idea what the difference between SetParentAttachment and MaintainOffset is. I tried both and they seemed to work identically, both teleporting the entity to the attachment point. I have no idea what "offset" they're talking about. How far the position of the child is offset from the parent? Doesn't seem like it, since it just teleports to the attachment point anyway...???

[SoulSharD]

Originally Posted by Chdata I still have no idea what the difference between SetParentAttachment and MaintainOffset is. I tried both and they seemed to work identically, both teleporting the entity to the attachment point. I have no idea what "offset" they're talking about. How far the position of the child is offset from the parent? Doesn't seem like it, since it just teleports to the attachment point anyway...???

I do believe they're identical, though I've only tested them in Team Fortress 2.

[Chdata]

Funny thing, apparently my common stocks .inc had

PHP Code:

AcceptEntityInput(iChild, "SetParent", iParent, iParent); 


Which prevents ClearParent from working properly.

Be sure not to make this mistake ;p


So what do you do to remove particles that linger even if you Stop and Kill them? ("duel_blue" and "duel_red")

PHP Code:

RemoveDuelIcon()
{
    new iDuel = EntRefToEntIndex(g_iDuelTargetEntRef);
    if (IsValidEnt(iDuel))
    {
        AcceptEntityInput(iDuel, "ClearParent");
        TeleportEntity(iDuel, OFF_THE_MAP, NULL_VECTOR, NULL_VECTOR);
        //DelayEntityInput(iDuel, "Stop", 0.05);
        DelayEntityInput(iDuel, "Kill", 0.1);
        g_iDuelTargetEntRef = INVALID_ENTREF;
    }
} 


The "Kill" input has to be sent later apparently, else the entity dies in place and leaves its remnants.

duel_icon particles apparently have a long lifetime which is why the particle persists even after the entity is destroyed.

[friagram]

Set parent does not use attachment points, it uses the origin. If you do to a player it is their feet.
Like you can parent almost any entity to another, like a prop dynamic to a func door.
Set parent attachment uses the attachment points, and offset keeps the original xyz offset from eachother

[Chdata]

Does offset keep the xyz offset from each other based off of an attachment point, or just the origin?

[404UserNotFound]

Ooh, very useful info that'll help me fix some old-ass issues from several years ago involving certain particle effects in TF2 remaining after they're killed. I remember those issues from the old AttachParticle stock that many plugins passed around (had two attachment points, "head" and "back" I think). Circling TF particle for example would remain after being killed. mp_restartgame 1 cleared it right up though.

Not to mention, parenting is also used in that recent Piggyback plugin, so this further info on SetParent/ClearParent is nice to have.

[friagram]

Originally Posted by abrandnewday Ooh, very useful info that'll help me fix some old-ass issues from several years ago involving certain particle effects in TF2 remaining after they're killed. I remember those issues from the old AttachParticle stock that many plugins passed around (had two attachment points, "head" and "back" I think). Circling TF particle for example would remain after being killed. mp_restartgame 1 cleared it right up though. Not to mention, parenting is also used in that recent Piggyback plugin, so this further info on SetParent/ClearParent is nice to have.

Children inherit their parent's attachment points iirc.
You could just parent to a weapon and use an attachment point on the player since it's bonemerged. I forget but I think I used to do this to weapons using the hand attachment for weapons... weapons themselves had no ap.

[404UserNotFound]

Originally Posted by friagram Children inherit their parent's attachment points iirc. You could just parent to a weapon and use an attachment point on the player since it's bonemerged. I forget but I think I used to do this to weapons using the hand attachment for weapons... weapons themselves had no ap.

You always know when to show up and dispense much-needed advice friagram

[Mitchell]

Originally Posted by abrandnewday You always know when to show up and dispense much-needed advice friagram

I have a work example in my WeaponAttachementAPI:
https://github.com/MitchDizzle/Weapo...I.sp#L102-L111
I use it to find the end of a player's barrel by parenting the same weapon model as a prop_dynamic to their player model and using setparentattachment on a info_target to get the abs position from.

[404UserNotFound]

Originally Posted by Mitchell I have a work example in my WeaponAttachementAPI: https://github.com/MitchDizzle/Weapo...I.sp#L102-L111 I use it to find the end of a player's barrel by parenting the same weapon model as a prop_dynamic to their player model and using setparentattachment on a info_target to get the abs position from.

Dude that is pretty damn cool. Specifically the parenting the same weapon model and using an info_target entity to grab the position part.