VIitS

TL;DR, copying those timestamps won't hurt anything, but things can still be broken if you copy precombined REFRs, as described below. Precombined REFRs are ones mentioned in the XCRI subrecord of the cell, and they will show as [Placed Object] next to the FormID rather than Placed Object. Assuming the timestamps are newer*, it will hurt nothing, and not carrying them over can disable previs/precombineds and cause performance issues. The sole purpose of those timestamps is to determine if precombineds/previs should be disabled by comparing the timestamp in that subrecord to the Version Control Info 1 subrecord in the precombiend REFR records contained in the cell. Two things will trigger the system that disables previs/precombineds for a given cell. 1) If any of the precombined REFRs have a newer date than that timestamp, previs/precombineds will be disabled for that cell, or 2) If any of precombined REFRs have no timestamp, it will disable previs/precombineds. The second is very common, as any record that is copied using FO4Edit/xEdit will have the timestamp removed. This is due to an issue that copying them over caused when using Version Control in the Oblivion Construction Set (something very much needed for managing heavily modded setups). Up until FO4, not having those values didn't hurt anything. You can fix the timestamps on the REFR records by opening the mod in the CK, right clicking the cell -> Update previs/precombineds timestamps** -> Save and exit the CK. If the mod has any .esp files as a master, this is a bad idea because the CK will "helpfully" remove that file as a master and completely break your plugin. The only other way you can fix it is to use the "Copy version control info from another plugin" script in xEdit. The script that comes with xEdit has a check to confirm that both the source and the target files have the same masters, but that is unnecessary***. Since it is an absolute pain sometimes to get them to match****, you can just remove that section and it will let you copy timestamps just fine without having to ensure both have the exact same masters. The section in question is: if not SameText(MastersList(GetFile(e)), MastersList(fromPlugin)) then begin AddMessage('Masters do not match between plugins!'); fromPlugin := nil; end; There are some other bits that can be removed as well but that is the only part that has to be removed. *Most likely, as the only way to make them older would be to manually edit that sub-record in xEdit, and there is no reason to do so when you can just click "Update Previs/Precombined Timestamps" in the CK. **Just selecting the cell and saving will add timestamps to the REFR records without timestamps, but the timestamp will be for the day you resave the mod, which would be newer than the value of the VISI and PCMB subrecords, so previs/precombineds would still be disabled. ***I spoke to zilav, the person who made the script, and they said that was just included because the person they made the script for requested it. I have used it with that part removed without any problems. **** Particularly if you are trying to get a timestamp from a DLC. If you are trying to get a timestamp from Fallout4.esm it would be impossible.

You can use xEdit (FO4Edit) 4.02: 1) Save your edited version in another folder 2) Load the original plugin in xEdit 3) Use the "Create delta patch" option and select your edited version 4) Save and exit xEdit, then change the file extension from .esu to .esp This will automatically create a patch with all the changes you made, and only those changes, and Diamond City Expanded would be a master just as it would using the CK. Depending on how much was required, having to redo the entire thing in the CK might be a pain. Additionally, if Diamond City Expanded's plugin is a .esp file, the CK will rip it out when you save your patch, which will break things horribly. The CK is "helpful" like that. Also, if Diamond City Expanded updates, you can use the delta patch process to compare the version your patch was made off of to the new version and quickly check if your patch needs to be updated.

You need a second flag, mentioned in the What's New tab of FO4Edit (xEdit). DO NOT edit the master list header for any reason other than something like this. Deleting masters from it WILL break your plugin, and manually sorting masters will do so as well. The ONLY reason to touch the master list in the file header is for something like you are trying to do here*. *Renaming a master for a plugin because the mod author of the master renamed the plugin is fine as well, and I consider basically the same thing as what you are doing here, i.e. renaming** plugins that had the name changed for various reasons. And not moving, removing, or adding

Scrap Everything doesn't use that ini. It gives the option for people who want to scrap outside settlements (like with Conquest), but it has several warnings on the option. Most complaints are from people who ignore those warnings, or have other mods that cause problems and blame Scrap Everything because they can't be bothered to properly test things to find the actual problem. Also, very few mods are broken by having Scrap Everything load after them. If you want to only allow certain things within a cell to be scrappable, you would use the CK to make those things un-scrappable, and regenerate precombineds and previs. DO NOT generate precombineds if you have done anything else in that cell during that session of using the CK. Save your plugin, close the CK, reload your plugin in the CK, and generate precombineds as soon as you have loaded the cell. Doing otherwise is likely to generate bad precombineds, because the CK is so finicky. If you are working in a cell that is not near a "busy" area*, you can usually get away with just disabling precombineds and previs with minimal performance impact. As pra mentioned, you can do this by copying a single REFR record that is part of a precombined mesh in the cell in question using FO4Edit, or you can remove the VISI, PCMB, RVIS, XPRI, and XCRI fields from the cell in your mod (this is what Scrap Everything does, and both will stay disabled even if the mod user uses one of the relevant ini edits**. If you want to look into generating precombineds, I recommend checking out this thread. *by which I mean a place with tons of stuff, like in the city **Having one of the two ini edits (precombineds and previs) will break the system that disables precombineds and previs based on REFR records, turning the other optimization method back on, which usually causes graphical glitches.

You might want to uninstall the CK, verify integrity of FO4 files, and reinstall the CK. It sounds like there may be a problem with the install. Edit: Actually, first delete the generated precombiend .nif files and try building previs (it will use vanilla precombineds). If that works, then the bad precombineds are causing problems with previs. Then try extracting the contents of the .ba2 to your data folder and rebuilding precombineds again.

If you add bUseCombinedObjects=0 to your Fallout4Custom.ini (globally disables precombineds), do you see them? If so, then there are a bunch of bad meshes. You usually see that if the mesh has a major issue (such as wrong format for the game). If not, something went horribly wrong with your precombined generation.

The only thing that breaks precombineds/previs is touching REFR records that are part of precombined/previs meshes, or direct edits to the CELL record to remove precombineds/previs. Texture replacers (where the .dds files are replaced and the mesh itself isn't touched) work fine, even on precombineds. Material swaps (either by editing the .nif, or applying a MSWP in the record, will not break precombineds, but it will also not apply to precombined versions of that mesh. I think that a material replacer (.bgsm/.bgem) that doesn't require an edit to the .nif or the record will also work, but I haven't tested it.

Yeah, loading it in the CK will also fix the missing timestamps in the CK. But if your mod has a bunch of .esp masters, it is easier to work on the precombineds in a separate plugin, then copy it over in xEdit, and use the script to copy the VC info data over.

The Oblivion issue was apparently related to something when you enabled Version Control in the CS (Construction Set). Not sure what the problem was, probably things not overwriting properly. Apparently using that was actually somewhat important in Oblivion modding to get things working properly, this is all third hand*, over a month ago. It was probably locked because it: A) wasn't decoded, so we had no idea what values were acceptable and B) was never used for anything except doing work that required it to be accurate in the CS up until Fallout 4 and the precombined/previs system. And the fact that it was used there was discovered (AFAICT) by me, shortly before I made that post. The other locked subrecords in the header are things that would cause all kinds of problems if you directly edited them (with a possible exception of VC Info 2), so VC Info 1 was just left locked for the time being. I don't think there is any timestamp embedded in the actual .uvd or .nif files. From my testing, all that matters is that the PCMB and VISI fields have the same or later date as any REFR that is part of a precombined mesh. You can get the VC Info 1 data as a hex value (to more easily compare) by selecting the VC Info 1 subrecord -> Ctrl+C, and paste it in a text doc or something. The first two hex pairs are what matter, the last two are probably related to the User/Index values. And I don't think the VC Info 1 for the Cell itself matters, pretty sure I tested that when I found the connection between REFR VC Info 1 and PCMB/VISI. Also, if you don't want to have to deal with making sure that both plugins have the same masters, I fixed the script to remove that requirement: I verified with Elminster that it doesn't matter, and zilav (the guy who made it) said it was put in at the request of the person who asked him to make it, and shouldn't be needed. My tests confirmed that it works fine without the masters matching. Might be related to that same "Version Control in the CK" thing. *The reason for it being disabled is directly from Elminster, He Who Created The Most Wondrous of Tools. The problem that occurred when using Version Control in the CS when using Copy as Override in xEdit was reported to him, and not something he directly experienced. My guess is that it makes it so the CS left it with the copied timestamp, whereas an empty subrecord was auto-filled with the current date when you load and save it in the CS (or CK).

You can use a delta patch to create a .esu file that only contains your differences. You would then be able to rename it to a .esp and it would only contain your changes, while having hte original as a master. To make a Delta patch: 1) Make sure you have xEdit (FO4Edit) 4.0 or newer. 2) Load the original version of the mod in xEdit (either rename your version, or put it in a separate folder). 3) Right click on the original mod -> Create Delta patch (near top of the right click menu). 4) Navigate to and select your edited mod. 5) Save and exit xEdit. 6) Rename the generated .esu so it has a different name than the original, and has a .esp file extension. 7) If you made a .ba2 file, or any files that require the filename to match, fix it to work with your new plugin name. Delta patches are wonderful, wonderful things.

Yes, if you want it added for you to be able to see it in the CK. You can always add the hair/eyes in FO4Edit, and not have those plugins as masters until you are done with the CK. There might be a better way, I don't tend to use the CK if at all possible.

Glad you got everything working :smile: And esp masters are fine, as long as you only look at it/edit it in xEdit. The game is perfectly fine with plugins that have .esp masters. The CK is just picky for no reason.

By the way, I confirmed that it is the file extension, not the flags, that matters. Bethesda "fixed" it just looking for the ESM flag :mad: If you can scrap the same thing in the normal build area, it is probably just out of the new build volume (vertically). Yeah, probably for the best to just edit it directly. And if you wanted to make it a separate plugin, you could use xEdit's New (with 4.0) Delta patch feature. You can use it to compare two versions of a plugin, and it will make a .esu file (ignored by game, only useful in xEdit) that contains only the changes between the two versions. It is how the super in-depth Fallout 76 patch notes have been made. If you haven't already, get the newest xEdit, Elminster added so many awesome features (collapsible nodes in the View window is a godsend if you use xEdit with large records, like the Race records) between the old 3.2.2 and the 4.0 release.

Have you tried saving it as a Looksmenu preset and using Face Ripper to convert it to a normal preset? In a quick test I did, the resulting plugin had the tints listed for the NPC under the Face Tinting Layers subrecord. Also, the CK hates .esp masters. You used to be able to just add a ESM flag using xEdit, but the current version of the CK "fixed" that, so masters need to have .esm or .esl file extension if you want to be able to load it in the CK. Otherwise the CK will just remove the .esp master, and break things.

Not sure why it would refuse to believe that something changed. You could just tell it to update the precombined/previs timestamps for the cell(s) you are working in, since you are going to delete them anyway so them being different won't matter. Yes, unresolved errors are a result of your file having a .esp (Build High) as a master. The CK just rips out any non ESM master, because reasons. I think you could get away with just the flag at some point, but I have heard something about it needing to have the .esm file extension for the current version of the CK. Make sure the height is more than needed, some things are "technically" below the vanilla build volumes. It is one of the first thigns Build High did, before it expanded horizontally (hence the name :D). Also, depending on the type of debris decal, it might not be scrappable. I think Texture Sets are one of the ones that can't be directly scrapped. Yes, broken precombineds from Scrap Everything combined with Extra Object Selection from Place Everywhere means you should be able to scrap anything at all, as long as precombineds are broken in the expanded area as well. If you can disable it with the console it isn't a problem with precombineds. Also, I have noticed some things that are below/above the build volume are unscrappable even with extra object selection enabled. using modpos to move them suddenly makes it scrappable, even though extra object selection should have done that already. Precombined/previs tips: The scale gizmo is supposed to let you scale in a single direction, but I am not sure if it works on things that aren't primitives. You might have to edit the mesh directly for the borders. If you are using straight border indicators (like those used in the Mechanist's Lair) rather than the custom ones that follow the landscape and contours of the vanilla volume, you can use Nifskope and directly edit the Vertex Data to change the z coordinates to make it taller. You can also just use Blender or 3DS Max to edit the nif. By the way, the if you switch to one of the render modes that shows textures (GBuffer_) when you have a gizmo open, or try to bring up a gizmo with those selected, it breaks the gizmo until you restart the CK. Took a while to figure that bit out.

^What he said. Merging involves more than just "Copy as Override". With the addition that removing masters manually when there are still dependencies will break a lot of records. Even if you did remove/renumber all the records pointing at old masters, it can still break things. I don't think there would be a problem if the only master left would be Fallout4.esm (and you actually had all the master-dependent records fixed/removed), but I'm not certain. The reason there can still be a problem even if all the master-dependent records were tweaked/renumbered to be internal to the plugin is that the Master list is basically a mini-load order for records i nthat plugin, and they have internal IDs that you don't see. Clean Masters renumbers those internal IDs properly, just editing the sub-record in the file header doesn't. So basically, that feature was removed for a reason, just use Clean Masters instead. And if Clean Masters doesn't remove a master, there are still dependencies. You can use the "Report Masters" script to tell you what records you need to fix first.

I have been using xEdit since Fallout 3, for both conflict resolution and just tweaking mods in general (such as if I don't think this mod-added weapon is doing the right amount of damage, or think that item is too light/heavy). And with the release of Fallout 4, I began making and releasing actual mods. The only time I ever touch the Creation Kit is if I absolutely have to, 99% of the work is done in xEdit. I would never have made a mod without xEdit, and the modding scene for TES/Fallout games would never have gotten nearly as big as it is without this amazing tool. If you are an avid mod user, please try and support further development of this tool, even if it is just $1-2.

Only from a plugin (.esp/.esm/.esl). Texture replacers, and probably material replacers as well (based on what the internal structure of a precombined .nif file looks like) will work fine on precombined records. Edit: Technically there is another way to break things. If you manually edit/replace one of the precombined .nif files, it will break previs (occlusion culling). Though the precombined records will still be precombined, so I guess you could say that doesn't break precombineds, just previs. Still a bad idea, but thankfully not one that people are likely to try (and it is fairly obvious in-game should they check their mod before releasing).

Yeah, what Trosski said should be fine. I haven't done it for more than one cell at a time, but I didn't need to either. And yes, test extensively. Test before you pack files, and test after packing. Make sure that you remove the loose files after it is packed, or you won't realize if anything is wrong with the packed version. Cleaning ITMs before or after shouldn't make a difference, but previs in particular is very picky. Can't even manually edit a precombined .nif file without breaking previs in little ways.

Regenerating precombineds and previs should overwrite the existing ones. If there are any meshes that are no longer used at all, the old ones would still be left in that folder but not actually be used by the game, so it shouldn't be an issue. Changes in xEdit or in the CK will both be reflected when you re-generate precombineds/previs, as long as the changes are done first. You don't need to do both. Just make sure that you save and relaunch the CK before regenerating precombineds. You should never do anything in the CK between loading the cell you are working on and generating precombineds, as detailed in my last post on the previous page.

Select both FormID Lists at the same time (Ctrl+click on the second one), right click on either one -> Compare Selected.

I had that happen when I was rebuilding Vault 88 again, and it seems to be a result of making some change or another in the CK between loading the plugin and generating precombineds. If you save and exit, relaunch the CK, and build precombineds first thing, it should never happen. Also, I found the exact reason touching a precombined REFR in xEdit can break precombineds/previs. The auto-disable system compares the Version Control Info 1 field (a record timestamp) of the REFR records listed in the XCRI sub-record of the CELL to the PCMB timestamp. If the REFR has a later timestamp, or has no timestamp (all 0s in old xEdit, or None in xEdit 4.0), it disables previs/precombineds for that cell. So if you are building precombiends with one plugin and trying to merge it into another, you'll have issues, since xEdit zeros that field out when you copy (as override, or as new record) into another plugin. This is apparently related to some issues people were having in Oblivion days when it did copy that field.

I would try reinstalling the CK, there is definitely something wrong with the install. Of note, if you have the precombineds already rebuilt, you just need to Generate Precombined Visibility, not the regular "Generate Visibility".

I've occasionally had issues with it not properly generating it (mainly applying previs to things I don't want it applied to), but not completely failing. It usually takes longer than precombined generation, in my experience. That said, I have only generated precombineds/previs on individual cells, haven't tried to regenerate precombineds/previs for the entire worldspace yet. If you try to generate it for just one cell, does it work? Also, one note: if you have a mod that just adds records to the worldspace, or at least doesn't touch any REFR records that are part of a precombined mesh (i.e. show as [Placed Object] rather than just Placed Object in FO4Edit), you don't need to generate new precombineds/previs, as the old ones aren't broken. You can, and if the mod adds thousands of records it might be worth it, but it will only break if you touch previously precombined meshes. A quick way to test in-game if they are broken in a given cell is to type tpc into the console twice. If it just says "Pre-culling now enabled" the second time, it's fine. If it says something about "but disabled for this area", previs is disabled in that cell. And unless you used the bUsePreculledObjects=0 ini edit precombineds will be disabled for that cell as well.

It is saving to the wrong place, make sure your Game Data Path in your Bodyslide settings includes the Data folder at the end. Right now it looks like it created and is saving to a Meshes folder outside your Data folder, which the game won't see.