MissingMeshTV

There is no "dilapidated tileset" for the vaults. All of the ruined/dilapidated vault pieces are the base, shiny, clean Playskool pastel colored pieces with a material swap applied to each individual reference in the cell. The material swap changes the textures used to show the run down and dirty vault pieces instead of the clean and shiny default textures. The vault material swaps in question all start with VaultDamageTheme and there are several different variations of them for different uses. Take a look at the Vault11402 cell in the CK or xEdit and you'll see the damaged vault material swaps applied to pretty much all of the vault walls and floors.

Precombines/previs function no differently for interiors than they do for exteriors when properly generated. I'd say interior cells are actually easier since you only have the one cell to deal with. Besides Vault 88, the Mechanist Lair is the largest cell in the game that comes to mind. It's huuuuge. Much larger and filled with far more clutter than Mass Pike Tunnel, with an insane amount of complexity.

LOL...forgot he could do that! Shows how much I take advantage of his l33t H4x0r skillz. :laugh:

Close to Metal, Nick Valentine's companion perk. It's pretty useless considering a terminal resets a whopping 10 seconds after you get locked out, as opposed to being locked out permanently in FO3 and FNV.

This is the first I've heard anyone mention this bug in a very, very long time. The original bug was said to have been fixed long ago. I never personally ever ran into it. Maybe this is something new?

Cell reset bug? If you mean the cell reset bug the game shipped with in 2015, that was fixed ages ago AFAIK. It should no longer be an issue, unless there is some new strain I've never heard about.

Are you maybe thinking of Ultimate Window Overhaul?

I concur with jjb54's advice on the scrapping mod. I gave up using scrapping mods ages ago as they cause far more problems then they are worth. For a scrapping mod to do what it does, it disables the optimization system in the cell(s) it touches. They can also cause problems in places you wouldn't expect. Scrap the scrapping mods, and things like this are less likely to happen. Is LOOT a good program? That depends on your definition of "good." Personally, I have never used it nor will I ever. It seems to cause more problems than it aims to solve, especially when users just push the sort button and expect it to magically resolve all conflicts with a perfect load order. I find common sense, a little reading and using xEdit to to find conflicts to be a better solution than pushbutton software. YMMV. Most people i know who insist on using LOOT don't fully rely on the sorting it does, and adjust things themselves when LOOT gives questionable results. Where should you put the FPS fix in your load order? Did you read all of my post? The mod page? EDIT: Here is some info in how the optimization system of this game works. It might help you understand why the mods you are using will not work together and why they give you the preculing issues. The first page has the most relevant info for the majority of mod users. The rest of the thread can get very technical, but has loads of information to help you understand what is happening.

This has absolutely nothing to do with textures. This is a preculling/broken previs data issue caused by your load order. Since you are using Boston FPS Fix, you should go back to the mod page and reread the description and get familiar with what the mod does, how it works, and where it should be placed in your load order (Hint: Not near the top where you have it but near the bottom, but above any scrapping mod you use...stated plain as day in the documentation and comments.) You are using mods that overwrite the optimization data of Boston FPS Fix. DO NOT use No More Disappearing Act. The mod description is clear about what it does: disables the game’s preculling functionality (also known as previs) which is a key component of the optimization system. You have it loaded below FPS Fix, which negates any benefit from using the FPS fix. It is likely conflicting with the previs data in the FPX fix causing the preculling issues in your screenshot. Having FPS Fix so high on your load order lets other mods that modify the same cells overwrite the optimization data of FPS Fix and not only will cause these visual issues (and likely performance issues), but renders any benefits that FPS Fix might give null and void. That’s why I’m suggesting getting rid of No More Disappearing Act. Not only does it conflict with FPS Fix, but it disables a core function of the optimization system. After fixing your load order, you may still run into previs conflicts like this if you have mods with conflicting optimization data (two mods that regenerate precombines and previs for the same cell or cells). Learning to use xEdit to examine your load order and see what mods conflict in which cells will save you a lot of grief in the long run in trying to troubleshoot and figure out where problems are coming from.

That is probably one of THE worst .ini file edits you can possibly make, and you should never advise other people to use it. It essentially disables the game's optimization system. It may seem to fix preculling issues caused by some mod in your load order, but you open yourself up to some pretty horrible performance and tanking frame rates among other issues. It's a horrible workaround to something in your load order causing the preculling issues. It is NOT a fix. More info in this forum thread. The first page has the best info for the average mod user.

I learn something new every time I pop into the forums. Glad I could give little back. :smile:

Maybe I'm just lucky (or maybe I'm going to jinx myself by saying this), but all my various CK installs have been stable and issue free. The only time it seems to crash is when I to too many Cntrl-Z commands too quickly. In theory, if you save your work at regular intervals you can prevent losing too much work if there is a crash. The CK automagically makes a backup .esp every time you save. Look in the Backup folder of the game folder and there should be the last 10 saves of every mod you've made save for with a .bak extension. This has saved my bacon more than once with only minimal loss. We're talking minutes of lost work, not hours. As with every other piece of software I use, I live by the "Save early, save often" mantra, and I don't rely on those CK generated backups as my only line of defense. After I've done any significant amount of work, I'll save and quit the CK then copy my .esp to a backup folder on a different drive. I'll sequentially number each backup so I can revert to any state of a project at any time if needed. That is of course, until that drive with my backups and the archive drive that backs up the backups die simultaneously. OK, Really should stop jinxing myself. Is the CK perfect? Not by a long shot. Is it a free tool provided by the game publisher? Yes. Are there alternatives that can do what it does? Not for world or interior building and generating optimization data. I'll take the warts given the price I paid to purchase it.

If you are trying to use the mesh from a static item on a new activator item, you don't actually need to extract anything from an archive to get the file path/name of the mesh you want to make the activator with. From the Object Window, just open the static item you want to use the mesh from. Go to the Model field and you'll see the file path to the mesh for that item. Copy the file path. Now go to your Activator and open it. Go to the Model field and click the Edit button. This opens the Model Data window. Paste the file path you copied from the static into the Model File Name field. The activator item in the preview window should now be using the mesh you copied the path for. Close out all the windows and your activator will now be using the new mesh. Not sure if that's where you're getting hung up or if I missed something in what you were trying to do, but that's I find that's the easiest way to swap one mesh for another, which is what it seems you want to do.

100% complete removal of the settlement/workshop mechanic with several existing settlement locations replaced with developed communities filled with lore, merchants and quests, along the lines of Arefu, Canterbury Commons, Primm, Novac, Shady Sands, etc. Places where the "fun" already exists, rather than having to build it yourself.

Have you tried adding the DefaultDisableHavokOnLoad script to your refs? That should totally disable any physics on them.

Since you're working with an activator with animation states (and not a "normal" door), you might look at using PlayAnimation or PlayGamebryoAnimation in a script attached to a trigger box to control the animation state. I've used PlayGamebryoAnimation with success in some basic testing (ages ago) when PlayAnimation didn't seem to work with any of the animation states I defined. The default toggle button scripts might also give you some ideas as well. There's likely a vanilla game example close to what you want to do that you could reverse engineer, but I'm drawing a blank on one right now.

DiodeLadder: That's some good info on the navcuts. Thanks for sharing that. It would seem that at least for me, some navcuts don't seem to work as well as others, such as the gravel wall barriers for example. Before I started using the "F4 to show collision" trick, companions would get stuck on them during testing as they disappear during navmeshing and I totally forgot they were there so I navmeshed right through them. That's when I started using the collision as a guide. Or, maybe companion AI is just too impaired to detect those navcuts. Naw, it could never be that.

Movable statics disappearing in navmesh mode seems to be a normal "feature." Because why would you need to see them while navmeshing? In these cases, I'll toggle the F4 key before entering navmesh mode to show collisions on items in the render window. Then when the movable statics disappear in navmesh mode, the collision outline is still there to use as a guide to set up the navmeshing around those items.

You can also attach the DefaultAddItemOnLoad script to a container or NPC ref and define the item and quantity in the properties.

Mines are definitely wonky in this game. What DieFeM said is spot on. It's something that people continuously complain about in the comment section for FROST, blaming it on the mod. But it's a 100% vanilla "feature." People tend to notice it more in FROST because they die so much more frequently than in vanilla. I've been told it's a memory bug that dates back to Oblivion, along the lines of what DieFeM described. I've also been told it's intentional to "help" players avoid death loops from mines. I'm more inclined to believe the former. The only thing I know for sure is that's it's definitely a thing that happens with mines, and also with enemies on occasion.

That’s a totally incorrect description of what that mod does. It does not eliminate precombines. It regenerates all new precombine and previs data for a large portion of the map, which is why it has a 565MB BA2 file. The intent is to restore that optimization data for users who have mods that do remove or otherwise disable it. Saying that it eliminates that data is the exact opposite of what it actually does and is wholly inaccurate. You are correct that it can cause problems with scrapping mods if loaded after them, because of how scrapping mods work (by disabling precombines). The scrapping mod wants to break them, FPS Fix overrides those changes and restores them, hence scrapping mod longer works. That is one of the reasons I suggested the OP re-read the FPS Fix mod description for info on proper load order placement if they intend to keep using it.

Boston FPS Fix should be at the bottom of your load order, are at least close to it. Re-read the mod description for clarification. If you're using mods that break precombined meshes (and I see a couple in your load order: Tales from the Commonwealth and Eli's Armor Compendium) and they are below FPS Fix, they will override all of the optimization that FPX Fix rebuilds and give you the lousy frame rates you're getting, negating the reason to be using FPS FIix. The downside is, that having FPS Fix lower in your load order will probably override (or obscure) any changes made by those mods, but you should get better performance in those cells. Example: Tales from the Commonwealth disables the optimization for one or two two cells (can't recall it its one or two offhand) across from Easy City Downs because it makes changes to a building facade for one of its quests, and doesn’t have regenerated the prcombined/previs data to restore it. The FPS in that area can be awful as a result. Presumably, FPS Fix includes regenerated data for those cells (I don’t know for certain, as I’ve never found the need to use FPS Fix myself). Having TftC below FPS Fix will override all of the optimization data that FPS Fix aims to restore. Moving FPS Fix below TftC will restore the optimization and improve performance, but you will likely loose the changes made by TftC, or they may be obscured and/or covered by the vanilla items that FPS Fix has baked into its optimization data. You’ll want to test this out yourself. The same goes for Eli's Armor Compendium for the cell with the shop, but much less drastic. Any vanilla refs restored by the FPS Fix should be limited to the debris and rubble that the mod removes. The load door to the shop and all the other additions around the shop should be fine, but again, you want to test this out for yourself. There is no alternate path when dealing with this game’s optimization system. You either use mods that break precombines and suffer the performance consequences, use the FPX Fix that is based on vanilla references and have it override the changes made by the mods that break them, or choose not to use the mods that break the optimization in the first place. In that case, there is no need to “fix” what isn’t broken and the game performs perfectly fine. The other option, is to learn how to use the CK to regenerate the precombines/previs for those mods that break them. I made a video on how to do this a while back that might help get you started. In your case, I’d suggest you start by re-reading the info on the Boston FPS Fix page regarding proper load order placement of the mod and go from there.

The god ray distortion on edges is caused by them being set to a setting other than Ultra. Lowering the setting won't help. The only way to make it look any better is keep them set to Ultra, but of course you'll likely get a performance hit depending on your hardware. Rather than removing them, I prefer to use the Ultra Quality God Rays Performance Fix. It's a bat file that runs a console command that tweaks the god ray settings so they do not impact performance when they are set to Ultra. They look amazing, no edge blockiness, and the game performs on par with having them set to the lower settings. The mod page has instructions on how to add a line to your Fallout4Custom.ini to run the bat file at game launch, but I image the setting could be added directly to the .ini file itself. It's the best option besides nuking the god rays altogether. EDIT: This also has nothing to do with using an ENB.

I've run into this using other mods, namely FROST, and always assumed it was intentional. It wasn't until I used my first feral corpse over the weekend that I realized it wasn't. This is happening with my dev install where the only active mod is the one I'm working on, so definitely not a conflict in this case. No loose files that would impact ferals either. It doesn't just work.

Hey, SKK! Thanks for the workaround info and confirming I'm not alone in this weirdness. The corpses are just set pieces for 'mershun and I'm only using a few in a single cell, so I'll likely just live with it and move on. It is damned bizarre though.