User Inputs and Outputs

The FireUser1-4 inputs and OnUser1-4 outputs are available on every entity that can receive Inputs and Outputs.
This set of controls are specially linked to work together. Entities receiving the "FireUserN" input will fire its corresponding "OnUserN" output.
Essentially, "FireUserN" and "OnUserN" are exactly the same as "Trigger" and "OnTrigger" that a logic_relay has. Except that you have four of them at once, in every single entity, and they work independent and unrelated to each other.
Valve usually uses this to have one entity trigger the same output to multiple entities, while achieving different outcomes every time because each target tells itself what to do.
One could also use it to avoid using logic_relay when the target should be triggered by multiple entities at different times. As each triggering entity directly tells the target to trigger itself.

Note:These outputs will fire even on a disabled entity.

Warning:Using FireUserX via an output that automatically sends a parameter (math_counter's OnGetValue for example) can cause an error and won't fire it properly. That is because FireUserX was coded (possibly by mistake) to accept a string parameter, but the parameter sent by the math_counter is a number. Make sure to specify dummy parameter in such cases.

Example - Quicker Workflow

The map d2_coast_08 contains a logic_auto that fires the "FireUser1" output to three npc_seagull entities named "Seagull". Those then trigger themselves to fly to a unique destination, at different times.

The logic_auto firing as follows:

	My Output >	Target Entity	Target Input	Parameter	Delay	Only Once
	OnMapSpawn	seagull	FireUser1		0	No

Each of the npc_seagull entities then fire this output, but with different destination name and delay.

	My Output >	Target Entity	Target Input	Parameter	Delay	Only Once
	OnUser1	!self	FlyAway	bird_flightpath_a_48	0	No

One may look at this and think this is silly, as every single output would still need to be defined separately and in three different entities no less.
Surely it would have been easier to just name the seagulls unique names and then let the logic_auto tell each bird to fly anywhere. But you'd be wrong. This is faster to build.

Without FireUserN, the mapper would need to place multiple birds and take the time to give them all unique names. Then the logic_auto's outputs need to be set up for every bird one after another by setting Targetname and Parameter for the destination.
With FireUserN, the mapper needs to set up one single output in the logic_auto to fire to all bird entities at once because they have the same name. Then set up a single bird with its outputs and copy paste it somewhere else. Since every copy has the same name, it already is targeted by the logic_auto, so all that is needed now is to change the destination name in the parameter field. Which can be done quickly if the mapper doesn't close the parameter window.

Another Example

The map d3_citadel_01 contains multiple func_tracktrain (zapperpod1_train) with a func_door_rotating (zapperpod1_rotator) as a child. The func_tracktrains move along a path_track.
The vmf of this map can be found in "sourcesdk_content\hl2\mapsrc\sdk_d3_citadel_01.vmf".

One of the path_track entities, specifically "pod_bay_zapper_track4", the following relevant outputs:

	My Output >	Target Entity	Target Input	Parameter	Delay	Only Once
	OnPass	!activator	Stop		0.00	No
	OnPass	!activator	FireUser1		0.10	No

Once a func_tracktrain passes this path_track named "pod_bay_zapper_track4", the path_track causes the activator, which in this case are all the func_tracktrains, to stop right there and then fire "FireUser1
Each "func_tracktrain" the following OnUserN outputs:

	My Output >	Target Entity	Target Input	Parameter	Delay	Only Once
	OnUser1	zapperpod1_rotator	Open		0.00	No
	OnUser1	zapperpod1_rotator	Close		5.00	No
	OnUser1	playerpod1_vehicle	Open		1.00	No
	OnUser1	playerpod1_vehicle	Close		4.00	No

This whole setup essentially tells every single func_tracktrain to stop, turn the pod around and open its doors. Another entity will cause the pod to continue moving, but that is not relevant to this example of User inputs.
This speeds up workflow as well, as the mapper needs to set this up once, and then just rename the target entities by changing the number on them after pasting them multiple times.

Example - Entities triggering themselves

In some occasions, an entity might be more convenient to trigger itself, rather than having to keep checking on a logic_relay's outputs. One stellar example of that is env_tonemap_controller.
Usually a logic_auto would set various settings of the tonemap controller on map spawn. But it feels a little backwards to have the env_tonemap_controller be in the map, but all the settings for it are stored somewhere else
So for convenience's sake, one might want a logic_auto that fires "FireUser1" to the env_tonemap_controller, which then fires "OnUser1" to itself for all the things it needs to do.

	My Output >	Target Entity	Target Input	Parameter	Delay	Only Once
	OnUser1	!self	SetTonemapRate	0.25	0.00	No
	OnUser1	!self	SetBloomScale	0.2	0.00	No
	OnUser1	!self	SetAutoExposureMin	0.4	0.00	No
	OnUser1	!self	SetAutoExposureMax	1	0.00	No

See also

• AddOutput