Please or Register to create posts and topics.

beam thru portal

I decided to include some new elements on my map, but I occurred a problem that I can't make a beam that has no end point and that can go thru portal. Is it even possible? It must be because the beams of turrets goes thru portals too.

I have run into exactly the same problem. Apparently, the turrets have some special coding that allows them to do that. A normal env_beam or env_laser just ignores the portal.

I'm going to make a laser puzzle where you have to aim the laser at a target using rotating mirrors and portals. I eventually found a way to fake it, but it is headache-inducingly complicated.

It involves having fixed portal frames so that the position of the portals is exactly known, extra env_lasers in each frame to make the same beam appear to travel through the portal, a func_portal_detector in each frame and a gigantic pile of logic_branch and logic_branch_listener entities to tie it all together. Oh, and a funky physics gadget that drops when a func_portal_detector fires, in order to determine if the portal just opened or closed. And I almost forgot about the template shooting thing that makes sure that you get a continuous beam, even when one of the portals is placed in an arbitrary spot in the map.

Executive summary:
:notwant:

PS: if you just want the effect, you can place a prop_dynamic and give it the turret model, that will then produce a laser that travels through portals, just like the real turrets. You might be able to hide the turret model in some kind of enclosure.

Sendificate series: Sendificate | A Beam Too Far | Airtime | 302
Other Portal 2 maps: Medusa Glare
Portal 1 maps: Try Anything Twice | Manic Mechanic
Quote:
I'm going to make a laser puzzle where you have to aim the laser at a target using rotating mirrors and portals. I eventually found a way to fake it, but it is headache-inducingly complicated.

That was my idea too :roll:

Maybe I try that turret thing with portal detectors

Something to keep in mind HMW is that when a portal detector is activated, the origin of the detector is moved to the center of the last portal fired on it. You could try using that to dynamically spawn what ever entity setup you are using for the beams at the center of the portal

Are you sure? As far as I can see, func_portal_detector entities don't have an origin. (They also don't show the blue dot that you can drag around in Hammer.)

I have tried parenting things to the detector (an env_entity maker for example) and these just stay in their original location when a portal lands inside the detector. And I have tried using ForceSpawnAtEntityOrigin, with the detector as the target. This just spawns the object at the entity maker's original location.

Lastly, I have tried to de-activate smart editing in Hammer and adding an origin property manually, but that seems to get ignored by the game.

I read your post on Interlopers.net. If you got this to work, please explain how it's done. That would be very helpful!

EDIT: Never mind, I was being stupid. I didn't realise that the sender of the detector's touch event is the portal itself. So you can send a ForceSpawnAtEntityOrigin with !activator as the parameter. This spawns the template at the origin of the portal.

Anyway, that was a very useful hint. Thanks! 8)

Sendificate series: Sendificate | A Beam Too Far | Airtime | 302
Other Portal 2 maps: Medusa Glare
Portal 1 maps: Try Anything Twice | Manic Mechanic