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.

Of note, all that matters is the flag, not the file extension. So you can just use xEdit to add the ESM flag, that way you don't have to worry about fixing file names in the masterlist.

I am guessing that the plugin you used to generate precombineds is a .esp plugin. If so, you need to add the ESM flag to that plugin using xEdit before generating, otherwise the CK will rip it out of the masterlist, causing the issue you are seeing. The problem is caused by the CK not liking non-ESM masters. You'll want to leave that flag until you also generate previs, but can remove it once you are done (and since you are just adding a flag and not changing the extension, no need to worry about the masterlist pointing to the wrong file name). The fact that the built in version info script worked for you is another bit of support for that being the problem, since the copy shipped with xEdit only works when the two plugins have the same masterlist. Thankfully, that requirement is artificial (put in there by zilav at the request of the person who asked for the script, per my discussion with him), so you can remove that requirement and it will work fine. Here is a tweaked version of the script without the "same masterlist" requirement: Basically, you just remove these two sections: //================================================================================== // list of masters of a plugin function MastersList(aFile: IInterface): string; var masters: IInterface; i: integer; begin masters := ElementByName(ElementByIndex(aFile, 0), 'Master Files'); for i := 0 to Pred(ElementCount(masters)) do Result := Result + GetElementEditValues(ElementByIndex(masters, i), 'MAST') + #13#10; end; and if not SameText(MastersList(GetFile(e)), MastersList(fromPlugin)) then begin AddMessage('Masters do not match between plugins!'); fromPlugin := nil; end;

Correct, geometry (precombineds) are done individually per cell. For the previs, I think the CK should automatically center it on the correct CELLs. I guess just check things in xEdit, and if the RVIS changes, redo the previs. As far as doing both Visibility and Precombined Visibility, I've heard differing things, some say do both, some say only do precombined visibility*. I have had some decent success with doing just precombined visibility, but generating visibility first won't hurt anything if you are worried about it being needed. *Not meaning that doing visibility first is bad and will break things, but that it is pointless

Regenerating previs/precombineds without clearing out the data first shouldn't cause problems. The only place in the plugin that information is stored when you regenerate them is in the CELL (VISI, RVIS, PCMB, XPRI, and XCRI, and the first 3 are just timestamps and a reference to the center cell for Previs). XCRI lists the records that were baked into precombined meshes, and XPRI is somehow related to previs (not sure what the relevance is, just know that it is not touched by building precombineds, only previs). Those subrecords are fully overwritten each time you regenerate the corresponding thing (precombineds and/or previs). The only thing you would need to worry about in terms of cleaning is the actual precombined .nif files that are created. If there are any for which the file name would be different, you might have leftover, unused nif files taking up space. For previs, it should always be using the same center CELL, so the .uvd file should always have the same name unless RVIS changes. If RVIS changes, you did something wrong, and you want to regenerate it again centered on the listed RVIS cell, because changing the RVIS will throw the 3x3 block off in relation to the rest of the grid, and is pretty much guaranteed to cause occlusion bugs (things flickering/vanishing in the distance). And yes, linking that way will work to scrap the leaves when the linked object is scrapped. However, the object you are linking to (i.e. the one you people will scrap in order to scrap the leaves) MUST be flagged as persistent (the CK will do so automatically when setting up the link). I was experimenting with linking LIGH records to the "light source", and removing the persistent flag made it stop working. The object you are linking needs the WorkshopStackedItemParentKEYWORD [KYWD:001C5EDD] keyword under "Linked References" with the target object as the ref, and the one you are linking to (in addition to the persistent flag) needs the WorkshopItemKeyword [KYWD:00054BA6] keyword in "Linked References", with the Workbench REFR for that area as the linked REF.

If you can get rid of it with disable, there are only two reasons I can think of for not being able to scrap them: 1) The base object is flagged with the "Unscrappable" keyword. 2) They are missing collision, in which case you have to look at a small area around the point that the "base" (0,0,0 point) of the nif is. For 2, there are a couple vanilla items like that, that don't have any collision once you break the precombined mesh. Here is a list of some of them (the ones I have already fixed for Scrap Everything): Architecture\Buildings\Residential\Res01ModernDormer01RR Architecture\Buildings\HouseKit\HouseKGrndAddonDeckKRoofEndL01 Architecture\Buildings\HouseKit\HouseKGrndAddonDeckKRoofEndR01 SetDressing\IndMachines\ValvePlain01.nif SetDressing\MachineKit\MachineParts\MacConBreakerBox03.nif Interiors\Vault\Vault111\SetDressing\V111SafetyPosterSmall01.nif I think the lettering on Starlight Drive-in is also the same way, but haven't fixed it yet. And if any of those are relevant for your mod, feel free to include the fixed meshes from Scrap Everything in your release.

To fix the issue: If you look at the CELL listed in the RVIS subrecord of the CELL you are in when you see that "preculling is enabled but disabled for this location" message, check placed objects (REFRs) for that cell, and the 8 cells that reference it. At least one of those cells has placed objects that are either missing a value (displayed as "None" in xEdit) in the Version Control Info 1 subrecord in the record header, or they have a newer date than you see in the corresponding VISI/PCMB subrecords of the containing cell. To fix this, any that have "None" need to get a date added (this is done by loading the relevant plugin in the CK, loading that cell, and saving the plugin*), and for any cells with REFRs that have newer dates, you can right click -> Update timestamps in the CK (if you don't need to rebuild precombineds for that area). Since you rebuilt previs and precombineds for your mod, you probably have another mod touching one of the relevant cells the your mod doesn't touch, as updating things in the CK should update all the relevant timestamps as needed. *If that relevant plugin breaking things has non-ESM masters, add the flag in xEdit before loading the plugin in the CK. Explanation for why this is the case: Precombineds and previs (preculling) are two different things. Precombineds are the combined meshes, and are handled on a per-cell basis. Those are clearly enabled in the cell you are testing, since you were seeing things that your mod removed. From the sounds of things, you rebuilt precombineds properly (when you got the things to no longer show). Previs (preculling) is the occlusion system, where distant objects that would be hidden from view by objects are not rendered (in order to save processing power). Previs is generated on a 3x3 cell grid (i.e. each previs file is used for an entire block, 3 cells by 3 cells). What you are seeing is a result of the system that Bethesda implemented that will automatically disable precombineds and previs for a cell if any changes are made to any of the placed objects that are part of a precombined mesh (in xEdit they show as [Place Object] with the brackets, and referenced in the XCRI subrecord of the CELL in question). Since previs is handled in 3x3 grids, any one of those cells triggering that system will disable previs in the entire 3x3 area. For some reason, they decided to make it so the ini edits (bUseCombinedObjects=0 and bUsePreCulledObjects=0) disable this system. So you disabling precombineds using bUseCombinedObjects=0 to globally disable precombineds disabled that system, which re-enabled previs. If the date listed in Version Control Info 1 (viewable in xEdit, dates were decoded in the 4.0 update) of any precombined REFRs (placed objects) is either newer than the VISI/PCMB (timestamp) subrecords of the containing cell, or that field shows "None" (which happens when you copy using xEdit), then that will trigger the system. Loading a plugin in the CK and saving it should add todays date in that field for any that are missing a date, and updating timestamps/rebuilding precombineds and previs for the relevant cell should update the VISI/PCMB subrecords.

As RoNin said, the biggest concern is the effect the void has when visible, and enabling the skybox as described will eliminate that issue. Also, of note, the build volume for the Mechanist's Lair is actually made up of about a dozen build volume primitives. You can either expand the existing ones, or make new ones and attach them to the workbench.

From my (limited) understanding, the lizards thing was not the biggest complaint people had. And even if it was, there is a difference between having it be something you can have your character do, and crass humor of people making fun of someone else. And since it is a reference to a specific character from Skyrim, anyone complaining about it should be ignored. Honestly, if anyone freaks out about the dialogue you quoted, the proper response is to roll your eyes and ignore them, they are not going to manage to get significant outrage stirred up over something like that.

Yes. You can also use the base "Compare selected" feature (which has to be used in order to use copy to selected) to look at multiple records side by side, and the default behavior is to auto-compare up to 4 selected records. It won't let you compare two records of different types though, and if they are in different groups (such as REFRs in two different Cells), auto-compare won't work and you have to right click -> Compare selected. And I wasn't recommending reading the whole thing, just skimming the table of contents and looking at the details for any features that sound useful or interesting. I have found a couple nice features that really compliment the way I use xEdit that way, which is why I recommend it, so you can find ones that would be most useful for you.

Primarily the new features are all documented in the What's New. You can look at it in xEdit, tab at the bottom with "Information", "Messages", and "Referenced by", and it is also listed on the Tome of xEdit (accessible through the Help button in the top left in xEdit). The What's New is section 18, here is the link to the section about the Delta Patch feature: https://tes5edit.github.io/docs/18-whatsnew.html#Createdeltapatchusing. If you don't already know about it, one of my favorite features is "Copy to Selected records" (and its counterpart "Remove from selected records"), that can save a ton of time if you are doing something like adding (or removing) a specific keyword to a bunch of records. edit: There is a lot of information in there, especially for the 4.0 release, but I highly recommend at least skimming through it if you are a frequent xEdit user.