We can provide even more control over which objects or NPCs trigger which event using filters. Filters help to tell a trigger which entities can or cannot affect them. The filter_activator_class entity, for instance, will check the activator's class name against its setting and will only let the trigger fire if the class names match.

The following flowchart will explain the logic of the sequence:

Using the previous example of throwing a rock at a window, create a brush with a window texture and tie it to a func_breakable entity. Name it window01 and in the Flags tab, check the only break on trigger box to ensure that only a triggered input can make it break. Create a trigger brush in front of the window that the rock must pass through. Check only the Physics Objects box in the Flags tab and then create the following output:

OnTrigger, window01, Break, 0.00s delay

Create the filter_activator_class point entity and name it rock_filter. In the Filter Classname property, type prop_physics to allow only prop_physics entities to break the window.

In the trigger_once properties, set the filter parameter to rock_filter to allow the trigger to look for the prop_physics trigger.

Now, we need to create the two different types of physics objects so that we can see the filter in action. You already know about prop_physics entities, but there is another physics object known as a func_physbox entity. A func_physbox or a physbox entity is a brush or group of brushes tied to a func_physbox entity that will respond to the physics engine in the game. Create a prop_physics entity using the rock_forest01b.mdl model, and then create a sphere brush and tie it to a func_physbox entity.

Our trigger_once brush will use this filter to determine which entity name or entity type is allowed to trigger an input. In the trigger_once properties, assign Filter Name to rock_filter.

Our entity setup is now complete and we can test it in-game! You can throw the func_physbox entity at the window until your finger gets a cramp, but it will never break the window because the filter tells the trigger to ignore the incorrect activator. Toss the prop_physics entity at the window; however, the window will break immediately, allowing the rock to pass through to the other side.

Activator_name filters act just like the Activator_class filters except that the filter_activator_name filter looks for a specific entity name instead of a generic entity class. Using the filter_activator_name entity, you can set a trigger's flag to everything to allow all types of entities to activate the trigger. The filter_activator_name entity will only allow entities of a certain name to actually have any effect on the trigger. Look at the example map to see this in action.

Filter_multi entities have the ability to perform logic operations with existing filters. A filter_multi entity will compare up to five existing filters and then decide what the outcome should be. There are four different logic operations that can be performed:

Filter_multi entities are implemented just like the other filter entities such that you enter the filter name into a trigger's filter property.