How It Works:If you are unfamiliar with anything below, please refer to the Developer Wiki. This system makes use of AddOutput, OnUser1-4 and FireUser1-4 to have the players keep track of their own entities. Each spawn point has a trigger, a logic\_branch for each level and a logic\_branch\_listener to keep track of them. The triggers are filtered to ignore any entity with a name beginning with "player", and when a player triggers the trigger, their name is set to player1 ("1" will be whichever spawn point it is, e.g "player2" for the second spawn point). All spawn triggers will then ignore any player who has already touched a spawn trigger. The other outputs on the trigger add outputs to the player who touched the trigger (the !activator) to set each branch to true when the relative output is fired. OnTrigger, !activator, AddOutput, OnUser1 branch1_t1:SetValue:1:0:-1 adds the output: OnUser1, branch1_t1, SetValue, 1, 0, -1 to the player who touched the trigger. Then when the player's FireUser1 input is fired, it will do whatever we told it to do in its OnUser1 output (FireUser1 -> OnUser1, FireUser2 -> OnUser2 etc). In this case it sets the player's first logic\_branch to true. As you may have guessed already, the teleport at the end of each stage does the above. When a player triggers the teleport, their FireUser# input is fired, which then sets the linked branch to true, indicating that the level has been completed. Doing it this way instead of adding to a counter means that when the player finishes the level again, the branch is still true, but with a counter you'd still increase it (we can't filter the player name for the teleport as we can't change it, else other things will go wrong). Why can't we change their name? Well, for one, they would be able to trigger the spawn triggers again which would enable them to control multiple sets of branches at once (as we can't remove the outputs we added with AddOutput and they don't reset) and possibly mess with other people (this could possibly be worked around by keeping the spawn separate in some way). Secondly, when the logic\_branch\_listener finds that all the branches are true, and thus the player has finished, it can't reference the player without their name (how can we tell which player's listener it is? There's no hierarchy!). With a consistent player name, when the player has finished, we can 'teleport' them to the end area using their name. Usually you would do this by changing their name to a filter allowed by an ending trigger\_teleport, but we can't change their name. To get around this, we need to use somewhat of a little trick by directly setting the player's origin property to where we want them to be. If you look at a branch listener, you'll see the output "OnAllTrue, player#, AddOutput, origin x y z". This sets their position to the coordinates x y z. You'll need to change these coordinates to your ending area if you use this prefab. To get an entity's coordinates, select it and look at the bottom right of Hammer (eg 16w 16l 16h @(-128 128 8)).
How To Use:Each spawn needs the 1 trigger, 4 branches and 1 branch listener. To add more spawns, copy the group of entities around the info\_player\_terrorist. Some of the names should work with automatic renaming if you use Paste Special to paste the copies. It should be obvious which names to change, but if it isn't: Spawn 1 -> New spawn (3)
branch1(-4)\_t1 -> branch1(-4)\_t3
branchListener\_t1 -> branchListener\_t3 Outputs:
OnAllTrue, player1, ... -> OnAllTrue, player3, ...
OnAllTrue, branch1(-4)\__t1, ... -> OnAllTrue, branch1(-4)\_t3, ... (trigger)
OnTrigger, !activator, AddOutput, targetname player1 -> targetname player3
OnTrigger, !activator, AddOutput, OnUser1 branch1(-4)\_t1:SetValue:1:0:-1 -> OnUser1 branch1(-4)\_t3