One Way Door

[RavenStryker]

You guys are probably starting to love me by now But hey, at least I'm keeping the juices flowing up there for everyone.


I was wondering if there was a way to make a one way door. But here is the catch, it's only one way for one team, whilst the other team can still get through from both.


going in--->|<---going out

Red--->|<---Red

Blue--->|x---Blue

 

[Armadillo of Doom]

You guys are probably starting to love me by now But hey, at least I'm keeping the juices flowing up there for everyone.

And we thank you for it The door you want can be done fairly easily. Set up your door just like normal, but instead of having 1 big trigger_multiple, you'll have 2, one on either side. Then adjust the activation for each one and you're done. You'll wind up w/ two sets of triggers targeting one object (the door). Hope this helps

 

[Apom]

It will take a more complicated layout if you want to avoid players being stuck. One large red trigger to open the door, one small blue trigger to open it from only one side, and one large neutral to close it.

 

[Laz]

I would just set up with 2 triggers; one on each side, and adjust the team filters. Then with a logic entity, set it up so you dont get players stuck when players from both teams are moving in and out of the entity. Make sure you dont send a close to the gate when one of the two triggers is still returning a true.

 

[UKCS-Alias]

To be more clear about the above (which is the best solution). Make 2 logic_branch entities and call them for example: door_state_red1 and door_state_blue1. Instead that the triggers open or close the door they simply set their branch value to 1 (open) or 2 (closed). Then make a logic_branchlistener (if im right its called that way). put the 2 door states in the branches it should listen to.

Then give that listenser the following outputs to the door:
onalltrue - open
onallfalse - close
onmixed - open

This checks if either 1 team has their trigger active. if it does then the onmixed will be used. when both teams are in the onalltrue is used. if none are in then the onallfalse is done.

FYI, the logic_branch is just a boolean check entity, its set to either true (1) or false (0) and is able to perform actions based on it. The listener just listens to these entities and performs actions based on all. This entity is usualy used to have multiple buttons to be activated before an action happens when there is no order in when they should happen but also allows actions/checks like these

Note: im not sure if the listener should be triggered also or not. if it has to be triggered give the branches an extra output to the listener

 

[A Boojum Snark]

It will take a more complicated layout if you want to avoid players being stuck. One large red trigger to open the door, one small blue trigger to open it from only one side, and one large neutral to close it.

What he said.

Obviously the three trigger_multiple would have their edges overlapping properly.
This is more reliable than the logic method when it comes to not having blue players stuck IN the door when it closes.

 

[Apom]

What he said.

Yes, exactly what I meant, I'm too lazy to upload images

Note that the blue trigger brush should stop within the door, or before, but not after. Even if the outer edge is shared with the door's, touching the door can be enough to activate the trigger (I'm not exactly sure how Soruce handles this, and whether it is systematic or random, but I know it happens).

Alternatively, you could restrict the red brush to the right side, and make the blue brush not filtered. Same result, perhaps a little bit cleaner in terms of brush layout.

This is more reliable than the logic method when it comes to not having blue players stuck IN the door when it closes.

It's 100% reliable and, more importantly, incredibly easier than messing with logic. Generally speaking, doing logic in Hammer is awful.

 

[RavenStryker]

Okay! the image makes it much much easier to visualize. Lol. I've never used logic in Hammer and I hope not to, but I'm sure there will be a time when I will.

 

[UKCS-Alias]

From that image there is 1 downside, if a blue player stays inside the gray marked trigger then the blue team simply keeps the door open allowing people to go back also. Better is to have both the red and blue trigger have the onendtouch instead of the gray trigger. And when you combine that with the logic_branch thing i told before you can ensure the door would only be open when at least 1 player touches their own team's trigger. Still, my way uses more entities so its up to decide what is best for you.

If you dont mind that blue can keep the door open like that then you should definitely choose for that as it saves alot of hard work and time.

oh and about the logic thing making player stuck in the door. there is no worrys needed for that. you can set it in such a way that the door doesnt need a forced close. this makes the door stop closing when it touches a player and so they dont get stuck.

 

[Apom]

oh and about the logic thing making player stuck in the door. there is no worrys needed for that. you can set it in such a way that the door doesnt need a forced close. this makes the door stop closing when it touches a player and so they dont get stuck.

If the "no-force" setting worked, it would be much easier and in even less need of logic: half-brush on the left (not filtered) and half-brush on the right (red only), both with open/close commands.

 

[UKCS-Alias]

If the "no-force" setting worked, it would be much easier and in even less need of logic: half-brush on the left (not filtered) and half-brush on the right (red only), both with open/close commands.

It does work then. the only problem is that when you use 2 half brushes the moment you step into the other one the door already tries to open (while its open already) and when you stop touching the other one the door closes (because when you get out of the trigger later the door closing is triggered later).
So it still looks like it doesnt work while it actualy does. The player that just passed the door however must get out of the trigger first before that side works again.

 

[A Boojum Snark]

The logic method doesn't prevent a blue player from holding the door open, and ultimately even if you prevent keeping it open, a player can still just trigger it from the outside to let their mates out.

 

[Laz]

this thread is golden!

 

[RavenStryker]

Yes I've made a golden thread! Well I didn't make it, but you get the jist.
Thanks to all who have made this possible! All your ideas are grand! You've made lives easier around the world! Lol.