Settlement Borders.

[speedynl]

mm its a long time ago that i used the ck, but i think it was 2 to get the adjust arrows( 2 up/down, 4 all directions), t was top view i think

Edited January 13, 2019 by speedynl

[HeyYou]

mm its a long time ago that i used the ck, but i think it was 2 to get the adjust arrows( 2 up/down, 4 all directions), t was top view i think

2 works, but, it scales the object in ALL dimensions, not just the one I an interested in. Not sure if it is supposed to work that way.

[HeyYou]

Well, tried a different approach, and simply enlarged the current build area box (hitting '2' actually gave me the arrows I expected.....). CS didn't seem to think any changes were made.... (no asterisk by the mod name in the title bar.) Is there something special I need to do to convince the cs to save the 'new' size? (the original size box was still there)

 

Also, I simply moved one of the border tiles on the Y axis. Saved the mod, opened it in xEdit, and the border tile shows as "unable to resolve". (placed object, shows as REFR, and not Static, as I would expect.) I am obviously missing a trick here, but, the CS wiki is no help at all.

 

I am open to any suggestions/pointers/whathaveyou. I would REALLY like to know just WHY this isn't working the way I think it should.

 

Edit: Do I need to make build high an esm file in order to use it as a master for my changes??

Edited January 13, 2019 by HeyYou

[VIitS]

Not sure why it would refuse to believe that something changed. You could just tell it to update the precombined/previs timestamps for the cell(s) you are working in, since you are going to delete them anyway so them being different won't matter.

 

Yes, unresolved errors are a result of your file having a .esp (Build High) as a master. The CK just rips out any non ESM master, because reasons. I think you could get away with just the flag at some point, but I have heard something about it needing to have the .esm file extension for the current version of the CK.

 

Make sure the height is more than needed, some things are "technically" below the vanilla build volumes. It is one of the first thigns Build High did, before it expanded horizontally (hence the name :D). Also, depending on the type of debris decal, it might not be scrappable. I think Texture Sets are one of the ones that can't be directly scrapped.

 

Yes, broken precombineds from Scrap Everything combined with Extra Object Selection from Place Everywhere means you should be able to scrap anything at all, as long as precombineds are broken in the expanded area as well. If you can disable it with the console it isn't a problem with precombineds. Also, I have noticed some things that are below/above the build volume are unscrappable even with extra object selection enabled. using modpos to move them suddenly makes it scrappable, even though extra object selection should have done that already.

 

Precombined/previs tips:

A tip that might help for only breaking the precombineds needed: generate precombineds for the loaded cells when you have your full area loaded, then use xEdit to delete the VISI, RVIS, PCMB, XPRI, and XCRI sub-record for the cells with PCMB data (PCMB is the precombined timestamp). You can use this script to remove that data for you.

 

I recommend direct CELL edits over just referencing a precombined REFR (the way that Spring Cleaning did, though the exact mechanics weren't perfectly understood then, hence the hundreds of ITM records per cell it has). If you (or a mod user) use one of the ini edits to disable either precombineds or previs globally (NOT recommended for a variety of reasons), the auto-disable by ITM REFRs gets disabled, so the bUseCombinedObjects=0 ini edit would make you have occlusion bugs because previs got turned back on in those cells. And making ITMs in the CK might not even work, since that auto-disable system compares the Version Control Info 1 sub-record of the precombined REFRs to the PCMB/VISI sub-record in the CELL (before the Version Control Info 1 sub-record was deciphered, the first two hex pairs matched what is in the VISI/PCMB sub-records).

 

Shouldn't be needed if you are just breaking them, but if you are interested in precombineds/previs, you can check out this thread, which is a collection of what a lot of people have learned about precombineds. Such as, generating precombineds in the CK if you have made ANY changes to REFR records since launching the CK can make precombineds not work properly (such as missing collision data). So if you are making a mod that you want to generate precombineds for, make sure to save and relaunch the CK after making any worldspace changes that require precombineds to be rebuilt. And the "non-occluder" flag on base records is very useful if you don't want something to be used in previs calculations (such as if there is a tiny gap between it and something else, and you have occlusion bugs when looking through the gap).

 

 

 

The scale gizmo is supposed to let you scale in a single direction, but I am not sure if it works on things that aren't primitives. You might have to edit the mesh directly for the borders. If you are using straight border indicators (like those used in the Mechanist's Lair) rather than the custom ones that follow the landscape and contours of the vanilla volume, you can use Nifskope and directly edit the Vertex Data to change the z coordinates to make it taller. You can also just use Blender or 3DS Max to edit the nif.

 

By the way, the if you switch to one of the render modes that shows textures (GBuffer_) when you have a gizmo open, or try to bring up a gizmo with those selected, it breaks the gizmo until you restart the CK. Took a while to figure that bit out.

[HeyYou]

Not sure why it would refuse to believe that something changed. You could just tell it to update the precombined/previs timestamps for the cell(s) you are working in, since you are going to delete them anyway so them being different won't matter.

 

Yes, unresolved errors are a result of your file having a .esp (Build High) as a master. The CK just rips out any non ESM master, because reasons. I think you could get away with just the flag at some point, but I have heard something about it needing to have the .esm file extension for the current version of the CK.

 

Make sure the height is more than needed, some things are "technically" below the vanilla build volumes. It is one of the first thigns Build High did, before it expanded horizontally (hence the name :D). Also, depending on the type of debris decal, it might not be scrappable. I think Texture Sets are one of the ones that can't be directly scrapped.

 

Yes, broken precombineds from Scrap Everything combined with Extra Object Selection from Place Everywhere means you should be able to scrap anything at all, as long as precombineds are broken in the expanded area as well. If you can disable it with the console it isn't a problem with precombineds. Also, I have noticed some things that are below/above the build volume are unscrappable even with extra object selection enabled. using modpos to move them suddenly makes it scrappable, even though extra object selection should have done that already.

 

Precombined/previs tips:

 

 

A tip that might help for only breaking the precombineds needed: generate precombineds for the loaded cells when you have your full area loaded, then use xEdit to delete the VISI, RVIS, PCMB, XPRI, and XCRI sub-record for the cells with PCMB data (PCMB is the precombined timestamp). YOu can use this script to remove that data for you.

 

I recommend direct CELL edits over just referencing a precombined REFR (the way that Spring Cleaning did, though the exact mechanics weren't perfectly understood then, hence the hundreds of ITM records per cell it has). If you (or a mod user) use one of the ini edits to disable either precombineds or previs globally (NOT recommended for a variety of reasons), the auto-disable by ITM REFRs gets disabled, so the bUseCombinedObjects=0 ini edit would make you have occlusion bugs because previs got turned back on in those cells. And making ITMs in the CK might not even work, since that auto-disable system compares the Version Control Info 1 sub-record of the precombined REFRs to the PCMB/VISI sub-record in the CELL (before the Version Control Info 1 sub-record was deciphered, the first two hex pairs matched what is in the VISI/PCMB sub-records).

 

Shouldn't be needed if you are just breaking them, but if you are interested in precombineds/previs, you can check out this thread, which is a collection of what a lot of people have learned about precombineds. Such as, generating precombineds in the CK if you have made ANY changes to REFR records since launching the CK can make precombineds not work properly (such as missing collision data). So if you are making a mod that you want to generate precombineds for, make sure to save and relaunch the CK after making any worldspace changes that require precombineds to be rebuilt. And the "non-occluder" flag on base records is very useful if you don't want something to be used in previs calculations (such as if there is a tiny gap between it and something else, and you have occlusion bugs when looking through the gap).

 

 

 

The scale gizmo is supposed to let you scale in a single direction, but I am not sure if it works on things that aren't primitives. You might have to edit the mesh directly for the borders. If you are using straight border indicators (like those used in the Mechanist's Lair) rather than the custom ones that follow the landscape and contours of the vanilla volume, you can use Nifskope and directly edit the Vertex Data to change the z coordinates to make it taller. You can also just use Blender or 3DS Max to edit the nif and re-import it.

 

By the way, the if you switch to one of the render modes that shows textures (GBuffer_) when you have a gizmo open, or try to bring up a gizmo with those selected, it breaks the gizmo until you restart the CK. Took a while to figure that bit out.

Well now, There is an "Ah HA!" moment. Thank You. Guess I am going to have to esmify BH, and start over again. (not really that much of a chore, not like I am making radical changes.)

 

As for the debris decals, I can scrap them just fine within the 'stock' build area of BH, Wonder if this relates back to having an esp as a master.... Guess I will find out. :D

 

Thanks for the tip on previs/precombines as well. I am going to give it a shot, see what happens.

 

I am tempted to simply edit BH esp file directly, (I have a backup....) as this is only for personal use. :) If I screw it up too bad, I can simply restore my backup esp. Might be the easier route.

[VIitS]

By the way, I confirmed that it is the file extension, not the flags, that matters. Bethesda "fixed" it just looking for the ESM flag :mad:

 

If you can scrap the same thing in the normal build area, it is probably just out of the new build volume (vertically).

 

Yeah, probably for the best to just edit it directly. And if you wanted to make it a separate plugin, you could use xEdit's New (with 4.0) Delta patch feature. You can use it to compare two versions of a plugin, and it will make a .esu file (ignored by game, only useful in xEdit) that contains only the changes between the two versions. It is how the super in-depth Fallout 76 patch notes have been made. If you haven't already, get the newest xEdit, Elminster added so many awesome features (collapsible nodes in the View window is a godsend if you use xEdit with large records, like the Race records) between the old 3.2.2 and the 4.0 release.

[HeyYou]

Yeah, I am working on it now. :) Just editing directly, seemed like the easiest solution.

 

The build high "bounding box" is incredibly tall...... I suspect it was just because some items were in an 'odd' area between the two new build areas I added. I'll find out soon enough. :D

[HeyYou]

Ok, now THAT worked as expected. I was able to expand the build area, and move the border tiles to some approximation thereof. Went in-game, and though it whined about the previous esp file being gone, (I deleted it.) everything was where it should be, previously unscrappable stuff was now scrappable, and I can build where I want to.

 

Lesson Learned: Can't have an esp as a master, and expect it to work. :D

 

Still and all, some stuff was a tad annoying. Like trying to guess where the widget you just enabled is...... not to mention have the widget somewhere that you can use it, and still see what it is you are trying to do. (sometimes, if I moved my point of view to where I could see the widget, one edge of the object I am working with, and the ENTIRE object I am trying to line it up with, would unload from the render window. :D That was fun. It's close, but, not perfect. I may tweak it a bit more, then again, since its just for me...... I may not. :D

 

Thank You All for getting me thru this. Greatly appreciated.

[VIitS]

Glad you got everything working :smile:

 

And esp masters are fine, as long as you only look at it/edit it in xEdit. The game is perfectly fine with plugins that have .esp masters. The CK is just picky for no reason.

[HeyYou]

Glad you got everything working :smile:

 

And esp masters are fine, as long as you only look at it/edit it in xEdit. The game is perfectly fine with plugins that have .esp masters. The CK is just picky for no reason.

There is definitely some hoop jumping involved with the CS for esp masters..... I am just pleased it actually works now. Once again, Thank You. :D