@@ -475,9 +475,6 @@ it through Mapper. After the door has been unlocked, it will remain as such, unl
475475the player locks it once more.
476476***************************************************************************************/
477477procedure map_enter_p_proc begin
478- /* Set up the door state only when the player enters the map, not on game load */
479- if (is_loading_game) then return;
480-
481478 if (local_var(LVAR_Set_Door_Status) == 0) then begin
482479 set_local_var(LVAR_Set_Door_Status, 1);
483480 set_local_var(LVAR_Trapped,TRAPPED_STATUS);
@@ -486,11 +483,20 @@ procedure map_enter_p_proc begin
486483 // Locked status: locked
487484 if (LOCKED_STATUS == STATE_ACTIVE) then begin
488485 // Ensure that we don't have objects "locked open"
489- if obj_is_open(self_obj) then begin
490- obj_close(self_obj);
486+ // Some doors, like Rebecca's basement door, have dynamic status. Active when she's alive, inactive when dead.
487+ if obj_is_open(self_obj) and obj_is_locked(self_obj) then begin
488+ // We don't want to close+re-lock the door on simple game load, that makes gameplay inconsistent.
489+ // So we just unlock. (This shouldn't happen anyway, defensive code)
490+ if is_loading_game then begin
491+ obj_unlock(self_obj);
492+ end else begin
493+ // But if it's map change, close+lock is justified.
494+ // defensive: if the door is "locked open", then unlock first, otherwise close fails
495+ obj_unlock(self_obj);
496+ obj_close(self_obj);
497+ obj_lock(self_obj);
498+ end
491499 end
492- // Ensure locked status
493- obj_lock(self_obj);
494500 end else begin
495501 obj_unlock(self_obj);
496502 end
0 commit comments