Remove Precombined Objects + Regenerate PreVis?

[YouDoNotKnowMyName]

I have "only" 16 GBs of RAM.

How does one "assign" virtual memory to the CK, like you mentioned?

I am guessing that is just "normal" hard drive memory that will get used like RAM, but slower, right?

[MissingMeshTV]

 

 

Precombining geometry disregards matswaps. No matter if the matswap is on the reference or the base object, if there is one, it won't make it into the precombines.

The only way to make it works seems to actually create new NIFs which use the correct material, and replace the base object in the references. After that, this can be undone.

 

That's certainly true for custom material swaps applied via the Model Data window of base object, but not for swaps applied to a reference via the Material Swap pull down of the Extras tab. Swaps applied to a ref via the Extras tab remain intact after precombines are generated. If you need to generate things that have a custom swap applied to the base object, you can set those items to Initially Disabled prior to generating. Anything set to Initially Disabled is ignored. Then remove the Initially Disabled flag after generating. Using a new layer for the items to be temporarily disabled and the Batch Action window are great time savers when doing this.

[pra]

Interesting. I wonder what these bytes actually are, and whenever they unlock more "internal" features which were never meant for us lowly modders.

 

My script generates new base records and new nifs for them, where the matswap is integrated, and then updates the REFRs. It is mostly capable of replacing them back, but I'm not quite content with this part. And in general, it is quite hacky.

 

MAYBE, if precomb generation via CLI works, a script to generate them could be made. It would simply call the ck. However, that would probably be pointless.

 

edit:

 

 

That's certainly true for custom material swaps applied via the Model Data window of base object, but not for swaps applied to a reference via the Material Swap pull down of the Extras tab. Swaps applied to a ref via the Extras tab remain intact after precombines are generated. If you need to generate things that have a custom swap applied to the base object, you can set those items to Initially Disabled prior to generating. Anything set to Initially Disabled is ignored. Then remove the Initially Disabled flag after generating. Using a new layer for the items to be temporarily disabled and the Batch Action window are great time savers when doing this.

really? that could simplify the aforementioned script a lot. Just grab the matswap of the base and put it on the refr. No need to even undo it afterwards. Hm I have a deja vu. I think someone asked me for a script like this...

 

Excluding them from precombining would be a bit pointless imo. Also, you don't need to set them to initially disabled, there are several other ways. See my previous post.

[VIitS]

Interesting. I wonder what these bytes actually are, and whenever they unlock more "internal" features which were never meant for us lowly modders.

 

According to the post the person who helped me got that info from, that value basically just sets commandline precombineds to use 32-bit Havok. 00 sets it to use 64 bit havok (what is required for FO4 on PC), 02 sets it to generate precombineds that would work for the PS4 (if Sony hadn't locked it down to not except external assets...).

 

MAYBE, if precomb generation via CLI works, a script to generate them could be made. It would simply call the ck. However, that would probably be pointless.

 

Using the fixed byte values I listed, I was able to successfully generate precombineds (and previs, but the fix is only required for precombineds) for The Mechanist's Lair. Based on my testing, I think the issue I was having before was the CK didn't like something about my plugin. And on that note, another thing I forgot to mention is that the plugin name can't have spaces.

[flecked]

 

Precombining geometry disregards matswaps. No matter if the matswap is on the reference or the base object, if there is one, it won't make it into the precombines.

The only way to make it works seems to actually create new NIFs which use the correct material, and replace the base object in the references. After that, this can be undone.

That's certainly true for custom material swaps applied via the Model Data window of base object, but not for swaps applied to a reference via the Material Swap pull down of the Extras tab. Swaps applied to a ref via the Extras tab remain intact after precombines are generated. If you need to generate things that have a custom swap applied to the base object, you can set those items to Initially Disabled prior to generating. Anything set to Initially Disabled is ignored. Then remove the Initially Disabled flag after generating. Using a new layer for the items to be temporarily disabled and the Batch Action window are great time savers when doing this.

I didn't think it was possible to use material swaps on refs that are in precombine meshes. When doing it in Xedit, the precombines get broken. Edited December 31, 2019 by flecked

[MissingMeshTV]

 

 

Precombining geometry disregards matswaps. No matter if the matswap is on the reference or the base object, if there is one, it won't make it into the precombines.

The only way to make it works seems to actually create new NIFs which use the correct material, and replace the base object in the references. After that, this can be undone.

That's certainly true for custom material swaps applied via the Model Data window of base object, but not for swaps applied to a reference via the Material Swap pull down of the Extras tab. Swaps applied to a ref via the Extras tab remain intact after precombines are generated. If you need to generate things that have a custom swap applied to the base object, you can set those items to Initially Disabled prior to generating. Anything set to Initially Disabled is ignored. Then remove the Initially Disabled flag after generating. Using a new layer for the items to be temporarily disabled and the Batch Action window are great time savers when doing this.

I didn't think it was possible to use material swaps on refs that are in precombine meshes. When doing it in Xedit, the precombines get broken.

 

As I said...set a swap on a reference under the Extras tab of the ref, generate your precombines/previs, and the swap will be intact when you go in-game. The vanilla game is loaded with static refs that are part of a precombine with material swaps applied to them in this way that display just fine.

 

If you're changing them in xEdit after the fact, then yeah...you might break them. I've never had reason to do that, so I have no idea what happens. Doing what I need to do with precombines "just works" in the CK, and I've never had the need to edit them with external tools after generating. Then again, I do very little editing to vanilla cells and mostly work on newly created cells.

[pra]

changing refs in the same mod works, without breaking precombs. I have successfully done it before.

 

And, obviosly, my plan is to put the matswaps onto the refs (the same as what the CK would do using that "extra tab") BEFORE generating the precombs.

 

I somewhat wonder about previs generation via CLI. Doing it from the ck, I had that problem of invisible objects, unless I generate "regular" visibility first and then precombined visibility.

Either that CLI argument does both, or we are missing a step...

 

I guess I have to try this on my fairline hills when I get home...

[pra]

Found the apply matswap script. Posted it here:
https://forums.nexusmods.com/index.php?/topic/6992141-custom-material-swapping-problem/

This was requested by warhammerempire, he also pointed out that I should have restricted it to SCOLs and STATs.

[VIitS]

flecked,

Copying a record into another mod using xEdit will wipe out the Version Control Info 1 (basically date modified for the record), which will cause the game to disable precombineds and previs for that cell. This is expected behavior (it will also do the same if the VC Info 1 date is later than the PCMB/VISI timestamps in the corresponding cell). If you load the Cell in the CK afterwards, it will assign the records VC Info 1 with a date matching the day you loaded it in the CK.

 

 

pra,

If you have already generated precombineds, you shouldn't need to generate regular previs first, generating precombined vis should completely overwrite the previous .uvd file that is generated, and I don't think it takes into account existing .uvd files when generating new previs. That said, I haven't tested that much myself. I would definitely be interested in what you find.

 

Also, I didn't explicitly make it clear before, but after you generate precombineds, you want to merge the changes from the generated "Combined Objects.esp" plugin into your main plugin before continuing, and you would do the same for the Previs.esp generated when making previs. And you definitely want to run all four CLI arguments, not just the precombineds and previs ones. the CDX and PSG are used for shared-geometry precombineds (same as base game and DLC use), which is what you get when you use the CLI argument rather than going through the CK normally.

 

Also, while I haven't finished testing extensively, you probably don't want to use the "Clean Precombineds" option of my Precombined xEdit script, it is likely to break things* (and the main point of that was to minimize the size of an upload for a mod, which is much less of a problem for shared-geometry precombineds due to their significantly smaller size.

 

*My testing resulted in previs hiding just about everything, but copying the removed precombined .nif files back in place didn't fix it, so I have to figure out what is causing it to not use the previs data properly. It was working perfectly fine before I ran my script, so I don't know why copying the missing .nifs back in place and loading an earlier save didn't fix it.

[yarrmateys]

the filename of the mod seems to be baked into something if you generate the clean version of precombines. either the geometry file or the precombines themselves. the moment you rename it everything will go insane. if you go this route, make sure the filename is final, you won't be able to change it afterwards.

 

also if you're trying to use this to regenerate the entire wasteland and include every dlc, you'll have to copy every single cell and have at least one override entry within it (ideally a background object rather than something that can be picked up) to force creation kit to treat it as changed and regenerate it, even if it's an itm. only really useful for things like an optimization pass or total overhaul mods like dustbowl overhaul, scorched earth, regrowth overhaul and the likes that change the flora of the entire world.

 

you don't need any scripts to fix the combinedobjects.esp and previs.esp plugins it generates afterwards. just open the file in creation kit, save it, then open it in xedit and deep copy as overrride (with overwriting) into the original mod.

Edited January 6, 2020 by yarrmateys