“These inter-dimensional gates have proven to be completely safe. The device however, has not.”
~ GLaDOS

Autoportals are super-easy to make. You remember them, right? They're those colorful ovals that don't move and are "attached" to a frame. The ingredient list is just a prop_portal and a prop_dynamic for the frame (set the world model to models\props\portal_emitter.mdl), both named separately. This model has skins that we'll be using: 0 is off, 1 is glowing blue edges, and 2 is glowing orange edges.

The setup:

1) Set your keyvalues for the prop_portal accordingly: Portal pair ID should be 0 in order to link up with the player's portalgun. The portal should also be blue ("Portal 1") or orange ("Portal 2"), and the opposite color of what the player has (e.g. if the portalgun is firing blue, the auto-portal should be orange).

NB With the weapon_portalgun, check the keyvalues to ensure that it can only fire one color portal. You should not have to rely on the give_portalgun command for this!

2) Position your prop_portal and frame accordingly:



3) Let's say you want to hook up the auto-portal to a button for toggling. Using a logic_branch and the ToggleTest input coming from the button, here are some I/O you can try for the logic_branch:



NB You can also get fancier with the skins by using extra I/O and some delay, just as you saw in Valve's singleplayer overgrown maps. However this approach is not recommended if you're using a less predictable input device, such as a laser catcher or floor button.

“With it, you can create your own portals.”
~ GLaDOS

This section will essentially be divided into two parts: creating the rotating stand and creating the mechanism that lets the player pick up the device.

The essential mechanism that makes the portalgun stand rotate so perfectly and flawlessly is a func_door_rotating, but that alone does no good. Using some special parenting and unparenting tricks, we'll set up a ratchet-like mechanism that "winds" the stand around 90° each time. The basic formula:



1) Start with the portalgun and stand parented to the func_door_rotating.
2) Open (rotate) the door.
3) Unparent the portalgun and stand while we close the door.
4) Re-parent the portalgun and stand to the now-closed door.
5) Repeat 2-4 until the player picks up the portalgun.

All right, now the ingredient list:

• A dangerous-but-nifty weapon_portalgun
  
• Two prop_dynamics: one for the base (world model: models\props\pedestal_base_reference.mdl; set "Disable shadows" to "Yes") and one for the pedestal (world model: models\props\pedestal_center_reference.mdl).
  
• A func_door_rotating (a brush size of 16×16×4 should do the trick) — set "Disable shadows" to "Yes", "Speed" to 30, and "Delay Before Reset" to -1
  
• A 4×4×56 func_door or func_movelinear to recess the stand once the portalgun is grabbed — set "Disable shadows" to "Yes", "Speed" to 16, "Delay Before Reset" to -1, and "Move Direction" to 90 0 0 (down)
  
• 3 ambient_generics for effect — set the sounds to Portalgun.pedestal_rotate (rotating pedestal sound), Sphere.FiringPowerup (portalgun "charge" sound) and doors/default_move.wav (for opening the portalgun stand)
  • For the func_door and func_door_rotating, it may help to check off the "Door Silent" flag in the Flags tab.
• 4 more prop_dynamics with world model set to models\props\portal_emitter.mdl for each of the frames
  
• A trigger_once for opening the stand to allow the player to grab the portalgun
  
• A logic_timer to make it all run; should reset after approximately 10 seconds
  
• If you want to get fancy, also include a math_counter and a logic_case

Everything will need a distinct name. There is a special hierarchy of parenting going on here: the portalgun is parented to the stand, which is parented (and unparented on in-between occasions) to the func_door_rotating, which is parented to the func_door.



The positioning of everything should be fairly intuitive, so I won't go over it here. Just make sure that:

• The func_door_rotating is in the center of the pedestal or lower
  
• The func_door and func_door_rotating both use the nodraw texture so as to ensure invisibility
  
• There is a little hole for the base so that it doesn't look weird when the pedestal recesses into the ground.

And finally, the I/O for everything. First, the I/O for getting the portalgun rotating:





And now the additional I/O for when the test subject comes into the scene:

As seen in Mevious' Portal mods Portal Pro and Rexaura, the rotating portalgun can sometimes have inputs. The setup is very similar to above, except that instead of using a logic_timer, we'll be using a pedestal button to perform the rotations. As usual, there are subtle differences in the I/O. If your pedestal stand is to be bi-directional — controlled by a second button perhaps — a second func_door_rotating of the same size as the original will be needed. It will take on pretty much the same I/O as the original, but with one subtle difference: it starts open instead of closed and closes each time the stand is parented to it instead of opening.



In the bi-directional setup, I used two logic_relays for organization and control (the CancelPending input becomes very valuable here!).

And now, without further ado, here's the I/O setup you can use for rotating the portalgun (I/O for the the portal emitters have been excluded for now):





The additional I/O for picking up the portalgun is nearly identical. Instead of disabling a logic_timer, you're going to lock (and optionally recess) the button(s) instead.

Note: it is not recommended to rotate your portalgun pedestals with anything other than a pedestal button, unless you can plausibly figure out how to control/gate the I/O so that it behaves much like one (and I'm talking more than just a logic_relay here :P).

• ... The most common mistakes here are to touch the operational end of the device, to look directly into the operational end of the device, to submerge the device in liquid (even partially), and finally, to [REDACTED]
  
• Seriously though, there likely aren't any major mistakes.
  
• Keep up the good work.

More information from the VDC Wiki:

• Official weapon_portalgun page
  
• The rotating portalgun (that page was designed for Portal, but it can also work for Portal 2)

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 17/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 the Aperture Science Pneumatic Diversity Vent)
Next Guide (cooperative mapping details: beginning, doors, ending, and airlocks)

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!