I'm on my second playthrough of Fallout 4 right now and just ran into this bug.
It is mind-blowing to me that this game has been out for nearly 10 years and Bethesda never bothered to patch or fix this.
I found posts describing this problem going back all the way to November of 2015.
I'm using the Unofficial Fallout 4 Patch as well, which also evidently doesn't address this.
I would've never even realized something was broken had I not been trying to side with BoS this playthrough.
I was looking up a guide on how to do their quests and realized something was going wrong when I hit a roadblock where Danse was not having anything unique to say and the military frequency was just silent.
This is a serious, game-breaking issue that has apparently just never been fixed until now. Wild.
... you should read some of the comments before adding your own. This bug is actually introduced by UFO4P. It's not in the base game. (that being said, it's a super wonky bug that's apparently pretty tough to get rid of)
I've also worked directly with Arthmoor and Sclerocephalus to get this resolved directly in the unofficial patch, which should set the affected gate up to work properly and also close/open it as needed for players on existing saves who have it in the wrong state.
It's funny. I asked Arthmoor about submitting this to the patch and he thought they already had a fix for it. Apparently that's the only reason there isn't already one, is that everyone on the team remembered discussing the problem and thus assumed it had been patched.
This issue is caused by UFO4P, the door out of the control room is locked in vanilla disallowing you from leaving any other way, I reported it to them last year when I was working on my own Fallout 4 bugfix mod, and was subsequently ignored.
I will admit, I am salty that they ignored me after I reported it three times over the course of UFO4P's lifespan only for them to only fix it now, but thank you Glitchfinder for finally forcing their hand to fix a bug they created.
I don't blame them for this. I just spent four hours debugging it and their code is correct. That door is just super broken somehow. This is the chain of events that leads to the door opening when it shouldn't:
When in FortHagen01 and approaching the load door for FortHagen02, the player hits an invisible trigger box that sets stage 101 of MQ106.
Stage 101 attempts to open that door. This can fail in the base game, so the unofficial patch modifies the stage to wait for the door to load and, if it doesn't or can't, sets a custom flag that forces it to open/close next time it loads.
The player enters the load door and loads FortHagen02.
The door loads but does not properly fire the OnLoad event that the unofficial patch uses to change its state. Somehow, the door is functional and open at this point in spite of this. More accurately, the event fires but does not appear to recognize the flag set in step 2. This may be some form of engine level synchronization issue caused by loading the door too quickly after setting stage 101 of MQ106.
The player enters another invisible trigger box just before entering the boss chamber where Kellogg is. This box sets stage 105 of MQ106.
Stage 105 closes the door.
The door now properly fires a load event if it failed to properly fire earlier. This load event recognizes the flag set in step 2 and opens the door. Note that this is not something that normally happens. Activators like this door should not be capable of animating without being properly loaded, and they do not normally fire a load event after completing an animation.
I've submitted a proposed change to Default2StateActivator that resolves point 7 for them.
The part that has me surprised is that this is not supposed to be a possible state for the door to be in. With the code as it is in the unofficial patch, UFO4P_ShouldActivateOnNextLoad can only be changed to true on the door while it is unloaded. The code then checks that variable in an OnLoad event and will open or close the door and clear that flag.
Similarly, it should not be possible for an object to animate when its 3D isn't loaded, and it shouldn't be possible for an object's 3D to be loaded when the object's underlying data is not. (Precombines aside, anyway. Those are a different matter.) And yet, this object is loading its 3D and properly processing the SetOpen function as expected. The unofficial patch even modified that function to abort rather than throw an error when the object's 3D isn't loaded.
But somehow, the object is successfully loading its 3D without fully loading its data, and then firing an OnLoad event after closing the door when entering Kellogg's room. Note that it does actually fire an OnLoad event when you first enter the cell, but that event does not properly read the state of UFO4P_ShouldActivateOnNextLoad when it does so. (I verified this)
Similarly, the door will only fire an OnLoad event after closing in the circumstances mentioned above. If I modify the OnLoad event to add specific functions such as GetFormId() (which I tried as an attempt to limit debug prints while testing this), it will fully load the door when the cell loads, and the OnLoad event will not fire after the door closes.
Overall, this seems to be an extremely unique engine-side edge case tied to persistence and load states. It can be worked around but it shouldn't need to be.
Edit: Further inspection shows the actual door model itself may be at fault, and that the anomalous second OnLoad event is actually the first event resuming after the door closes, since closing the door fires off an animation event that the OnLoad event was paused and waiting for.
Funny timing, I JUST learned about this the other week because I was confused as to why the prydwen never arrived. I assumed that it was a change from my alt start mod but nope.
It's weird, the way the room is laid out, you would assume that the devs wanted you to go back the way you came.
Didn't know this problem could be fixed, and got into such a mess of missions which could not conclude I just went with the institution and killed all BoS. Tried jumping in a vertibird with the Railroad once, and it flew forever into the vast nothing beyond the map :D (because no Prydwen had arrived to fly to).
Thank you.
Edit : Having already killed the BoS, decided to go see what difference this now makes. Went to Fort Hagen garage and got the announcement before entering the building proper, went back out of the garage and watched the majestic appearance of the Prydwen. Made my way to the airport and then found the Prydwen wreckage (as I have already cleared the area this I guess should be expected). so at least in my game it has made anything waiting to progress get to completion and no loose ends are left behind in the scripting. Had a few more BoS to kill in the wreckage.
You did it again! Another essential fix. I was waiting for someone to fix this ever since I went out the wrong door. I actually enjoyed the game without the freaking vertibirds taking all my kill XP. I just went back later in the game and unlocked the right door. Still worked for all the Brotherhood stuff after that, but I think it screwed up my end game.
I know more than a few players who just got lost and went back out the other way. Reddit used to have a whole bunch of threads about this bug.
If you want to grab a copy of the script and utilize that on an activator for your fort hagen alternative entry mod, feel free to do so. I do recommend changing the namespace on the script to prevent yours overwriting mine or vice versa, but aside from that it would do precisely what you had trouble accomplishing for your original plan.
Glitchfinder, PER11 i guess :) Before that and the idea came to my mind when seeing your mod appear i need to check if i can force the trigger to appear once Kellogg is dead. My idea is to create the trigger as big as Fort Hagen is covering all the exit points. I will let you know.
You don't need to force the trigger to appear once he's dead, it will simply not fire if the player has yet to kill him. I had to be very careful about the conditions because players can walk up to the trigger boxes at any point.
The problem with covering all of Fort Hagen (and the reason I covered the exits individually) is that the parking garage exit is underground, which means the flyover would start before you've properly "left" Fort Hagen.
You don't need to force the trigger to appear once he's dead, it will simply not fire if the player has yet to kill him. I had to be very careful about the conditions because players can walk up to the trigger boxes at any point.
Yes, but the last trigger to force the Prydwen to appear is tied to the Terminal afaik. So if player char does not open the door via Terminal nothing will happen, and BGS set it, so you cant do anything else rather than open the Terminal at least if you leave the building from the top.
I didnt even think about not leaving the building from the top. Henceforth your mod highlights a flaw in the base game.
The problem with covering all of Fort Hagen (and the reason I covered the exits individually) is that the parking garage exit is underground, which means the flyover would start before you've properly "left" Fort Hagen.
I can see alot of super trigger boxes in the base game. So my idea is just this. Create a super trigger box which is one trigger box so big that it will cover all the exit points, top, bottom, left, right, all. Once the player will leave FortHagen01/02 he will automatically hit the super trigger box and the Prydwen should appear like you did in your mod. So no need to use the Terminal which was a problem in my initial idea for the Fort Hagen circumventer.
Its the same principle like BGS used to force the manhole to appear/not appear in the V114 mod i released. For Fort Hagen it should work also at least if the base scripts for Fort Hagen have all the options like V114 had.
Yeah, the script in this mod is a modified derivative of the script fragment the terminal uses to activate the flyover. Copying this mod's triggerbox and placing it over the elevator exit area would accomplish the same thing it does for the other entrances, without needing to run through the terminal itself.
Most of the big trigger boxes around Hagen are ones that set quest stages as you approach. They're how the game knows when to have Kellogg taunt you through the loudspeakers, for the most part. There's a big angled blue one (that never gets turned off afterwards) that gets used to clear the weather if you exit via the elevator. I opted not to extend that one because it's rather superfluous due to how long it takes to actually have an impact.
26 comments
It is mind-blowing to me that this game has been out for nearly 10 years and Bethesda never bothered to patch or fix this.
I found posts describing this problem going back all the way to November of 2015.
I'm using the Unofficial Fallout 4 Patch as well, which also evidently doesn't address this.
I would've never even realized something was broken had I not been trying to side with BoS this playthrough.
I was looking up a guide on how to do their quests and realized something was going wrong when I hit a roadblock where Danse was not having anything unique to say and the military frequency was just silent.
This is a serious, game-breaking issue that has apparently just never been fixed until now. Wild.
Thanks for this.
(that being said, it's a super wonky bug that's apparently pretty tough to get rid of)
Anyway, yes. This is almost certainly going to be in the next update for the unofficial patch.
I will admit, I am salty that they ignored me after I reported it three times over the course of UFO4P's lifespan only for them to only fix it now, but thank you Glitchfinder for finally forcing their hand to fix a bug they created.
- When in FortHagen01 and approaching the load door for FortHagen02, the player hits an invisible trigger box that sets stage 101 of MQ106.
- Stage 101 attempts to open that door. This can fail in the base game, so the unofficial patch modifies the stage to wait for the door to load and, if it doesn't or can't, sets a custom flag that forces it to open/close next time it loads.
- The player enters the load door and loads FortHagen02.
- The door loads but does not properly fire the OnLoad event that the unofficial patch uses to change its state. Somehow, the door is functional and open at this point in spite of this. More accurately, the event fires but does not appear to recognize the flag set in step 2. This may be some form of engine level synchronization issue caused by loading the door too quickly after setting stage 101 of MQ106.
- The player enters another invisible trigger box just before entering the boss chamber where Kellogg is. This box sets stage 105 of MQ106.
- Stage 105 closes the door.
- The door now properly fires a load event if it failed to properly fire earlier. This load event recognizes the flag set in step 2 and opens the door. Note that this is not something that normally happens. Activators like this door should not be capable of animating without being properly loaded, and they do not normally fire a load event after completing an animation.
I've submitted a proposed change to Default2StateActivator that resolves point 7 for them.The part that has me surprised is that this is not supposed to be a possible state for the door to be in. With the code as it is in the unofficial patch, UFO4P_ShouldActivateOnNextLoad can only be changed to true on the door while it is unloaded. The code then checks that variable in an OnLoad event and will open or close the door and clear that flag.
Similarly, it should not be possible for an object to animate when its 3D isn't loaded, and it shouldn't be possible for an object's 3D to be loaded when the object's underlying data is not. (Precombines aside, anyway. Those are a different matter.) And yet, this object is loading its 3D and properly processing the SetOpen function as expected. The unofficial patch even modified that function to abort rather than throw an error when the object's 3D isn't loaded.
But somehow, the object is successfully loading its 3D without fully loading its data, and then firing an OnLoad event after closing the door when entering Kellogg's room. Note that it does actually fire an OnLoad event when you first enter the cell, but that event does not properly read the state of UFO4P_ShouldActivateOnNextLoad when it does so. (I verified this)
Similarly, the door will only fire an OnLoad event after closing in the circumstances mentioned above. If I modify the OnLoad event to add specific functions such as GetFormId() (which I tried as an attempt to limit debug prints while testing this), it will fully load the door when the cell loads, and the OnLoad event will not fire after the door closes.
Overall, this seems to be an extremely unique engine-side edge case tied to persistence and load states. It can be worked around but it shouldn't need to be.
Edit: Further inspection shows the actual door model itself may be at fault, and that the anomalous second OnLoad event is actually the first event resuming after the door closes, since closing the door fires off an animation event that the OnLoad event was paused and waiting for.
It's weird, the way the room is laid out, you would assume that the devs wanted you to go back the way you came.
Didn't know this problem could be fixed, and got into such a mess of missions which could not conclude I just went with the institution and killed all BoS.
Tried jumping in a vertibird with the Railroad once, and it flew forever into the vast nothing beyond the map :D (because no Prydwen had arrived to fly to).
Thank you.
Edit : Having already killed the BoS, decided to go see what difference this now makes. Went to Fort Hagen garage and got the announcement before entering the building proper, went back out of the garage and watched the majestic appearance of the Prydwen. Made my way to the airport and then found the Prydwen wreckage (as I have already cleared the area this I guess should be expected).
so at least in my game it has made anything waiting to progress get to completion and no loose ends are left behind in the scripting. Had a few more BoS to kill in the wreckage.
I know more than a few players who just got lost and went back out the other way. Reddit used to have a whole bunch of threads about this bug.
Before that and the idea came to my mind when seeing your mod appear i need to check if i can force the trigger to appear once Kellogg is dead. My idea is to create the trigger as big as Fort Hagen is covering all the exit points. I will let you know.
EDIT: Thank you! :)
The problem with covering all of Fort Hagen (and the reason I covered the exits individually) is that the parking garage exit is underground, which means the flyover would start before you've properly "left" Fort Hagen.
Yes, but the last trigger to force the Prydwen to appear is tied to the Terminal afaik. So if player char does not open the door via Terminal nothing will happen, and BGS set it, so you cant do anything else rather than open the Terminal at least if you leave the building from the top.
I didnt even think about not leaving the building from the top. Henceforth your mod highlights a flaw in the base game.
I can see alot of super trigger boxes in the base game. So my idea is just this. Create a super trigger box which is one trigger box so big that it will cover all the exit points, top, bottom, left, right, all. Once the player will leave FortHagen01/02 he will automatically hit the super trigger box and the Prydwen should appear like you did in your mod. So no need to use the Terminal which was a problem in my initial idea for the Fort Hagen circumventer.
Its the same principle like BGS used to force the manhole to appear/not appear in the V114 mod i released. For Fort Hagen it should work also at least if the base scripts for Fort Hagen have all the options like V114 had.
Most of the big trigger boxes around Hagen are ones that set quest stages as you approach. They're how the game knows when to have Kellogg taunt you through the loudspeakers, for the most part. There's a big angled blue one (that never gets turned off afterwards) that gets used to clear the weather if you exit via the elevator. I opted not to extend that one because it's rather superfluous due to how long it takes to actually have an impact.