the_irate_pirate
04-19-2007, 07:04 PM
This tutorial will teach how to make a player "carry" an object. I hope you already understand how "naming players" goes, if not read this (http://www.dayofdefeat.net/forums/showthread.php?t=71144).
There is an input called "SetParent", which parents (chains) an entity to another entity. However way the 'chained' and the 'parent' entity were situated in regards to one another, they'll remain like that (the exact distance and angle will be maintained). However, there is an input called "SetParentAttachment" which can tell the chained (or parented) entity which point of the parented entity to attach to. I think this input was intended for scripted sequences. Anyways, you can look up attachment points for a model by opening it with the model viewer from SDK tools, then going to the "attachments" tab. Player models have few attachments points but head and one of the arms are definitely there.Also, just know that "SetParentAttachment" is not necessary, only if it really serves your purpose.
Example setup:
trigger_multiple Output tab:
Output #1
Output name: OnStartTouch
Target entities named: !activator
Via input: AddOutPut
Via parameter override of: targetname transporter
delay: 0 seconds
*At this point all we've done is given the carrying player the name of "transporter". For this tutorial let's assume that the object to be parented is an env_spark called "sparkie" (make sure the "StartON flag is checked). There are plenty of things you can parent and attach to a player, like prop_dynamic's or a func_physbox (an object with physics that you can design yourself). Be aware, however, that you can make the "transporter" stuck if you parent a solid object (like parenting and attaching a solid func_physbox to a player's head). Also, just know that "SetParentAttachment" is not necessary, only if it really serves your purpose.
Output #2
Output name: OnStartTouch
Target entities named: sparkie
Via input: SetParent
Via parameter override of: none
delay: 0.2 seconds
*At this point you've parented the object to the player
Output #3
Output name: OnStartTouch
Target entities named: sparkie
Via input: SetParentAttachment
Via parameter override of: head
delay: 0.4 seconds
*Now Mr. Sparkie is really within the "transporter's" head.
Note: All the output's happen one after, in this order, all from the same trigger_multiple (I guess 'naming-the-player' part can happen seperately, but be careful so that multiple people wouldn't end up with the same targetname, but "SetParentAttachment can only work after you've set a parent). If you want the object to appear to be above the player's head, you might have to get creative, for example, make the func_physbox out of visible and invisible brushes or maybe even try to parent one object to another, to another..
I was always going to do something more with this, but then I got struck with a terrible disease. It doesn't have a name or a cure, but it's symptoms include extreme laziness and disinterest towards mapping :D. Now it's up to you - use the newly-gained power until the disease strikes you!
Obviously this method is nowhere near perfect and is prone to errors. First you should try to make sure that once a person begins "carrying" an object (gets the object parented and attached to him), that no other person can touch the trigger and have the objected parented to him all of a sudden. What you could do is set a time limit in which the "transporter" must deliver the object to a certain point and if time runs out, reset the whole thing (for example, rename the "transporter" to "someguy123", make the object to be carried invisible until it is needed again).
I guess you can also try to allow the object to be carried even when the initial "transporter" dies, but that is a lot more tricky. The way to make the map realize that an entity has disappeared (or died, in "transporter's" case) is to have a trigger_multiple fire an output "OnEndTouch" when "transporter" stops touching it (set up a filter_activator_name to check for the trigger_multiple).
I hope this hasn't been confusing. For those of you still wondering as to how you can use this, I'll give just one scenario:
A player enter's a protected building in an enemy's base. He touches a trigger, gets the targetname "xyz" assigned to him and the prop_dynamic "doc" (for secret documents..?) is parented to him. No "SetParentAttachment" is used this time. The player goes back to his own base and finally touches a trigger_multiple that had set up a filter_activator_name to look for an entity name "xyz" and the only dod_capture_area in the map becomes exposed (let's say an invisible floor breaks and exposes it and the round is won), The "transporter" is given a new, bogus targetname, "doc" get the "TurnOff" input and becomes invisible.
There is an input called "SetParent", which parents (chains) an entity to another entity. However way the 'chained' and the 'parent' entity were situated in regards to one another, they'll remain like that (the exact distance and angle will be maintained). However, there is an input called "SetParentAttachment" which can tell the chained (or parented) entity which point of the parented entity to attach to. I think this input was intended for scripted sequences. Anyways, you can look up attachment points for a model by opening it with the model viewer from SDK tools, then going to the "attachments" tab. Player models have few attachments points but head and one of the arms are definitely there.Also, just know that "SetParentAttachment" is not necessary, only if it really serves your purpose.
Example setup:
trigger_multiple Output tab:
Output #1
Output name: OnStartTouch
Target entities named: !activator
Via input: AddOutPut
Via parameter override of: targetname transporter
delay: 0 seconds
*At this point all we've done is given the carrying player the name of "transporter". For this tutorial let's assume that the object to be parented is an env_spark called "sparkie" (make sure the "StartON flag is checked). There are plenty of things you can parent and attach to a player, like prop_dynamic's or a func_physbox (an object with physics that you can design yourself). Be aware, however, that you can make the "transporter" stuck if you parent a solid object (like parenting and attaching a solid func_physbox to a player's head). Also, just know that "SetParentAttachment" is not necessary, only if it really serves your purpose.
Output #2
Output name: OnStartTouch
Target entities named: sparkie
Via input: SetParent
Via parameter override of: none
delay: 0.2 seconds
*At this point you've parented the object to the player
Output #3
Output name: OnStartTouch
Target entities named: sparkie
Via input: SetParentAttachment
Via parameter override of: head
delay: 0.4 seconds
*Now Mr. Sparkie is really within the "transporter's" head.
Note: All the output's happen one after, in this order, all from the same trigger_multiple (I guess 'naming-the-player' part can happen seperately, but be careful so that multiple people wouldn't end up with the same targetname, but "SetParentAttachment can only work after you've set a parent). If you want the object to appear to be above the player's head, you might have to get creative, for example, make the func_physbox out of visible and invisible brushes or maybe even try to parent one object to another, to another..
I was always going to do something more with this, but then I got struck with a terrible disease. It doesn't have a name or a cure, but it's symptoms include extreme laziness and disinterest towards mapping :D. Now it's up to you - use the newly-gained power until the disease strikes you!
Obviously this method is nowhere near perfect and is prone to errors. First you should try to make sure that once a person begins "carrying" an object (gets the object parented and attached to him), that no other person can touch the trigger and have the objected parented to him all of a sudden. What you could do is set a time limit in which the "transporter" must deliver the object to a certain point and if time runs out, reset the whole thing (for example, rename the "transporter" to "someguy123", make the object to be carried invisible until it is needed again).
I guess you can also try to allow the object to be carried even when the initial "transporter" dies, but that is a lot more tricky. The way to make the map realize that an entity has disappeared (or died, in "transporter's" case) is to have a trigger_multiple fire an output "OnEndTouch" when "transporter" stops touching it (set up a filter_activator_name to check for the trigger_multiple).
I hope this hasn't been confusing. For those of you still wondering as to how you can use this, I'll give just one scenario:
A player enter's a protected building in an enemy's base. He touches a trigger, gets the targetname "xyz" assigned to him and the prop_dynamic "doc" (for secret documents..?) is parented to him. No "SetParentAttachment" is used this time. The player goes back to his own base and finally touches a trigger_multiple that had set up a filter_activator_name to look for an entity name "xyz" and the only dod_capture_area in the map becomes exposed (let's say an invisible floor breaks and exposes it and the round is won), The "transporter" is given a new, bogus targetname, "doc" get the "TurnOff" input and becomes invisible.