The Entity Test Request Forum

[dirtyminuth]

Hi everyone!

I have decided to try something out. In an effort to help fellow mappers (and learn more about entities in the process), I will be taking requests for and working on small, entity-focused proof-of-concepts. Here's how it will work:

1. People will post requests for small entity tests / ideas they want to try out but don't have the time (or maybe don't know where to start).
2. I will examine said requests, in first-come-first-serve order.
3. Requests should be reasonable (i.e. not "Make an entire map!").
4. I will work on the proof-of-concept for a couple days and post results (including example maps in vmf / bsp format, if necessary).
5. Repeat until my head explodes.

This is entirely an experiment; I'm hoping it will be well received.

 

[DJive]

I'm going to do so many very wrong things to this thread lol.

First thank you Dirtyminuth.

Second Here is what im trying to do..

I have a CP behind a glass wall. Once glass is broken, it triggers "enable" for the trigger_capture_area and allows capture. That part works fine no problem.

What i want is..

Once the glass is broken, team can capture, once a team captures i want the glass to respawn again, rinse and repeat *once glass is back up it protects the CP, once broken CP can be captured, once captured glass is back up*

I've tried for the last hours to find out on how to get the stinking glass to "respawn" on capture.

any ideas?

 

[MangyCarface]

DJive, this entity is probably your best option: http://developer.valvesoftware.com/wiki/Env_entity_maker

As for the request... I can't seem to get a neutral spawn room to work correctly. I have it set so that there's three cps and each team starts out owning one, where they each have their own spawn room to begin with. I want to make it so that on capturing the second cp, either team will begin to spawn in this third spawn room until the other team captures it back. I've had no luck :c any ideas?

 

[MacNetron]

The following might work:

The func_respawnroom named respawn_neutral.
The info_player_teamspawns grouped named playerspawn_neutral.

For team Red, created "some" outputs on the neutral team_control_point:

[B]Output		Target entity		Input	 Parameter[/B]
OnCapTeam1	respawn_red		Disable
OnCapTeam1	respawn_neutral		Enable
OnCapTeam1	respawn_neutral		SetTeam	 2
OnCapTeam1	playerspawn_red		Disable
OnCapTeam1	playerspawn_neutral	Enable
OnCapTeam1	playerspawn_neutral	SetTeam	 2

Basically the same for Blue.
Note that this is just covering the initial capping. You might need some extra outputs for the case for changing ownership.

 

[MangyCarface]

Yeah, I tried doing the whole set-team thing and it didn't work out. Currently I have 32 players in that room, one set of 16 belonging to red and one set to blue, both associated to the control pt. I then have the cntrl pt change the filter that operates the doors of the respawn room as well as change the respawn room to red/blue as needed. Still no luck.

 

[MacNetron]

Don't use the Associated Control point on the spawns and no team-specifics ones. Set them by capping the Neutral point.

Just with the bunch of outputs:

You spawn at the neutral (orange) spawnpoint, and not in the red one anymore:

Here is the vmf: poc_cp_neutral_spawnroom.vmf

 

[dirtyminuth]

Ok DJ, your request is first on the list and I'll check it out when I get home today

 

[MangyCarface]

MacNetron, thank you very very much for putting that file together really quickly. your solution works great, rep+. You should consider reposting in tutorials for other people to look at!

 

[dirtyminuth]

DJ, got it working. I will only post how to respawn glass here, and leave the CP entities out (minus one reference).

===== Entities =====
logic_auto

func_breakable : window00
<Standard settings>

point_template : window00_temp
Template 1 : window00

trigger_capture_area: cp00_trigger
<Settings not important for glass>

===== I/O =====
logic_auto:
OnMapSpawn > cp00_trigger > Disable > (Delay of 0.1, Fire Once)
OnMapSpawn > window00_temp > ForceSpawn > (Delay of 0.1, Fire Once)

window00:
OnBreak > cp00_trigger > Enable

cp00_trigger:
OnCapTeam1 > window00_temp > ForceSpawn
OnCapTeam1 > cp00_trigger > Disable > (Delay of 0.1)
OnCapTeam2 > window00_temp > ForceSpawn
OnCapTeam2 > cp00_trigger > Disable > (Delay of 0.1)

===== Operation =====
That's about it. You facilitate spawning glass by creating the point_template and having the actual func_breakable as its "child template." When you want to spawn it, you target the point_template with a ForceSpawn input. The gotcha is that you must do this when the map / round begins. I've done that via the logic_auto.

Link to vmf / bsp bundle: http://tf2maps.net/downloads.php?do=file&id=172

 

[dirtyminuth]

Marking DJ's request as completed. Accepting other requests now! Don't delay!

And if you request now, we'll send you two bottles of Orange Clean Free!

 

[DJive]

+Rep, awesome!. works exactly how i had hoped. Man.. so much to learn about damn triggers and entities.

great job and thanks again

 

[Brandished]

Once the glass is broken, team can capture, once a team captures i want the glass to respawn again, rinse and repeat *once glass is back up it protects the CP, once broken CP can be captured, once captured glass is back up*

Just tested this out today and had it working. First, if you have not already done so, name your func_breakable. Then create a "point_template" entity, name it something like "template_01," and under template 1 in its object properties, put the name of the func_breakable. Now goto the trigger_capture_area protected by the func_breakable and add the output:

OnEndCap > template_1 > ForceSpawn

You'll probably want to add a delay for the ForceSpawn with a trigger push / teleport (or something similar...) that clears off the point immediately after being capped so players aren't trapped inside the newly spawned func_breakable.

I've uploaded a sample map using something similar to the above here:
http://www.sendspace.com/file/s6v9sm (61kb, vmf included)

Looks like someone else beat me to it and posted their reply while I was typing my post :3

And now for my question:

Is it possible to strip just one player of a class of their weapons when they enter a certain area of the map? I tried using a trigger_proximity with an output of OnStartTouch > Weapon_Name > Kill, but this removes the weapon(s) listed from everyone else on the map using it as well as the player touching the trigger area. I want just the one player who touches the trigger area to lose their weapons. I'm trying to limit an area of the map to just one class.

 

[MacNetron]

MacNetron, thank you very very much for putting that file together really quickly. your solution works great, rep+. You should consider reposting in tutorials for other people to look at!

thnx! I shall have a look if I can extend it a bit, as for a tutorial it is a bit short

Marking DJ's request as completed. Accepting other requests now! Don't delay!

And if you request now, we'll send you two bottles of Orange Clean Free!

I hope you're not offended I also answered a request? :blush:

 

[dirtyminuth]

Is it possible to strip just one player of a class of their weapons when they enter a certain area of the map? I tried using a trigger_proximity with an output of OnStartTouch > Weapon_Name > Kill, but this removes the weapon(s) listed from everyone else on the map using it as well as the player touching the trigger area. I want just the one player who touches the trigger area to lose their weapons. I'm trying to limit an area of the map to just one class.

Sounds interesting - I'll give it a shot!

I hope you're not offended I also answered a request? :blush:

Of course not! Helping people with entity problems isn't something to be shunned.

 

[dirtyminuth]

And now for my question:

Is it possible to strip just one player of a class of their weapons when they enter a certain area of the map? I tried using a trigger_proximity with an output of OnStartTouch > Weapon_Name > Kill, but this removes the weapon(s) listed from everyone else on the map using it as well as the player touching the trigger area. I want just the one player who touches the trigger area to lose their weapons. I'm trying to limit an area of the map to just one class.

I've been messing around with this and so far no success. Here's what I've tried:

* Creating a trigger_multiple which, when triggered, targets a point_servercommand with the command to "ent_remove_all <Weapon>". This removes <Weapon> globally.

* Creating a trigger_multiple which, when triggered, targets a point_clientcommand with the command to "ent_remove_all <Weapon>". This removes <Weapon> globally.

* Creating a trigger_remove with a filter_activator_class of <Weapon>. This doesn't do anything.

* Creating a trigger_remove with a filter_activator_name of <Weapon>. This doesn't do anything.

One more failed idea:

* Creating a trigger_multiple which, when triggered, targets a point_clientcommand with the command to "ent_remove <Weapon>". This fails with the "FCVAR_SERVER_CAN_EXECUTE" errors for trying to execute sv_cheats and ent_remove on the client.

So, I'm out of ideas for now, going to sleep on it and see if anything comes to mind.

 

[MacNetron]

If you can't strip the weapon, maybe you can remove the ammo? Or will that remove all ammo globally? (melee fight!)

 

[Geuel]

I'm looking for a way to hinder player movement. The idea is for my second map, ctf_hedge_maze.

I want to have gaps in the hedges that players can "shimmy" through, and want to simulate this by slowing their movement.

I would assume that whatever worked for that could be applied to the tops of hedges to simulate sluggish walking on the hedges and would also weaken jumping from hedges.

 

[dirtyminuth]

I'm looking for a way to hinder player movement.
...

I'll gladly take a look at this tonight.

 

[dirtyminuth]

I'll gladly take a look at this tonight.

Tried a couple things to simulate slowed movement in small gaps. Here's the list:

Viable setups:

1. Place a trigger_multiple inside the gap. Use a point_clientcommand to force the player to duck with:
OnStartTouch > [point_clientcommand] > Command > "+duck";
OnEndTouch > [point_clientcommand] > Command > "-duck";

This can be easily circumvented, however, if a player simply binds "-duck" to a key and hits it right after entering the gap. This will grant you full movement ability in the gap. Possible solution is to use a timer to force the player to duck every 0.X seconds.

2. Place two trigger_push entities in the gap, dividing the gap into two areas (when viewed from the top down). The triggers push the player away from the center of the gap. When a player enters the gap, they will move slowly until the get to center, where they will be pushed out the other side. This simulates a player squeezing through a gap and then "popping" out the other side.

This works well when the player is constantly moving. However, if the player stops moving they will continue to be pushed by the triggers. This can be alleviated by reducing the width of the triggers, leaving empty space in the gap. I also tried to disable the triggers when a player stops moving inside, but couldn't get it to work.

Failed setups:

1. Using a single trigger_push that pushes down constantly. Thought maybe it would slow down the player, but it doesn't.

2. Using a trigger_vphysics_motion brush entity. Can't do this because it's not a TF2 entity.

3. Using a func_brush as a floor and using the AddOutput I/O to change its "friction" field to something other than 1.0. Values from -1.0 to 0.1 to 10000.00 don't seem to change anything.

Looks like you're using the point_clientcommand in your hedge maze thread. If you implemented it differently, let me know.

 

[R3dRuM]

In need of the following:

When person grabs intel, person slows speed -50%
When person grabs intel, person cannot be uber'd
When person grabs intel, person jump height -50%

If you cant do the uber part, dont worry about it, just try to reduce speed.
Please and thank you!