Hostile NPCs have free access to your vehicles

[Regularitee]

Recently did one of the storyline missions involving hunting down bandits, and found to my surprise they could just walk up, open the door to my APC, and go inside. Unlike zombie mobs they don't have to bash their way in.

Seems like a bug if all the armor in the world can be thwarted by doorhandle technology.

[BorkBorkGoesTheCode]

Player-locked safes and doors would be useful as well.

[saneman226]

Just use a security system. I have no idea if they are implemented to stop other npcs when the player installs them rather than mapgen. If the security system doesn't do this then I believe it should be added to work like this.

[Regularitee]

I had a security system at the time. They don't lock doors on vehicles (which is why you never need to lockpick open cars doors).

[saneman226]

I am surprised that the security does functionally nothing when installed by the player. Perhaps this could be an easy-pass to get this issue fixed? As for the locking doors, we could have a craftable key and lock that is able to be attached to any door.

[l29ah]

YES THIS SUCKS I HAVE TO KILL EVERY NPC BECAUSE THEY'RE ALWAYS STEALING MY STUFF

[angoddu]

Player-locked doors would be amazing it would solve so many problems I have been having with NPCs. Is anyone currently working on this? I have some C++ experience so if I can figure out how to follow this code I would be more than happy to give it a shot

[Night-Pryanik]

@angoddu, give it a try, we all will be appreciated if you could implement this.

[angoddu]

I'll give it a shot. haven't used C++ in a year or two. I usually have to code in java for work

[Night-Pryanik]

Closed by #22144.

[l29ah]

I cannot avoid NPCs stealing stuff from my doors and seats this way, even if they are outside, can i?

[Night-Pryanik]

No, you can't. You have to put your stuff in a lockable and locked container to prevent stealing it.

[l29ah]

Then the issue is still there, as it talks about the vehicle access being unhindered by doors.

[kevingranade]

Lockable doors should be very similar in implementation to lockable containers.

[mlangsdorf]

So it looks to me like there's two separate but related issues: in src/npcmove.cpp lines 1925:1942 in npc::find_items, NPCs can't pick up items from LOCKED locations, but no vehicle part has the LOCKED flag. The CARGO_LOCKING flag protects some cargo locations, but again can't be applied to (most) doors or seats. Proposed solution: give all vehicle doors and hatches the LOCKED flag. Survivors have to pick the locks of vehicles (or break into them). Also add a PLAYER_LOCKED flag, which replaces LOCKED on the doors and hatches of a vehicle when the PC takes a to be determined vehicle repair/installation action. The PC and their allies treat doors with PLAYER_LOCKED as though they weren't locked. PLAYER_LOCKED could also be an option to add to constructed doors and windows.

in src/pathfinding.cpp:327-358 in map::route, non-friendly NPCs can open car doors and then move to seats to pick up stuff. Since seats can't be locked, you can't stop that from happening. Suggested solution: add a check to the OPENCLOSE_INSIDE || statement, that if the door is PLAYER_LOCKED, they can't open it (but might still bash it or find another way into the vehicle).

Fundamentally, I don't think either of those are really hard changes. But they're tricky enough that I don't want to try implementing them unless the mods think that is a good approach to take.

[Night-Pryanik]

PLAYER_LOCKED could also be an option to add to constructed doors and windows.

That would great and solve a lot of issues. Too bad there is no way for now to add flags to furniture or terrain during runtime.

[kevingranade]

Please consider if this is worth the effort considering the npc will just bash a window instead. There are also a number of weird corner cases around this, like the fact that the player would either need to break or repeatedly pick the locks on the car, since they don't have a key.

Basically, it's working as intended, because the npc can be presumed to be roughly as resourceful as the player, and therefore capable of breaking into the players car if they like. See a post on the forums for a suggestion about a more robust solution.

[mlangsdorf]

At a minimum, having an NPC start bashing on my (hopefully reinforced) windows takes some time and makes noise, which means I have more time to get close to the NPC and engage them in conversation.

Alternately, if the NPC encounters PLAYER_LOCKED on a vehicle, he might decide not to get stuff from inside it at all.

My initial idea for setting PLAYER_LOCKED was PC remembers the vehicle location and has turned on or off the engine. I didn't initially propose it because I figured you thought it would be too easy, but honestly, PLAYER_LOCKED should be something easy to set. And once PLAYER_LOCKED is set, the PC doesn't have to break in anymore because PLAYER_LOCKED has no effect on the PC and their allies. Oops, I should note that in the original proposal.

[kevingranade]

At a minimum, having an NPC start bashing on my (hopefully reinforced) windows takes some time

If you think it's worth the effort, feel free to implement locking and bashing.

Alternately, if the NPC encounters PLAYER_LOCKED on a vehicle, he might decide not to get stuff from inside it at all.

How does a NPC tell a player locked vehicle from a vehicle locked by the original (presumably dead) owner? Also, why would they care?

a to be determined vehicle repair/installation action.

You need to be more specific about this, the original door lock is inoperable (no key), so what is the player replacing it with?

[mlangsdorf]

Proposal v2: New vehicle part: vehicle tag, requires Mechanics 0, a can of spraypaint or a permanent marker or survival marker, and 30 minutes. Applies the PLAYER_OWNED flag to all vehicle components (adding new components gives them the flag, removing components causes them to lose the flag). Intelligent NPCs who can see the PC and are not hostile or fleeing won't attempt to take stuff from a PLAYER_OWNED location - you're basically telling them "back off" when they get close. Monsters don't care, hostile NPCs are hostile and may steal stuff before killing you. The tag part represents the PC writing warnings all over his car, which NPCs can ignore when the PC isn't physically present to enforce them.

New vehicle part: (player) security system, requires the same thing as adding a security system does normally and is now the only option for a PC to install a security system. (player) security system never spawns on vehicles, it can only be installed by the PC. Adds PLAYER_OWNED to all vehicle tiles (same as the vehicle tag) and PLAYER_LOCKED flags to doors and hatches. Non-friendly NPCs can't steal stuff from closed PLAYER_LOCKED doors or hatches or open them from the outside, but can still bash the vehicle. The (player) security system represent the mechanically and electrically adept PC rekeying the locks on the car and creating new ones as needed.

I think this addresses the concern from the playbase (we want a way to prevent non-hostile NPCs from stealing from our vehicles after they give us a mission but before we move away from them) while still addressing Kevin's concerns about realistic behavior of NPCs. And it makes security systems useful in a sensible way.

Stretch proposals: Add a tool item, made from metal (requires forge, anvil, hammer, etc), that is a lock that can be installed on doors and windows and makes replaces them with doors or windows with the PLAYER_OWNED and PLAYER_LOCKED flags, with the same effects as above. Zombies will still burst through a PC's windows at home, and other hostile NPCs might try to break in, but that friendly medic NPC won't go randomly rummaging through your stuff. Add a construction item: warning sign. Requires paint, permanent marker, or survival marker, some two by fours, nails, and a hammer. Applies PLAYER_OWNED to the entire map tile.

Double stretch goals: NPC warning signs, so bandits and hostile NPCs can declare their own territory which the PC is free to ignore.

[Epictyphlosion]

Has adding the ability to lock car doors been suggested already?

[mlangsdorf]

Yes.

[GearheadLydia]

I have an idea that might be useful: add a property of some sort to the security system item, like an "owner tag", that is set to some random value that is NOT the player's name when the vehicle is initialized. When the player installs a security system into a vehicle, or hacks an existing security system, the new security system's "owner tag" is the name or ID of the player, which means that the player has access.

Granting access to friendly NPCs is a more difficult question, but I'm wondering if that could be integrated into another idea I had: creating wearable IFF transmitters for each of the NPCs, so that player-owned turrets wouldn't shoot them (#22801). Maybe the IFF transmitters could also serve as car keys for each of the vehicles "owned" by the player, or at the very least, the same kind of "I'm with the player character!" verification protocol could maybe be reused with some modifications.

[Zireael07]

Alternately, null owner tag when vehicle is initialized, and check if tag exists and is player's tag... less spurious data to keep.

[GearheadLydia]

That's true. It wouldn't really matter whether the deceased owner of an abandoned vehicle is described as Fgsfds or a blank string.

[kevingranade]

IFF transmitters and receivers are a bit out of scope for player craftability.

[GearheadLydia]

Hmm. Fair. Maybe that should be restricted to car keys.

(Also, I still feel that the problem of turrets shooting friendly NPCs should have some work-around -- unless turrets are explicitly being balanced against by the fact that they force you to be a solo act, which is reasonable for gameplay purposes, if unintuitive.)