User Inputs and Outputs: Difference between revisions
Jump to navigation
Jump to search
CelolOracv (talk | contribs) m (trocracbocel) |
JordanNolan (talk | contribs) No edit summary |
||
| 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]]. 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 '''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. | ||
Revision as of 21:38, 18 April 2008
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 FireUserN input simply causes the corresponding OnUserN 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.
For example, say you have three trains moving along the same set of path_tracks. 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 !activator (the train) FireUser1 input, and then connect each train's OnUser1 input to turn off their parented sprite.
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).