More precombine questions - part2

[dizietemblesssma]

Hi,

I'm trying to edit Echo Lake Lumber,

I've checked my start save to see if 'TPC' in the console reports that 'preculling is enabled' which it does.

Then I load my mod and TPC says 'preculling is enabled but disabled for this location' which I've read means that precombines are broken.

But then I can't explain the following:

with no attempt to generate new geometry and visibility, items that I have deleted in my mod are still present and cannot be scrapped - which would make sense (to me at any rate) if precombines weren't broken.

if I do the generation - geometry of edited cells, visibility of loaded areas, previsibility of loaded areas; then now I do not see the deleted items. But of course I wouldn't expect to if the regeneration had gone properly, yet 'TPC' still reports 'preculling is enabled but disabled for this location'.

 

If I disable my mod, set busecombinedobjects=0 and then restart the game in my clean save; I can now scrap all sorts of things I couldn't before with visual glitches that just don't turn up using my mod and busecombinedobjects=1.

Also, 'TPC' in the console reports that 'preculling is enabled' which is not what I would have expected.

So, is my mod disabling precombines or not, and if it is why is there such a it difference when not using it but setting busecombinedobjects=0?

Does 'preculling is enabled but disabled for this location' not mean what I've read it means?

 

diziet

[VIitS]

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.

[dizietemblesssma]

Thanks for replying, I'll be going through the eps in xedit in a bit, but your comment about other mods touching the area worries me. Can you see any of these mods doing that?

 

 

# Automatically generated by Vortex
*Unofficial Fallout 4 Patch.esp
*WorkshopFramework.esm
*SS2.esm
*CanarySaveFileMonitor.esl
*HUDFramework.esm
*IDEKsLogisticsStation2.esl
*dz_echo_edit.esp
*CreationClubDelay.esp
*EBMD_AllInOne.esp
*FO4Hotkeys.esp
*HoloTime.esp
*SS2_FDK_TinyLiving.esp
*SS2WastelandVenturers.esp
*ohSIM_Sim2_Settlements_Scrappers_Addon.esp
*JunkTownTwo.esp
*SS2-PraRandomAddon.esp
*SS2-PraRandomAddon-VIS.esp
*CarryWeight99999.esp
*SCDC_Optional_-_Mute_Player_Character_Voice.esp
*Raze My Settlement.esp
*SS2WalledGardensAndMore.esp
*SS2WhisperPowerPlots.esp
*SS2Extended.esp
*SettlementMenuManager.esp
*SS2_ruined_simsettlement_addonpack.esp
*Quieter Settlements - Contraptions.esp
*SimHomestead2.esp
*SS2AOP_VaultTecTools.esp
*SS2WastelandReconstructionKit.esp
*WorkshopPlus.esp
*IDEKsLogisticsStation2_SS2_Patch.esp
*SCDC_v0.5.esp
*Quieter Settlements - Vanilla.esp
*Quieter Settlements - Wasteland Workshop.esp

 

 

 

would the quieter settlements be a culprit? dz_echo_edit.esp is my mod. Without my mod loaded from my clean save the TPC console command does report 'pre culling is enabled' - thankyou for the explanation too:)

 

diziet

[dizietemblesssma]

I worked out what it is I think, it's UFO4P:)

It never occurred to me to load that in the CK! Numpty I am.

With that loaded and saving the esp i now get my edits plus 'tpc' in the conosle saying 'pre culling is enabled'.

Only issue now is that some of my edits are still only "scrappable" if that's the right word, using disable in the console, whereas most of them them show up highlighted using Place Everywhere's 'extra object selection'. If I could work out how to get all my edits to show up with Place Everywhere that would be a lot more convenient. I'm not interested in making them constructible objects with scrap value or anything, just wonderng why they don't get highlighted.

Thanks for making me look at my load order. I've used UFO4P for so long I forget I use it:)

 

diziet

[VIitS]

 

Only issue now is that some of my edits are still only "scrappable" if that's the right word, using disable in the console, whereas most of them them show up highlighted using Place Everywhere's 'extra object selection'. If I could work out how to get all my edits to show up with Place Everywhere that would be a lot more convenient. I'm not interested in making them constructible objects with scrap value or anything, just wonderng why they don't get highlighted.

 

diziet

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.

[dizietemblesssma]

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.

 

Ah, thankyou. I suspect 2. since most of these items seem to be leaves on the ground!

since my intent was to linkref? bundles of leaves together using the workshoparentstackedkeyword (or somesuch) would that still work if the object linked to was scrappable i.e. scrap that object in the workshop and the other objects also go?

 

an aside: for workflow purposes, every time I regenerate in the CK do all the references in the esp get deleted then remade, or should I clean the esp manually using xedit first, then regenerate? Am I potentially leaving rogue entries in the esp by just regenerating a lot?

 

diziet

[VIitS]

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.

[dizietemblesssma]

Thankyou again! Deleting nif files is a lot easier than using xedit to clean up the esp:) I got the keyword name wrong but thanks, good to know my new plan has some potential.

 

From what I have read, it is important to do the vis and previs generation from the same cell. But if I have edited more than one cell, then does it matter which cell I choose? The geometry is done individually from each cell - at least that's what I have been following - so I can't see how any one cell is 'more important' than the other, and does it matter if (for the future) edited cells are not contiguous?

 

If I can get this all down, I can see making a few more little such mods for myself (hence my other recent thread post) and this info is very helpful.:)

 

diziet

[VIitS]

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

[dizietemblesssma]

I managed to get my leaf piles to link and scrap, after I made the pile that is linked to (from?) in the collection a scrappable object, this meant I didn't have to mess with nifs and collision - way above my pay grade! Which with DieFem's help on the batch action thingy means I think I can get what I want. Thankyou all!

 

diziet