Locked Safe Room Door?

[Iyvanne]

Hi, is there anyway to lock the prop_door_rotating_checkpoint entity at the start? I've tried checking the "Starts Locked" flag but it did not work. So I tried going into the director and tried to lock the door at the start of the game. It also did not work. Is there anyway to this?

I tried checking the "ignore player +USE" flag, this kinda worked but I don't know how to disable it so the survivors can't close it once it opens...plus the bots teleports inside the safe room for some reason.


I know this is my third post in the past two weeks. Sorry guys!

[Evil]

It is possible but there's a quark with that specific door type, it starts in a locked state by default. But it also has a built in unlock method (this is why safe room doors require you to hit the use button twice for it to actually open).

This leaves you with a few options.
- Try to lock the door after it is used once but before the door is actually opened
(not sure how you'd do this)
- Use a standard prop_door_rotating entity instead
(you'd probably need an invisible checkpoint door parented to this door for the nav to work correctly)
- Use two prop_door_rotating_checkpoint entities
(the first with ignore player +USE ticked, the second linked with a point_template. After xx amount of time, kill the first and spawn the second door in it's place)


As for the door closing part, untick the 'Use Closes' flag.

[AlwaysToast]

It depends on what you mean by “lock”, what position you want the door to be in, and which saferoom door you are speaking about. The exit to the start saferoom and the entrance to the end saferoom can be “locked” in different ways, and require different techniques to get different results.

If you just want the locking bar to appear on the door exiting the starting checkroom, set on the prop_door_rotating_checkpoint: Body 1 (from the default Body 0 )

If your talking about making the door stay in a certain position knowing the position you want to maintain, and the reason you want to maintain it, would help us give you better suggestions (instead of making us have to suggest every option we can think of).

Generally a real door only locks when it is closed and the locking mechanism is engaged. If you want a door to stay stuck open, that’s not the same thing as being locked.

On the exit to the starting saferoom, if you want it to be stuck open, then unchecking the use_closes flag will do that. Or as Evil suggested you can kill the door. I’d suggest using the door itself OnFullyOpen to trigger a point_template to spawn a different version of the door, and have the point_template OnEntitySpawn kill the original door. I’d suggest a prop_physics (since it will work with the same model), since you can make it not move (with flags) or have it fall off the hinges. If you have the door fall, make sure it can’t fall in such a way to block the survivor’s path in a way that it gets stuck.

If you want to keep the exit to the starting saferoom closed with the survivors inside… I would need an explanation of why, because that’s nutty.

If you want the exit to the starting saferoom to close after everyone leaves so they can’t go back, that’s doable. But it’s generally easier to put a drop down that they can’t climb back up, if you want to prevent retreat.

The prop_door_rotating_checkpoint for the entrance to the end saferoom doesn’t lock as far as I know (the start locked flag has never worked for me). Other than when the map transition occurs.

If you want the entrance to the end saferoom to start open and lock closed after it closes, that’s a terrible idea. As the first player to the door could close it while outside, causing the entire level to be unwinnable and requiring a wipe to restart. That’s not fun. Trying to create a situation where a survivor can get in and lock other survivors out, isn’t going to work well (the bots will teleport inside, and so will anyone smart enough to use “take a break” so their survivor becomes a bot that will teleport inside). It would be easier to cover the rest of the level in damage to kill any survivor not in the saferoom. Then at least you wouldn’t have to wait to die if someone closes the door before anyone gets inside. But people are going to HATE that kind of mechanic if it isn’t super clear what is happening. Actually they will probably hate it no matter what, since it's anti-cooperation in a coop game.

If you want the entrance to the end saferoom to be blocked, so the survivors have to deal with an event or something before entering: You need to use something else to physically block the survivors from reaching the door. Such as a brush func_door before actually reaching the saferoom rood or func_breakable (set to break on a trigger). It will work best if it’s not right up against the prop_door_rotating_checkpoint.

What specific situation you are trying to setup also changes what suggestions I'd make for dealing with bots teleporting.

[Iyvanne]

Originally posted by AlwaysToast:

It depends on what you mean by “lock”, what position you want the door to be in, and which saferoom door you are speaking about. The exit to the start saferoom and the entrance to the end saferoom can be “locked” in different ways, and require different techniques to get different results.

If you just want the locking bar to appear on the door exiting the starting checkroom, set on the prop_door_rotating_checkpoint: Body 1 (from the default Body 0 )

If your talking about making the door stay in a certain position knowing the position you want to maintain, and the reason you want to maintain it, would help us give you better suggestions (instead of making us have to suggest every option we can think of).

Generally a real door only locks when it is closed and the locking mechanism is engaged. If you want a door to stay stuck open, that’s not the same thing as being locked.

On the exit to the starting saferoom, if you want it to be stuck open, then unchecking the use_closes flag will do that. Or as Evil suggested you can kill the door. I’d suggest using the door itself OnFullyOpen to trigger a point_template to spawn a different version of the door, and have the point_template OnEntitySpawn kill the original door. I’d suggest a prop_physics (since it will work with the same model), since you can make it not move (with flags) or have it fall off the hinges. If you have the door fall, make sure it can’t fall in such a way to block the survivor’s path in a way that it gets stuck.

If you want to keep the exit to the starting saferoom closed with the survivors inside… I would need an explanation of why, because that’s nutty.

If you want the exit to the starting saferoom to close after everyone leaves so they can’t go back, that’s doable. But it’s generally easier to put a drop down that they can’t climb back up, if you want to prevent retreat.

The prop_door_rotating_checkpoint for the entrance to the end saferoom doesn’t lock as far as I know (the start locked flag has never worked for me). Other than when the map transition occurs.

If you want the entrance to the end saferoom to start open and lock closed after it closes, that’s a terrible idea. As the first player to the door could close it while outside, causing the entire level to be unwinnable and requiring a wipe to restart. That’s not fun. Trying to create a situation where a survivor can get in and lock other survivors out, isn’t going to work well (the bots will teleport inside, and so will anyone smart enough to use “take a break” so their survivor becomes a bot that will teleport inside). It would be easier to cover the rest of the level in damage to kill any survivor not in the saferoom. Then at least you wouldn’t have to wait to die if someone closes the door before anyone gets inside. But people are going to HATE that kind of mechanic if it isn’t super clear what is happening. Actually they will probably hate it no matter what, since it's anti-cooperation in a coop game.

If you want the entrance to the end saferoom to be blocked, so the survivors have to deal with an event or something before entering: You need to use something else to physically block the survivors from reaching the door. Such as a brush func_door before actually reaching the saferoom rood or func_breakable (set to break on a trigger). It will work best if it’s not right up against the prop_door_rotating_checkpoint.

What specific situation you are trying to setup also changes what suggestions I'd make for dealing with bots teleporting.

Thanks for the reply! Sorry for not being specific enough.

Basically, I have a button beside the end safe room. I want the survivors to not be able to go inside right away... I want the button to trigger a forcedpanicevent (which already works) before opening/unlocking the door after a delay.

I'll be trying the last option you've suggested

[AlwaysToast]

Originally posted by Iyvanne:

plus the bots teleports inside the safe room for some reason.

Originally posted by Iyvanne:

Basically, I have a button beside the end safe room. I want the survivors to not be able to go inside right away... I want the button to trigger a forcedpanicevent (which already works) before opening/unlocking the door after a delay.

The reason the bots are teleporting into the saferoom is because once the bots get close to the saferoom they go inside. The bots navigate based on the nav mesh, not on what they see. If the nav mesh is unblocked, but the bot can’t reach the area they are going to, the game will eventually let them teleport so human players don’t need to wait for them. The game has assumed the bots couldn’t reach that location because bots have navigation issues, because you haven’t blocked the nav to tell the game the bots are not allowed to go there yet.

In order for them to know the path to the saferoom is blocked you need to block the nav (but not the flow since I assume this is the only path into the saferoom). Normally you only need to block the nav at the location of the door (or whatever is blocking them). If this is particularly close to the saferoom, you may need to block the entire nav inside the saferoom to prevent them from teleporting inside. I’d suggest blocking the point of the obstruction first, then test to see if bots teleport past it. If they do, then block the nav inside the saferoom as well.

Make a brush entity with the trigger texture, then make it a func_nav_blocker. Place it over the nav you want to block.

Important things to know about blocking nav:
A func_nav_blocker will block any nav it touches (so generally you want them to touch the floor), it doesn’t matter if it’s totally overlapping or only overlapping by 1 unit.

Blocking nav does nothing to the human players, it only affects bot navigation. But you don’t want any large areas that have blocked nav that players can stand on (that infected couldn’t reach them by standing at the edge of that piece of nav).

A func_nav_blocker is a lazy brush that follows the AABB rule, so if you put it at an angle, the outer bounding box is what determines which nav is blocked. If you make multiple brushes, select them all, and make them one func_nav_blocker, you get single entity multiple solids result, the big outer bounding box will be used. So it’s easy to block a doorway or square room. But if you want to block nav along a diagonal, you need to use multiple individual func_nav_blocker(s). You can give multiple individual func_nav_blocker(s) the same name so they are triggered at the same time.

Give the func_nav_blocker a Name. I suggest using the same naming pattern for all your func_nav_blockers. So something like: nav_b01, nav_b02, etc. You can use whatever you want for the name, but make it one consistent name at the start then a variable. Make sure only func_nav_blockers start with that name.

Team(s) to block = Everyone
Affect Flow? No
You set Affect Flow to Yes if you are blocking a path, and causing the survivors (and the flow) to take an alternate pathway. If there is no alternate pathway for the flow to take, and it is set to Yes, the nav will break. Always use Affect Flow NO, if you are blocking the only path to the saferoom (there is no other path for the flow to travel on inside the playable area).

Affects Flow No, can be understood to mean: The way is blocked. Wait for it to unblock before moving forward.

This should also prevent infected from spawning on the other side of the blocked nav if there is no path for them to take to reach the area where the survivors are.

All nav blocking has a bug. You need to send the UnblockNav command to the entity before it can block nav.

To un-bug them you can use a logic_auto to trigger it.
target = nav_b* (or whatever the consistent name of your nav blocker is)
The * works as a variable, so anything that starts with the name before the * will get the command. Hence nav_b* would send the command to nav_b01, nav_b02, nav_b03, etc.

Target Input = UnblockNav.
This will work on all func_nav_blocker including those that are going to be spawned by a point_template (ie it hasn’t been forcespawned yet, but it can get the UnblockNav command to make it function properly when you do spawn it from the point_template).

Then after a delay of 0.5 you can send the BlockNav command (ether to individual func_nav_blockers or to all of them).

If you are using a point_template to spawn a func_nav_blocker later on (more common for alternate paths), you want to use the point_template to OnEntitySpawned send the Block Nav command to that specific func_nav_blocker. (you are probably not doing this for this design, but I'm including this extra info in case you need it later)

Then you need to set up something that sends the UnblockNav command when the event is finished (when the func_door OnOpen, or OnFullyOpen, etc or the func_breakable OnBreak, etc).

When you are editing the nav, you should use mark TRANSIENT on all the nav that is under a func_nav_blocker, so the nav knows that piece of nav can and will be blocked/unblocked.

Then inspect the nav to make sure it is blocked in the right places (and not in the wrong places). If the nav mesh has a light blue square inside it, that means the nav is currently blocked. You may have to use nav_split some nav mesh to cut them into smaller pieces, so only the area right by the obstruction is blocked, or you may need to fiddle with the placement of your func_nav_blocker(s).

After all the changes have been made run nav_analyze.