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.png](/w/images/thumb/c/cc/Note.png/10px-Note.png)
![Warning.png](/w/images/thumb/c/cb/Warning.png/10px-Warning.png)
Example
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:
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:
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.