VIitS

Yeah, using an SCOL nif with a STAT record is known to be problematic (can't remember if it causes any problems outside precombined generation). It should be fine placing the SCOL there and generating with that in place, so you still have the right collision. And collision is taken into consideration in the most annoying way: a single CELLID_physics.nif file that contains most (sometimes all, sometimes just some of the precombineds*) of the collision data for all precombined REFRs in that cell. It makes precombineds just that little bit less modular (if collision was kept in the corresponding nif, there would be ways to mix and match potentially, though it would not be very user friendly and you would still need to regen previs, so not really a big loss that you can't do that, just annoying). *No idea what makes it leave collision in a precombined nif rather than merging it into the physics.nif file, but it doesn't seem to be that common (only a few of the vanilla precombined nifs I have looked at had the collision data in them)

Note: you can confirm if it is previs by using the tpc command in-game. That stands for toggle preculling, and will turn previs off/back on. If they stay invisible, but you get a "previs enabled, but disabled in this area" message after the second use of tpc, that would mean something is causing the previs to not load, and thus you have some other occlusion method in that area that is causing the invisibility. If they appear when you use tpc and the second use confirms it is working locally, then I would try adding the "non-occluder" flag to a couple base objects in the area and regenerating, especially anything like railings that mean you are looking through a single nif (also important when you have a small gap between two separate nifs, had an issue with that in Vault 88, between the cave wall and a vertical I beam at the entrance, just before the vault door). See the PRP* channel of the collective modding discord (link in description of PRP), or the precombineds/previs channel of the xEdit discord (discord link inside xEdit), for some fun that BenRierimanu and others have had with things occluding when they shouldn't :teehee:. And yes, it sounds very much like bad room bounds, but as you said, you are in an exterior cell and room bounds/portals are only used in interior cells. Also, the room bounds/portals system is disabled when previs is active. *PRP (Previsibines Repair Pack) is like the precombineds/previs version of UFO4P, because Arthmoor and co rightly took one look at the precombineds/previs systems and noped out.

to this: I can see that many workshopScrapRecipe_XXX records include STAT objects while scrapping some STAT will brake PreCombines and else. Most of the STAT object are [Placed Objects] and thus shouldnt be touched at all, while some of them are not BUT only in the settlement cell(s). I assume in order to gain the most performance out of the engine most of the world is PreComined/PreVis and only the objects (but not all) in a settlement cells arent. I found some STAT objects which can be scrapped by vanilla already which decrease performance which in turn place alot of "???" around my head, since it doesnt make any sense, more likely it seems this game was either finished in a rush or the communication/knowledge about certain stuff was not 100%. whatever its very weird. That was an oversimplification. Any edits to existing [Placed Objects] REFRs will break precombineds. The game compares the Version Control Info 1 (VCI1) value (in the record header in xEdit) to the PCMB subrecord in the containing CELL. If the VCI1 value is None*, or has a more recent date, precombineds and previs will be broken in that area. In any case, that was talking about normal mod making. When generating precombineds (and previs), there are many things that can cause a record to be excluded form precombineds. Being the created object in a recipe seems to cause them to be excluded if, and only if, they are in a settlement, while letting them still be precombined outside settlements. There are a number of other things that will exclude REFRs from generation as well, such as any linked reference and some others that are not coming to mind at the moment. If you want more up to date info, you can check out the PRP channels on the Collective Modding discord (linked in the description of PRP) or the Precombineds and previs channel on the xEdit discord (discord button in the top right within xEdit). *happens if you copied the record in xEdit, since xEdit intentionally wipes that value when copying a record.

Greekrage is right on both counts (it will break, if it didn't your changes wouldn't be visible). If you want the details why: It will break precombineds. This is because the game compares the Version Control Info 1 (VCI1) value (in the record header, visible in xEdit) of all [placed objects] (i.e. REFRs listed in XCRI of the winning copy of the CELL*), to the PCMB timestamp in CELL record. If the VCI1 of any REFR is newer than the PCMB timestamp of the winning CELL record, both precombineds and previs are broken. Same if the VCI1 shows as "None" in xEdit (which will happen if you copy them using xEdit**). Technically, you could copy that VCI1 data in xEdit using a script, or use the "Update Timestamps" option in the CK to set a new PCMB (and VISI) date, but if you do so without regenerating precombineds and previs, then your changes won't show up in game. This is because a record being in XCRI tells the game to not actually load the REFR, instead relying on the precombined nif file. That nif file has things baked into it, including model (mesh), position (and orientation) in the WRLD (or in the CELL for an interior), scale of objects, and material applied to them. *Fun fact: it looks at the winning copy of ALL REFRs in the winning XCRI. If your mod rebuilds precombineds, and it doesn't touch some of those REFRs but another mod does, the game will compare the VCI1 of the winning version of the REFR from that other mod (even if your mod is loaded at the end of your load order). If it is newer than when you rebuilt precombineds, precombineds and previs go poof. This makes sense when you consider how the game handles overrides°, but means that it is a pain to track down which mod is breaking precombineds and previs, if you notice they are breaking in-game and it doesn't happen with just your mod and the base game+DLC. Someone is working on an xEdit script to help, but it is not yet published. Once it is, I will 100% be referencing it on my mod page, as I am sure some others will :laugh:. **This is intentional, as back when xEdit copied it (back in TES4 days), it caused problems for people using the Version Control system in the CK, and until FO4 it never mattered for anything else. °Once loaded, the game doesn't distinguish which plugin a winning override came from. It just discards all non-winning versions of records, with very few exceptions (REFRs and CELLs are not one of those exceptions).

I know that expedition saves convert to a regular one when done, but is there any way to use hte save editor to turn a regular save into an expedition one? I want to play through the expedition but don't really want to start from scratch with it right now.

Exosolar's Quick Scan with Range Boost works fine for me (haven't updated yet for Sentinels, just running in offline for now), I just used the provided .lua file with AMUMSS (not hard at all to use, just download the required files and follow the instructions). The .pak release obviously needs to be updated for the Sentinel update, but both that and using the lua are stuck waiting on an update to the mbin compiler, same with everyone else. I will probably reduce it when I rebuild the pak for the Sentinels update, it is about half a second with the mod's defaults. And similarly, if you only want the faster scanning from it and not the other features, you can edit the lua pretty easily using any text editor, the author includes a comment noting the vanilla values for everything.

Nevermind, apparently the soundMod file linked in this video works fine, as does the instructions in the video (I edited a different bnk file than the ones they were talking about, but that is irrelevant).

I was following this guide on replacing audio in .bnk files: https://nmsmodding.fandom.com/wiki/Replacing_Audio. Python is installed (3.9.10), I grabbed Monkeyman's BNK Compiler from the link at the top of the page, and got it to extract the .wem files just fine. Found the .wem I needed using the corresponding XML for the .bnk file, and replaced it with a .wem that works fine when replacing a .wem outside a .bnk file. But when I recompile the bnk file, all sounds controlled by it are just silent in-game. I see someone with the same problem in the comments of the above wiki link from 2018, but there is no response to them. Am I doing something wrong? Or does the bnk compiler not work for the current version of the game? I tried using the BNKcompiler.py file from their github, but that seems to be missing a lot of things in the file linked on the wiki page, and I noticed that the readme on the github page says "The recompilation of bnks is currently broken sorry". I would leave it at that, but since the compiler file on the wiki is different from the one on the github page, I am hoping that the compiler was fixed by someone else, and recompiling works.

That is the hex code that is actually in the plugin, it is converted to the timestamp you see. If you need to copy the VCI1 header info from one copy of a record to a copy from another plugin, you can use the "Copy version control info from another plugin.pas" script included in xedit. You would just need to remove the bits that check for identical masterlists (those were put in at the request of someone, I confirmed with zilav (maker of the script), that they are not truly needed. Here is a copy of the plugin with the masterlist check removed: { Copy Version Control Info inside Record Header between plugins. Apply script to destination records, then select the source plugin. Both plugins must have the same masters list, records are matched by FormIDs. } unit CopyVCInfo; var fromPlugin: IInterface; //================================================================================== function Process(e: IInterface): integer; var frm: TForm; clb: TCheckListBox; i: integer; r: IInterface; begin // plugins selection window for the source plugin to copy from if not Assigned(fromPlugin) then begin frm := frmFileSelect; try frm.Caption := 'Select plugin to copy from'; frm.Width := 420; clb := TCheckListBox(frm.FindComponent('CheckListBox1')); // add files except the current one for i := 0 to Pred(FileCount) do if not SameText(GetFileName(e), GetFileName(FileByIndex(i))) then begin clb.Items.AddObject(GetFileName(FileByIndex(i)), FileByIndex(i)); Inc(i); end; // get the first checked file if frm.ShowModal = mrOk then for i := 0 to Pred(clb.Items.Count) do if clb.Checked[i] then begin fromPlugin := ObjectToElement(clb.Items.Objects[i]); Break; end; // if nothing is checked then abort if not Assigned(fromPlugin) then begin Result := 1; Exit; end; finally frm.Free; end; end; // copy VC info r := RecordByFormID(fromPlugin, FixedFormID(e), False); if Assigned(r) then begin SetFormVCS1(e, GetFormVCS1(r)); SetFormVCS2(e, GetFormVCS2(r)); end; end; end. Also, to be clear on how the VISI and PCMB are used: they are compared to the VCI1 of the REFRs listed under them in that copy of the CELL (i.e. the REFR records your mod touches) that are part of the precombined mesh. The way you can tell which ones are part of a precombined mesh, is they will have brackets (i.e. [Placed Object] rather than Placed Object). That denotes REFRs listed in the XCRI subrecord of the CELL.

I don't know of any that break precombineds, but as a result they don't enable scrapping of things that are part of a precombined mesh. You can use the bUseCombinedObjects=0 ini edit to globally break precombineds so you can scrap anything, but that is risky since - you will now be able to scrap the walls of interior cells - it doesn't break previs (occlusion culling), so scrapping large objects like buildings, privet hedges, trailers, etc... will result in occlusion bugs. bUsePreCulledObjects=0 will disable previs and fix that issue, but it will even further worsen the performance impact, and for some interior cells it will introduce occlusion bugs (even when nothing is scrapped) as some interiors have really bad room bounds and portals (old occlusion system used in previous games, re-enabled when previs is disabled). If you want to enable scrapping everywhere that is safe, I recommend Geth7n's mod. For compatibility, it would probably be best to place his plugin mod at the top of your load order, and use the xEdit script to apply the edits to any CELLs overridden by other mods (that way, any mods relying on edits to the CELL record would still work).

Just the other day, I made a patch for Greekrage's Fort Hagen and Boston Natural Surroundings. Quite unexplicable at first, the landscape at the entrance gate would be heavily deformed in-game, whenever I loaded the patch. The deformation could neither be seen when just loading BNS or just loading the Fort Hagen Mod. There was no evidence of it in Creation Kit while making/editing the patch either. After deleting a bunch of XPRI records from the patch, the landscape was fine. Good to know. I was basing this on messing up the XPRI data when merging previs built with a temp plugin into the main plugin, resulting in nothing but "could not be resolved" errors for that subrecord. Previs (and precombineds) were perfectly fine. Combined with what you saw, that would mean it is actually used for something, but if it is missing that doesn't break previs. Definitely good to know.

Landscapes are not considered for or a part of precombineds. I don't think they are considered for previs (occlusion culling), but could be wrong there.

If you have a CELL in a mod with no REFRs that have brackets, precombineds are not broken and, unless it adds a ton of stuff in a busier area of the game (like in/near the city), there is no point touching those precombineds. That said, it is very unlikely a mod will add enough things to affect performance (even in the middle of the city) without breaking precombineds. If the mod touches ANY REFRs with brackets, the precombineds and previs for the 3x3 square of CELLs that CELL is in will be broken. For some areas, it is not a big deal, but for others having those precombineds and previs broken will have a significant impact. Doesn't matter if they show as yellow, red, or green in xEdit, it will break them. That said, you only need an updated previs timestamp for any CELL with the bracketed REFRs. Even though the CK will update the timestamp for all 9 cells when you regenerate the previs, the way that the game determines if it should break previs or precombineds is by comparing the timestamp in the VISI and PCMB subrecords in xEdit, to the Version Control Info 1 subrecord (in the record header) for all bracketed REFRs nested in that specific version of the CELL*. If any of those VCI1 subrecords have a timestamp more recent than the PCMB/VISI subrecords, or any are missing the timestamp (shows in xEdit as none**), previs and precombineds for that CELL will be disabled. Which means, if you update previs, you can then remove any CELL that has no child REFRs and for which the only change is to the VISI timestamp, leaving only the cell(s) that prompted the need for fixing previs. *so it doesn't matter if other mods that load earlier have bracketed REFRs, if the winning version of the CELL doesn't have any precombineds and previs won't be disabled. Which would actually caused problems in the form of undoing changes those mods made to those REFRs, but that is not relevant for a mod you ware working on for release **Copying records in xEdit will wipe out that subrecord, because preserving it can cause problems with the Version Control system, and that was the only thing the subrecord was used for prior to FO4. Resaving the plugin in the CK will set the current date for any records missing a date. If you are curious, the way xEdit determines which REFRs to put in brackets, it looks at the XCRI subrecord. REFRs in that subrecord are not actually loaded in-game when precombineds are enabled, it only loads the precombined meshes (also listed in the XCRI subrecord).

For future reference for anyone who comes across this thread, NEVER USE THAT SCRIPT. There are differences in the data structure for some record types between form 43 and form 44. That is why you should use the Creation Kit to convert plugins to form 44 for Skyrim SE. If you are lucky, the record you are converting will have not been changed, or the parts that were changed were not being used in the records in the plugin you are converting. By far, it is more likely to result in broken records. Usually broken in a way that won't necessarily show up quickly.

One thing that may be useful, depending on what sort of things you want to SCOLize: if, when making the SCOLs, you choose the option to make a "load screen SCOL", it will let you pack some non-STAT objects into a SCOL. It basically converts them into static versions of themselves. So Flora selected this way will no longer be pickable, as an example. There are still limits (trying to include an NPC just made the entire thing invisible), but otherwise they work fine when placed in the world. The other thing to remember is that SCOLs lose all the properties/keywords that were on the associated Statics. So, as an example, most objects won't be able to be built on the SCOL (basically, only the things that have "treat everything as ground", since any "treat this as ground" keywords will be gone. Precombineds have certain things handled as part of it, among other things they seem to all get that "treat as ground" treatment. So if you do want people to be able to build on the ship, they will either need to use Place Everywhere (which is a wonderful mod), or you will need to turn the ship into precombined meshes.