That's actually really awesome. I'm going to take a stab at how you did it.

Logic_measuremovement measuring eyes, moving an invisible brush
Energy ball launcher entity parented to brush
Nonfunctional portal gun
Game_ui
4 linked_portal_doors
8 info_particle_systems on the portals, 1 per projectile color
1 trigger_multiple to detect energyballs and parent everything to them
Some entities to control orientation (maybe func_tank?)

Thanks! That's about it, but minus the func_tank and plus one logic_script (to orient the portals, which uses a bit of vector math, and to keep everything in sync). You can't really see it in the video, but there's also a playerproxy to slow down the balls when the player ducks (via AddOutput) and a second trigger (one for each effect color).

A word of advice to anyone thinking of implementing a similar mechanic: make sure there's at least one unit between the two back-to-back world portals, or there'll be that annoying stutter.

wow I'm amazed that I got that right!

Also, couldn't you also use prop_portals alternatively, for a less squared appearance?

No, those fizzle if you SetOrigin them to a bad place.

By the way, I added some simple checks to prevent portals from being placed touching walls on the sides. Since I'm having great difficulty with portal bumping it just makes it fizzle for now.

Would it be possible for you to use physics object collision to fix the portal? (Not sure if this could work at all.) Spawn in an invisible model with a collision box the size of the portal, wait, then spawn the portal where the model is after. (Might need a trigger_vphsics to turn off the object's gravity, and I'm not sure if objects will even try to move away from others they're stuck inside.

Something that may help you check for collisions: try moving an env_entity_maker with the "ForceSpawn: only if room" checked to where the portal should be, then try to ForceSpawn in an invisible func_brush/model the size of the portal. If it fits, the maker should fire a OnSpawned output which you could use to replace the placeholder with a real portal. If it instead outputs OnFailedSpawn, offset it a bit or something and try again. This could allow slight adjustments to be made.

I tried the first one, but if there's too much interpenetration (or no solution, like if I shoot a portal down a 64x64 hallway) it throws errors in the console and makes the game lag rather than fixing the collision.

The second is brilliant, and I'm going to try that today. It's far more elegant than my solution (tracing lines between the center of the portal and a bunch of points on the edge), and will detect brush entities as well as world brushes. It'll probably run faster as well, as the env_entity_maker code is all C++.

Keep in mind that "ForceSpawn: only if room" only tests the point where the env_entity_maker is, it does not take the size of the spawned objects into account. However, it may work if you use one env_entity_maker for testing each corner of the portal.

Interesting, I did not know that. What size of bounding box does it use for collision testing?

As far as I can see from my own tests, it really just looks at a single point. There is no bounding box or collision hull. Sounds weird, but that's how it appears to work.

What you also could do, is add 4 info_targets to the template, one at each corner. After spawning the template, use the TraceLine() script function between each two targets (along each edge) to check for collisions. If one of those tests does not return 1.0, it means that the portal is partially inside a wall and should not be opened.

TraceLine() is a bit finicky in that it only detects world brushes, func_details and func_physboxes. So you may have to take special measures for things like fizzlers and windows. (I have done that with the new version of the sendificator. It's not as bad as it sounds.)

That's actually what I do now, except that the targets aren't spawned from a template; I just use the same set every time.

I was actually considering switching to the older Sendificator method, with the lasers (as that would prevent things like opening a portal inside a prop_physics). Are there significant drawbacks to that?

You know, you could just spawn a point_push in the portal that momentarily enables, pushing physics objects slightly out of the way, then disables.

I will probably do that, but what if the physprop is (e.g.) trapped against the wall?

Good point. I guess you could try bumping any objects, but you could have a trigger that appears that checks for any inside the portal that also enables afterwards then disables, and if any are detected, the portal dissipates.