ttt_damageowner (was: Mappers, tell me about your traps)

[Bad King Urgrain]

I am investigating the possibilities for creating a ttt_trigger_hurt entity to replace the standard one, in order to allow attribution of trap kills to players. For this, I need to know things about how player-controlled traps (or whatever you want to call map-based murdering tools) are set up with regards to entity I/O.

So tell me how your traps work. What entities do they use, what inputs and outputs are involved, what does the whole logic chain look like, etc. Example VMFs would be ideal because then I don't have to manually rebuild things. I'm especially interested in timed traps: traps where a traitor might press a button or trigger something, but the trigger_hurt does not deal damage until a while later, or perhaps it slowly deals damage over time.

The reason I need to know these things is because I want to investigate whether the original !activator (ie. the player pressing the button) is still there when the trigger_hurt is enabled, even when there are timers and delays involved. And of course the same thing for any other non-timed case you might be using.

[Citizen_001]

It might get sort of complicated as far as Temple goes, since the spike chamber trap uses two func_movelinears closing in on each other with 900 blocking damage each. No trigger hurts are involved in that one in particular.

[Bad King Urgrain]

I expect that besides doing things with activators, the trigger hurt replacement will require an input that lets you override who owns the damage it deals (ie. who it should attribute to). That should always allow proper attribution with some entity logic wrangling. It would be the low-level fallback if the basic usage doesn't suffice. For that spike trap it might involve parenting ttt_trigger_hurt entities to the movelinears, and firing their attribution input as soon as a traitor starts up the movelinears, so when they touch a player he will be attributed.

Besides that relatively complex "manual" method, I would like to have the easier option of simply replacing trigger_hurts with a ttt version available and working for common cases. I don't have a good view of what the common case looks like right now. Is it just func_button -> trigger_hurt? Are timers used or trigger_hurts built-in damage over time stuff? That kind of thing is of more interest to me right now than special cases (we'll get to those when the simple ones work).

[JossiRossi]

Made a test map. Here's the .vmf
http://www.filefront.com/17199456/ttt_trigger.vmf

1. Trigger Hurt
Button toggles a trigger hurt that does 10 damage, 20 double.

2. Trigger Hurt
Button toggles a trigger hurt that does 100 damage, 200 double.

3. Trigger Hurt
Button toggles a trigger hurt that does 1000 damage, 2000 double. (I did this because gmod seems to force all damage down to just 50 per "hit")

4. Trigger Hurt
Button toggles a trigger hurt that does 1000 damage, 2000 double after a 5 second output delay.

5. Trigger Hurt
Button triggers a logic_case to randomly select 1 of 2 options both of which toggle a trigger hurt that does 1000 damage, 2000 double.

6. Func_tracktrain
Button activates a tracktrain that will do 50 crush damage, 5 seconds later it deactivates.

7. Trigger Hurt
Button activates a logic_timer that every 5 seconds triggers a logic_relay that will trigger a logic_case to randomly choose 1 of 3 options all of which toggle a trigger hurt that does 1000 damage, 2000 double.

8. Trigger Hurt
A trigger_multiple is activated by a player walking through a cosmetic laser, this will toggle a trigger hurt that does 1000 damage, 2000 double.

Small 0. Explosion
A button activates an env_explosion that does around 100 damage at explosion origin.

Big 0. Cast in the na- info_Manipulate
An info_manipulate will toggle a trigger hurt that does 1000 damage, 2000 double.

Hope that helps.

[Bad King Urgrain]

Thanks, should be very helpful.

[Bad King Urgrain]

I did some testing. Of all those trigger_hurt scenarios, only #7 is problematic in that the logic_timer becomes the activator. A ttt_trigger_hurt should be viable, as that logic_timer case could be made to attribute properly by firing the planned "attribution override" input on the ttt_trigger_hurt that I posted about.

Of course, a trigger_hurt replacement doesn't help for the explosion or tracktrain scenarios. There is a more universal option I would like some opinions on:

A ttt_attribute entity that has an input that basically lets you say: "the damage dealt by the entity <targetname> is in fact caused by this input's !activator". You would make the button that enables the trap fire that input, so that game knows that the button's activator (the player) is the owner of the damage caused by whichever entity (or entities) deals the damage in your trap.

I think such an entity would cover every possible case. It doesn't seem that complex to use either, but I'm not the best person to ask, so I'm asking you instead.

Big 0. Cast in the na- info_Manipulate
An info_manipulate will toggle a trigger hurt that does 1000 damage, 2000 double.

Maybe it was intentionally an info_manipulate (out of ZM compatibility interest) and you already know this, but in a TTT map you should always use ttt_traitor_button instead. Just in case an aspiring mapper sees this map and uses it as example.

[JossiRossi]

Maybe it was intentionally an info_manipulate (out of ZM compatibility interest) and you already know this, but in a TTT map you should always use ttt_traitor_button instead. Just in case an aspiring mapper sees this map and uses it as example.

Shoot, I actually totally forgot you had made your own custom entity for the info_manipulate equivalent, I'll go ahead and fix that just in case.

Also, were there any possible combinations or trap styles I may have missed that you'd like to test before I go in and make that change?

[edit]
That "Attribution Override" entity sounds pretty perfect. I can't think of a single case where whatever would kill the player would not be named, or it would be trivial to name. So for me at least that sounds great.

The only thing I would request on it is the ability to clear the attribution because let's take ttt_digdown as an example. There is a mineshaft that you can easily fall into by accident on your own. However there is also a board that you can shoot the supports of to cause a player to fall to his death. It'd be nice if when the supports are shot (if the !activator can be traced appropriately for gun damage to an entity) then there is a 5 second window where a player falling into a kill trigger would count toward that player, also perhaps the ability to limit to the number of attributed kills so in this case if one person is shot down and 10 people just jump down on their own, only 1 kill gets attributed?

Sorry for the ramble, I just woke up.

[Bad King Urgrain]

Not that I can think of, no. It seems to cover all interesting angles.

[Rectal Exambot]

Would these kills effect Karma?

Would the traitor checker in thething count as a kill if someone placed explosives instead of a battery?

Would pressing the button on losttemple count as a kill if an innocent stood in there?

[Bad King Urgrain]

1) Yes.

2) Notary would be able to set that up, yes.

3) I don't know which button you mean. The goal is to make almost any type of trap count as a proper kill if it's set up for it.

[Bad King Urgrain]

A ttt_damageowner entity is now in the SVN version, with FGD stuff and everything. Garry was talking about a tuesday update again so hopefully there will be one around that time.

JossiRossi, would you mind if I added a modified version of your traps map to the example VMFs that come with TTT? I've made all the traps attribute properly using the entity, so it seems like a good example map.

I'll outline the basics of the entity:
- A "Target entity" property specifies which damage-dealing entity you want to override the damage owner for.

- The SetActivatorAsDamageOwner input will then set the !activator of that input to be the player to which damage should be attributed when the target entity deals it. You'd make a trap-triggering button fire this input for example.

- The ClearDamageOwner input will clear the override again. Only necessary if you want the entity to be able to deal damage that isn't owned by someone.

- Lastly, a property lets you specify how the round report event log should refer to the damage-dealing entity. Lets you do things like "bob was crushed by joe using a giant boulder" for a trap that drops a giant boulder on someone.

[JossiRossi]

Yeah by all means you can include the test map. Glad it was useful.

[Bad King Urgrain]

Cool, it'll be in there.

[Rectal Exambot]

You know how many maps have traitor chambers? The ones on Lost Temple can be activated while an innocent is inside them, if they are innocent and someone presses the button they die, but traitors are allowed to pass to the trap rooms.

Will pressing the button while someone is walking in (which crushes them) count as a kill? Will pressing the button while someone is inside count as a kill (as innocents get stabbed by spikes).

[Bad King Urgrain]

The mapping guide has a bit of information on the new entity: http://ttt.badking.net/mapping-guide

Probably nothing new for those who have read this thread, but the guide now has a download link for the example maps, including the traps one.

You know how many maps have traitor chambers? The ones on Lost Temple can be activated while an innocent is inside them, if they are innocent and someone presses the button they die, but traitors are allowed to pass to the trap rooms.

Will pressing the button while someone is walking in (which crushes them) count as a kill? Will pressing the button while someone is inside count as a kill (as innocents get stabbed by spikes).

This is all up to the mapper.

[Redcow]

I have a trap (http://www.garrysmod.org/downloads/?a=view&id=107813) on that map.

Basically there is a building (This map is a nazi concentration camp) which acts as an "oven".  Now you ask, why would people ever want to go in if you just die?  Well, you don't.

There is a traitor testing machine inside.  It works simply, go in, lights are green, you're good to go.  Lights are red, you're a traitor.  But there's a catch.  If someone happens to find one of the canisters lying around the map and put it in the back of the building where there is a dropoff, it will "enable" the chamber.

People will go in to use the tester and as soon as they step into it the door will lock everyone inside, and the lights will turn off 1 by 1.  Gas will come on, and turn off.  After a second or two everyone will be lit up in flames.

[Blade Nd64]

Not sure how useful this would be now, but there is an old HL2DM map that featured a number of unique traps (which I hold a modified version better suited to TTT). From the mechanics of it, you may find it useful to consider.
While many of these traps are entirely avoidable, players are inclined to risk the danger for the reward of good weapons. By default, most of these traps will trigger should you enter within the danger zone. There are typically buttons that disable the trigger for a short time allowing safe passage. However, there is usually another button that overrides this safety and kills the helpless individual who ventured forth.

Allow me to explain the physical nature of the traps:

Trap 0 - Trigger - Disable/Override Buttons
When this is triggered, a floor will disappear beneath the player either sending him to a trash compactor (func_movelinear) or a laser room (env_laser, which broke in this map with the 2009 engine, fixed in the modified version).

Trap 1 - Trigger - Disable/Override Buttons
When triggered, a ceiling of spikes (func_movelinear) will proceed to impale to the player.

Trap 2 - Trigger - Open Door/Override Buttons
When triggered, two doors will prevent the player from escape (unless they hit the door open button, located inside) while the platform will slide out from beneath him sending him into a radioactive chamber (trigger_hurt). If he manages to survive that, the series of jumps below him will proceed to kill him with fall damage.

Gas Chamber - Trigger - Disable/Override Buttons
When triggered, the chamber will be filled with gas (trigger_hurt) suffocating the player.

Camera Room - Button
When triggered, the floor will slide away sending any players to drop into a rigged maze (Modified version has water in the maze to prevent any fall damage).

Crush Room - Button
A button triggers the ceiling (func_movelinear) to crush any players in that room.

Giant Ball - Trigger
Accessed through teleporters. Consists of a giant ball that continually rolls down a ramp by riding up an elevator at the bottom of the ramp. Possible to evade assuming you have good timing.

Fire Trap - Button
Sets aflame (env_fire) a dead end of a catwalk choked off by a trap.

[Bad King Urgrain]

Of that list, I would say only the trap that makes someone fall would not allow for kill attribution using ttt_damageowner (which is available in the current version of TTT, just to make sure that's mentioned here). However, it seems like it would be possible to work around that using a trigger_hurt that is set to deal "FALL" type damage, and have the player fall through it on his way down (so he would technically be dead before he hits the ground).

Seeing as the entity exists now and should take care of most traps, it's not terribly useful to tell me about traps anymore. I'm more interested in problems/successes people have in actually using ttt_damageowner in their maps. I've changed the thread title a bit in that direction.

---

In the meantime perhaps it's useful to say something about testing it. I personally did this using bots. Here's the basic method: load the map in a "create multiplayer" game, and run something like this in the console:

sv_cheats 1
ttt_debug_preventwin 1
bot_zombie 1
bot_mimic 0
bot;bot;bot;bot;bot

This gets you a bunch of bots. Disabling bot_mimic and enabling bot_zombie will make them stand in place like good test subjects (note: bot_mimic overrides bot_zombie). The trick is then in getting them to the trap:

ent_teleport 2

This will teleport the first bot to the place you are looking at. The "2" is his entity index. When running a local server, 1 is you, the next player/bot to join is 2, and so forth. So by just trying "ent_teleport <next number>" you can one of your bots where you need it.

Then when you want to see if everything worked, you disable ttt_debug_preventwin again and check the events in the round report.

[Redcow]

Of that list, I would say only the trap that makes someone fall would not allow for kill attribution using ttt_damageowner (which is available in the current version of TTT, just to make sure that's mentioned here). However, it seems like it would be possible to work around that using a trigger_hurt that is set to deal "FALL" type damage, and have the player fall through it on his way down (so he would technically be dead before he hits the ground).

Seeing as the entity exists now and should take care of most traps, it's not terribly useful to tell me about traps anymore. I'm more interested in problems/successes people have in actually using ttt_damageowner in their maps. I've changed the thread title a bit in that direction.

---

In the meantime perhaps it's useful to say something about testing it. I personally did this using bots. Here's the basic method: load the map in a "create multiplayer" game, and run something like this in the console:

sv_cheats 1
ttt_debug_preventwin 1
bot_zombie 1
bot_mimic 0
bot;bot;bot;bot;bot

This gets you a bunch of bots. Disabling bot_mimic and enabling bot_zombie will make them stand in place like good test subjects (note: bot_mimic overrides bot_zombie). The trick is then in getting them to the trap:

ent_teleport 2

This will teleport the first bot to the place you are looking at. The "2" is his entity index. When running a local server, 1 is you, the next player/bot to join is 2, and so forth. So by just trying "ent_teleport <next number>" you can one of your bots where you need it.

Then when you want to see if everything worked, you disable ttt_debug_preventwin again and check the events in the round report.

What if the activator is a prop, like in my map, that a traitor places?

[Bad King Urgrain]

Ultimately what you have to do is get the traitor as activator to ttt_damageowner before the damage is dealt. It doesn't necessarily have to be the same I/O chain.

So if the traitor places a prop, you could perhaps make that activate a trigger_multiple around the area, which then fires an OnTouch (not sure which one) because the traitor is in there. You can then hook that up to the damageowner stuff because the traitor will be activator for that output.

Alternatively, you could make the player place the prop and then press a button to activate it. That would be the easiest solution.

So some creative entity I/O can be needed. Sadly there's no way to magically make it work, somehow the game needs to know who caused the trap to happen.