Now we finally get to the good stuff: designing cubes, buttons, lasers (and associated equipment), and those classic round test chamber doors. The good news is that you won't have to name any of these things except the doors.

“Cube- and button-based testing remains an important tool for science, even in a dire emergency.”
~ The Announcer

Ah, buttons: the quick escape for anyone who doesn't know how to use triggers. There are several button entities to work with:

• prop_button — everyone's favorite pedestal button, used for everything from spawning a cube to shutting down GLaDOS during a stalemate resolution.
  
• prop_floor_button — the 1500 megawatt Heavy-duty Super-collding Super-button. Can be pressed by cubes (including the edgeless safety cube) and players. In the old days, you would've had to fake this with several props, a func_door and a trigger. Now, "everything's been taken care of. Didn't have to. Didn't have to do that."
  
• prop_floor_ball_button — only accepts edgeless safety cubes, which are in fact cubes (specifically prop_weighted_cube with type set to "sphere"). Does not accept players.
  
• prop_floor_cube_button — normally only accepts hexahedral cubes, but can be programmed to accepts cubes of any type. However, the normal behavior of this button type is not enabled by default, so:
  
  
  
  prop_floor_cube_button also does not accept players.
  
• prop_under_button and prop_under_floor_button — the old version of the buttons Aperture used up until about 1990, before Aperture decided to switch to the newer version. In any case these entities function exactly like prop_button and prop_floor_button, respectively. For our purposes of staying with a clean, modern theme, we won't be using these entities right now.

About the pedestal button's special keyvalues:

• Delay Before Reset: if you ever remember seeing a little timer in the Puzzlemaker when you were adjusting one of these things, this is the keyvalue it controlled. Now you can make the pedestal button reset in as little as approx. 0.2 seconds, or as long as you want (i.e. beyond 30 seconds). To make the infinite-time pedestal button, you'll have to approximate with some large number such as 999999999.
  
• Play timer sound?: when you hear that little "thwick-thwick" sound, it's not coming from the timer display, but instead from the button. This should only be enabled for buttons that have finite time values and aren't tied to trivial things such as cube droppers.
  
• Prevent fast reset?: do you remember encountering PeTI maps with a timed pedestal button in them, and then pressing it again and again and again until you felt ready? Setting this to "Yes" will prevent this.
  
• Skin: Clean or Rusted.

The pedestal button sends outputs via these outputs:

• OnButtonReset (this fires an output signal whenever the button pops back out.)
  
• OnPressed
  
• OnPressedBlue/OnPressedOrange (special coop player filters for ATLAS/P-Body, respectively)

The floor button has a changeable button model. There are three models to choose from:

• models\props\portal_button.mdl (clean/normal, the default model)
  
• models\props\portal_button_damaged01.mdl (fully damaged)
  
• models\props\portal_button_damaged02.mdl (partially damaged)

The floor button sends outputs via these outputs:

• OnPressed
  
• OnPressedBlue/OnPressedOrange (special coop player filters for ATLAS/P-Body, respectively; not applicable to cube/ball buttons)
  
• OnUnPressed

Accompanying these buttons will be the prop_weighted_cube, which also has special keyvalues:

• Skin (OLD): select from Standard (blue), Companion, Standard Activated (orange), Reflective (a.k.a. the "Aperture Science Thermal Discouragement Redirection Cube," which is technically more correct, as the cube doesn't reflect anything), Sphere (a.k.a. the "Aperture Science Edgeless Safety Cube"), and Antique (used before Aperture decided it needed sturdier boxes...and decided to make them look pretty).
  
• Cube Type: select from Standard, Companion, Reflective, Sphere and Antique. Preferred to the old skinning method.
  
• Skin Type: Clean or Rusted.
  
• Use new skins: by default this is set to "No," but I recommend setting this to "Yes."
  
• Paint Power: this is one of the flexibilities of working with Hammer: you can have cubes pre-coated with any type of gel (although only the Bounce and Speed gels will work)!
  
• Allow Portal Funneling: if set to its default option of "Yes," cubes, just like players, will be magically guided towards the center of a portal. This will conveniently allow the player to perform special flings on cubes without having to do too much trial & error.

NB In Hammer the cube skins and types won't look correct, but they are guaranteed to appear and act correctly in-game.

Button bases are meant to make your buttons look prettier. You can even recess them into the floor if you want (and not just by a hunky 128 units anymore):



There are several floor button instances lying around in the instances subfolder. Instead of using the instance, I usually just copy and paste the base (it's all just one func_detail) from one of the following files:

• instances\p2editor\floor_button_black_intact.vmf
  
• instances\p2editor\floor_button_white_intact.vmf
  
• instances\p2editor\floor_ball_button_black.vmf
  
• instances\p2editor\floor_ball_button_white.vmf
  
• instances\p2editor\floor_cube_button_black.vmf
  
• instances\p2editor\floor_cube_button_white.vmf

Then I texture the underside with nodraw. The top and sides can be retextured too. Just select all the relevant faces using the Face Edit tool, choose a new texture, and hit "Apply." Signage overlays can be applied to the bases too. Just be aware of this:



1) The overlays have been applied but don't fully appear. Yes, this is even true of the regular button base.

2) A little fix from our old friend the Face Edit tool...

3) ...and now the overlays appear in full again.

Pedestal button bases are easier to create. Just create a nodraw block that's 32×96×8 units. The top can be textured with virtually any floor tile texture, and the sides get textured with a frame texture (rotate by 90° if you need). All that's left is to place your button on top and a descriptive signage overlay or two on the sides of the base.

The associated props (more point entities) are:

• prop_laser_catcher
  
• prop_laser_relay

The laser catcher has a couple of special options:

• Skin Type: Clean or Rusted.
  
• laser catcher model: use for switching between two different model types: the small catcher model shown above (models\props\laser_catcher.mdl), and the large, centered model, as seen in Valve's singleplayer maps (models\props\laser_catcher_center.mdl).

Both of these send outputs via the outputs OnPowered and OnUnpowered. They can be likened to OnPressed and OnUnPressed for floor buttons.

The Aperture Science Thermal Discouragement Beam, or laser, is yet another point entity: env_portal_laser. Special keyvalues include:

• No placement helper: the info_placement_helper point entity helps perfect portal placement, and is embedded into the operation of a few of Aperture Science's equipment, such as the lasers. Default is "No," and this should only be changed if you have a custom info_placement_helper at the end of the laser, perhaps to create a sideways portal, for example.
  
• Laser model: use for switching between two different model types: the small emitter model (models\props\laser_emitter.mdl), and the centered model (models\props\laser_emitter_center.mdl).
  
• Start off?: Yes or No.
  
• Deal lethal damage: because how is this even Science without the potential consequence of death? While "Lethal" will instantly kill with just one touch (and uses a different sound for the laser as well), "Non-lethal" will just burn the player away (but it will still kill them if they persist).
  
• Should auto aim: this option is set to "Yes" by default for the sake of the many of us who are imprecise with our aiming of lasers into their catchers.
  
• Skin Type: Clean or Rusted.

The env_portal_laser entity doesn't have any special outputs, but instead accepts inputs — more about that in a later guide. Meanwhile, you can use the env_portal_laser to control laser catchers and relays.

“Please continue into the next test chamber.”
~ GLaDOS

With all these output devices, I'm sure you're wondering what to control with them. The answer: lots of things! For now, we'll just start with one of those round doors seen at the entrance and exit of every test chamber. The entity to use is prop_testchamber_door.



Before we get into the I/O of this testing element, we need to first go over the door frame. As with floor button bases, I usually just copy and paste the base (it's all just one func_detail) from one of the following files:

• instances\p2editor\door_frame_black.vmf
  
• instances\p2editor\door_frame_white.vmf

The sizes of these door frames are 128×128, but the door will extend beyond that, so make sure to have at least another 64 units on each side (unless of course your door is at the end of some narrow hallway). The sides that the player can see can (and sometimes should) be retextured too (but don't mess with the nodraw stuff that the door touches). Just select all the relevant faces using the Face Edit tool, choose a new texture, and hit "Apply."

Now just put your door into the frame and make the connections using the "Open" and "Close" outputs. The doors can also be locked and unlocked too. In order to make the connections, you need to name it something (e.g. "door1"); we'll use a button for our output device:





The test chamber door has special outputs too, but we won't need then right now. This I/O scheme is sufficient to make the door open whenever the button is pressed (i.e. the player stands on it or when a cube is put on it), and close whenever there is nothing on the button (i.e. whenever the player steps off or a cube is removed).

So now you know how easy it is to create a door. Back in the old days of Portal, you would've had to use two func_doors, two prop_dynamics some prop_statics and an ambient_generic because the door had no sound.

To help associate a button with a door (or any input element such as a hard light bridge with an output element such as a laser relay), use some signage overlays nearby. In the next guide, we'll learn how to create indicator lights, bypassing the need for such signage altogether.

Sometimes the player or an object can get stuck inside a door and not get killed. Here's a little recipe for how to fix this:

Ingredients:

• One invisible-textured func_brush (using the tools/toolsinvisible texture)
  
• One trigger-textured trigger_portal_cleanser (using the tools/toolstrigger texture) with the "Physics Objects" flag checked

Each of these should be 128 units wide, 104 units high, and 8 units thick. Give each of these entities a name and place them in the middle of the door.

Now the door will need to use its outputs to control these:



Though this doesn't exactly resolve the issue of what happens in the (hopefully rare) instance that your player gets stuck inside a door. Fixing that depends on whether or not you want your door to be nice. For more information on that sort of thing, check out this article by Galactic Cafe[web.archive.org] (author's note: the Galactic Cafe website no longer exists. Thank goodness for Wayback Machine!), creator of all those doors in that other awesome Source game we know as The Stanley Parable.

Seriously though, let's cover both possibilities. For the killing door, you'll need a trigger_hurt (same dimensions as the other trigger but with half the thickness, and still centered in the door), with a name and these settings:



Also you'll need to send outputs from the door to this trigger too. For this, you can just copy and paste the I/O going to the trigger_portal_cleanser and change the name ("My Output Named") to the name of your trigger_hurt.



The nice door is a little more complicated to set up. It may also open up unintended solutions in your puzzles, especially in coop. Instead of a trigger_hurt, you'll have a trigger_multiple that's 16 units thick instead of 4 (and yes, still centered and everything). You'll also need:

• Two logic_branches, named separately
  
• A logic_branch_listener, set to listen to each of these logic_branches (they can be set in the keyvalues)

And here's the I/O setup for everything using a button as an input device:




In general, when working with logic_branches and a logic_branch_listener, the logic_branches will only be receiving inputs — not sending any outputs — and the logic_branch_listener will only be sending outputs. A logic_branch_listener receives input not through the usual I/O system, but more directly, via pre-selected logic_branches in its keyvalues.

• Not using a button base. Good work is in the details, people!
  
• Not using a hole for the laser, laser catcher, and/or laser relay. Believe it or not, it looks weird when all we see is a frame nested into a wall (or worse, the floor).
  
• Not using door frames. It's a rather important detail — func_detail, that is.
  
• Forgetting to debug doors. Yes, no one likes getting stuck in a door. Please don't just use a prop_testchamber_door and be done with it. At least use a clipping texture whenever the door closes!

More information from the VDC Wiki:

• Aperture Science's Buttons, designed for use inside of test chambers
  
• Aperture Science Weighted Storage Cube (also the Companion and Edgless Safety variants)
  
• Lasers: can be made deadly upon request.
  
• Test Chamber Doors

The ease of puzzle design is that many things can be prototyped in Hammer, thanks to all sorts of specialized point entities:

• prop_button
  
• prop_floor_button
  
• prop_floor_ball_button
  
• prop_floor_cube_button
  
• env_portal_laser (laser emitter)
  
• prop_laser_catcher
  
• prop_laser_relay
  
• prop_testchamber_door

Please note that there are still some works in progress. This section will be updated as I finish more guides for you!

You are currently viewing part 04/19 in the series.

| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 |

Previous Guide (about sound in Portal 2)
Next Guide (about indicator lights and checkmarks/timers)

Please feel free to leave a well-reasoned question or comment below. Either I or a qualified Test Chamber Associate (you'll know because they make all the good maps on the workshop) will respond. If your question or comment is not well-reasoned, I recommend reading over my guides again until you understand them 100%. No further information is required here or will be provided, and you will become an excellent Test Chamber Designer — using Hammer!