Entities come in two varieties: brush based and point based.

Brush based are entities that are applied to some sort of brush (the blocks and stuff you draw in Hammer with its constructive solid geometry tools). They have volume. For instance, trigger entities are a common type of brush based entity. Triggers fire some sort of output or perform a function when an entity that meets certain criteria enters the volume or volumes denoted by the brush(es) that it is tied to. To make a brush based entity first create the brush that you are going to use (many will need the special tools/toolstrigger texture so that they are invisible) then go Tools --> Tie to entity (or Ctrl + T). Select which kind of entity you want it to be from the drop down box at the top left.

Point-based entities are just that: points. They may be three dimensional for purposes of collision, but Hammer handles them as points. (Don't worry if it doesn't look like the entity is in the correct place from a long distance in Hammer, as the position that the semi-rendered model is is the point entity's actual position) Point entities are placed using the entity tool (Shift + E). Position the cursor in either two of the 2d views or by clicking on the correct spot in the 3d view (depending on where the entity's origin is the 3d view may not be suitable).



Class info tab: This contains all of the properties specific to this entity. Click on a property in the list on the left and change it on the right. If you turn off the SmartEdit button, you can add properties that the designers of it did not intend for you to use (such as the parentname property on spawn points). Do not turn off SmartEdit unless you reaally have to, as the developers did not intend it to be off. I will include examples of entities where it can be useful.

Outputs tab: This is where you add outputs to your entity. Outputs are the primary way your entity interacts with other entities. To create a new output for your entity, click the Add button near the bottom. This creates a blank output with no name, target, or action. The first thing to do is figure out which output you are using. Select a name from the 'My output named' drop down box. If the output you are looking for isn't there, hit the 'Apply' button and look for it again (to update all but the Class panel tab when you change an entity's class you must hit 'Apply'). Next select the target entity from the 'Target entities named' drop down box. If the entity doesn't exist yet, type its name in by hand (and make sure you give that name to something later!). Now that that is done, select the Input on the target from the 'Via this input' drop down box. If the correct input is not there, hit 'Apply'. If it is still not there, make sure the target is of the correct type (to quickly switch to the target's properties box select the output and click 'Mark'). Some inputs require you to enter a string of text. This string will go in the 'With a parameter override of' box.

Inputs tab: This shows a list of all the outputs that are directed at this entity. If you want to edit the input, click 'Mark' and it will open up the entity that is providing the input and switch to the 'Outputs' tab. I infrequently use this tab.

Model tab: Used on entities that use a model. Here you set what it's default animation is and where it starts during that animation. You will probably never use this in Sourceforts mapping.

Flags tab: This is used to set class-specific properties of this entity. For instance, item_suitchargers have two flags: 'Citadel charger' and 'Kleiner's charger'. These were special modes added in for use in HL2, so you probably won't use them in SF. Other entities, such as func_button, have some very useful flags such as 'use activates' and 'damage activates'. These allow players to press the button with E or press it by punting it with their gravity gun, respectively (more on func_buttons and which flags you should use later).

VisGroup tab: This shows which groups of objects this object belongs to. This is the only tab that shows up if you select 'properties' on a straight-up brush. Fairly useless unless you are checking whether brushes are water brushes or not.




func_brush
This entity is essential to both build walls and basic spawn doors. It can be toggled on and off at the behest of other entities. For spawn doors it is combined with a trigger_multiple. This trigger_multiple has its OnStartTouch output keyed to disable the func_brush and the OnEndTouchAll output keyed to enable the func_brush. For build walls use a game_phase_control. The OnBuildPhase output enables, the OnCombatPhase disables. Do not use the OnSwitchPhase output to fire the Toggle input. It doesn't work reliably.

func_button
This is used mainly for block spawners, but can also be used for capture points. The major output you will be using is the OnPressed output. If you set the "Toggle" flag, you will use the OnIn and OnOut outputs for when the button is set and cleared, respectively. Whenever you use buttons you will want the "Use activates" flag set (it is set by default). This flag allows players to +use (default key is 'E') the button. For spawner buttons the "Damage activates" flag is a good option because this lets people punt the button with their GGun from a distance. Unless you want to sort out movedirection, lip, and distance for every button you do, the "Don't move" spawn flag is your friend.

func_nofreeze
Fairly straight forward. This volume represents where one or both teams cannot freeze. Be very sure to set which team cannot freeze correctly! One common mistake is to forget to reset it from its default "Blue can't freeze" state. 011003 has done this on several maps, such as sf_junkyard and sf_vex. func_nofreeze's can have parents, but you need to add the parentname value with SmartEdit turned off. If you do so be very careful because mobile nofreeze zones are griefers' best friends. Good mapping practice is to mark out where the nofreeze zones are with something obvious like a small pedestal that matches the footprint of the nofreeze.

func_flagzone
This is the zone where the owning team will try and bring the opponents' flag to. It usually goes on/around the owning team's flag. The tighter the zone conforms to the flag the harder it is to make cap-but-no-grab flag defenses. Making it significantly smaller than a surrounding nofreeze zone also accomplishes this.

func_disposer
Kills anything that touches it. Parentable via the SmartEdit workaround. Good for getting rid of blocks or making fatal drops. Every map with block spawners should have a build-phase accesible func_disposer so that teams can recycle blocks they have for blocks they need. sf_reservoir does not have a disposer, and this is one of the main reasons it is not played. Be careful where you place disposers because improperly placed or shielded disposers can cause trouble in combat phase. Two examples are sf_infinity and sf_fortfield. In sf_infinity when trying to ramp out over left side it is quite common to accidentally bump the disposer with the block, destroying it until it can be replaced in the next build. And anyone who has played sf_fortfield has accidentally walked into the disposer. One way to avoid the accidental encounter with the disposer is to put a brush with the playerclip texture on it (tools/playerclip or something like that) so as to prevent players from walking into the disposer. sf_infinity does do this, but because it is so thin (1 unit) you can still get players to touch the disposer if you slam them with a block. 8 units should prevent all player-disposer collisions.

trigger_multiple
An important trigger for spawn doors (see func_brush for more info about how to use this for spawn doors). It is also possible to apply filters (in addition to the ones provided by trigger_multiple's flags). This means you could make a blue spawn door that only blue team's presence would open (as only blue would trigger the outputs of trigger_multiple). Be sure that spawn doors only have the "Clients" flag selected, otherwise items such as slams will keep the door from functioning properly.

trigger_hurt
This trigger hurts objects inside it by the specified amount if those objects pass its filter. Useful for spawn doors that exclude the other team (use filter_activator_team).

func_clip_vphysics
This entity is solid to physics objects (grenades, flags, blocks, prop_physics). Its most notable use is on sf_infinity in addition to a nofreeze zone. You should parent these to another entity (via SmartEdit workaround) so that they can be moved out of the way when combat starts (as blocking thrown grenades is generally considered a bad map feature). Possibly use this in conjunction with a non-solid func_brush to denote the boundaries more visibly.


info_player_team_spawn
These are spawn points. Every map should have at least two. There are three key values that are relevant are angles, skin, and parentname. parentname is not available through SmartEdit, and skin should only be selected through SmartEdit as it tells you which team it is for, and without it merely gives you a number. As for orienting the spawn point, only orient/ adjust the yaw. Pitch and roll are ignored.

prop_flag
This is the entity that controls where the flag starts and where it is returned to. It also functions as a small func_nofreeze for both teams (you can't freeze anything inside the flag model). It can be parented, but this is buggy (as it will not move the model or capture zone until the flag has been picked up and returned), so you really shouldn't bother. It can be named for use in point_template/env_entity_maker arrangements to create a one-time placeable flag. It's primary attribute is its team property. Make sure you use the SmartEdit list so as to make sure you don't choose an OOB value. You can have more than one flag per team, but there is really no gameplay purpose to and you would instantly usurp whoever the current lolcow is at the time. Refer to the Wiki for suggestions and rules-of-thumb on where to place the flag (the biggest one is do not require teams to build to it).

light
A static, omni-directional light. It's properties are fairly self explanatory as far as color goes (just click 'Pick color...' and do like you would in MS Paint).

game_phase_control
This fires outputs on phase changes. The OnBuildPhase is fired when build phase begins (but not the first build phase!), OnCombatPhase is fired when combat phase begins, and OnSwitchPhase whenever the phase transitions (but not when the game starts). It can be used for many things, such as freezing func_physboxes when phase changes, toggling build walls, or enabling other entities.

item_suitchargrer
Armor charger. By default it can be used by both teams, so make sure you have the Teams value set correctly. It can be parented to other entities via turning off SmartEdit and adding the parentname field. It can be oriented via its angles values or by rotating it in one of the views.

item_healthcharger
See item_suitcharger.

item_ammo_crate
See item_suitcharger.

env_block_spawner
These make blocks when you fire their Spawn input. Do not use anything else to make blocks as the env_block_spawner is tied into the block limit and any other entity that makes blocks will not refer to the block limit. See sf_euphoria for an example of block spawners that don't use env_block_spawner entities. Set your sf_team_blocklimit to 1 and start pulling blocks off. You'll see that they keep going no matter what. This comes in six flavors, plain, *_2d_1x2, *_2d_1x5, *_2d_2x3, *_3d_1x1, *_3d_1x2. If you can't figure out which spawns what you should buy a gun and shoot yourself. The plain version is old and is mostly still around as a template for the others. To set which type of block it makes select the correct value for Type. Be careful how you design your block spawners though as they will spawn a piece no matter whether there is room or not (resulting in excessive collisions which can cause lag).

Filters
A subset of entities targeted at sorting other entities. These are referenced primarily by trigger entities. Here are some general properties of filters:
Name: For a filter to be referenced it must have a unique name.
Filter Mode: If set to allow, the referencing entity will perform its action when the activating entity passes the filter. If set to disallow, it will exclude the entities that pass the filter (the trigger will take no action).
Filter [property]: The property to screen by. For example, if it were a filter_activator_team this would read 'Filter Team'. The players whose team you select would pass the filter. For the filter_activator_class, only entities whose class (class = type of entity) matches the text will pass.




Prefabs are extremely useful tools for when you are creating a lot of maps or have a complicated structure that you want to replicate, but don't want to remake it by hand and can't use point_template/env_entity_maker (like if you want to repeat interactive structures like block spawners). There are two ways to make prefabs, singular or repeatable.

Other notes: Hammer does not support inserting prefabs with the wild card reference (*) in them. Your map will have buggy effects if your prefab includes a wild card.

Making a singular prefab
Singular prefabs are things that you are only ever going to have one of in a map, or have no entities that need unique names. A perfect example of this would be a flag/flagzone/nofreeze combo, as none of these need names and even if you did name them, you only need one of them in a map. The first step to making a prefab is constructing the entities and brushes that will comprise it. Once you have done that, select all of the bits you would like to turn into a prefab. Temporarily group them for the next step. Find the map's origin (where the blue lines cross) and move the group to it. The origin is where the entity tool's crosshairs will be. For instance, if you had a block 10 units to the right of the origin, the prefab would spawn ten units to the right of the entity tool when you inserted it. Once it is in the correct position, select it and hit the 'Create Prefab' button in the entity tool's options box (by default in the lower right of Hammer). Viola! You're done.

Making a repeatable prefab
Whether a prefab is repeatable or not depends on how its entities are named. If you try the singular prefab, you will notice that every time you insert it the entities have the same name as the original. This can sometimes be good, but if you have things that would interfere with each other, i.e. block spawners, you must add the special tag &i in the names of all the entities that you wish to repeat, preferably at the end of the name, and in the prefab's internal references to those entities. When you insert the prefab into a map, the &i is replaced with a unique integer (1 for the first, 2 for the second, etc.). "But computeraddict," you may ask, "how do I reference every single instance of a duplicated entity?" The answer is simple if you put the &i tag at the end of the name. Simply refer to the group collectively as [name]*, replacing the number with the wildcard symbol, *. For instance, if you wanted to lock all 2x3 buttons on all of the blue spawners you could do something like: "OutputName blue_button_2x3_* Lock". But the wildcard has even more uses! If you wanted to lock all the buttons on the blue spawners, you simply need to change "blue_button_2x3_*" to "blue_button_*" because the wildcard can replace any text! That's all there is to it.




This list is not comprehensive. If you notice a flaw in this overview please post it so I can correct it.

I hope this helps you!