- Dec 12, 2007
- 203
- 47
This guide will consist of 4 parts.
Part 1 is the easy starter and will just show how to make a Control Point (=CP from now on).
In Part 2, we extend our one CP room to a room with 3 CPs, named A, B and C. In Gravelpit-style, A and B together unlock C for capture.
If that is not enough for you, in Part 3 we throw in some logic to unlock C for capture after A OR B has been capped. Now that will teach them not defending C!
For the final piece the resistance, Part 4 will make the room ready for publication by adding final pieces like setup-time and its triggered doors.
[Part 1]
First, create a big room so everything we will build will fit. I've created a 2048x2048x384 sized one. You are of course free to make 3 rooms to 'replicate' the Gravelpit-style, but I've just textured one side Red and the other side Blue (Red and Blue textures by Youme, available on the forum).
Now, a CP consists of a couple of brushes and entities, 4 to be precise (as you can see below):
Lets create a CP.
That is it! You've done it, your CP is ready and fully operational.
Some further explanations. The team_control_point (point 3) is controlling who is the owner of the CP and for instance dependencies. Just have look at the properties. The trigger_capture_area (point 4) is making sure a player inside it, is capping the point if he is allowed to do that at all. The added output triggers a change of the skin of prop_cap_a. It will turn blue (by showing picture number 2) after the event OnCapTeam2 is triggered. Team1 is Red and Team2 is Blue.
Technically speaking, if you look closely who is referring to who, only building the last two would be enough for a CP, but that will not look very TF2-ish.
For the names, I follow the convention: “what is it doing?”_”who/where is it?”. So in this case everything with the same functionality will be “grouped” together in the various pull down menus we will see later on. And of course “a” is just for this tutorial. We could also named it “factory”, but you already guessed that, right?
[Part 2]
Now, for a Gravelpit-style map, we need 3 CPs. As rehearsing is the key concept of learning, do Part 1 another two times. Veterans are allowed to copy two CPs from CP A
Make sure you replace all “a”'s in the names with “b”'s and “c”'s (“Duhh!” I hear you say...).
Now lets look at the properties again for the various parts as there are small adjustments needed. The changes or additions are marked in bold.
Point A (and B but with “b”):
Now our final Point C, I'll hope you say something like – I guessed that!:
Each Index must be unique. We will see why later on. At CP C, we define which CPs are required to unlock capping. In this case, CP A and CP B are required to be capped by Blue, then and only then CP C will be available for capturing.
You can see at the left (blue) side the CPs A and B and on the right (red) side CP C.
Add an info_player_teamspawn for each team and you are able to test the map for both sides.
And we run immediately into problems. When playing Blue, we instantly lose, and when playing Red, we instantly win. We have created a linear CP-game, like Granary and Well. Congratulations, but that was not our goal.
Lets add the final entities to complete Part 2 (Yes, those are the small dots in the middle of my map).
The team_control_point_master draws the Cap Layout on the HUD (with the Indexes, so that is why they need to be uniquely numbered). And it restricts team Red from winning when Red has all CP captured. So only Blue can win by owning all CPs.
Red can only win if the time runs out. To create this, we have a nice combo by team_round_timer and game_round_win. The timer creates a 2 minute (=120 seconds) game and has an output to game_round_win_red. When the timer hits 0, it triggers an OnFinished. With the output-link, it will now raise the event RoundWin on Reds win condition, so Red can now win too.
Part 1 is the easy starter and will just show how to make a Control Point (=CP from now on).
In Part 2, we extend our one CP room to a room with 3 CPs, named A, B and C. In Gravelpit-style, A and B together unlock C for capture.
If that is not enough for you, in Part 3 we throw in some logic to unlock C for capture after A OR B has been capped. Now that will teach them not defending C!
For the final piece the resistance, Part 4 will make the room ready for publication by adding final pieces like setup-time and its triggered doors.
[Part 1]
First, create a big room so everything we will build will fit. I've created a 2048x2048x384 sized one. You are of course free to make 3 rooms to 'replicate' the Gravelpit-style, but I've just textured one side Red and the other side Blue (Red and Blue textures by Youme, available on the forum).
Now, a CP consists of a couple of brushes and entities, 4 to be precise (as you can see below):
Lets create a CP.
1) Create a brush at the bottom with a minimum size of 224 (mine is even 512x384 to create a nice big capture area). Keep its height low, so we can walk onto it. My base is quick and dirty textured with “hazardstrip001a”. I leave it to the reader to create a nicer looking one.
2) Add an entity prop_dynamic and edit its properties:
World Model: models/props_gameplay/cap_point_base.mdl (hint: filter on cap_point)
Name: prop_cap_a
Thats all, move the prop to the middle of the bottom brush.
3) Add an entity team_control_point on top of the prop_cap_a. Properties:
Name: control_point_a
Print Name: A
Default Owner: Red
On the tab Outputs, add a new output with the following settings:
My output named: OnCapTeam2
Target entities named: prop_cap_a
Via this input: Skin
With a parameter override of: 2
After a delay in seconds of: 0 (Click Apply)
4) Last, create a boxed brush with texture “tools/toolstrigger”. Width and length of the bottom box and a height of (in my case) 256. Then tie it to an entity by Tools -> Tie to Entity or just CTRL-T.
Class: trigger_capture_area (click Apply)
Name: team_cap_area_a
Control point: control_point_a
2) Add an entity prop_dynamic and edit its properties:
World Model: models/props_gameplay/cap_point_base.mdl (hint: filter on cap_point)
Name: prop_cap_a
Thats all, move the prop to the middle of the bottom brush.
3) Add an entity team_control_point on top of the prop_cap_a. Properties:
Name: control_point_a
Print Name: A
Default Owner: Red
On the tab Outputs, add a new output with the following settings:
My output named: OnCapTeam2
Target entities named: prop_cap_a
Via this input: Skin
With a parameter override of: 2
After a delay in seconds of: 0 (Click Apply)
4) Last, create a boxed brush with texture “tools/toolstrigger”. Width and length of the bottom box and a height of (in my case) 256. Then tie it to an entity by Tools -> Tie to Entity or just CTRL-T.
Class: trigger_capture_area (click Apply)
Name: team_cap_area_a
Control point: control_point_a
That is it! You've done it, your CP is ready and fully operational.
Some further explanations. The team_control_point (point 3) is controlling who is the owner of the CP and for instance dependencies. Just have look at the properties. The trigger_capture_area (point 4) is making sure a player inside it, is capping the point if he is allowed to do that at all. The added output triggers a change of the skin of prop_cap_a. It will turn blue (by showing picture number 2) after the event OnCapTeam2 is triggered. Team1 is Red and Team2 is Blue.
Technically speaking, if you look closely who is referring to who, only building the last two would be enough for a CP, but that will not look very TF2-ish.
For the names, I follow the convention: “what is it doing?”_”who/where is it?”. So in this case everything with the same functionality will be “grouped” together in the various pull down menus we will see later on. And of course “a” is just for this tutorial. We could also named it “factory”, but you already guessed that, right?
[Part 2]
Now, for a Gravelpit-style map, we need 3 CPs. As rehearsing is the key concept of learning, do Part 1 another two times. Veterans are allowed to copy two CPs from CP A
Make sure you replace all “a”'s in the names with “b”'s and “c”'s (“Duhh!” I hear you say...).
Now lets look at the properties again for the various parts as there are small adjustments needed. The changes or additions are marked in bold.
Point A (and B but with “b”):
3) The team_control_point:
Name: control_point_a
Print Name: A
Default Owner: Red
Index: 0 (and B: 1)
Blue Previous Required Point 1: control_point_a (Yes! Itself!)
4) The trigger_capture_area:
Name: team_cap_area_a
Control point: control_point_a
Can RED Cap?: No
Name: control_point_a
Print Name: A
Default Owner: Red
Index: 0 (and B: 1)
Blue Previous Required Point 1: control_point_a (Yes! Itself!)
4) The trigger_capture_area:
Name: team_cap_area_a
Control point: control_point_a
Can RED Cap?: No
Now our final Point C, I'll hope you say something like – I guessed that!:
3) The team_control_point:
Name: control_point_c
Print Name: C
Default Owner: Red
Index: 2
Blue Previous Required Point 1: control_point_a
Blue Previous Required Point 2: control_point_b
Name: control_point_c
Print Name: C
Default Owner: Red
Index: 2
Blue Previous Required Point 1: control_point_a
Blue Previous Required Point 2: control_point_b
Each Index must be unique. We will see why later on. At CP C, we define which CPs are required to unlock capping. In this case, CP A and CP B are required to be capped by Blue, then and only then CP C will be available for capturing.
You can see at the left (blue) side the CPs A and B and on the right (red) side CP C.
Add an info_player_teamspawn for each team and you are able to test the map for both sides.
And we run immediately into problems. When playing Blue, we instantly lose, and when playing Red, we instantly win. We have created a linear CP-game, like Granary and Well. Congratulations, but that was not our goal.
Lets add the final entities to complete Part 2 (Yes, those are the small dots in the middle of my map).
1) Add an entity team_control_point_master:
Name: team_control_point_master
Cap Layout: 2, 0 1
Restrict team from winning: Red
Switch teams on map win?: Yes
2) Add an entity game_round_win:
Name: game_round_win_red
Team: Red
Switch teams on map win?: Yes
3) Last, add an entity team_round_timer:
Name: team_round_timer
Timer length (in seconds): 120
Max timer length (in seconds): 120
Start paused: No
Setup timer length (in seconds): 10
On the Output-tab, add a new output:
My output named: OnFinished
Target entities named: game_round_win_red
Via this input: RoundWin
After a delay in seconds of: 0 (Click Apply)
Name: team_control_point_master
Cap Layout: 2, 0 1
Restrict team from winning: Red
Switch teams on map win?: Yes
2) Add an entity game_round_win:
Name: game_round_win_red
Team: Red
Switch teams on map win?: Yes
3) Last, add an entity team_round_timer:
Name: team_round_timer
Timer length (in seconds): 120
Max timer length (in seconds): 120
Start paused: No
Setup timer length (in seconds): 10
On the Output-tab, add a new output:
My output named: OnFinished
Target entities named: game_round_win_red
Via this input: RoundWin
After a delay in seconds of: 0 (Click Apply)
The team_control_point_master draws the Cap Layout on the HUD (with the Indexes, so that is why they need to be uniquely numbered). And it restricts team Red from winning when Red has all CP captured. So only Blue can win by owning all CPs.
Red can only win if the time runs out. To create this, we have a nice combo by team_round_timer and game_round_win. The timer creates a 2 minute (=120 seconds) game and has an output to game_round_win_red. When the timer hits 0, it triggers an OnFinished. With the output-link, it will now raise the event RoundWin on Reds win condition, so Red can now win too.
Last edited:
