Filter system

Sam edited this page Sep 21, 2017 · 2 revisions

The filter system enables you to control continued execution of triggers. You may specify a filter that must be matched in order to allow the event in question to continue, or to stop it.

Usage

Specifying a filter for an entity will make it check if its filter matches its condition before continuing execution. Filters can have different settings that affect how the matching is performed.

When a filter fails to pass, the current event is ignored as though it did not occur. Some entities may still change their internal state regardless.

Shared filter settings

All filters share some settings.

Keyvalue Description
Negate result Whether to negate the result of the operation

Filter types

A number of filters are provided by default.

filter_targetname

Matches the targetname. The entity to perform the comparison on defaults to the activator, but can be overridden to compare with other entities using Input event keywords.

filter_classname

Matches the classname. The entity to perform the comparison on defaults to the activator, but can be overridden to compare with other entities using Input event keywords.

filter_model

Matches the model name. The entity to perform the comparison on defaults to the activator, but can be overridden to compare with other entities using Input event keywords.

filter_damage_type

Matches damage types. More than one damage type may be matched with, and can be combined using either AND or OR logic.

filter_damage_amount

Matches damage amounts. This can match using the following mathematical operations:

> < >= <= == !=

filter_multi

Combines the results of multiple filters, allowing aggregate filters to be constructed.

The results may be combined using either AND or OR logic, and may be further negated using the shared Negate result setting. This means that negated AND would pass if any filter failed, and negated OR would pass if all filters failed.

Adding new filter types

New filters can be added either through modifying the C++ code and adding them there, or by adding them as custom entities.

If extensive use of specific filter combinations is required, it may be easier to create a single custom filter that handles all of the logic by itself, which requires far fewer entities, takes up less memory and is faster to process.

C++ base class

The base class for all filters is CBaseFilter. It provides methods that can be overridden to implement filters for specific types of events.

By default, a filter will pass for all events.

Input filtering

The input filter has the following format:

virtual bool FilterTrigger( CBaseEntity* pSelf, InputData& inputData );

The pSelf parameter is the entity calling the filter. It will match !self targetnames.

The inputData parameter contains all information regarding the input event.

Damage filtering

The damagefilter has the following format:

virtual bool FilterDamage( CBaseEntity* pSelf, const CTakeDamageInfo& info );

The pSelf parameter is the entity calling the filter.

The info parameter contains all information regarding the damage event.

Angelscript base class

The base class for all filters is CScriptBaseFilter. Its behavior is identical to its C++ equivalent.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.