TTT includes an FGD and several mapping examples. You can extract them from the GMod GCF using GCFScape, or download recent versions below (right click, save as):
If for some reason you really want to manually install things, get a .zip from the Releases section.
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:
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.
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.
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:
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".
This entity can be used to test the role (traitor/detective/innocent) of the !activator. You can use any trigger to send an input to a ttt_logic_role. It will then fire its OnPass output if the player is of the role you specified in the entity, and OnFail if it is not.
The ttt_traitorcheck.vmf example map shows one way to use this entity. You should use it instead of ttt_traitor_check, which is older, less versatile and harder to get working.
This button works much like regular buttons when it comes to entity I/O. However, it is shown only on the HUD of traitors, who can simply aim at it and press their +use key to press it. Hence, it does not need a world model. Traitors can press it from a distance of up to 1024 units.
Unlike regular buttons that have a ttt_logic_role or ttt_traitor_check to prevent innocent players from using them, these traitor buttons are not even visible to innocents. This means they can also not be used as an improvised traitor testing device where innocents tell a player to press the button to see if a door opens.
The ttt_traitorcheck.vmf and ttt_traps.vmf examples have a traitor button in them.
ttt_traitor_checkThe 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.
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.
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.
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:
The entity also fires outputs at certain points in a TTT round:
Turns into a random type of ammo when it spawns.
Turns into a random type of weapon when it spawns. You can set it to spawn some boxes of the matching ammo type.
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.
This entity can be used to give or take credits to/from a player. Upon receiving a TakeCredits input, it will attempt to take the number of credits you specify in the entity from the !activator. If this number is negative, it will give the credits instead. The output OnSuccess is fired if giving/taking the credits was successful, while OnFail is fired if the player had insufficient credits (only occurs when taking credits).
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.
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.
The primary venue for asking and answering questions regarding TTT mapping is the mapping Q&A thread at the forums.