VIitS

Bethesda implemented a system that automatically disables precombineds and previs if you have a mod that touches a precombined reference and didn't generate new precombineds. It knows if you generated new precombineds by the timestamps (PCMB and VISI for Precombineds and Previs, respectively). So, since Chusksteel's tester plugin touches precombined references without any change to the PCMB field, it disables them. This isn't reflected in the Cell record, as it is a dynamic system that applies at launch. Also, to clarify on how to tell when a mod touches a precombined reference: As shown here, the ones with the brackets around placed object [Placed Object]are part of a precombined mesh, and if they show up in in your mod FO4Edit your mod will break precombineds (unless you make new ones) for that cell. And the ones that without brackets Placed Objectare not part of a precombined mesh, and can be edited without worry.

A) Correct, the only way to cause that to happen for that to happen is to break precombineds, unless the object in question was never part of a precombined mesh (in which case a simple material swap can change it). 99.9% of buildings outside the settlements (and indeed, almost everything that isn't movable/interactable) are part of precombined meshes. If you're unsure (and have access to the main .esm files on a PC), FO4Edit indicates what is part of a precombined mesh by listing it as [Placed Object], and if it isn't part of a precombined it's just listed as Placed Object. B) Just took a look at Insignificant Object Remover: as it doesn't touch any cell records (and doesn't include any ini edits), it is incapable of breaking precombineds. It just changes some "Grass" records, so if those records did get included in precombineds they wouldn't visibly change in the game. Can't say anything to other similar mods, but IOR definitely doesn't touch precombineds. If you change a base record (Grass, Static, Static Collection, Armor, etc...) but don't touch any Cell records (CELL) or Placed References (REFR), the changes will only apply to non-precombined versions of that base record. It's why a mod like the Skyrim Mesh Improvement Mod are all but impossible for FO4. You'd either have to globally break precombineds, or rebuild precombineds for every instance of every object you want to change. Thanks to zilav (one of the makers of xEdit) it is possible to trim the unchanged precombineds, and thanks jonwd7 (maker of nifskope), it is possible to manually edit precombineds, so rather than 10+ GB of precombineds you might be able to get it down to 3-4, or maybe even 1 GB if you don't change as much as SMIM has, but you'd still have some big problems: -That's still a huge download, especially for XBOX -You'd have to regenerate precombineds every time you add a new object to the mod, so SMIM's method of adding things and updating the mod as they went would add insane amounts of work (a few hours of fixing up some meshes -> a few days of redoing precombineds) -It's incredibly tedious, mind-numbing work that would likely make anyone just give up and only release a "breaks all the precombineds" version -If you regenerate precombineds for every cell, it makes it incompatible with basically every mod that changes a cell (unless that mod breaks precombineds for the cell it is editing)

Nope. You can import the mesh then export it with Fallout 4 settings*, but they won't have collision. If you wanted collision, you'd have to 1) make new collision using 3ds max 2013 and the official plugin 2) add collisions taken from existing meshes and added to yours using nifskope 3) use collision boxes in the CK to make static, rectangular collision. *Don't know what the Blender nif plugin looks like, if there is one**, but the 3ds max one lets you choose which game you want the mesh to be for (FO3/FNV/FO4/TES4/TES5). **If there isn't, you'd have to use either Nifskope or Outfit Studio as a middle-man to convert the nif to an obj, and vice-versa.

1) The reason for the visual change is because the material saved in the precombined mesh is not the same one set in Fallout4.esm (or whatever DLC plugin it's happening with). There are two ways it can happen without breaking precombineds: a) Replacing the textures the material (in the precombined nif) uses, or b) remaking the precombineds/manually editing the precombined nif to point it at a different material. If a mod has no loose files or .ba2, and is just a esp/esm, the only way it can cause that change is by breaking precombineds. In-game, you cannot affect a precombined mesh at all. You can't scrap it, you can't select it and disable it (using the console, something Console versions of the game can't access), you can't have a script do anything to it. 2) LODs are baked into your saves, precombineds aren't. The main save I use for testing (I rarely actually play anymore) has over 300 hours of playtime. I have disabled and re-enabled (or left disabled) so many mods (including ones that disable precombineds), so many times, that I am actually surprised that it is stable. I have never noticed any instability not caused by a bad plugin. I have even made new precombineds for cells I had already visited (so if precombineds were baked into the save, they would be here), and not had any issues. What is baked into a save is what you have and have not scrapped. So if you scrap something with the referenced scrap mod, disable the mod (allowing the precombineds to show back up), and then re-enable it later on (or use a different mod that disables precombineds), the stuff you had scrapped will disappear again. But it won't hurt your save. The only mods I know of that will break saves are ones with actively running scripts, and those will immediately break the save (trying to load it without the mod results in an immediate crash). If you want to know way, way more about precombineds, the most comprehensive collection of knowledge on the subject is this thread

Two things of note: 1) From what I have found, once you have the precombined generated, you don't need the regular mesh for the precombineds to still work. I don't think I've actually tested it, but I have seen that some SCOLs (which are only used as part of precombineds) that don't actually have the SCOL mesh anywhere in the vanilla .ba2 files. 2) Thanks to jonwd7 updating Nifskope to work with CK-generated precombineds, if you are feeling particularly masochistic (or only need to fix material swaps for a few things), you can manually edit which material the precombined will use. Obviously you wouldn't want to do this when you have a ton of instances of an object, but it's something to keep in mind. But chucksteel's method sounds best. If that is for Placed References like I think it is (as opposed to base objects), FO4Edit would be useful for applying the same material to tons of records.

Don't use Blender, but I have run into similar issues in 3ds max. The only solution I know of is to redo the UV (either as a whole, or just for the section it is a part of, depending on what options Blender has).

1) Select records you want to change the FormID of 2) Right Click -> "Change FormID" 3) Watch FO4Edit do exactly what you want, because zilav is amazing.

You have to Rip their face off.

Just a heads up, jonwd7 just released an update to nifskope a few days ago, with some nice little additional features: https://github.com/niftools/nifskope/releases

Actually, it is. There's a gap in your structure, allowing you to see The Void*. For some reason, when The Void is partially visible (even just a tiny sliver), it will cause that effect. *The pure white glow that is the default space for interior cells, unless you set it to use an actual background. To see what I mean, clip through the walls of a place like the Old State House, then do the same for a cave (like Vault 88).

So, jonwd7 just released a new update for Nifskope (v2 dev7). You can now look at (and edit) CK-generated precombineds the same way you could do normal precombineds. It's of limited usefullness, since the CK still packs almost all the collision data for precombineds in a cell into the CELLID_physics.nif, but it's definitely useful in certain situations. If nothing else, you can just poke around in them like I did with the vanilla precombineds. It's also got tons of other tweaks and new features, the full list available here: https://github.com/niftools/nifskope/releases

This is the method I used on remaking precombineds for Vault 88 and the Mechanist's Lair, and it is every bit as painful as it seems it would be. Of course, since I was trying to ensure certain things would be scrappable, I'm not sure if there was a better way to do it.

You'll need to use FO4Edit (generic name is xEdit), the CK doesn't like letting you remove dirty edits , or really do much at all with previs/precombineds outside of generating them. If you want to remove "dirty" edits (records you touched in the CK but either made no actual edits to or undid any edits you made), any record that has a green background in the tree (left side) and doesn't have any sub-records (i.e. don't remove Worldspace just because it is green :tongue:) can be safely removed, as it has no changes compared to the vanilla version of it. The quick way to do this is: 1) Right Click on the left side -> Apply Filter for Cleaning 2) Right click on your mod -> Remove "Identical to Master" Records (also known as ITMs) If you didn't intend to move or delete anything, just add, then you can also delete any placed object references that have a yellow background, as that indicates that it is an edited record. A white background means it is the only instance of that record, so any newly added record in your plugin would have a white background. If you see a red background, that means two plugins have edited that record°, so same applies as with yellow records. If you purposefully moved (or otherwise edited) some things and accidentally moved others (without noticing and undoing the edit, which would result in an ITM), you have to manually go through each of those edited (yellow or red) records and see if it was a purposeful change. Having both xEdit and the CK open at the same time (with xEdit opened after saving your changes in the CK, otherwise your changes won't be reflected in xEdit°°) is good for this, as xEdit will show the changed records and it's often easier to tell if you meant to change it when looking at it visually. °when editing your mod in xEdit, you should only have your plugin and any required masters, so when cleaning your mod this should only happen if your mod has a DLC as a master, and are editing a record that is in the base game and also edited by the DLC. °°A bit of warning: if you have a plugin open in xEdit when trying to save it in the CK (and vice versa), it won't let you save any changes made. You also won't be able to save (in xEdit or the CK) if you have the game running with the mod enabled Beyond those (detailed info on previs/precombineds, and the editing thereof): If you want more info on precombineds/previs, this thread has just about every bit of info we (i.e. modders) have learned about the systems. If you want to just make a cell not use precombineds/previs, this script is great for that. DO NOT USE IT FOR INTERIOR CELLS. For an explanation on why, check the thread I linked.

Somehow, I'm not that surprised that functionality is already built in. Seriously, Creation Engine modding would be nowhere near where it is today with xEdit. :smile:

Something I noticed when trying to locate the thread where the Dev talks about the precombined auto-disable system* was that xEdit has a scripting function that checks whether a record has a precombined mesh, presumably what it uses to determine which "Placed Object" records need brackets. So someone who properly knows how to make pascal scripts for use with xEdit** could make an xEdit script that detects if a given mod will break precombineds (and possibly lists either the offending records, or the cells they are in). It would need to check the VISI and PCMB fields of the containing cells and compare them to the vanilla values (and the ones from DLC, where relevant***) to avoid giving false positives (i.e. saying it will break precombineds, when the mod rebuilt precombineds to account for the edits). The wiki page where I found these functions: https://www.creationkit.com/index.php?title=TES5Edit_Scripting_Functions *The link in the first post doesn't seem to work, I guess as a result of one of the changes they made when they redid their community forums system, so I tried to find the wiki page on Precombineds that is essentially just a repost of that Dev response **rather than someone like me, who can either 1) beat my head against a script someone else made that does something similar to what I want until it works (my formlist/recipe script), or 2) interest zilav enough that he makes it for me while I just act as a tester (my Precombined Data editor script) ***might want to have it check against a stored list of those values, in order to not give a false positive just because the mod doesn't require a DLC to load, but the value in those fields is from the DLC and not the base game

Looks pretty good. To sum up what became a bit rambling: Both detection methods you noted seem to be a result of the placed references being edited (via material swaps or something similar) to use a different material than the one they had been assigned when the precombined meshes in that cell were generated Another detection method (only usable in settlements) is losing the ability to place most things (beds for sure, among many others) on a surface. This is because precombineds seem to automatically have the "treat as ground" property applied to them, and as a result Bethesda didn't bother adding it to a lot of base records that really should have it xEdit puts brackets around the "Placed Object" descriptor on the lefthand side :tongue:. In more detail (with tangents), spoilered because holy s#*! did I ramble: And on a final note: auto-save drafts for posts are wonderful, amazing things. I accidentally refreshed the page when I was almost done with this post, and when I was trying decide if I should bother rewriting the whole thing (versus just the TLDR version at the top) I noticed "View Auto Saved Content" at the bottom of the post window. Not sure why the Nexus doesn't have a dedicated "Save draft" icon like some other forums, or why it doesn't automatically restore the saved draft when you do something stupid like I did and leave/refresh the page without posting, but at least I finally realized it does save drafts.

That was an interesting thing I noted as well. What I've done is import into 2016/2017, make my edits there, then export it as a .3ds / .obj / etc... Then I just imported that into 2013 using the built-in 3ds max importers. Edit: nifskope also has a .obj exporter which you could use instead of 3DS Max 2016/2017.

You need 3ds max 2013, it's the only version Bethesda's plugin works for. You can find the plugin in the Tools\NIF_Exporter folder (the tools folder will be in whatever folder CreationKit.exe is, likely in your Fallout 4 main folder). If you can get the 2013 version, here are some good tutorials: For stairs, you'll need to use a stair type collision group. It won't block bullets, but it will let you walk up it (making a normal collision mesh won't allow you to walk up it, though a gentle enough slope might let you even using a normal collision). In order to do that, you'd have to make a second collision using whatever type of material you want it to act as, and have it slightly down and back (so it won't block the walkable stair collision). I found about 5 units (in 3ds max) back and down worked pretty well, though you might have to play with it.

I think it is related to Acoustic Spaces. You can definitely use it to make it sound like the rain is muffled or hitting a metal/wood/brick/etc..., and I think it also blocks the visual effect. Not certain on that, it's more of a vague memory of a discussion. If not, it's likely either related to a certain setting when making collision meshes, or possibly culling planes. I haven't really done anything with housing or locations, so this is all a combination of half-remembered discussions and deduction/guesswork. But I'm fairly sure Acoustic Spaces are related to blocking the visual effect.

The visible boundary you see for vanilla settlements is an actual mesh. Presumably Bethesda has some quick way of making them, but as far as I know no one has figured it out.

Two recipes for the same thing could potentially conflict, but generally you're fine. The last recipe to load will determine what yield you get from scrapping it (and if you had two build recipes, it'll show up twice). Originally it was reversed (first recipe determined scrap yield), but I guess they decided to change it to be more in line with how everything else works. There's two things you'll want to look at: 1) Unless you set the "Category" to scrap, the return you'll get is going to be some fraction of the amount you'll get back, as you noticed. For static objects, setting the category to scrap will make it so you can't move it in build mode (it'll have a yellow outline), but for something you can pick up it doesn't matter. 2) When making a scrap recipe, you'll want to make sure you're using the "MISC" version (denoted by _scrap at the end of the editor id) , not the "Component" version. For building you want to use the "Component" version. If you make it use the component version, you'll still get the scrap from it and can use it to craft something, but it'll be invisible in your inventory. This isn't your problem, but I thought I'd mention it anyway. You can actually see what the multiplier will be by looking at the "Component" record for the material. It'll have a "Mod Scrap Scalar", and if you look up the value associated with that, the yield (for a non-"Scrap" recipe) = that value * 1/2, If I remember correctly.

I personally avoid cleaning plugins (especially DLC) of ITMs unless it being dirty will cause problems (with ITMs, that's generally just if Bethesda updates the base record, or you have another mod trying to change the same record. For the other types of dirty edits, I'd recommend cleaning most of them. Any deleted records should be undeleted and disabled. If the crashes you mention are a result of dirty mods, it's probably some mod author deleting records. And it's often a good idea to use the "Check for Errors" option. Some are mostly fine (any issue caused will be unnoticeable, though some intended feature might not work), but "Error: Could not be resolved" can frequently cause crashes. It means the mentioned record is referencing a record that doesn't exist. It tends to happen either when someone improperly deletes a record (i.e. they didn't update all the records that reference it), or if there's some weirdness with the order of the master records the plugin references (in which case, the last 6 characters would be right, but it wouldn't have the right load order for the plugin the record is from).

With Spring Cleaning, you're gonna want a patch. If you're curious why, scrap mods like SC and SE rely on disabling precombined meshes/previs, two performance systems explained pretty well [https://forums.nexusmods.com/index.php?/topic/5522717-fallout-4-optimization-and-performance-systems-explained]here[/url]. Or you could switch, though I will warn you that some people don't like that it lets you scrap a bit more than Spring Cleaning (i.e. they accidentally scrap roads/foundations, or have to be very careful not to). Shadowslasher is working on an in-game system that will let you disable scrapping for whatever you want, which will fix that issue, but it's hard to say when it will be ready (the game really doesn't make it easy). So if that's something you think might be an issue, I'd suggest just using that patch until the SE update is ready. And I definitely suggest saving often if you decide to go ahead and switch now. But yes, switching is fine. Due to how both mods work (very similar, I guess you could say it's methods are a bit more developed), you shouldn't have any issues. You could even disable it for a while, and when you re-enable it later on the things you had previously scrapped will disappear again.

No, you need to fix your load order.

I took a quick look at the cells associated with Fairline Hill Estates*, and every single one has at least 200 references that are part of precombined meshes. So you might not be looking in the right place**. Also, the reason your formlists suddenly started working is that your mod touched a precombined mesh (moving the monkey bars/slide), which triggered a workaround Bethesda implemented. What it does is disable precombineds and previs in any cell where a precombined mesh is mentioned in your mod (even if nothing is changed, if the placed object reference is mentioned in your mod it counts). If you didn't notice any significant performance impact, then you can use the first method I mentioned without worrying, as the workaround you triggered does the same thing. One last note: if another mod touches one of those cells without disabling previs/precombineds, and it is loaded after your mod, then the problem objects will be unscrappable again, and any that were scrapped will reappear. There's not anything you can really do about that though, it would happen no matter which method you use. It's a result of the way Bethesda's precombined system works when combined with the way records work (i.e. any time two+ mods edit the same record, the last one to be loaded wins). *According to the wiki: 0000e5b1 0000e591 0000e5d4 0000e58f **Here's an example of where to look: