User Inputs and Outputs: Difference between revisions

From Valve Developer Community
Jump to navigation Jump to search
mNo edit summary
m (Moved over content from talk page)
Line 1: Line 1:
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 '''FireUser1-4''' inputs and '''OnUser1-4''' outputs are available on every entity that can receive [[Inputs_and_Outputs|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 '''FireUser''N''''' input simply causes the corresponding '''OnUser''N''''' output on the same entity to fire. 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.
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.


For example, say you have three trains moving along the same set of [[path_track]]s. Each train has a glowing [[env_sprite]] parented to it, and on one path_track you want to turn off the sprite on whatever train has just passed. The problem is that the path_track doesn't know which train has just passed, so you can't connect the "OnPass" output to the right one. So, you solve this by connecting the path_track's "OnPass" output to the <code>[[!activator]]</code> (the train) '''FireUser1''' input, and then connect each train's '''OnUser1''' input to turn off their parented sprite.
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).
:&nbsp;
In the "func_tracktrain" entity's Outputs tab, there's 2 settings:


In the past, you could hack around this kind of thing by putting a [[trigger_multiple]] for every train on the path_track, set them to only trigger when the matching train touches them, and use the "OnStartTouch" output to turn off the sprite. Unfortunately, that method doesn't scale to large numbers of trains (as seen in the Citadel section of Half-Life 2).
:{| border=1 cellpadding="2" cellspacing="1"
|- align=left style="background:#DCDCDC; color:black"
!
! My Output > !! Target Entity !! Target Input !! Parameter !! Delay !! Only Once
|-
| [[Image:Io11.png]] || OnUser1 || zapperpod1_rotator || Open || &nbsp; || 0.00 || No
|-
| [[Image:Io11.png]] || OnUser1 || zapperpod1_rotator || Close || &nbsp; || 5.00 || No
|}
:&nbsp;
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:
 
:{| border=1 cellpadding="2" cellspacing="1"
|- align=left style="background:#DCDCDC; color:black"
!
! My Output > !! Target Entity !! Target Input !! Parameter !! Delay !! Only Once
|-
| [[Image:Io12.png]] || OnPass || !activator || FireUser1 || &nbsp; || 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 <code>[[logic_auto]]</code> is used to tell 3 seagulls 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:
:&nbsp;
:"origin" "3349.73 -2612.79 1033"
:"spawnflags" "1"
:"classname" "logic_auto"
:"OnMapSpawn" "seagull,FireUser1,,0,-1"
:&nbsp;
:"origin" "3328 -2688 2177"
:"targetname" "seagull"
:"spawnflags" "4"
:"classname" "npc_seagull"
:"OnUser1" "!self,FlyAway,bird_flightpath_a_48,0,-1"
:&nbsp;
:"origin" "3319.87 -2531.21 2177"
:"targetname" "seagull"
:"spawnflags" "4"
:"classname" "npc_seagull"
:"OnUser1" "!self,FlyAway,bird_flightpath_a_48,12,-1"
:&nbsp;
:"origin" "3191.87 -2531.21 2177"
:"targetname" "seagull"
:"spawnflags" "4"
:"classname" "npc_seagull"
:"OnUser1" "!self,FlyAway,bird_flightpath_a_10,12,-1"
:&nbsp;
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.


[[Category:Level Design]]
[[Category:Level Design]]

Revision as of 22:14, 21 January 2009

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.

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
Io11.png OnUser1 zapperpod1_rotator Open   0.00 No
Io11.png 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
Io12.png 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 seagulls 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"
"OnMapSpawn" "seagull,FireUser1,,0,-1"
 
"origin" "3328 -2688 2177"
"targetname" "seagull"
"spawnflags" "4"
"classname" "npc_seagull"
"OnUser1" "!self,FlyAway,bird_flightpath_a_48,0,-1"
 
"origin" "3319.87 -2531.21 2177"
"targetname" "seagull"
"spawnflags" "4"
"classname" "npc_seagull"
"OnUser1" "!self,FlyAway,bird_flightpath_a_48,12,-1"
 
"origin" "3191.87 -2531.21 2177"
"targetname" "seagull"
"spawnflags" "4"
"classname" "npc_seagull"
"OnUser1" "!self,FlyAway,bird_flightpath_a_10,12,-1"
 

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.