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. Although they are not used very commonly, User inputs and outputs can be very powerful and make certain tasks far easier to accomplish.
The OnUserN output simply stores an action that is not performed until it is activated by a corresponding FireUserN input. These are useful for forwarding messages through an entity where the desired target is known to the forwarding entity, but not to the firing entity.
Note:These outputs will fire even on a disabled entity.
Warning:Using FireUserX on 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 by mistake to accept a string parameter, but the parameter sent by the math_counter is a number. You can get around this by using AddOutput, as you can force a dummy parameter that way into the FireUserX parameter field.An example can be found in the Valve map, "sdk_d3_citadel_01.vmf", found in the "sourcesdk_content\hl2\mapsrc" folder. A func_tracktrain (zapperpod1_train) with a func_door_rotating (zapperpod1_rotator) parented to it moves along a path_track (pod_bay_zapper_track).
In the "func_tracktrain" entity's Outputs tab, there's 2 settings:
My Output > Target Entity Target Input Parameter Delay Only Once 
OnUser1 zapperpod1_rotator Open 0.00 No OnUser1 zapperpod1_rotator Close 5.00 No
So basically, when User1 is fired, the "func_door_rotating" will open and, after a 5 second delay, close. To fire this output, one of the "path track" entities, "pod_bay_zapper_track4", has an output of:
My Output > Target Entity Target Input Parameter Delay Only Once 
OnPass !activator FireUser1 0.10 No
When the "func_tracktrain" passes the "path track" entity, it becomes the !activator and its User1 output listed above is fired.
Another Example
Here is another example, from Half-Life 2's d2_coast_08:
A logic_auto is used to tell 3 npc_seagulls with the same target name to fly away. Most mappers would specify each output individually, but using the User Inputs and Outputs, the mapper here was able to do it all with a single FireUser1 output, as shown below:
- "origin" "3349.73 -2612.79 1033"
- "spawnflags" "1"
- "classname" "logic_auto"
My Output > Target Entity Target Input Parameter Delay Only Once OnMapSpawn seagull FireUser1 0 No
- "origin" "3328 -2688 2177"
- "targetname" "seagull"
- "spawnflags" "4"
- "classname" "npc_seagull"
My Output > Target Entity Target Input Parameter Delay Only Once OnUser1 !self FlyAway bird_flightpath_a_48 0 No
- "origin" "3319.87 -2531.21 2177"
- "targetname" "seagull"
- "spawnflags" "4"
- "classname" "npc_seagull"
My Output > Target Entity Target Input Parameter Delay Only Once OnUser1 !self FlyAway bird_flightpath_a_48 12 No
- "origin" "3191.87 -2531.21 2177"
- "targetname" "seagull"
- "spawnflags" "4"
- "classname" "npc_seagull"
My Output > Target Entity Target Input Parameter Delay Only Once OnUser1 !self FlyAway bird_flightpath_a_10 12 No
In this case the FireUser1/Onuser1 was not required, but it did simplify the task at hand. The genius of the system is that you can tell each seagull to do something separately. The first seagull flies to bird_flightpath_a_48 with no delay. The second seagull flies to the same path but waits 12 seconds before doing so. The last one also waits 12 seconds, but flies to a different path bird_flightpath_a_10. All of this is accomplished using one output and one targetname for 3 entities.
