[Guide] Payload's Logic

This reference covers what you need to know to deal with the logic of the payload gamemode. We're not trying to reinvent the wheel here, so this is based on the gametype prefab available in ABS's Mapping Resource Pack. I expect you'll use the prefab in your map.

Before starting, be sure you're comfortable with the basics covered in UEAKCrash's Tutorials and the Inputs and Outputs system.



Say hello to the payload.




Say hello to the parts of the payload that matter. And by matter, I mean what's required for the logic to work. Blue team won't be happy with a bare minimum payload since it'll be both invisible and lack a dispenser.


The Payload

trigger_capture_area

• Volume players stand in to push/block the payload.
• Disabling this will stop players from being able to push the payload. If you’re stopping the payload for more than a few seconds, you’ll want to prevent the pushing team from losing during overtime. You do this by disabling the trigger, setting the payload speed to 0 (OnTrigger func_tracktrain addoutput startspeed 0), and enabling the trigger.
• Note: the control point value must be set to the first Red owned control point, otherwise the cart cannot be pushed. The ABS defaults already handle this, but be aware if you're exploring wacky setups.

func_tracktrain

• The ‘train’ that moves along the path. This is where you define the payload’s movement properties, like speed and starting position. You can input commands to this to manually control the payload, or do it through the team_train_watcher.

path_track

• The nodes of the path your payload follows. You can mark these as rollback and rollforward zones, and use entity logic to enable disable.
• Cloning (Shift-drag) this entity will activate a feature used to automatically and quickly create a track. This feature will alter both the Name keyvalue, and the Next Stop Target keyvalue, so that a track is created between the source and the clone. More specifically, Hammer will add a counter after the Name keyvalue of the clone, or increment this counter if it already exists, creating a unique name in a series. If a name is completely omitted, it will simply name the clone "path". If a Next Stop Target keyvalue has been specified, it will also alter this keyvalue of the source, to the name of the clone, resulting in a track being drawn between them.
  
• Note: A payload pushing against a disabled node will not proceed if the node is enabled. You must enable and disable the trigger_capture_area to ‘reset’ the pushing.
• Also note: The ABS Resource Pack includes curved track prefabs for your convenience.
• Extra specially note: It's not uncommon to experience crashes while cloning these. Save often.

team_train_watcher

• Manages the payload pushing logic and hud progress. This is where you tell the game what the payload is, where it starts, where it ends, what the control points are, and where they are. Manual payload control is optional and requires additional entity work.
• Multiple needed if multiround.
• Remember to update if you add/remove control points or the start/end nodes change.

How Does It Work?

1. A player stands within the trigger_capture_area.
2. The trigger_capture_area tells the team_train_watcher how many cappers there are.
3. The team_train_watcher tells the func_tracktrain to move.
4. The func_tracktrain moves along the path_tracks.

If you're planning on making any sort of dynamic element that involves the payload, it's important to understand how these entities work.

Brief overview of func_tracktrain (this video uses func_tanktrain) and path_track (yours will look like a solid white block):


As mentioned before, if a path_track has a name, performing a shift+drag will make a new node in the existing path. You don't need to manually assign their names and targets.


The Important Entities

info_player_teamspawn

• Players spawn here. You ‘move’ spawns forward by enabling and disabling sets of these. Can also associate them with a team_control_point, so the owners of that point will own these spawns.

team_control_point

• The ‘checkpoints’ in payload. Successful capture rewards a point, and team victory requires ownership of all checkpoints.
• Required for trigger_capture_area to push the payload.
• To capture, the func_tracktrain passing a path_track fires an output to change ownership.

team_round_timer

• Controls the game’s timer. Setup time, initial round time, and timer specific outputs are defined here. For example, when the timer runs out, it tells game_round_win to make Red team win.

logic_auto

• Used to configure tf_gamerules at the start of a round.

The Checkpoint

Checkpoints are set within the team_train_watcher. If you ever add or remove a checkpoint, the team_train_watcher, surrounding checkpoints, and new checkpoint must be updated appropriately.


Protip: Click and hold to select something behind the closest object, like for a path_track inside a team_control_point.

How does a checkpoint work?
First, the payload passes the highlighted path_track. The path_track does the following:

1. Sets the cap model to use the blue skin.
2. Stops the payload sparks (this is in case the payload rolls back here).
3. Awards Blue team four minutes of extra time.
4. Disables the path_track behind it.
5. Tells the trigger_capture_area to capture its current control point.
6. Plays the capture bell sound.
7. Sets the owner of the current control point to Blue team.

Upon capture, the team_control_point does the following:

1. Sets the trigger_capture_area's control point to the next one.

Many checkpoints do additional tasks, such as:

• Change team spawning locations.
• Open up previously blocked areas.
• Change directional signs.
• Change team respawn times.

The Finale

For Blue team to win, all that's necessary is to set the final control point's owner to Blue. But that isn't very rewarding, so instead we get a finale. In this example (from ABS), we get a nice explosion once the payload is pushed to the end.



How does a finale work?
Once the payload reaches the final path_track, the path_track fires off its outputs:

1. Play the cart tipping sound.
2. Stop the payload's flashing light.
3. Tell the trigger_capture_zone to capture its current control point.
4. Kill the physics constraint between the func_tracktrain and payload prop.
5. Kill the func_tracktrain.
6. Set the owner of the final control point to Blue.
7. Play the cart beep sound.

The newly freed payload prop gracefully falls down into the pit. Once the payload enters the trigger_once at the bottom, the trigger does the following:

1. Kills the payload prop.
2. Tells the env_shake to shake.
3. Plays the cart boom sound.
4. Starts the explosion particle.

Typically, there's also a trigger_hurt that's enabled upon explosion, killing all players in the immediate area.


The Still Important Entities That Are Justifiably Ignored

game_round_win

• team_round_timer tells this entity to make Red team win when the time runs out.

tf_gamerules

• Gets configured by logic_auto and any mid-round inputs.
• Used to set roles and respawn times.

team_control_point_round

• Defines a round. Needed if the map has multiple rounds.

team_control_point_master

• Global settings for defining a round.

tf_logic_multiple_escort

• Tells the game it’s PLR. That's it.

Outtro

After covering the essential aspects of payload, you should be ready to handle building your own payload map. If there's some cool entity magic you saw in another map, I'd encourage you to take a look at it in Hammer. It's how I learned a lot of what I know.

Any questions? Feel free to ask here.

 

Could you elaborate?

 

Don't beat yourself too much over it. This reference assumes previous knowledge which new guys like you won't have, which isn't helpful. To fix this, I've updated the beginning to include links to two resources that should cover the knowledge needed.