should_always_be_locked

[grayman]

What was the original intent of this door spawnarg?

 

If a map author locks a door at mission start, should "should_always_be_locked" default to "1"? Atm it defaults to "0".

 

Or are locked doors that are unlocked allowed to stay unlocked?

 

I imagine that the latter is the case, given this situation:

 

1 - player picks a locked door

2 - AI use the door

3 - player uses the door again. He picked it once, so he doesn't need to pick it again.

 

For existing FMs, would it be considered a breakage in gameplay if--by default in 1.08--the player has to unlock doors he's previously unlocked?

 

Thanks.

[i30817]

Maybe it's to alert guards if they try the door and find it unlocked?

 

Can the player relock a door without a key anyway?

[grayman]

Maybe it's to alert guards if they try the door and find it unlocked?

 

AI don't react to a "supposed to be locked" door when they find it unlocked. Is this something that was never implemented?

 

Can the player relock a door without a key anyway?

 

The player can't relock a door, even with a key.

[i30817]

Oh i was just uninformed speculating, don't mind me.

[grayman]

Oh i was just uninformed speculating, don't mind me.

 

Having an AI react to an unlocked door that's supposed to be locked makes sense. Perhaps we can get a few more readers here who can comment on this.

[Sotha]

Huh? I could swear the player can lock doors with a key.

 

Do we need AI getting an alert if they find a door unlocked that should be locked? What would the AI do then, search around the door? Pull out a sword? The player might be confused if the AI freaks out due an unlocked door, since there is no visual cue and we don't have vocals for it "hm this should be locked.."

 

WRT AI locking doors that were unlocked but that should be locked... In real life that would be the norm. But for gameplay this would punish players who don't KO all AI. I fear it might increase annoyance factor too much, people complain about always locked minor lootitem chests etc already. I believe players would not find it fun to have to lockpick same doors again and again. On the other hand, it increases tension as escape routes would be blocked by routine AI activity. I am not sure if it would be good. What do people think?

 

On the other hand, we can't have AI leaving doors unlocked too if two AI happen to pass through it instead of one AI.

 

Overall, I think it would be maybe better if the AI just locked doors that should be locked, instead of getting alert. Relocking the door already increases the difficulty, no need to have an alert too.

[Sotha]

To summarize, I'll present a few possible scenarios:

 

current scenario:

1 AI goes through door, locks the door after him

2 or more AIs goes through a door, the last AI leaves the door unlocked

Player unlocked doors will not be relocked by AI unless "should_always_be_locked" spawnarg is 1. Defaults to 0.

Pros: current behavior

Cons: multiple AI going through doors leave doors unlocked.

 

 

Scenario 1:

1 AI goes through door, locks the door after him

2 or more AIs goes through a door, the last AI locks the door after him

Player unlocked doors will not be relocked by AI unless "should_always_be_locked" spawnarg is 1. Defaults to 0.

Pros: probably the optimal situation, works like current, but fixes multple-ai-leaving-doors-open.

Cons: no ready code support?

 

Scenario 2:

1 AI goes through door, locks the door after him

2 or more AIs goes through a door, the last AI locks the door after him

Player unlocked doors will always be relocked by AI. The player can remove this by changing the "should_always_be_locked" spawnarg, but then multiple AI going through will leave the door unlocked.

Pros: alraedy existing code support, more challenging gameplay

Cons: increased boring lockpicking of the same doors, fundamental issue multiple-ai-leaving-doors-open exists one spawnarg away.

 

Scenario 3:

1 AI goes through door, locks the door after him

2 or more AIs goes through a door, the last AI locks the door after him

Player unlocked doors will not be relocked by AI unless "should_always_be_locked" spawnarg is 1. Defaults to 0. In addition, AI gets alerted by the unlocked door.

Pros: AI alerted, rewards more careful play as the player should remember to lock doors in order to keep AI oblivious

Cons: difficult to cue player of alerts. Player does not always have possibility to relock doors. Should probably need a separate spwnarg for the unlocked-alerts. How to address multiple-ai-leaving-doors-open-problem?

[Bikerdude]

The player can't relock a door, even with a key.

er, yes they can.

 

Scenario 2:

2 or more AIs goes through a door, the last AI locks the door after him

Player unlocked doors will always be relocked by AI. The player can remove this by changing the "should_always_be_locked" spawnarg,

you mean mapper...?

[Sotha]

Yes, typo.

[Springheel]

Huh? I could swear the player can lock doors with a key.

 

I thought you could as well. Isn't there a section of the training map that specifically encourages you to lock an AI into a room where he can't get out? Or was that just a proposal that never made it in?

[grayman]

Huh? I could swear the player can lock doors with a key.

 

How?

 

Never mind.

 

I found that if you use the key on a closed unlocked door, it will lock it again. I play with "use when frobbed" enabled, so I never use the use key separately when dealing with doors, since my use key is automatically incorporated into the act of frobbing.

[grayman]

So far no one's posted a reason for the "should_always_be_locked" spawnarg. Either no one knows/remembers, or those who do don't read the forums any more.

 

I can only assume, then, that it's for one or both of these reasons:

 

1 - to solve the problem of multiple AI using a door and making sure the last AI relocks it

2 - to keep a door locked, so that the player isn't given a freebie unlocked door just because AI have been using it

 

Since the spawnarg is available, I don't see a strong reason (yet) for changing the current code. Just add the spawnarg to the door and set it to "1" and we get the desired behavior.

[Tels]

The doc in thed ef file does not help, it says "closed", not "locked".

 

75:	 "editor_bool should_always_be_locked"	  "If set to 1, the door will always be closed by AI after passing through, given the AI can lock/unlock the door in the first place. Code defaults to 0."

[grayman]

Yeah, that should be "locked".

 

Changing it now.

[Tels]

But even with that word changed, does it explain what the spawnarg is supposed to do?

 

Edit: I think it is supposed to do Nr 2. Relock the door so the player has to unlock it again. It defaults to 0 because it is dangerous and annoying if all doors are always relocked once an AI passes through.

[grayman]

It only explains what the code does: in a queue of AIs passing through a door (even 1), the last one through, who's responsible for closing the door, is also required to lock it if

 

- the spawnarg is present and set to "1"

- the AI has the ability to lock/unlock that door (has a visible or invisible key, can lock doors, etc.)

 

What the editor comment doesn't do--and I expect this is the job of the Wiki--is explain why the spawnarg was created in the first place. Was its original purpose just to make sure the door gets locked again? That's why I posted this thread, to see if anyone still around knew the original intent.

 

If it's just meant to do what the editor comment says, then that's what it does today and we're done.

 

Edit: It's probable that the use of the word "closed" was to convey that the door would actually be closed (and by implication due to the presence of "locked"--locked). I don't recall if AI always closed doors after they passed through them before I did all the door queue work.