---

Configuring Hammer

Garry's Mod runs on the Orange Box version of the engine, so you will probably want to select Episode 2 in the Source SDK launcher, so that you get the new version of Hammer etc. If Garry's Mod is in the list of configurations, that's good too of course.

TTT includes an .FGD. You can add it in your Hammer options. It will add all TTT weapons (entities start with weapon_zm_* or weapon_ttt_*), ammo, and special entities (which start with ttt_*) to the entity list. It can be found here:

  \garrysmod\gamemodes\terrortown\ttt.fgd

Note that TTT requires CS:S, but does not require Episode 2. Hence you should not use Ep2 materials and models, but you can use CS:S stuff if you want.

---

Running a game

Put the map you want to test in the \garrysmod\garrysmod\maps\ directory.

Start up gmod and click either the Singleplayer or Create Multiplayer option. Singleplayer is generally more convenient.

You should see the gmod game setup window, with a list of maps grouped into categories. One of them should be called "Trouble in Terrorist Town", with all maps starting with "ttt_" or "zm_" in it. One of those map is hopefully yours. If not, just select it from wherever in the list it appears.

Then switch to the third tab (the second being the ungrouped map list), which has some game settings. Most of these concern the sandbox gamemode and can be ignored. The important bit is the gamemode dropdown menu. By default it will probably say "sandbox", so click on it and select the "terrortown" entry that should be in there if you installed correctly. You can put it in either the override dropdown or the other one. It should work equally well.

Now click "start game" at the bottom, as you might expect.

---

Configuring for testing by yourself

TTT assumes you want to play with multiple people, so it will start out in "waiting for players" mode. Use the following commands in the console (enable it if you haven't) to make it playable by yourself:


The first convar prevents a round from ending. You need this because with just you playing it looks like you've won immediately (seeing as no one else is alive).
The second convar sets the minimum required players to one, so that a round will start. This is necessary because things like entity replacement do not occur until a round starts. This convar will be stored for future games once you've set it once (unlike the first convar).

If you manage to kill yourself, force a respawn as follows:
This will respawn you (as an innocent).

If for some reason you need to be the traitor but you're not, use "ttt_force_traitor". There is an equivalent command to become a detective: "ttt_force_detective".

---

Entities

The ttt_traitor_check entity is a brush-based entity meant for detecting traitors within its bounds. You will almost always want to use ttt_logic_role with a standard trigger_* instead of this entity.

If you are sure you want to use this one, send it a "CheckForTraitor" input and it will in turn send a "TraitorsFound" output, that will have the number of traitors whose feet are inside the brush as parameter. You can use it to with a logic_compare and such to do things depending on this value.

The ttt_traitorcheck.vmf example map has a setup where a player presses a button and a sprite turns red or green depending on if there is a traitor or only innocents near the button.

ttt_weapon_check
Use ttt_weapon_check for weapon/metal detectors and such. It checks if there is a player carrying a certain weapon or weapon type inside it. It works much like traitor_check with a few differences. It has two kinds of inputs: "CheckForType" and "CheckForClass". The last one takes a string as parameter, and checks only for the weapon named by that string (it should be a weapon entity name, such as weapon_zm_shotgun or weapon_ttt_c4).

CheckForType checks on a certain type of weapon, which you specify by setting the input parameter to one of the following:
1 = Primary weapons (shotgun etc)
2 = Secondary weapons (pistol/deagle)
3 = Traitor equipment (weapons and items, so c4 and body armor will trigger it)
4 = Grenades
5 = Any of the above (so any weapon the player did not spawn with)

When the entity receives one of these inputs, it will see if there is a player inside it carrying a weapon of the requested type/class. If yes, it fires the output WeaponsFound with "1" as parameter. If not, the parameter will be "0".

The ttt_weapon_check.vmf example map has a setup similar to the ttt_traitor_check example map, with one button testing for primary weapons, and another for C4 specifically.

ttt_win
You can use this item in order to force a win for the traitors or the innocent. Send it a "TraitorWin" input or an "InnocentWin" input, they should be self-explanatory.

I recommend you keep your objectives very simple and straightforward.

ttt_map_settings
This entity can be used to customize certain TTT gameplay aspects. It is a point entity you place in your map, and then configure some settings on that will take effect in-game. It should be straightforward as long as you have the FGD loaded, just place it and take a look.

These are the things you can currently configure:

• Enable/disable the crowbar forcibly unlocking doors you may have scripted to open only under specific circumstances.
• Enable/disable the crowbar doing that with buttons.
• Enable/disable the crowbar forcing movelinear entities to open.
• Specify the player model all players will use instead of the default randomly picked one. Must be a proper path to the model, like "models/player/phoenix.mdl". You can check the garrysmod GCF for more playermodels. To use one of the other ones TTT uses at random by default, use the path I just gave and replace "phoenix" with "arctic", "guerilla", or "leet".
• Enable/disable whether spectators can possess props that have a targetname set (defaults to off)

ttt_random_ammo
Turns into a random type of ammo when it spawns.

ttt_random_weapon
Turns into a random type of weapon when it spawns. You can set it to spawn some boxes of the matching ammo type.

ttt_game_text

Similar to standard game_text, but shows a message in the TTT message area in the top right. You can specify which types of player to send it to (!activator, everyone, traitors, etc), as well as the colour it should have. I recommend you use a colour that is not white, so that players are more likely to notice it and know it is the map telling them something rather than the gamemode.

Lets you attribute the damage dealt by an entity (like a trigger_hurt) to a player. Useful for making traps give score/karma to their user, as well as showing up properly in the round report.

You set the entity of which you want to attribute the damage as the "Target Entity" property of the ttt_damageowner entity. Then you fire the SetActivatorAsDamageOwner input on the ttt_damageowner, and whoever is the !activator of that input chain will be the player responsible for the damage done by the Target Entity.

To change who is responsible for the damage, fire the SetActivator.. output again with a different activator (ie. when someone else presses the button enabling the trap), or fire ClearDamageOwner.

The ttt_traps.vmf example map has a number of trap configurations that correctly attribute damage.

Spectators will be moved to this entity as soon as they stop viewing their ragdoll. If more than one of these exists, a random one is used. The angles of this entity determine the eye angles of the player, ie. where they are facing after being moved here.

This entity is completely optional, and only useful if you have some sort of special spectator area in your map.

---

Spawnpoints

The spawnpoint entity people tend to use is info_player_deathmatch. Technically other spawn ents will work equally well, but there's little reason to use them over that one. Do not use info_player_start, though, as it can cause issues.

Although TTT is intended for 16 to 18 players, many servers have a higher limit, so you might want to consider adding a bunch of extra spawns. Something to consider is that when there are more players than there are free spawnpoints, TTT will dynamically create temporary spawnpoints next to existing spawns. As a result, spawns are best placed in areas where there is some space directly around them, so that when a server runs at a higher playercount than you expect, TTT has room to do its thing.

Questions