Assigning targetnames to players


the_irate_pirate
02-09-2007, 11:11 AM
Hi, this tutorial will teach you how to 'integrate' players into the Input/Output system. The uses of this are many, even new gameplay modes are possible.

You name a player by having him touch a trigger and giving him the keyvalue targetname via the addoutput input. Here's an example:

Output: OnStartTouch
Target Entity: !activator
Via This Input: AddOutput
Via a parameter override of: targetname abc

And, Presto! Your player can now have inputs sent to him. if the "!activator" is confusing you, take a look here: http://developer.valvesoftware.com/wiki/%21activator

Unfortunately I cannot find a tutorial for the Addoutput input. It is for sure that the AddOutPut input was intended to.. add outputs. But thank god you can also add keyvalues. Like targetname. Or "health". Yes, you can even give players health! But that's a different topic. (Also, an easier way to give players health is to use the SetHealth input).

Here are some uses for this method:

*Using trigger_multiple's in conjunction with filter_activator_name to search for players. (Someone please make a V.I.P. map!)

*Parenting a sprite to a player. For example, you can parent an env_spark to a player, and the spark will follow the player forever (even after the player respawns), unless you assign Sparkie a new parent or send the "ClearParent" command. Don't forget about the SetParentAttachment input. You could parent the spark to a player's head, so it would seem that the player's head is sparkling!

*Use the player_speedmod entity (for your crazy orange maps). You can make the player run at least twice as fast, if not more, by using this entity.

*Random teleporting by using point_teleport and logic_case entities. For help and ideas, look here: http://www.editlife.net/tutorial.php?tutid=52 .

ATTENTION: The player keeps his assigned targetname even after he dies! And if you're not careful, many players could have the same targetname. Which would mean, many players getting the same input that may have been intended for just one player. To work around this, simply assign the player a bogus targetname.

Formologic23
02-09-2007, 11:45 AM
I use a system similar to this to use random spawning hostages in CSS. Works like a charm.

Ca-Chicken-Soup
02-09-2007, 03:43 PM
Very interesting, I must try it sometime

the_irate_pirate
02-09-2007, 04:20 PM
it would be very interesting to see a good mapper like yourself actually use one of these crazy methods.

JossiRossi
02-19-2007, 04:58 PM
Hrm, definitely need to do some tests on how this works but it really looks like it could be a lot of fun.

Furyo
02-20-2007, 12:30 AM
Every article on the addoutput setting should mention that it can be dangerous (as in it can create bugs and crashes.) The wiki is clear on that point.

the_irate_pirate
02-20-2007, 03:47 PM
True, however, as you can see, I'm not using the Addoutput in the way it was intended to. I've never had a crash by using it in these ways.

Dradz
02-20-2007, 08:10 PM
Could this be used to simulate someone picking up documents? You remember in the older versions of dod where one side had to retrieve some documents and the other had to blow the tanks (jagd?)

If not, is there another entity/process that could allow this?

the_irate_pirate
02-20-2007, 09:08 PM
most definitely! here's a sample setup:

1) The player notices the documents (which are a prop_dynamic)
2) Once he gets really close to them, he touches a trigger_multiple, which triggers these 3 events:

a) The player gets assigned a targetname of, let's say, "Transporter1"

b) The prop_dynamic (that was the documents) gets an input that makes it disappear (the player 'picked it up' now..)
b) Version2: the documents prop_dynamic gets parented to the player via input:
SetParent with the override parameter of "Transporter1" (that's what you named the player).

c) A text is shown on screen (via game_text or point_text, whatever) that tells the player that he 'picked up' the documents

3) Now that player must make it to a designated area, an area that contains a trigger_multiple that is looking for an entity named "Transporter1" to touch it. Of course, you must link a filter_activator_name to the trigger_multiple. Once triggered, the trigger_multiple assigns a new targetname to the player that carried the object (YOU MUST DO THIS!) and also triggers any one of these events:

a) An invisible wall, just below the trigger_multiple (func_wall, let's say) is removed and a dod_capture_area is now exposed. The round could end here if you like

b) A totally new objective can now be assigned. Or perhaps just a secondary/bonus objective, before the timer runs out (if you made it so that the team that stole the documents would win the round once the timer expires (since there is only 1 flag)). Also, don't forget about the ability to give players "tick points", of flag points. I forgot how to do it, but it certainly is possible. I think if you decompile dod_jagd, you can find some info about it.


As you can see, the possibilities are almost infinite!

EDIT: Of course, once the player dies, complications arise. To reset the whole process is not difficult, but what is a bit more difficult is how to make the game reset it at the right time (like when the player dies). But here is something you can do:

Once the player that 'carried the documents' dies and respawns, he immediately triggers a trigger_multiple (he still has his unique targetname, remember?) that assigns him a new, bogus targetname and resets the whole process.

However, if you went with the parenting the prop_dynamic to the player method, if you want other players to be able to pick up the object that "Transporter1" dropped when he died, it gets more difficult. You may want to parent a trigger_multiple to the prop_dynamic (the documents)... and I'd really advise against all this because it is prone to failure much more than the other methods. Parenting can be quite awkward.

P.S. Someone please try out all this, it's been a while since I played with hammer. I'm writing all this from memory and I definitely don't want to mislead people. Also, if you are having difficulties with some of this, I can make an example map sometime.

Dradz
02-21-2007, 07:02 AM
an example map would be cool, IP.

once the documents are picked up, does the original trigger multiple automatically go away? or is it already attached to the documents?

the_irate_pirate
02-21-2007, 11:43 AM
Well, I've made an example map. I didn't make it so you could pick up the Object after it's carrier dies. Instead, everything resets. We can work on the details later ;).

ultranew_b
02-21-2007, 04:17 PM
Well, I've made an example map. I didn't make it so you could pick up the Object after it's carrier dies. Instead, everything resets. We can work on the details later ;).

Very Clever !

:)

the_irate_pirate
02-21-2007, 04:43 PM
Thank you, thank you ;) See, the thing is.. almost NOBODY out there knows about this, while I knew about it for such a long time, I feel guilty. I must get people involved in this!

The 'carrying the object' definitely needs work, but if more people understand the concept, maybe we can figure something out.
One thing that I haven't been able to figure out is how to allow other players to pick up the dropped object. Even when I came close to it, it wasn't close to perfect. Whatever the ultimate solution will be, it probably won't involve parenting trigger_multiple's. That method seems so prone to errors.. If only there was a point entity that you could parent to a player and the entity would fire an output when certain conditions changed (like when the player who carried the object died..)

These are the only point entities that have some sort of output that's based on external conditions that changed:

http://developer.valvesoftware.com/wiki/Point_anglesensor
http://developer.valvesoftware.com/wiki/Point_angularvelocitysensor
http://developer.valvesoftware.com/wiki/Point_playermoveconstraint

I was especially hopeful with last entity, the point_playermoveconstraint because it had an OnConstraintBroken Output. Unfortunately, I couldn't get it to fire an Output when the player would die. Maybe a player dying doesn't count as breaking a constraint, I guess.

The 2 entities preceding it are quite beyond me. I was thinking, maybe they would work if they were to track the player's speed. I had heard that the player moves very quickly after he dies (he still exists as an entity after he dies). Maybe then one of the entities could recognize that...

Ca-Chicken-Soup
02-26-2007, 09:40 PM
Perhaps a good way to get interest in this would be to change Flash to a doco map (though it's not really built for it..). A full blown map supporting this would defiantly get attention. Kudos for figuring it out.

Dradz
03-01-2007, 10:52 AM
Could you somehow use the existing detpack entity? Seems when somebody runs over this, it gets picked up, and then when they die, it stays where they die? (or does it dis-appear?)

JossiRossi
03-05-2007, 11:17 PM
I've been trying to get a few things to work with no avail. I wanted to make a player controlled tank. Most of it is doable (although I had a lot of slowdown while testing but that could have been some other issues) basically parenting a prop_dynamic of a tank to the player gets the first part done ok, now the tank goes where the player goes. The player can be slowed down with the player_speedmod entity so he goes tank speed. You can even easily enough make the tank fire in the direction it is pointing by having a button slaved to the tank right in front of where the player should be.

The problem is to have the tank use the angles correctly. It really doesn't want to. every 2-3 seconds the tank will snap to the angle the player is viewing, but if the player looks up the tank points up with it, so the tank will follow the players view, but the transition is instant, so you can whip the whole tank around in a single "update" of it's angles.

Still testing, but I'm done for the night and tired, and maybe a few more heads on the idea would lead to something. Would be cool to see tanks tearing across a map =p

lgdevil
03-06-2007, 03:29 PM
That would be cool and sorely needed for a good wwii game. I've never thought about it before but yeah it's all players with guns right now. Would add a completely new dynamic to the game and really open up things for map designers to have fun with.

I doubt it's possible but sounds like you need to tie the gun to +mlook only and the body of the tank to movement keys. Getting a different speedmod for both the mlook and movement is something I do not envy you on right now.

I suggest when experimenting to create a basic box and do development inside it. Compiles were extremely fast with novis which allowed me to switch back and forth as fast as possible. That's what I did for my destructive environment experimentation. I took that as far as I could because of the engines limitation but that's what experimentation is all about. Hope you get it, that would rock!

fishy
03-08-2007, 05:17 PM
could this idea be adapted to a sort of 'rescue the wounded guys' type of gameplay? maybe some sort of field hospital that needs to be evacuated. a model of a wounded soldier on his back (animated?), and one being carried over a shoulder (same model, 2nd animation?) would seem to be all that's needed.

if only 1 or 2 wounded guys can be carried at any one time, the rest of the team can stay occupied by giving cover to the runners (slowed down by the speedmod thing that was mentioned)
as the wounded guy dies with the carrier, he doesn't need any fancy setups to make him stay pick-up-able. he returns to the field hospital as a new wounded guy.

someone with the right know how could probably make the amount of wounded guys dynamic. the fewer players on the map, the less need to be saved. or more, i suppose, depending on the map.

i don't know near enough about the i/o system to have a crack at this myself, but i can see it's more than possible. i'm also a bit too much of a hack at the modeling side of things to try and get into animating humans. :) i'd be willing to do some mapping though, if anyone else can come up with the entity and model setup.

dmGremlin
03-10-2007, 01:41 PM
I've been trying to get a few things to work with no avail. I wanted to make a player controlled tank. Most of it is doable (although I had a lot of slowdown while testing but that could have been some other issues) basically parenting a prop_dynamic of a tank to the player gets the first part done ok, now the tank goes where the player goes. The player can be slowed down with the player_speedmod entity so he goes tank speed. You can even easily enough make the tank fire in the direction it is pointing by having a button slaved to the tank right in front of where the player should be.

The problem is to have the tank use the angles correctly. It really doesn't want to. every 2-3 seconds the tank will snap to the angle the player is viewing, but if the player looks up the tank points up with it, so the tank will follow the players view, but the transition is instant, so you can whip the whole tank around in a single "update" of it's angles.

Still testing, but I'm done for the night and tired, and maybe a few more heads on the idea would lead to something. Would be cool to see tanks tearing across a map =p

Hey there, I saw this when you posted it but it took me a few days to wrap my brain around Hammer, and then finally this assigning targetnames to players concept.

Are you still working on this? I had a couple ideas, and also a couple questions...

What if you parented the player to an invisible square that was parented to a phys_hinge or phys_ballsocket that was then parented to the tank prop? I haven't tested that, I'm just thinking out loud (since I likely won't be able to attempt assembling a tank for a couple days), but I'm thinking that when the player would look up, in theory the hinge would take care of the upward movement.

What might be really cool is have a big tank made from brushes and textures that had room for a driver and a gunner.

How were you handling the tank gun? I haven't figured out how to make any kinds of external guns, and player guns wouldn't really work for a tank.

BTW: Big thanks to everyone posting in the tutorials this last week, I've made some pretty cool stuff in the last few days (mostly training map related) thanks to all the info and discussion, and I'm going to share when I get it fully tested and packaged - cheers :)

-D. M.

l3eeron
03-11-2007, 10:17 AM
I was thinking, I need this in addition to the strip/equip/button/prop steup I have to give weapons. How do I tell the strip and equip entities to only target the activating player? What are the I/Os I need to set up?

l3eeron
03-11-2007, 10:26 AM
I've been trying to get a few things to work with no avail. I wanted to make a player controlled tank. Most of it is doable (although I had a lot of slowdown while testing but that could have been some other issues) basically parenting a prop_dynamic of a tank to the player gets the first part done ok, now the tank goes where the player goes. The player can be slowed down with the player_speedmod entity so he goes tank speed. You can even easily enough make the tank fire in the direction it is pointing by having a button slaved to the tank right in front of where the player should be.

The problem is to have the tank use the angles correctly. It really doesn't want to. every 2-3 seconds the tank will snap to the angle the player is viewing, but if the player looks up the tank points up with it, so the tank will follow the players view, but the transition is instant, so you can whip the whole tank around in a single "update" of it's angles.

Still testing, but I'm done for the night and tired, and maybe a few more heads on the idea would lead to something. Would be cool to see tanks tearing across a map =p

Ive been workng on something similar. I gave up cuz the the tank looks stupid moving down the street with no treads or wheels turning.

Here's how I did it

I made a func_tracktrain with a path. Then parented a prop_dynamic of a tank to the train. It controls like an HL1 train and stays on its path. You can then parent a bomb_target to the back of the tank and make it a det objective =). But I trashed the idea cuz theres no way in hell i can make an animated tank model.

the_irate_pirate
03-15-2007, 03:32 PM
Hey guys, you know you could just make a map with a train. Vehicles will never work well in DoD:S. I got an idea: how about a map set in a train station? Anyone played Call of Duty 1? There was an awesome level from the single player campaign.. I hope someone makes a map like that. Just make sure there is plenty of cover for the defending side. Also, I think it would be nice to allow the attacking army to jump out of the train before reaching the stopping point. i.e. have the train slow down gradually so the attackers wouldn't be naded, sniped or gunned down as soon as they can touch the ground.

Punish
04-05-2007, 06:51 PM
I was wondering that myself Pirate, making a train depot. I have been making a map that has a train depot in it like a train layout. Once it's finished I'll post the link to download it. I wished you could get the trains to move unless someone knows how? :)

the_irate_pirate
04-19-2007, 06:10 PM
well it's really not hard to make trains. you can also make them start or stop moving whenever you like. interlopers.net is all you need: http://www.interlopers.net/index.php?page=hl2-entities.php (read the tutorials about elevators, same concept)

$INNER
04-19-2007, 06:23 PM
This has nothing to your concern but, hey what I have is loud noise with what i'm saying and my voice is really low even though I turn up the volume all the way up. Also whenever I test my mic on DOD, what ever sound I make it will continously repeat the same noise (louder and Louder)!!! Any IDEA?

the_irate_pirate
04-19-2007, 09:44 PM
That's right, this really has nothing to do with this thread, I have no idea why you even posted here. Sorry, I won't help you.

l3eeron
07-23-2007, 05:53 PM
I gotta question IP....

I have a decent "weapon-pickup" set up. I have it set up to when the player picks up the zook, it fires the game_player_equip and also gives the player 10 weapon_m1carbines. It works great! Until the player picks up a second zook, wich fires the game_player_equip again and carbines spill out on the ground everywhere cuz the player has been maxed out.

So I want to name the player, then have a filter on the weapon_bazooka, that way they dont get to pick up the weapons more than once per life...

is there a way to acheive this? Can you clear the !activator's targetname upon death? What do you suggest sir

the_irate_pirate
09-22-2007, 02:54 PM
l3eeron, I suggest that you set it up so the players either spawn into a trigger or must walk past one that will give them a new targetname (but can't return to it until they respawn). When they go to the trigger-weapon-setup, they get their new weapon and get assigned a targetname that will prevent them from getting a new set of weapons.

l3eeron
09-24-2007, 08:42 AM
Ahhhh, didnt think about putting it somewhere that can only be touched once.... lol some things are just too obvious for me!

Thank you

the_irate_pirate
09-24-2007, 12:57 PM
anytime :)

smashingpunk007
09-29-2007, 12:32 PM
i tried your sample map and once the player dies, the newspaper is back to the original spot but its invisible. is there a way to fix that?

the_irate_pirate
10-02-2007, 04:42 PM
I'm not sure. For one, the newspaper never really moves. It's only an illusion that it moves. What you could do is create a trigger_multiple in the spawnpoint and make it send the 'turn on' input to the newspaper as soon as it detects the 'transporter1' player entity.

Day of Defeat Forum Archive created by Neil Jedrzejewski.

This in an partial archive of the old Day of Defeat forums orignally hosted by Valve Software LLC.
Material has been archived for the purpose of creating a knowledge base from messages posted between 2003 and 2008.