Jump to content
Arthmoor

[Fallout 4] Known Engine Bugs

Recommended Posts

Fallout 4 - Known Engine Bugs



The following is a list of known engine bugs as of the official 1.7.15 release. These are things Bethesda has to fix on their end otherwise they impose undue limitations on the ability to mod the game.

Power Armor Resets In Settlements

As described so far, power armor brought to a settlement area will be reset to its default configuration when the settlement location is next called for a cell reset.

It appears that the cause of this is any attempt to change the X/Y/Z dimensions of the buildable area for a given settlement.

PC Workaround: None known thus far, other than not trying to change settlement dimensions.

XB1/PS4 Workaround: Uninstall any mods which cause this to happen.

This issue has been confirmed by Bethesda and a fix is pending: https://community.bethesda.net/thread/13747

Editing Actors Turns Them White, Loses Facial Features

Editing information on an Actor record results in their skin color changing to white (caucasian) and the loss of facial features such as freckles or scars.

This is an old engine bug that has been around since Fallout 3, that somehow skipped over Skyrim. The cause has never been identified.

Preferred Workaround: Check the "Is Chargen Face Preset" flag in the Actor record.
Alternative Workaround: Change the mod to operate as a master file. This is not recommended though, due to the next bug...

This issue has been tested and confirmed to be fixed as of Official Patch 1.7.15. Their changelogs do not note this though.

User Generated ESM Files Load Before Official DLC

When using the official Mods menu in the UI, user added mods are the only things displayed on the Load Order list. Upon saving you will find that any user generated ESM files are now listed in between Fallout4.esm and the official DLCs.

The underlying cause for this is not known, but it's obvious Bethesda is incorrectly prioritizing the official DLC master files.

This issue has been fixed as of Official Patch 1.6.3.0.

Weapons Dropped By Actors Killed in Combat Never Clean up When Cells Reset [Fixed - Patch 1.6]

Killing an NPC generally causes their weapon to fall away from the body as a separate object. These do not reset when the cells reset. Eventually, after a long enough time, the save will bloat up with leftover weapon forms lying around all over the place, and if you played heavily for long enough, you could exhaust the pool of generated form IDs in the FF range because they aren't getting cleaned up.

The internal cause is unknown, but was also a huge problem in Skyrim that was never fixed.

This issue is now fixed as of Official Patch 1.6. Bethesda's changelog does not note this, but it has been confirmed. The workaround in the UFO4P has been removed as a result.

Cannot Reposition Scrappable Static Objects

There are a number of objects in the game that can be moved around in the workshops menu that are already present in a settlement. Obejcts such as grills, patio furniture, etc. If a scrap formula is created for these objects, they can no longer be repositioned. They can only be stored or scrapped. Make enough scrap formulas and you could end up being unable to reposition anything in your settlements.

The exact cause is unknown, but is likely a UI related bug as it seems to be related to UI filtering of some sort.

The UFO4P initially caused this issue to show up for radios, but information came to light that adding the 3 craftable radios to the workshopScrapRecipe_Radio was causing this. Removing those 3 radios from the list restored the ability to reposition radios in general.

This issue has not yet been acknowledged by Bethesda. See thread: https://community.bethesda.net/thread/10250

Edits to *ANY* Cell Records Can Block Mesh Overrides

If you are editing any cell, whether exterior or interior, your edits may end up blocking the ability for the game to use a mesh or texture override even if that replacer does not contain an esp file of its own. It is difficult to diagnose because WHAT you edit matters rather than WHERE you edit. Flipping your mod to an ESM flagged file does not help.

What the underlying cause is is not known at the moment, but the basics of it are that each cell record has a list of Precombined meshes stored in a lengthy XCRI subrecord. As long as the reference you are editing is one of these in the list, you will have no problems and straight file replacers will work as expected. If what you edit is NOT in this list, nothing you do will get the game to load the replacer.

Workaround: Make a small edit to one of the references in the XCRI list. This will then allow the cell to behave normally as though nothing was wrong. Finding a reference that's appropriate to edit requires the use of xEdit though since these lists are not available in the CK. If the reference you are editing was already in this list, you have effectively used the workaround and all consequences of editing it that go with that.

This workaround comes with a price though. It disables the precombined mesh system in that cell, which will result in a performance drop. Rack up enough of these over enough cells and you're going to be in trouble even on higher end machines.

This issue has been acknowledged by Bethesda. Reported here: https://community.bethesda.net/thread/13241 (Credit to VIitS on Nexus for explaining it)

The above issue has been unfortunately confirmed to be how their system is intended to work.
This has the potential to be severely limiting to any mods editing cell data whether it's an exterior or interior.

Further updates on this issue. Apparently SOME of it isn't intended after all and an "upcoming patch" will be addressing it.

As of Patch 1.6, this problem is now SUBSTANTIALY WORSE than before. If a mod, whether flagged as an ESM or not, edits ANY reference in a cell that's part of a precombined mesh, all of the other references which are also part of that will simply not load when approached on foot (and presumably via fast travel). No collision, nothing. Just void space with Havok objects flaoting in the air that fall to the ground once touched. Removing only those edits which touch a precombined mesh resolves the problem, but that's not going to be feasible in a lot of cases.

Disappearing buildings are confirmed fixed as of Official Patch 1.7.7.0. It is still unknown if this has corrected the greater problem of disabling precomb in a cell.

Share this post


Link to post
Share on other sites

No public statement but privately some gnashing teeth, rolling of eyes, hair falling out and boxed ears! That does it. Not playing. :yuck:

Share this post


Link to post
Share on other sites

Don't forget about scrap!

 

Also, these are confirmed Papyrus bugs:

  • Calling Activate() on a stack of items dropped by the player will add only one count of those items from the stack to the player's inventory.
  • Calling RemoveAllItems() on a killed actor who has dropped its weapon will add a copy of the weapon to a container but leave a copy of that weapon on the ground, effectively duplicating the weapon.

SmkViper acknowledged the first to me, and forwarded the second to those responsible for the inventory system.

 

Two more Papyrus bugs I just reported:

  • Calling GetItemCount() on Activators with the IsAshpile keyword does not return an item count.
  • Calling RemoveAllItems() on Activators with the IsAshpile keyword does not remove any items.

Share this post


Link to post
Share on other sites

That RemoveAllItems() bug is no doubt related to the "Dropped Weapons Never Clean Up" bug that's solved by setting iDeathDropWeaponChance to 0. If you have someone already looking into that, I'd suggest passing that along to them too since it's all part of the inventory system. They never fixed that in Skyrim either.

Share this post


Link to post
Share on other sites

They have not. Would be nice, but that at least has a workaround that doesn't cause any nasty side effects. Much less problematic than the FO3/NV way that forced you to flip the ESM flag on the whole mod over it.

Share this post


Link to post
Share on other sites

Well after reading that which only confirms our fears

https://community.bethesda.net/message/81707#81707

the only thing that came to my mind is Skyrim's gamerpoop episode "We are f$cked. Butt f$cked."

 

Fallout 4 modding is over if we are talking about landscape mods and mesh replacements/improvements. They clearly didn't thought about modding when created that system, like at all. I blame consoles again.

Share this post


Link to post
Share on other sites

Yeah, I didn't like that answer either and I'm not sure he fully understood the specific scenario I explained. So I posted a response. Hopefully he sees it. From the way he explained it, editing the tire iron shouldn't have caused a problem, but editing the car did what was expected.

 

Now, if everything that's been done *IS* how it works then I guess we can be content with that, remove the car edit, and pass the buck on to whoever wants to replace the bridge and let them be responsible for it turning off culling over that 3x3 cell area.

Share this post


Link to post
Share on other sites

Sounds like the optimal solution would be for beth to release the precombine tool so it can be added to ur mod managers and bash/merge tools/tool chain.

Share this post


Link to post
Share on other sites

The system is daft though. A straight mesh replacer with no esp file wouldn't work on about half the shit in the game this way because it simply won't load it. So someone would need to create a dummy esp with a dummy cell edit in it just to force the issue if some other mod edits the cell but doesn't touch the precombined data. Which is what happened here. Editing a tire iron caused a mesh replacer for the Sanctuary Hills bridge to fail to load.

 

I guess I'll need to go check and make absolutely sure this isn't already an issue with the straight vanilla game + DLCs though. Cause if it is then it's basically a situation where we just didn't have all the information we needed to know how to deal with this.

 

I don't like the implication though that we'd end up needing to try and generate this info in the even we DO edit something in the precombined list. Nothing stupidier IMO than having to edit 9 cells worth of data to fix a single reference in one.

Share this post


Link to post
Share on other sites

Sounds like the optimal solution would be for beth to release the precombine tool so it can be added to ur mod managers and bash/merge tools/tool chain.

 

My understanding is it is part of the CK. Both the visibility menu and the associated command lines : -GeneratePreCombined and -GeneratePreVisData

Share this post


Link to post
Share on other sites

Fallout 4 modding is over if we are talking about landscape mods and mesh replacements/improvements. They clearly didn't thought about modding when created that system, like at all.

 

My thoughts exactly.  I'll just paste links to my discussion there as I don't want to repeat it here:

 

https://community.bethesda.net/message/82240#82240

https://community.bethesda.net/message/83353#83353

 

I mention how they should have been doing various things in each post.  Basically not a single person must have considered that this basically kills all modding of statics, which is funny since they clearly wanted to bring modding to consoles, and then kill off half of all mesh mods.  Half as in dynamic vs static.  The dynamic stuff (armor, clothes, weapons, movables) won't ever be in precombined at least.  But everything else is now completely unmoddable.

Share this post


Link to post
Share on other sites

The funny part is that even if unofficial patch with include all that "pre" shit, it will require compatibility patches with every single mod that also changes something not only in the same cells, but in nearby ones too. Otherwise users will see flickering occlusion bugs and other nasty stuff, or just don't see some effects from other mods.

Share this post


Link to post
Share on other sites

The way I understood it is that the precombined and previs obeys Rule of One. So whichever mod generates the data and loads last wins and invalidates the others before it. So there would be no flickering or whatever but you'd end up with a patchwork of working and not working data.

 

Overriding it for the UFO4P might not be that big of a deal because I doubt we're going to be engaged in any kind of radical changes to things. Usually when we touch a ref it's to move it slightly to correct an alignment issue. Something you probably wouldn't notice at distance anyway. So our refs will still have our edits and it probably won't matter hugely if someone comes along elsewhere and generates precombined based on the vanilla positions.

 

That said, if *WE* don't generate it, then we begin to slowly kill performance throughout the Commonwealth. Which means the UFO4P will become a bloated mess of data we really shouldn't need in a relatively short time. As of right now we already have dozens of cells we'd need to generate the data for, including several interior cells. I just don't know how sustainable that is long term.

Share this post


Link to post
Share on other sites

The irony here seems like we're going to need dirty edits to make mesh changes stick. Bravo Beth, bravo.

 

I checked the estimated time it takes to generate the preculling too, on my beast rig for the entire wasteland will take over a month.

Share this post


Link to post
Share on other sites

Overriding it for the UFO4P might not be that big of a deal because I doubt we're going to be engaged in any kind of radical changes to things. Usually when we touch a ref it's to move it slightly to correct an alignment issue. Something you probably wouldn't notice at distance anyway. So our refs will still have our edits and it probably won't matter hugely if someone comes along elsewhere and generates precombined based on the vanilla positions. 

 

Precombined is not "at a distance".  It literally replaces the actual refs with a baked mesh.  The Previs is "at a distance", to hide the baked refs based on precomputed visibility from a grid of points in the cell and the adjacent cells.   So the Vis files are basically what precombined data you can see from dozens/hundreds of positions in the cell.

 

Like you said if we nudge a ref that is in the precombined, we invalidate it.  So we need to regenerate the precomb/vis.   Mods that edit other things in the cell and include their own precomb/vis will not just hide our fixes at a distance, it will hide them completely.  The appearance of anything we nudge or fix the base NIF for will be completely undone by any mods including precomb/vis for those cells.  So there is basically no point in doing nudge fixes anymore, considering that to nudge one item we need to include precomb/vis for 9 cells which is just going to get undone by dozens of other mods.

Share this post


Link to post
Share on other sites

If that's actually the case then wouldn't that make stuff like what Chucksteel is doing completely non-viable? He's going to end up editing a whole lot of cells and any random mod coming along would invalidate his changes if even the local cell edit get canceled out because of the precombination data.

 

A really stupid system all around if this is how it works.

 

We'd still be able to do nudge fixes but it would be restricted to only those things not in a precombined list. Which is going to be severely limiting.

 

Also, exactly what happens if one of these refs is something Bethesda sets up to disable as part of a quest? What happens then?

Share this post


Link to post
Share on other sites

I'm guessing stuff linked to a quest is prohibited from being baked into precombined.  Though I'm not sure exactly how the engine implements "disabling" a ref via console when it's actually part of a larger NIF.  It might just toggle off the rendering of those triangles.  It knows the original ref that is in that location though.  The precombined data somehow points to it, but I haven't decoded where. 

 

Re: Beantown Interiors, all his new stuff will show up fine.  But he had to move some blocked doors and things, which may be in precombined, which invalidated the precombined.   Anything else may come along that uses its own precombined data for those cells, effectively boarding the houses back up. 

Share this post


Link to post
Share on other sites

If you have a static object and a miscellaneous object, and both objects have the same NIFs, what happens if you replace a static object with its miscellaneous counterpart?
 
yov4NUp.png
 

For example, BonesLeftLegStatic [sTAT:0018B9C7] and BonesLeftLeg [MISC:000347E5] both use SetDressing\Skeletons\BonesLeftLeg.nif. So, the precombined mesh is unchanged, right?

 

If precombination/previs for the cell is not disabled in this example, what happens when the player picks up the miscellaneous object?

Share this post


Link to post
Share on other sites

I've discovered that the Place Anywhere plugin for F4SE will allow you to select/move scrappable objects, such as those objects made scrappable by my Unofficial Scrap Patch. I imagine this will also work for the radios previously fixed by UFO4P. Of course, this also means that both a PC and F4SE are required for all mods that add scrap recipes until Bethesda fixes the problem on their end.

Share this post


Link to post
Share on other sites

Disable() and DisableNoWait() do not disable some (dead) actors, such as the Bloatflies in Sanctuary Hills, when called from Papyrus. These actors can be disabled with in-game console commands, however.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Support us on Patreon!

×