AI stucks in airlock-like compartment (it clicks on wrong button)

[pakvg85]

Disclaimers

• [X] I have searched the issue tracker to check if the issue has already been reported.
• [ ] My issue happened while using mods.

What happened?

Situation: there is an airlock-like compartment with doors and hatches that are wired to corresponding buttons via some logical elements. When a bot approaches to this compartment, it chooses to click on button that is not directly related to that door/hatch and thefore stucks eternally clicking on wrong button. What I expect to happen: bot chooses the correct button.

Below are few examples and a test submarine file. https://drive.google.com/file/d/12r56BJ-YfCdBNleBv6jaGUcwp_BNZC3-/view?usp=sharing

Example # 1 (https://youtu.be/buuy4-cyvrk) Compartement does not have logical components and the bot successfully opens doors/hatches. Everything is fine.

Example # 2 (https://youtu.be/sglqQcNqjAs) In this example buttons are wired to doors with some logical elements. The goal of logical scheme is: when one door (or hatch) is being opened, the other two neighbour doors should be closed. What happens here: bot comes to first door, clicks on button that relates to that door, and then immediately tries to open the hatch (because that hatch is located pretty close to the door and is accesible from bot's position). But instead of clicking hatch's button, the bot for some reason clicks on the first door's button, and it immediately being closed. I believe it happens because of this: when the bot's current waypoint is a door waypoint, bot tries to find the nearest button that is wired to the corresponding door/hatch, no matter what logic is behind that wiring - any button will fit. In this example it leads to incorrect button.

Example # 3 (https://youtu.be/eUtrQpU0NtI) This example is similair to previous example (# 2) - buttons are wired to doors with some logical elements, and the goal of logical scheme is the same (when one door/hatch is being opened, the other two neighbour doors should be closed). The difference is in starting position of the bot - now it is located to the left of the compartment. What happens here: bot comes to first door, clicks on button that relates to that door. The door opens normally (unlike exmaple # 2), because the hatch's button is located quite far from the first door and could not be clicked immediately. After first door is opened, bot comes to the hatch and tries to open it, but because of the same issue, he mistakenly defines that suitable button for that hatch is the nearest button to his center of mass - the first door's button.

Reproduction steps

1. Open test submarine from "Test Sub.zip" file
2. Place bots at the positions that are shown in examples above
3. Command a bot to follow other bot
4. Bot stucks eternally misclicking

Bug prevalence

Happens every time I play

Version

0.18.15.0

-

No response

Which operating system did you encounter this bug on?

Windows

Relevant error messages and crash reports

No response

[Regalis11]

Thank you for the report!

This is one's a little tricky. It's somewhat similar to an issue we had before where bots failed to figure out which button controls a door if there's some kind of a complex circuit in between the button and the door. I'm not quite sure how we could even approach an issue like this - coming up with a system that can determine how some arbitrary circuit behaves, and that they need to be standing at the other side of some other door before they can open another door (or in this case, a hatch), seems enormously complex to get working reliably. I would maybe instead suggest adding some delays to the doors so the bot has time to get through them before the circuit closes them.

[pakvg85]

Hello, thanks for reply! I understand that it cannot be fixed easy. I have a suggestion about possible solution. Currently the algorhythm seeks all buttons that are somehow connected to the door (no matter what pin is it), and then simply takes the closest button (relatively to the bot) from them all. Possible solution is - algorythm should start from only those door connections that lead only to door input pins (either to TOGGLE_STATE or to SET_STATE pins, with signal value = 1 - so the door could be opened). Then algorythm should recursively do the same thing to the components that are linked via found connections - observe only those connections, that lead only to input pins (with corresponding signal value that in the end will open the needed door).

I will try to implement and test this in my free time, also I appreciate if you let me know if there is something that makes this approach unviable

[MaaiG]

I too often have such problems. I even gave up.

I'm not quite sure how we could even approach an issue like this

@Regalis11 maybe could we link (anchor) the button to the door? Like some other objects in the game, as examle: an oxygen generator with vent etc.

https://user-images.githubusercontent.com/93348499/180618861-bd493b93-4118-44a8-9e3d-d47ec46557c8.mp4

In addition, if the door does not open immediately only after the execution of some cycle, the bot should know that after pressing the button the mechanism will start and the door will soon open. Could it be the some kind of traffic light built into the button? Like a traffic light: Red - bot can press the button. If after press button bot see the red again - No chance. This door will not open! If bot see Yellow - wait for green! Green - Go!

[MaaiG]

By type traffic light:

https://user-images.githubusercontent.com/93348499/180645325-3127939b-69ee-4780-8def-701f152ab06a.mp4

[pakvg85]

Could it be the some kind of traffic light built into the button?

Bots are programmed to keep pressing the closest button every 3 seconds until the door is opened. Eventually the door will be opened if there is any kind of delay mechanic in door's scheme.

[Regalis11]

Addressed in https://github.com/Regalis11/Barotrauma-development/commit/70df33d6f597ced954fc7dc5413eecf5e658bcdc

Some changes to make bots more capable at opening doors that are controlled by some complex circuit (https://github.com/Regalis11/Barotrauma/issues/9600):

• Try to find the correct button by finding the buttons connected to the toggle or set_state connections of the door (previously we'd accept a button connected to any of the door's connections - and there can be e.g. circuits that connect to state_out in order to control some other door).
• Heavily prefer buttons that have been linked to the door in the sub editor, instead of always choosing the closest one (so sub builders can help the bots figure out which button is the correct one).

[NilanthAnimosus]

Tested against dev commit https://github.com/Regalis11/Barotrauma-development/commit/43eb0a8fb27f532a3b23dfaba500cce2c41c4eec, no issues found, closing.

Notes: The AI still gets stuck on the hatches of the provided test submarine but does make it through doors better (Especially if you link all the buttons including hatch buttons).

however the issues with hatches are still problematic with the test sub but as noted by regalis11 in the PR: https://github.com/Regalis11/Barotrauma-development/pull/3523#issuecomment-1238036511, likely too complicated to attempt to fix - but would be easy to resolve by adding delay components to such doors to give the bots time to actually get through.

[MaaiG]

but does make it through doors better (Especially if you link all the buttons including hatch buttons).

In any case, I believe, the buttons that are link with door should have no alternative! Because these connections are created by a subbilder specifically for AI - it is not necessary for him to have alternatives! If the button is link to door, it should be the only one for AI. If the connection is missing or not exist, it will have a logical choice.

Besides, It seems to me that if AI comes closer to doors and buttons, many problems will disappear, as the logic of opening the doors given by the sub-builder will do everything itself. The distance from which the AI presses the buttons (or sees them) is very large.

https://user-images.githubusercontent.com/93348499/199227490-11cbd058-159b-4644-98b2-5f6d0e8b6f3a.mp4

It’s about two meters of playing space! It’s monstrous! AI pushes buttons he can’t reach by hand!