UFO4P does not contain maximum height data for Nuka World (at least my copy does not). But even if it did: Because UFO4P goes fairly high in the load order, any mods that edit NW worldspace would override any fix made in UFO4P anyway - Unless the modmaker included UFO4P as a master, that is. And if they did, their mods would quite obviously not work without UFO4P, then.
The main issue is of course the inexplicable lack of MHDT data in the DLCNukaWorld.esm Master file itself. It took literally one click and about 20 minutes of waiting to generate this data on my rig. So, is Beth just lazy AF? Did the executing studio not know any better? Who knows! But this means that, if you're making a mod and add an override of a NW Cell or Worldspace record, the override won't have any MHDT data either. So, even if another mod above yours (in the load order) would add the data, your mod will be conflict winner and it's empty (non-existent) MHDT records will obliterate any data added by any mods higher up in the load order.
Now, trying to be clever and putting this plugin below any NW worldspace mods will indeed enable Vertibird flight w/o crashing through mountains. But very unfortunately, this approach will most likely also break all of your NW worldspace mods. Dysfunction is even 100% guaranteed for NW settlement mods. This is because the plugin will revert cell location LCTN (and other things) back to DLC default.
It's a kind of effed-up situation.
The solution is to merge the MHDT data either directly into your NW Mods, or into specific patches made for them: For my own use, I merged the MHDT records from this mod into a custom made previs patch that covers both Nuka World Park Settlements and Nuka World Glory. And because that previs patch naturally goes below all other NW mods in my load order, everything works out perfectly smooth.
In case anyone wonders about installing this mod and have either PRP or FCF installed as well, you can safely skip this one.
PRP has generated MDHT entries for Nuka World (freshly made) since 0.57, and FCF I believe merges this plugin's generated data since 1.2. You only need this plugin for cases like using Boston FPS Fix, even with my replacer on top.
Well, it's probably closer to the year 6000 than 2023, but I continue to keep this mod in my load order and patch ANY Nuka World Mods I download or make to include this data. Doing that has allowed me to drop some Zetans into this world space and fight their "ufo's" all over the place! It's also VERY necessary if you want the alien craft in M's Abominations (Get VATS PATCH!) to fly around and attack you properly in Nuka World.
BTW, since I wanted to drop some of these alien monstrosities onto Genesis - Raintree Island - Settlements as well, I gotta thank you again for cluing me in on the Max Height generation process which is now part of an optional download for that mod. Flying saucers on a tropical island is just AWESOME!
Also, incorrect cell information caused by the CK in M's Abominations (And VATS patch) is easily overwritten by THIS mod, so that means you'd ONLY have to fix Far Harbor cells with an F04Edit patch to keep from having issues there as long as this mod loads AFTER it.
Anyway, sorry to resurrect a relatively dead comment stream but I just wanted to thank you again for sharing this wonderful mod and helping me to make my personal modding dreams come true. Good on ya! Game on!
Thanks Niston... Now I can low fly all over Nuka World to acquire all my locations in the pipboy... especially I will fly ALL over and around that NW RR area and embedd everything into my saves for a while.. then i will RETRY that 'Nuka World Command Post II' mod I was talking about elsewheres... and if necessary I will try that TPC command if the terrain is gone with that mod
I recently downloaded this mod and got an error in Fo4 Edit. the error is as follows: Errors[0]: [CELL:02002FB9] (in NukaWorld "Nuka-World" [WRLD:0200290F] at 6,18) Errors[1]: CELL \ XCRI - Combined References \ References \ Reference \ Reference -> [01007DCF] < Error: Could not be resolved >
This error is in Block 0,0; Sub-block 0,2 The error was already in the NukaWorld master, so it is not a new error introduced by this mod.
Any idea how to fix this? Or do you think simply removing this Null reference would be suffice?
I started comparing the Sub-Blocks next to the block 6,18 and they all have a reference to a placed object. But 6,18 was missing its reference to a tree cluster. Since this is the only reference in 6,18 and it misses a single reference, I made the conclusion that this must be the correct reference. [REFR:0204F042] (places TreeBlastedForestCluster02 "Trees" [SCOL:0013463C] in GRUP Cell Temporary Children of [CELL:02002FB9] (in NukaWorld "Nuka-World" [WRLD:0200290F] at 6,18))
(P.s. for those who want to "fix"/try this themselves: The load order creates the first two numbers, so read it like "XX04F042" where XX is the load-order number of NukaWorld.)
For future reference, errors like this happen when the CK drops a master during save. (You ESM all plugins being considered for precombine/previs generation or things like this happen.)
I merged the MHDT records from this mod into a custom made previs patch...
@niston More detail on this fix would be useful. This detail should probably explain what a 'previs patch' is, even if we figure out that pre-vis is part of how the game engine represents world space, or is it?
Im asking this because there seems to be a persistent problem here, which this mod doesn't entirely fix.
Previs is an optimization system the game uses, to accelerate graphics display. It works by pre-calculating visibility at design time (while the plugin is being created), as opposed to calculating visibility at runtime. Visibility as in, what parts of the 3D scenery are visible to the player character at any given position in the game world. This is nice for console and potato computer gaming and it allows Bethesda to gloss over some glaring mistakes in their plugins with a handwaving clicky-button-push...
But of course, convenience and performance gains come at a steep cost: Changes made to the scenery after visibility was pre-calculated won't be displayed properly under the acceleration scheme. A well known symptom is the blinking of everything in- and out of existence when you scrap the hedges in Sanctuary and then walk through the spot where they used to be. This is because, during previs pre-calculation, it was determined that nothing behind the hedge is visible to the player when they stand infront of it. So if you then scrap the hedge but leave the previs, the game will not render anything behind the hedge... Even if the hedge had been scrapped and is long gone.
Mods with recalculated previs data, on the other hand, are quite the compatibility nightmare. It will be simply impossible to use certain combinations of mods with each other, because previs is calculated for areas that span more than a single cell, where two or more mods might supply conflicting previs data for the same area, independently. But, unlike records in a plugin, previs data cannot be merged at all. This leads to the problem of mutual exclusivity, and of course, the only real solution to this dilemma is to recalculate previs on a per-installation basis (ie, the end user / gamer would have to do this for their particular load order, and redo it each time the load order changes).
Doing this is a real PITA; It takes a long while and the tools to do it are iffy and will crash more often than not.
Sooo... a previs patch usually works by disabling previs and removing precombined geometry information (the previs system relies on precombined geometry to work, and also, precombined geometry is not scrap friendly) for specific Cells -Settlements, quite ususally- to force the game to calculate visibility for that cell at runtime. By their very nature, these patches go in the load order after the mod(s) that makes changes to worldspace, so they are a nice place to merge the MHDT info into.
I think i understand. thanks. its interesting how the engine works, and how some of its most difficult problems have to do with the worldspace definition.
One thing that you seem to be saying is that there is null overwrite in the MHDT, meaning that instead of being an empty field it contains a signal for its emptiness. that sounds funny, but its something I didnt understand before. I would have expected missing data not to be able to overwrite present data, meaning the MHDT data would persist once it was added to the record of locations or co-ordinates.
I guess it makes sense that fixing any worldspace error in a master plugin would be difficult, since that kind of data is referenced often. I can even imagine a weather mod using a skybox or height data for clouds, containing and overwriting MHDT data for an whole group of cells. But you are saying it isnt the height data fixed by this mod which is overwritten, its the loss of the what-is-visible-from-where table, the pre-vis thing, which causes the problem.
So, without a patch, will even small changes to the world-space *co-ordinates* will cause terrain 'blinking' in that space?.
I think that is the persistent problem I was referring to, or maybe it was just the lack of a ready-made patch. But it seems patches must be custom made to each load order. Its like the LOD problem in earlier games. ... Q: How do we make the patch? A: Use CK.
Q: How do i know which mods change Nuka-World in a way which needs to be patched? A: Anything which adds, removes, or moves any non-actor (inanimate) object in NW will need to be patched. FO4Edit can tell you which mods do this.
How about: Are there any other mods which do this I should know about?
This is correct, an empty value in a mod can overwrite that value in the master with it's "emptyness".
But this altitude fix mod is not directly related to previs, sorry if I made that somewhat unclear. I just mentioned the previs patch as an example to merge the MHDT data into, because previs patches go mostly far down in the load order, so they are an ideal place to overwrite other mods' overwrites.
If you want to look at mods or make simple patches, I'd recommend xEdit (aka FO4Edit) over the Creation Kit for various reasons. xEdit has this nice treeview where it'll show all the records in the mod for inspection and editing. You can even load several mods into xEdit at once and apply a Filter to show conflicts. It will then highlight records and values that are conflicting/being overwritten. This is very helpful to identify problems and make patches.
We live in a Post-Pareto world, where corporations now call it a day after 80% of the job is done.
You can see this in the auto industry, in computer software, in consumer electronics, basically everywhere. The last 20% of the work (such as testing, for example) is left as an exercise to the customer. Who none the less pays 100% of the price.
They get away with it because consumers accept this. See Fallout76.
Yeah I guess it's true it's basically everywhere. 80/20 as a general rule that can sway to either direction.
I see it in crafting musical instruments.
Though it is fun to mod games, I only do textures, it would be nice to not have to deal with bugs/glitches in the base game.
Edit: -------
I mean't I only do textures myself but I do install and try and test just about any 'cool' mod I can find! XD
I must say it has developed and deepend my understanding of computers and games just in general. At least a little bit!
Programming and designing features isn't easy when there's lots of thing to take into consideration. Do that with computers and programs that have their own bugs and problems and your crying and doing it!
You're not normally supposed to be able to fly a vertibird in Nuka World, and there are never any NPC vertibirds there, so they didn't see a point in giving the buildings height data. And in my experience, the only other buildings vertibirds fly through is the very top of the tallest buildings in downtown Boston.
Greetings,I don't know if I'm overthinking this or not. Do I just extract the .esp file into the main Fallout 4 installation folder? Or does it need to go somewhere more specific? Many thanks.
I just now found this mod. Thanks to the new mod Flyable Personal Vertibirds, https://www.nexusmods.com/fallout4/mods/47187?tab=posts&BH=2. Before this new vertibird mod I used a mod that allows vertibirds in NW and FH. Got tired of flying through buildings and hill sides in NW.
I spent some time in FO4Edit and added the height data from your esp to the mods that I use that effect NW. I then edited your esp to eliminate the conflicts. Thanks for this. It has always confused me why Bethesda never had height data in the main esm. Endorsed.
25 comments
The main issue is of course the inexplicable lack of MHDT data in the DLCNukaWorld.esm Master file itself. It took literally one click and about 20 minutes of waiting to generate this data on my rig. So, is Beth just lazy AF? Did the executing studio not know any better? Who knows! But this means that, if you're making a mod and add an override of a NW Cell or Worldspace record, the override won't have any MHDT data either. So, even if another mod above yours (in the load order) would add the data, your mod will be conflict winner and it's empty (non-existent) MHDT records will obliterate any data added by any mods higher up in the load order.
Now, trying to be clever and putting this plugin below any NW worldspace mods will indeed enable Vertibird flight w/o crashing through mountains. But very unfortunately, this approach will most likely also break all of your NW worldspace mods. Dysfunction is even 100% guaranteed for NW settlement mods. This is because the plugin will revert cell location LCTN (and other things) back to DLC default.
It's a kind of effed-up situation.
The solution is to merge the MHDT data either directly into your NW Mods, or into specific patches made for them: For my own use, I merged the MHDT records from this mod into a custom made previs patch that covers both Nuka World Park Settlements and Nuka World Glory. And because that previs patch naturally goes below all other NW mods in my load order, everything works out perfectly smooth.
PRP has generated MDHT entries for Nuka World (freshly made) since 0.57, and FCF I believe merges this plugin's generated data since 1.2. You only need this plugin for cases like using Boston FPS Fix, even with my replacer on top.
Can't do it with Fo4edit since there's a dumb entry limit.
BTW, since I wanted to drop some of these alien monstrosities onto Genesis - Raintree Island - Settlements as well, I gotta thank you again for cluing me in on the Max Height generation process which is now part of an optional download for that mod. Flying saucers on a tropical island is just AWESOME!
Also, incorrect cell information caused by the CK in M's Abominations (And VATS patch) is easily overwritten by THIS mod, so that means you'd ONLY have to fix Far Harbor cells with an F04Edit patch to keep from having issues there as long as this mod loads AFTER it.
Anyway, sorry to resurrect a relatively dead comment stream but I just wanted to thank you again for sharing this wonderful mod and helping me to make my personal modding dreams come true. Good on ya! Game on!
Now I can low fly all over Nuka World to acquire all my locations in the pipboy...
especially I will fly ALL over and around that NW RR area and embedd everything into my saves for a while..
then i will RETRY that 'Nuka World Command Post II' mod I was talking about elsewheres... and if necessary I will try that TPC command if the terrain is gone with that mod
I recently downloaded this mod and got an error in Fo4 Edit.
the error is as follows:
Errors[0]: [CELL:02002FB9] (in NukaWorld "Nuka-World" [WRLD:0200290F] at 6,18)
Errors[1]: CELL \ XCRI - Combined References \ References \ Reference \ Reference
-> [01007DCF] < Error: Could not be resolved >
This error is in Block 0,0; Sub-block 0,2
The error was already in the NukaWorld master, so it is not a new error introduced by this mod.
Any idea how to fix this? Or do you think simply removing this Null reference would be suffice?
Thanks for your great work!
I started comparing the Sub-Blocks next to the block 6,18 and they all have a reference to a placed object.
But 6,18 was missing its reference to a tree cluster. Since this is the only reference in 6,18 and it misses a single reference, I made the conclusion that this must be the correct reference.
[REFR:0204F042] (places TreeBlastedForestCluster02 "Trees" [SCOL:0013463C] in GRUP Cell Temporary Children of [CELL:02002FB9] (in
NukaWorld "Nuka-World" [WRLD:0200290F] at 6,18))
(P.s. for those who want to "fix"/try this themselves: The load order creates the first two numbers, so read it like "XX04F042" where XX is the load-order number of NukaWorld.)
Im asking this because there seems to be a persistent problem here, which this mod doesn't entirely fix.
But of course, convenience and performance gains come at a steep cost: Changes made to the scenery after visibility was pre-calculated won't be displayed properly under the acceleration scheme. A well known symptom is the blinking of everything in- and out of existence when you scrap the hedges in Sanctuary and then walk through the spot where they used to be. This is because, during previs pre-calculation, it was determined that nothing behind the hedge is visible to the player when they stand infront of it. So if you then scrap the hedge but leave the previs, the game will not render anything behind the hedge... Even if the hedge had been scrapped and is long gone.
Mods with recalculated previs data, on the other hand, are quite the compatibility nightmare. It will be simply impossible to use certain combinations of mods with each other, because previs is calculated for areas that span more than a single cell, where two or more mods might supply conflicting previs data for the same area, independently. But, unlike records in a plugin, previs data cannot be merged at all. This leads to the problem of mutual exclusivity, and of course, the only real solution to this dilemma is to recalculate previs on a per-installation basis (ie, the end user / gamer would have to do this for their particular load order, and redo it each time the load order changes).
Doing this is a real PITA; It takes a long while and the tools to do it are iffy and will crash more often than not.
Sooo... a previs patch usually works by disabling previs and removing precombined geometry information (the previs system relies on precombined geometry to work, and also, precombined geometry is not scrap friendly) for specific Cells -Settlements, quite ususally- to force the game to calculate visibility for that cell at runtime. By their very nature, these patches go in the load order after the mod(s) that makes changes to worldspace, so they are a nice place to merge the MHDT info into.
What is that persistent problem you speak of?
One thing that you seem to be saying is that there is null overwrite in the MHDT, meaning that instead of being an empty field it contains a signal for its emptiness. that sounds funny, but its something I didnt understand before. I would have expected missing data not to be able to overwrite present data, meaning the MHDT data would persist once it was added to the record of locations or co-ordinates.
I guess it makes sense that fixing any worldspace error in a master plugin would be difficult, since that kind of data is referenced often. I can even imagine a weather mod using a skybox or height data for clouds, containing and overwriting MHDT data for an whole group of cells. But you are saying it isnt the height data fixed by this mod which is overwritten, its the loss of the what-is-visible-from-where table, the pre-vis thing, which causes the problem.
So, without a patch, will even small changes to the world-space *co-ordinates* will cause terrain 'blinking' in that space?.
I think that is the persistent problem I was referring to, or maybe it was just the lack of a ready-made patch. But it seems patches must be custom made to each load order. Its like the LOD problem in earlier games.
...
Q: How do we make the patch?
A: Use CK.
Q: How do i know which mods change Nuka-World in a way which needs to be patched?
A: Anything which adds, removes, or moves any non-actor (inanimate) object in NW will need to be patched. FO4Edit can tell you which mods do this.
How about: Are there any other mods which do this I should know about?
But this altitude fix mod is not directly related to previs, sorry if I made that somewhat unclear. I just mentioned the previs patch as an example to merge the MHDT data into, because previs patches go mostly far down in the load order, so they are an ideal place to overwrite other mods' overwrites.
If you want to look at mods or make simple patches, I'd recommend xEdit (aka FO4Edit) over the Creation Kit for various reasons.
xEdit has this nice treeview where it'll show all the records in the mod for inspection and editing. You can even load several mods into xEdit at once and apply a Filter to show conflicts. It will then highlight records and values that are conflicting/being overwritten. This is very helpful to identify problems and make patches.
Still "researching", not playing, and going to xEdit will wait, like maybe six months at least ;p
I actually haven't played the Nuka World DLC yet but I seem to remember this happening in other places as well.
Maybe Bethesda issues severe beatings for their workers if they do their job just a little too damn well?
I think it's maybe some sort of time restriction. Maybe they just say to their workers: "Your out of time, stop working. It'll just have to work."
You can see this in the auto industry, in computer software, in consumer electronics, basically everywhere. The last 20% of the work (such as testing, for example) is left as an exercise to the customer. Who none the less pays 100% of the price.
They get away with it because consumers accept this. See Fallout76.
Nice post.
Yeah I guess it's true it's basically everywhere. 80/20 as a general rule that can sway to either direction.
I see it in crafting musical instruments.
Though it is fun to mod games, I only do textures, it would be nice to not have to deal with bugs/glitches in the base game.
Edit:
-------
I mean't I only do textures myself but I do install and try and test just about any 'cool' mod I can find! XD
I must say it has developed and deepend my understanding of computers and games just in general. At least a little bit!
Programming and designing features isn't easy when there's lots of thing to take into consideration. Do that with computers and programs that have their own bugs and problems and your crying and doing it!
I spent some time in FO4Edit and added the height data from your esp to the mods that I use that effect NW. I then edited your esp to eliminate the conflicts. Thanks for this. It has always confused me why Bethesda never had height data in the main esm. Endorsed.