Source 1 Entity I/O: Wire Map Logic Without Code

The Silent Door That Never Opens

You compile a Source 1 map, walk up to a button, press it, and... nothing. No error message, no crash, just a door that stays shut. In Source 1's entity input/output (I/O) system, failures like this are usually silent. A mistyped targetname, an output that does not exist on that entity class, or an input unsupported by your game branch can all prevent logic from firing without telling you why.

The practical takeaway is simple: you can wire most map logic in Hammer by connecting one entity's named output to another entity's input, but you must match names exactly, confirm the input exists for your engine branch, and guard against circular chains. Source 1 only; Source 2 uses a different entity system and Hammer 2.

How Entity Outputs and Inputs Work

An output is a named event an entity broadcasts when something happens—for example, OnPressed on a button or OnDamaged on a breakable. An input is a command an entity can receive, such as Open on a door or Kill on almost anything. When you wire an output to an input in Hammer, you are telling the engine: when the first event fires, send this command to the target entity.

Inputs can carry parameters, delays, and flags that control whether they fire once or repeatedly. The addoutput input is especially powerful because it lets runtime logic change an entity's keyvalues without recompiling the map. That flexibility also means a single misconfigured chain can alter map behavior in ways that are hard to trace after compilation.

Worked Example: Make a Button Open a Door

1. Open the map in Hammer. Create a func_button and set its targetname to button_a.
2. Create a prop_door_rotating and set its targetname to door_a.
3. Select button_a, open its Outputs tab, and add an output:
• Output: OnPressed
• Target entities: door_a
• Via this input: Open
• Delay: 0.00
• Parameter: leave empty
• Fire once: set according to whether the button should work repeatedly
4. Compile the map and run it on a local server. Press the button.

Expected result: door_a receives Open and the door moves. If nothing happens, check that both targetnames match exactly, that prop_door_rotating supports Open in your game branch, and that no other entity is duplicating door_a.

Test Logic Live With ent_fire

Before wiring more outputs in Hammer, you can send inputs directly from the developer console while running a local server:

ent_fire door_a Open

You can also include a parameter and delay as placeholders for your own values:

ent_fire   [parameter] [delay]

Run this in the developer console during a local server session. Depending on the game and server configuration, you may need sv_cheats 1 or host privileges. Only test on a local server: firing inputs on a live production server can change map state, trigger unintended events, or strand players in a broken sequence.

If ent_fire produces no response, the targetname may not exist, the entity may not be spawned yet, or the input may not be supported by that entity class in this branch.

Limitations and a Practical Check

• Circular chains. If button A opens door B, and door B triggers button A, you can create an infinite loop that hitches the server. Guard chains with delays or once-only flags.
• Branch differences. An input available in Half-Life 2 may not exist in Counter-Strike: Source. Do not assume portability across games.
• Duplicated targetnames. Missing or duplicated names cause silent failures in shipped maps.

The most reliable check is to inspect the entity's class definition in your game's FGD or source code before wiring. Confirm the output exists on the source entity, the input exists on the target, and both are supported by your engine branch. Then verify with ent_fire before you recompile.

Start With One Wire

Pick one button, one door, and one output. Match the targetnames exactly, test with ent_fire, compile, and press. Source 1 entity I/O rewards small, verified steps and punishes assumptions.