VIitS

If something shows in xEdit as [Placed Object], it is part of a precombined mesh and touching it will break precombineds/previs if you don't rebuild them. If it does not have brackets, it is not part of a precombined mesh and you can do whatever you want to it.

You can just type the formID, you don't need to enter the name.

Nukem is wonderful and awesome: https://github.com/Nukem9/Fallout4Test/releases/tag/0.1 First (early, limited) release of CK Fixes for FO4. Includes the commandline fix, among other things. Just remember to be respectful and don't pester him for features/updates. Requires the latest VS2019 x64 redist, and if you have any issues there is no support. It is very much in the alpha stage, and Nukem barely touches FO4 so it is a much, much lower priority than any of his Skyrim stuff. Feel free to open an issue if you think there is a legitimate bug (rather than a PICNIC error) or you have a request for a feature/CK bug fix, but don't expect quick responses.

Right click -> Edit on the same field you are clicking to get the list of viable records.

Another good resource for understanding the systems is this thread: https://forums.nexusmods.com/index.php?/topic/5522717-fallout-4-optimization-and-performance-systems-explained/ if you want to go more in-depth, but if you just want to generate precombineds for a mod then Pelgar's guides look pretty good. A lot of the info is in the OP, but some stuff (especially in regards to generating shared-geometry precombineds like the base game+DLC use*) are spread in later posts. One thing I will note about previs: while I think the current version of the CK does this automatically, you want to ensure that previs in exterior cells is generated with the same central cell. Previs is done in 3x3 cell grids, and if the grid for your cells is out of alignment with the rest of the worldspace, that will cause significant object flickering issues. You can check by making sure the RVIS subrecord is the same for your plugin as it is for the source (Fallout4.esm or DLC if one of those worldspaces). That value is hidden in the CK so you would need to use FO4Edit to check it. I know that older versions of the CK didn't necessarily center previs properly if you didn't have the right cell selected (or maybe loaded) when generating, so it is worth checking to make sure that the current CK doesn't have that issue. *the main differences with Shared-geometry precombineds are that they use .cdx/.csg files, are much smaller (often on the order of 1/5 to 1/10) the size of the ones generated from within the CK, and also seem to be somewhat finicky and esily broken (such as by changing the name). They require an edit to the Creationkit.exe, and the filename can't have spaces, which is why the inability to change the filename after matters.

Those groups are listed in the order that they are written in the plugin. It seems like it is largely alphabetical, but that is only to the extent the Bethesda made it so. Look near the top, 5th group down.

If you mean that you generated precombineds/previs multiple times for the same cell as different plugins touched it, and want to merge the generated results, that won't work at all. Since you mention merging XPRI and XCRI, I assume that is your intent. If you want to generate previs/precombineds for one cell that is touched by several mods, you would needs to flag them all as ESM (just the flag using xEdit, don't change the file extension), load them as masters in the CK, then generate previs and precombineds and save the new plugin and use that as your patch. If you mean you generated precombineds and previs for different cells under different plugins and wanted to have them all saved under a single patch plugin, it depends on how you are doing that. If you are keeping the original plugins, you can just copy the CELL records into your patch, and make sure the VISI and RVIS are kept from when you generated. If you want to disable the original plugins and have a single mega-merged worldspace mod, that is a terrible idea, but you would also need to restore the Version Control Info 1 data, as copying to a new plugin using xEdit wipes that data. There is a script included with xEdit to copy the version control data, but you have to remove the bits of code that check if the masters are the same. You can also use the CK. If you load the relevant cell in the CK, it will set the VC Info 1 date to the current day for any record missing that info, but you would also need to right click -> Update timestamps or the REFRs would have a newer date than the VISI/PCMB timestamps and thus would break them in-game.

No idea, I have basically no experience with actual coding so wouldn't have the first clue on how to rip open and search the code in order to make a F4SE dll to change that.

If it is a MISC record (Miscellaneous item) with something in the CVPA - Components subrecord, it gets sorted under junk. The components you see in the pipboy are MISC versions of the CMPO (Component) records. If you add CMPO items to the inventory (such as adding it as a component for a scrap recipe rather than using the MISC version)*, they will be invisible. So what you want to do would require somehow using f4se scripts to change the game behavior specifically for a handful of records that are only different in terms of the EDIDs of the records. *Build recipes have the CMPO under components so that any MISC that has those under the components section of the record can be used for crafting it.

You need to look at the Version Control Info 1 value for the placed object records, not for the cell. If the VC Info 1 of any placed object is newer than the VISI/PCMB timestamps, that is what breaks previs and precombineds Here is a screenshot to show what I mean: The top 5 are part of precombined meshes, the bottom five are not. In general, if a mod touches a REFR record (placed object) that is part of precombineds and has vanilla values for VISI and PCMB, it probably breaks precombineds and previs If anything, I would expect previs to have a greater impact in most cases. And the easiest way to see what cells share a previs block are by looking at the RVIS: If you go to the cell listed in the RVIS and look at the "Referenced By" tab then sort by signature, the CELL records you see are almost certainly the neighboring cells that use the same .uvd previs file. In this example, you would want to look at 03000BC2 and see what other cells have that same value (as well as looking at if that cell breaks precombineds/previs, it is the center cell of the 3x3 block). Just wanted to make sure, some people only look in the Documents\my games\Fallout4 folder, while the ini files from mods are in the Data folder (or if using MO2, the mod's folder)

Scrap Everything provides the ini edits as an option for people who want to use mods like Conquest and scrap anywhere and everywhere. It works fine without it (at least in vanilla settlement bounds), because it is very easy to apply those changes on a per cell (or per 3x3 cell grid for Previs). Spring Cleaning only gives the ini option because it hasn't been updated since before the Cell Reset bug was fixed by Bethesda. That bug meant that any plugin that touched a cell and didn't have the ESM flag would cause the Cell to reset all the time (including things like containers and power armor). SC also has an ESM version, but as an ESM it is very easy for a later mod to undo the breaking of precombineds/previs by touching that cell in a way that doesn't break precombineds/previs. I put a ton of warnings on the ini options*, but a lot of people ignore them and then complain about the problems I warned about, so I am making them a separate download next update. That way I have proof that they used them. Honestly, if someone wants to use a mod like Conquest and be able to scrap anywhere, I would recommend using Geth7n's mod. Either the plugin or the script, making sure that it only gets applied to exterior cells. If you use mods that rely on Cell edits (like some lighting/sound mods), I recommend a combination of the two (Geth7n's plugin loading before them, with the script applied to those so that you get the affects of both. *among other things, disabling previs in interior cells re-enables room bounds and portals, and Bethesda did a very lazy, half-assed job on them for FO4 since they are not used unless you break previs), resulting in many things (like the elevator) being invisible unless viewed from the right spot

If a mod edits records that are part of precombined meshes without rebuilding them, precombineds and previs are automatically broken (this is intentional). The way you can check is to compare the "Version Control Info 1" subrecord (in the record header) of the precombined REFR records to the VISI and PCMB subrecords of the Cell containing them. If the date of any of the precombined REFRs is either blank (which happens if you copy using xEdit*) or newer than the VISI/PCMB timestamps, then precombineds and previs will be broken for that cell. You can tell a REFR is part of a precombined mesh because the "Placed Object" descriptor will be surrounded by brackets (i./e. [Placed Object] for precombined REFRs, Placed Object for non-precombined REFRs). If you are using the most recent version of FO4Edit (4.0.3), it will have the VISI/PCMB timestamps decoded. One other thing of note: since Previs (the thing you are checking with the tpc console command) is made in 3x3 cell grids, you want to check for all Cells that share an RVIS cell (as well as the cell referenced in the RVIS subrecord) with the Cell you checked tpc in. If Previs is disabled for one of those 9 cells, it is disabled for all 9. One final note: did you check for any mods having ini files, and not just the Fallout4.ini/Fallout4Custom.ini? If a mod has a ini file with the same name as the plugin, its settings will be merged with your main ini settings at runtime. That said, a mod having that ini setting without being a scrap mod is a sign that you should stay far away, as that is a terrible idea. Even for Scrap Everything (which I am a co-author of), I provide the option but warn people against using it unless they know exactly what using it can cause. Any Scrap mod that isn't allowing you to set up settlements anywhere can just disable it on a per-cell basis, relying on the ini is just asking for complaints about performance impact. *This is also intentional, as it prevents problems when people are actually using the Version Control system in the CK

"File index 3 is invalid. Clamping to 02" generally means you had a master file get ripped out. If you load a mod in the CK and it has a .esp master (without the flag), the CK will rip it out*, often destroying your plugin in the background, and loading a backup is your best bet to fix it. If you check and see that all the mods that should have been listed as masters still are, then something really weird happened to give a record an internal ID higher than it should have. For a bit more explanation: The FormID you see in the CK or in xEdit for a record aren't stored in the file with those formIDs, as the ID can be different depending on the plugins loaded. It instead has an internal File index, that it compares to the Master list in the file header (viewable in xEdit, also is the list of masters when loading the plugin in the CK)). So as an example, if you have a mod with a master list that looks like this: Fallout.esm DLCRobot.esm DLCCoast.esm Any records (or references to records), the records originating from DLCCoast.esm will be listed internally with a file index of 02 (e.g. 0200153A), the records from DLCRobot.esm will have a file index of 01, and the records from Fallout.esm will have a file index of 00. That error you got meant a file was stored internally as 03xxxxxx, but you only had three master files (Fallout.esm and two others), while an index of 03 points to your fourth master. *The easiest way to make a mod with a .esp master (i.e. you want to include another mod you didn't make as a master that isn't flagged as ESM), you can use xEdit to add the flag while working in the CK. If doing so messes with load order you would want to then remove the flag from said .esp master before testing in game. The other error sounds like it is related to Version Control, but I have never used version control so don't know how to fix it.

Pretty easy, this is a nice short video I like: https://www.youtube.com/watch?v=-SssqMofI_Y. Note, it has to be 3DS Max 2013, it cannot be a newer version.

You can just use xEdit to flag the plugin as ESM and leave the file extension as .esp if you want, and it is functionally no different from having the file extension. However, if you have any AI packages or scripts that rely on a REFR/ACHR being constantly loaded but that are not properly flagged, those will break as .esp files (without the ESM flag) will always load all REFRs at all times. If you need help, some of the people on the xEdit discord (link in top right of xEdit) have done some work on figuring out what is required/how to figure out what needs to be fixed when converting (make it clear you are the mod author so people don't tell you that the mod author should do it :tongue: ). Though to be clear, the only things that will be affected should always have had the Persistent Location or Persistent reference flags, they only worked without them due to frankly terrible decisions (assuming that it is intentional and not a bug) by Bethesda in regards to how temp REFRs are handled in non-ESM files. And no, there are no other ways to keep your mod from having a potentially massive impact on the object reference limit.

If you are placing a static in the world, you can use the scale option in the REFR record to change the size and the collision will change with it. Changing collision on something you can loot would require you to completely rebuild the collision using 3DS Max 2013 and the Bethesda plugin (under Tools\Nif_Exporter wherever you have the CK installed).

The total loaded REFR limit for FO4 is 2^21 (a little over two million). If your mod is flagged as ESM, then only REFRs flagged as persistent and ones in the currently loaded cells will count towards that limit, so you should be fine as long as you make sure to make your mod an ESM.

Not sure why it happens, since precombined meshes are not able to include animated objects, but for some reason disabling precombineds/previs will cause that. If you make changes to a precombined reference in a cell (it shows in FO4Edit as [Placed Object], the brackets indicating that that REFR is part of a precombined mesh), then the game will automatically disable precombineds and previs. The only fix is to either 1) Rebuild precombineds and previs in the CK or 2) Keep your mod from editing precombined REFRs in the relevant cell.

CMPO is used in build recipes and MISC is used in scrap recipes. If the scrap recipe has the CMPO instead of the misc, you will get the yield and be able to use in in crafting*, but it won't show up in your inventory as you having that material. So as an example, if you scrap something using a scrap recipe that gives 1 nuclear material CMPO instead of 1 MISC, the count of nuclear material you have will stay the same, but you will have one hidden unit. Also, and of particular note for scrap recipes: if the scrap recipe has a MISC item rather than a CMPO, you get exactly as much material as is listed in the COBJ. If it is listed as a CMPO item, the yield is affected by the scrap multiplier (for rare items it is .25 or something like that) so you get less. *I am almost certain this is the case, but not 100% it is usable in crafting

You would have to manually copy over the changes, and if you made a change to a different part of the same record, you would have to manually copy only the relevant parts of the fix from UFO4P to your mod. So if you want to ensure those fixes are included by default you should load it as a masterfile.

If you use the "Inject into master" method I mentioned, with ArmorKeywords.esm as the base master you are injecting and copying into, then those records wouldn't change. So anything relying on that .esm would be fine. Anything relying on any of the mods you merged into it would require you to completely remake the whole thing (or manually change references), but if you are only merging weapon mods into this particular merged mod, it is much less likely for another mod to reference the weapon mod than it would be for you to add another weapon mod that needs AWKCR.

Vanguardascendant, what HadToRegister means is, if you cahnge the file extension to .esl, the game will treat it as if it has both the ESL and ESM flags. So it will be sorted with other ESM plugins. If your mod manager lets you put .esl files in the middle of your normal .esp's, then you need to update/use a different mod manager. That (plus the fact that changing the file extension causes problems for patches/mods expecting a .esp extension°), is a big part of the reason it is recommended to use a .esp file extension and just add the flags you need using xEdit. Yes, you can just unpack the .ba2 files. You can also use the CK to repack them all into one large .ba2 once you are done merging. Yes, you can have any mods you want referencing things from the ESL-flagged mod. You can even add the ESM flag if it should have it (though there is no need to do so just because you have another mod using it as a master*) Any time you are merging plugins, you want to first make sure you have found all plugins that reference that one as a master that you might want to use, as merging plugins using any method will completely break the old links. If you have the child plugins loaded at the time you merge the master, it should update the links so things still work**. If you later want to add a plugin that relies on one you already merged, you either have to manually fix the references, or completely remake the merged mod from scratch. Which is the biggest reason to use espFEs whenever possible. That said, if I was merging records anyway, I personally would use the "Inject into master" and "Copy as override (with overwrite)" in xEdit. I can see what is happening there, and it is clearly defined what happens. Using that method, the "master" you select with the "Inject into master" is the final plugin you will be keeping. You just want to make sure that, if there are any records touched by multiple mods, you should do conflict resolution first and make sure you inject in the order your resolution was done, since the (with overwrite) version of Copy as override will replace existing version of a record with the one you are copying. The normal "Copy as override" skips any records that already exist in the target plugin. °The bigger problem is, if you release a mod as a .esl, and it later grows large enough that you have to remove the flag (i.e. more than 4095 new records), you HAVE to change the file extension, causing problems for any child plugins. With an espFE, you can just remove the flag and the patches will still work fine. *one note: if loading a mod into the CK, you need to make sure all it's masters have the ESM flag (adding it using xEdit if missing), or the CK will rip them out and break your plugin. **At least, the xEdit method I describe does. I assume mator's Merge Plugins does too, but I have never used it.

I haven't truly played in several years, but when I did I used an older version of NMM that installed directly into the Data folder. And like you, I installed most manually and basically just used it as a FOMOD manager/plugins.txt editor. You can still get the old versions from the github (the one I happened to stop on is 0.63.15). For that version, it completely ignores the ESL flag and so won't try and force them to load with ESMs like the last non-github release did, though as a corollary it won't even recognize .esl plugins, which might be a problem if you have any that aren't from the CC*. If you know what you are doing, the main downside to installing directly to the Data folder is when you have multiple overlapping mods that don't use .ba2 archives, and you can always manually extract files from a specific mod should you need to. You don't have profiles that allow swapping between mod setups, but the only need I have felt for that is to more easily create a blank slate when I am modding, and renaming folders/disabling plugins works well enough. *not that people should be using the file extension, an ESL-flagged .esp is better in just about every way, but that is a discussion for another time

Changing the file extension to .esl is never the right way to go. It adds both the ESM and ESL flags (at launch, not to the plugin flags, so you can't remove one of them), and if your mod ever needs to have more new records than an ESL can safely hold, removing the .esl filename will break any existent patches (whereas a ESPfe can just have the flag removed and the patches won't be broken).

As thousande said, it can be done in nifskope. If there is a vanilla object with the exact animation you want, you can even steal it. Not sure if it would be easier to copy the animation into your mesh or copy your mesh into the vanilla .nif and replace the parts with your own. That said, what are you using to import into Max? I don't know if there is a good FO4 .nif importer for 2013 directly, but the 2017 importer works great. I used it a while back to import the vault gear door and create a close animation (would have uploaded it, but someone else already did). With Max it was a lot easier than it would have been in Nifskope, was able to just copy it and reverse it. If you do have access to Max 2017 or 2018, you can use 2013 to give it the necessary collision for an animated mesh, then do all the animation in the newer version. Here is a nice tutorial for making FO4 collisions (make sure to generate the right kind): https://www.youtube.com/watch?v=-SssqMofI_Y Here is one for making animations from scratch in 2013: https://www.youtube.com/watch?v=XETBRVJArZU