Quote from TeamSpen210 on May 22, 2014, 4:18 am

Use a trigger_multiple with some filters. For the flags, check only "everything". Make a filter_activator_class, set the "filter classname" to "projected_wall_entity" (the entity for the actual wall). Set the "filter name" property on the trigger_multiple to whatever you called the filter_activator_class.

Quote from FelixGriffin on May 22, 2014, 11:57 am

Note however that this doesn't always detect the bridge properly. I'm not exactly sure why, but the only surefire method I've found is to put the trigger where the portal will be to send the bridge into the receptacle. Perhaps the origin of the entity is there?

Quote from albian on May 22, 2014, 5:25 pm

That's brilliant, thanks guys. Never used filters before and I haven't got a clue yet of how they work but it does exactly what I want.

The reason I want this is that I have botched together a type of fizzler that blocks a light bridge but lets you walk through it (and i wanted it enabled when a light bridge hit it). When I say botched together, it uses three triggers and three func_brushes and it's a bit crude. I'd be interested to know if you can use a filter to have a brush act as solid only to a light bridge - any ideas?

Quote from Blaizer on May 22, 2014, 7:36 pm

Try a func_clip_vphysics with the same filter as the one you put on your trigger multiple. That's the only thing I think would work.

Quote from albian on May 23, 2014, 7:38 am

Blaizer wrote:

Try a func_clip_vphysics with the same filter as the one you put on your trigger multiple. That's the only thing I think would work.

Thanks but unfortunately that doesn't appear to work. I can't get func_clip_vphysics to block a light bridge.

Quote from FelixGriffin on May 23, 2014, 10:55 am

I don't think light bridges use VPhysics. You might make a little brush right where the light bridge will hit that is enabled only if there is a bridge there. The player won't notice it because that same area is blocked by the end of the bridge.

Quote from TeamSpen210 on May 23, 2014, 3:02 pm

Maybe you could parent the func_brush to a prop_portal, a certain distance in front of it. Then you could use func_portal_detectors to detect when a player places the portal so it goes through the field, and enable a brush the correct distance away (you'll probably need more than one to handle different distances). Put a placement_helper on the exit of the light bridge portal to force it to be in one position for easier brush placement, and add a func_portal_detector to detect whether a portal is placed for the light bridge. You'll need to basically duplicate this for both of the player's portals.

Logic-wise, if you made sure there was nothing but void behind the light bridge, and the distance from bridge emitter and portal was shorter than the distance to the first func_brush from the portal you can name the two brushes at the same distance away from the portal the same thing. You'll want to have a logic_coop_manager per brush pair to remember where portals are and enable/disable brushes accordingly. If you wanted you could also add an info_particle_system or other effect on the func_brushes, so it's more obvious the field is blocking it.