Triggering visportals

[Springheel]

I have a portal that I would like to close if the player is approaching from one direction, but leave it open if they're coming from the other. Is it possible to link triggers to visportals? Since portals are worldspawn I assume you can't just target them directly, but is there a way to target a func_portal attached to the visportal?

[Mortem Desino]

I do know that certain movers with an explicit "open/closed" value can open and close a visportal. Maybe a brushwork func_mover_door touching the portal will open and close it when triggered.

[Bikerdude]

I guess you could target a func_portal from a trigger which would then close open the VP...

[Springheel]

The more I think of it, the more I think triggering it won't work....I can't use a trigger_multiple, because that would just turn it on and off if the player stood there.

 

Bleh.

 

I'm trying to close a portal in a long vent to keep sound from the room below from going straight to the player. But there's a long view from the opposite side, so I can't use a func_portal (unless I can figure out how to trigger a fake 'window' to hide the closed visportal).

 

We really, REALLY need to add some sound loss controls to visportals now that we have the source.

[Bikerdude]

We really, REALLY need to add some sound loss controls to visportals now that we have the source.

I thought we had something like that already..?

[Mortem Desino]

 

I'm trying to close a portal in a long vent to keep sound from the room below from going straight to the player. But there's a long view from the opposite side, so I can't use a func_portal (unless I can figure out how to trigger a fake 'window' to hide the closed visportal).

Don't doors have a spawnarg that controlls sound loss while closed and a different arg while open? I think it's something like "loss_open" and "loss_closed".

 

But I hear ya. Visportals ought to be easier to control.

[grayman]

The training mission uses func_portals targeted to func_statics in the windows of the tower in the archery area. Those func_statics are just black, but you can paint anything you want on the side facing the player, for the case you're describing.

[Springheel]

The training mission uses func_portals targeted to func_statics in the windows of the tower in the archery area. Those func_statics are just black, but you can paint anything you want on the side facing the player, for the case you're describing.

 

Ok, I'll check out how they did it; I haven't been able to get it to work.

 

Don't doors have a spawnarg that controlls sound loss while closed and a different arg while open? I think it's something like "loss_open" and "loss_closed".

 

Yes, but that only works for doors. We need the same functionality for all visportals.

[Springheel]

Ok, the func_static was inside the visportal, and had a "hide" "1" spawnarg at it. Once I did the same I got it to work. Thanks!

[Tels]

The more I think of it, the more I think triggering it won't work....I can't use a trigger_multiple, because that would just turn it on and off if the player stood there.

 

Bleh.

 

I'm trying to close a portal in a long vent to keep sound from the room below from going straight to the player. But there's a long view from the opposite side, so I can't use a func_portal (unless I can figure out how to trigger a fake 'window' to hide the closed visportal).

 

We really, REALLY need to add some sound loss controls to visportals now that we have the source.

 

Definitely! Not only open/closed, but "muffle" etc.

[Sotha]

Spring, you CAN easily use trigger multis.

Have a trigger_multi and target A and B.

A is the thing you want to toggle.

B is the entity that changes the trigger_multi's target to nothing, thus disabling the trigger_multi. I can't remember the entityname. Something like target_changespawnarg or something.

 

 

I used it for the trap in phrase book.

Works beautifully.

 

Then you just need another triggermulti setup which gets enabled when the other TM gets disabled.

[demagogue]

That'd work too, but I was going to say you could also use the info_location script calls. Then you can have the script fire when you enter the right location (triggering the thing on), and trigger it off when you exit it at any point (or some variation of that). The trigger is sensitive to your location AND you don't have to worry about repeat fires (even if to empty targets, you're still hogging resources with it) or mis-toggles.

 

Edit: I would go so far to say that any time the idea of a trigger_multiple comes to mind, immediately think if an info_location script could do the job instead... unless you want something smaller than the location or you don't want to make a script.