Locked Doors and Door Controllers

[grayman]

I'm schooling the AI on how to use controllers (buttons and switches) to open and close doors.

 

This enhancement will be in 2.02.

 

We will then have three kinds of doors:

 

1 - Frobable rotating doors

 

2 - Frobable rotating and sliding doors that use door handling positions

 

3 - Non-frobable rotating and sliding doors that use controllers

 

Door types 1 and 2 can be locked.

 

But type 3 ... Since locks are opened with keys, and the controllers operate the doors, the locks need to be on the controllers. When an AI unlocks a controller, uses it, and opens the door, he's also unlocking the controller on the other side. He'll walk through and use that controller to close the door, which will relock both controllers.

 

The unlocking/locking rules when a conga line of AI uses a locked door will also apply to the controllers: the first AI will unlock them, all the AI will pass through, and the last AI will relock them.

 

A door that's marked "should be locked" will have that rule applied to its controllers.

 

Please discuss pros and cons.

 

Thanks.

[RJFerret]

Hmm...

 

Pros:

• Gives you something to create?
  
• Allows AI that aren't following path nodes (searching/chasing) to pass through separately controlled doors.
  

 

Cons:

• Redundant, path_interact already provides this with existing doors and controllers.
  
• Additional door type adding complexity/confusion for mappers, especially as one is a subset of the other.
  

 

May I ask what the design goal is? If it's purely to allow off path AI to get through doors with controllers, wouldn't it be easier to provide a new spawnarg for doors directing them to the controllers? Then all the current interaction they do with a door can take place at that location instead and voilà. (Yes, I realize it gets complex with multiple controllers, while in the existing system there is no complexity of which controller they access.)

[grayman]

There was an original design goal to have AI be able to deal with doors that use controllers. This design goal predates me. The door-handling code includes references to being able to use controllers, and also includes some code to make that happen.

 

However, it wasn't fully implemented, and thus didn't work. No one's been able to design a door setup using just a door and some controllers.

 

I'm making it work for 2.02.

 

I'm not familiar with how folks have used the path_interact entity to solve this problem. Can you describe how it works?

 

And also describe how it handles these situations:

 

1 - Two or more AI want to use the door simultaneously.

 

2 - The door becomes blocked while moving.

 

3 - The door is locked.

 

4 - An AI is searching near the door and needs to pass through it, perhaps several times.

[grayman]

As a reference for how old this design goal is, I offer this open bugtracker issue from 6 years ago.

[SteveL]

I can't think of any cons off-hand. Will it really be necessary for the mapper to indicate the controller from the door though? The controller will already target the door, so couldn't the code discover all the binary frobmovers that target the door?

[grayman]

Will it really be necessary for the mapper to indicate the controller from the door though? The controller will already target the door, so couldn't the code discover all the binary frobmovers that target the door?

 

I currently have it working using the original design, which is to register each controller with the door using the "door_controller" spawnarg on the door.

 

Only two maps have used this spawnarg, Dufford's and Outpost.

 

In Dufford's, the AI don't use the door or the controller, only the player.

 

In Outpost, the intent was that an AI used the controller to operate a sliding door from one side, and couldn't operate the door at all from the other side. The door_handling_position on the controller side of the door was placed next to the controller, and the code was looking for the closest controller in order to operate the door. So the door_handling_position was required for the controller to work properly. The controller wouldn't have worked correctly otherwise.

 

I can have the code register all controllers automatically at spawn time, the same way I automatically registered switches for relighting electric lights. That would ease some of the burden on mappers (though not much, and the Outpost and Dufford's authors obviously had no problem with it), but I can't eliminate the "door_controller" spawnarg because it's already been used in two maps. I'd need to combine door_controllers and any controllers targeting the door into a single list.

 

Edit: Examined Dufford's more closely, and changed the description above accordingly.

[RJFerret]

Thanks for the original design info.

 

I'm not familiar with how folks have used the path_interact entity to solve this problem. Can you describe how it works?

 

Sure, a lever/button/whatever controller targets door. A path_interact targets that controller, done. So AI uses the control, door opens. Potentially another set to close on far side (and changing a spawnarg if don't want AI swinging it closed, but by using a separate control).

 

1 - Two or more AI want to use the door simultaneously.

 

By default, extras would have no ramifications on the same control. If they came in sequence though, it would depend on the timing, which defaults to 0.4 seconds for the standard lever entity. However if there were multiple levers accessed simultaneously, the door would start to open and then be stopped, the AI would subsequently open it directly (the mapper would have to change a spawnarg from default if they wished to prevent this and have the AI be blocked).

 

2 - The door becomes blocked while moving.

 

AI would try to open it as they do now, unless it can't be used by them (IE, changed from default setting), in which case same as blocked doors now, they circle or bump into it, unable to continue their desired path.

 

3 - The door is locked.

 

It depends if the AI has the key. If so, voilà; if not, no go.

 

4 - An AI is searching near the door and needs to pass through it, perhaps several times.

 

This is the aspect I put under "pro" in my original response, with the current design, if an AI is not pathing, they won't use the path_interact to activate the controller, so they would use the door itself (default) unless the mapper change the spawnarg to prevent them from using it directly.

 

PS: Note there are several spawnarg adjustments that impact the results above, I believe I described default settings.

[SteveL]

I can have the code register all controllers automatically at spawn time, the same way I automatically registered switches for relighting electric lights. That would ease some of the burden on mappers (though not much, and the Outpost and Dufford's authors obviously had no problem with it), but I can't eliminate the "door_controller" spawnarg because it's already been used in two maps. I'd need to combine door_controllers and any controllers targeting the door into a single list.

 

That sounds good to me, if it's do-able. No need to deprecate the "door_controller" spawnarg as it'll still be needed for situations where the controller targets the door indirectly, e.g. through a trigger_relay. For the straightforward set-up it's one less spawnarg to remember.

[grayman]

@RJ:

 

What you're describing sounds like something a mapper would set up in very specific circumstances. What I'm doing solves the general case. I suspect that because the general solution hasn't been available, the path_interact stands in as a satisfactory substitute for certain situations. But it doesn't satisfy the needs of the general case.

 

For example, your description makes it sound like the AI use a controller to open the door initially, and close it eventually, but if it gets stuck or needs unlocking, or the AI is searching near the door while not on a patrol path, they then interact directly with the door, which flies in the face of the door relying on controllers to operate it.

 

And path nodes are usually assigned to specific AI, and not shared. W/o using the path node assignment entities, how do you keep AI from stepping all over each other when they want to operate the door at the same time?

 

I looked for the use of path_interact with doors in existing maps and the only "door" cases I could find are where the mapper wants a certain AI to interact with the door, but not go through it. For example, I used it in SATC to have a patrolling guard open a door and look into a room, and in Home Again to have a guard rattle a locked door, checking to make sure it's still locked. Springheel used it in Reputation to have an AI open a safe (but not enter it). (None of these interactions were with a door controller, though, but with the door itself.)

 

Can you point me to a map where the path_interact solution is used for the general case where several AI use the same door? By "use" I mean they walk through it to get to somewhere. I'd like to see how it operates in-game.

[RJFerret]

Yes, except for the unlocking part, that the mapper would put on the controller logically.

 

Can you point me to a map where the path_interact solution is used for the general case where several AI use the same door? By "use" I mean they walk through it to get to somewhere. I'd like to see how it operates in-game.

 

I'm sorry, that's beyond my ken, I wouldn't know how to find that.

[RJFerret]

But I do know how to make a map. Here's two lever controlled doors, one with two AI crashing back and forth, another with just one passing to and fro.

 

TestDoorLever00.map.txt

 

(Note, as I was making it, early on I found the AI simply left the door open if their frequency of passage was too quick, never manipulating it to close.)

[grayman]

Using 2.01, there are (at least) these issues with your test map:

 

1 - Each door can be operated by both the lever and by (simulated) frobbing. I would think that if a door is operated by a lever, then that's the only way to operate it.

 

2 - If I open a door while the corresponding AI is away from it, he's not aware that the door is open, and he does what his patrol route tells him to do: he goes to the lever and flips it, thus closing the door, causing him to circle around a bit at the door and finally open it by frobbing it, ignoring the lever that he's supposed to use to operate it.

 

3 - The two AI on the same patrol route quickly run into issues as to who's doing what. If they approach the door together, the first guy there flips the switch, opening the door. As he walks to the door, the second guy flips the switch, thus closing the door while the first guy is trying to go through it. They quickly become entangled with each other as they work out who's going to frob the door open. Which one of them eventually does, ignoring the lever that's supposed to operate the door.

 

4 - They're unable to utilize the levers to solve the problems posed when the door stops before becoming completely open or closed.

 

Edit: 5 - Even when the AI use the lever to open a closed door, they walk through the door and neglect the lever on the other side, choosing instead to frob the door closed behind them.

 

So, again, using path_interact to operate levers, and thus a door, is great when the mapper wants to orchestrate a specific sequence between one AI and a door, but it's not very useful when trying to implement generalized door handling.

[RJFerret]

Yes, plus the issues we've already mentioned.

 

Edit: 5 - Even when the AI use the lever to open a closed door, they walk through the door and neglect the lever on the other side, choosing instead to frob the door closed behind them.

 

However #5 is obviously not a universal condition, I chose to set it up so they'd close the doors directly, rather than use levers to close them or prevent them from manipulating them (since most people simply swing shut doors behind them, and I wasn't interested in spending extra time on producing this for you). That was my choice as a mapper. Obviously it could be set up so the AI couldn't manipulate the doors directly, which would cause the additional issues we've detailed previously in this thread.