During my multitude of Fallout 3 play-throughs, I've always suffered from the occasional crash. This time around, I noticed something that seems to be recurring: I usually start getting crashes after getting into and then leaving the "Underground Hideout by danthegeek:"
http://www.nexusmods.com/fallout3/mods/9592/?tab=2&navtag=http%3A%2F%2Fwww.nexusmods.com%2Ffallout3%2Fajax%2Fmodfiles%2F%3Fid%3D9592&pUp=1
It's not an all-the-time thing. It just seems to start happening after leaving the hideout for the first time. This time, it was as I walked out of the Hideout's modded area into the base game's Rivet City area. So, out of curiosity, I thought I'd take a look at what I could find with "FO3Edit 3.0.31 EXPERIMENTAL by ElminsterAU updates by TES5Edit team:"
http://www.nexusmods.com/fallout3/mods/637/?tab=2&navtag=http%3A%2F%2Fwww.nexusmods.com%2Ffallout3%2Fajax%2Fmodfiles%2F%3Fid%3D637&pUp=1
According to that tool, the Underground Hideout has four "Identical to Master records" and two objects that it has Deleted from the base game. With a bit of playing, I found three of the four identical records:
- [06] OriginalUndergroundHideout.esp Worldspace 0000003C <Wasteland> Block 0, 0 Sub-Block 1, 1 0000173B <RegulatorHQ>
- [06] OriginalUndergroundHideout.esp Worldspace 0000003C <Wasteland> Block 0, 0 Sub-Block 0, 3 000014AB
- [06] OriginalUndergroundHideout.esp Worldspace 0000003C <Wasteland> Block 0, -1 Sub-Block 2, -3 00000E2D Temporary 0006AC08
I haven't been able to figure out what the fourth record is. The two Deleted objects are:
- [06] OriginalUndergroundHideout.esp Worldspace 0000003C <Wasteland> 00002DB4 Persistent 0006ABDE
- [06] OriginalUndergroundHideout.esp Worldspace 0000003C <Wasteland> Block 0, 0 Sub-Block 1, 1 0000173C Temporary 0005FA23
The identical records aren't necessarily a bad thing: they could lead to some issues with changes from other mods not necessarily sticking. But, these kinds of things should be removed from the original mod. On the other hand, the Deleted records can be bad. If another mod references those records from the base game, and this mod (or yet another) has deleted them, the game can crash. Deleted records should be marked as Disabled instead of Deleted.
After viewing Gopher's video on "Cleaning Your Master Files:"
http://www.youtube.com/watch?v=fw3g_N1jcZQ
I used FO3Edit 3.0.31 to automatically fix those problems. I've been playing with the "cleaned" mod for a while and haven't noticed any negative results. So, I'm assuming it's safe to do this. Unless someone comes around and tells me it's not a good thing to do, I'm recommending you do the same thing to your setup. I'm not adding this to my "DALCO Fixes for Underground Hideout:"
http://www.nexusmods.com/fallout3/mods/16945/?tab=1&navtag=http%3A%2F%2Fwww.nexusmods.com%2Ffallout3%2Fajax%2Fmoddescription%2F%3Fid%3D16945%26preview%3D&pUp=1
since I'm not sure if these kinds of issues can be fixed in a mod to a mod. If you want to do this yourself, here's the process I followed (I highly recommend you watch Gopher's video, above, first):
- Start FO3Edit, right-click on the list of mods that comes up, and choose Select NONE.
- Find UndergroundHideout.esp on the list, check it, and hit the OK button.
- After everything has finished loading (look for "Background Loader: finished" at the bottom of the Messages tab on the right panel), right-click on the UndergroundHideout.esp entry in the left panel and select "Apply Filter for Cleaning."
- Watch the status information on the title bar of the window. When everything is done being filtered, right-click on UndergroundHideout.esp again and select "Remove 'Identical to Master records'."
- You should get a pop-up warning about editing the mod. Once the countdown has finished, accept it.
- After a bit, you'll see the following at the bottom of the Messages tab on the right panel: "... Processed Records: 6277, Removed Records: 4...". That means the four records that were included in the mod but were unchanged from the base game have been removed.
- Again, right-click on UndergroundHideout.esp and select "Undelete and Disable References."
- After a bit, you'll see the following at the bottom of the Messages tab on the right panel: "... Processed Records: 6273, Undeleted Records: 2...". That means the two records that the mod had Deleted from the game have been changed to Disabled. Now, if another mod references those records, they'll still exist in the game and won't cause trouble.
- Finally, save your changes. Either hit [CTRL]-S or just close the program. You'll get a dialog asking you where you want to save your changes. Make SURE only UndergroundHideout.esp is checked and nothing else. If it says something else, you've made a mistake and need to uncheck everything so it doesn't save. Then close the program and repeat the process. I'd also recommend checking the "make a backup" box at the bottom of that save dialog.
You should be done. Fire up FO3 and make sure everything runs as expected. If it doesn't, find that FO3Edit Backup file in your FO3 Data directory, rename it to UndergroundHideout.esp (i.e., remove the trailing stuff FO3Edit tacked onto the name), and copy it back to your Data directory. You should be back to your original setup (again, run the game to check that everything is working).
videogame_asset My games
Install hundreds of mods with the click of a button.
Notifications
4 comments
Should be possible to include those fixes in Underground Hideout's .esp by pasting from the fix as well. Haven't tried it but should work, so I'll leave out the details...
But now that you mention it, I seem to recall comparing the pear entries to the other fruits & veggies and that difference may have been what prompted me to make the change and try it to see what would happen...
OK, just ran FO3Edit and checked again and here's what I noticed: Despite what might or might not be going on code-wise, what made me think it would work is if you look at the references just above the pear that have to do with the apple, you'll see there's one called 'EHAppleRipeRef'. This variable does NOT have the 'Initially Disabled' flag set! However, the original entry named similarly for the pear DID have that flag set. You will however also see that 'EHAppleNotRIpeRef' does have that flag and so does the matching one for the pear called 'EHPearNotRIpeRef'. So, I think the way the code might have seen things would have been like the following:
- When the mod is first installed and run and you then entered the Hideout, all the stuff in the garden would have been ripe and ready to pick right away. And the first batch of pears would be there too because the objects representing the pears had been created during the mod's initialization. But, because the flag was set to disabled, the pears wouldn't ripen (or grow again actually) because of that flag state and no new pear objects get created to pick and move to player inventory.
BTW, I should mention that all my reference numbers should have had XX as the first two digits and that people should substitute their load order's number for the Hideout's .esp when looking to make changes. My mistake - it's been awhile since I've played around with Fallout 3 and forgot about that detail.
Anyway, as far as variables go, I do recall that many scripts run using the global variable 'GameDaysPassed' to determine when to do what. I know that Underground Hideout's code is no different as I saw it used in both the apple and pear's scripts (and no doubt many of its other scripts do too!). Whether any of this code actually runs during the game I cannot say. None of the other stuff in the garden seems to have problems regrowing so doesn't this mean their scripts are being executed? All I know is that logically, if everything else is OK, that flag state is what screws up the pear - at least as far as I could determine.
If it can be proven it's not the case then I'll happily retract my advice...
http://www.nexusmods.com/fallout3/mods/16246/?
Initially, I thought that since someone else had already fixed the problem, I'd just use his method. But, lately, I had been thinking just like you: why get another mod when it could be fixed in mine? I'll have to look through the logic in the original Underground Hideout. From just cursory glances, it looks like he's got several variables in various places that he declares and uses but never initializes. So, hunks of code never run. With your method, don't the pears immediately re-grow (i.e., harvest them, wait a few seconds, and there they are again?)? The code to disable them until some time has passed looks like it's in one of those areas that won't ever run.
I thought I would also add my two cents and say that while you're at it, you might want to fix another bug that's present in the UndergroundHideout.esp. It's a known fact that it contains an error that causes the pear tree in the hydroponic garden to NOT supply new pears after you pick the first crop. There is a separate mod that addresses this issue but I've looked into the problem on my own and found that an extra mod isn't needed if you're proficient at using FO3Edit. Why run another .esp if you can fix the original I say?!
Using FO3Edit, you can edit the proper entry and fix the problem - I've tested it and it works. So, for anyone that wants to fix it on their own, here's the procedure:
- Load 'UndergroundHideout.esp' using Dave's load instructions (no need for me to repeat them here)
- Goto entry: Cell>Block0>Sub-block6>1B001DEC>Persistent
- Near end of entries, find 1B13EF3A 'EHPearRipeREF'
- On right-side view, locate Record Flags under Record Header
- Right-click over flag entry 'Initially disabled'
- Select 'Edit' from context menu
- In dialog box, press DEL to remove the number 1
- Press ENTER and the flag entry 'Initially Disabled' should disappear
- Save the changes or exit FO3Edit to get the prompt to save
- Done! Pears should now regrow just like the other fruits & veggies