Jump to content

Static Collections and Material Swap strangeness


VilanceD

Recommended Posts

 

 

2nd try posting this....

 

Hi, I am getting a strange result when I use CK to create a static collection(SC) using either HouseK or DecoMain building parts. The material swaps(MS) change drastically. For the HouseK parts they immediately almost all become primary color red, secondary color green. If I cycle thru the MS or select edit base, edit nif, custom material swap, a few original colors remain but most are not the normal options or just red/green.

 

As a programmer/DBA type this looks like some kind of list/array with offset/index error.

 

Any way to fix this, or work around, other than don't use SCs?

 

Thanks in advance,

 

V.

I've re-created a SCOL test setting with the different kits you used and it appears that the mat swaps for the HouseKit stop functioning correctly when being part of a SCOL. This might stem from the fact that especially the matswaps for the outer parts (wood panels) were probably done by color pallet scaling instead of the traditional way of switching to an entirely new texture set. I haven't, or only rarely, seen such behavior in the CK. Color pallet objects usually seem to work fine while being part of a SCOL, although they seem to revert back to some kind of standard coloring which you can usually not achieve with any existing matswap (e.g. the HiTec swaps). For instance I do get some kind of super bright beige tone for the HouseKit while its parts are part of a SCOL. This seems to either be some kind of standard color or one that is specific to my CK/PC? Who knows? Bethesda's tools are janky at best.

 

In any case, it seems that the matswaps work fine again after breaking up the SCOL. So I would suggest the following workflow:

1. Create your buildings.

2. Create your SCOL's

3. Place your buildings where you want them to be and make sure that their position won't change much

4. Swap to your desired matswap

5. Break up the SCOL to get rid of the weird colors

 

P.S: I also suspect that it's some kind of color pallet indexing error or a default value.

 

I agree to variations of HouseK parts to have been done with simple color manipulation instead of of a different texture all together.. But even so they still have those edited texture maps as part of a material/swap file and that is what the game looks at when loading and not how the color/texture variation was made... I also suspect that HouseK parts where originally scols converted to Statics or something similar...Hence why nifskope has issues with them when they are sanitized . I had to dump 100s of hours of work where i used HouseK parts to build a whole buildings that i retextured in nifskope because upon saving Nifskope corrupted the names leading to either crashes in CK when mesh was used or Issues when generating previs (walls of texture across the map etc. ).

Meaning that HouseK parts Do have an issue that shows up when edited.

Due to my "new found" knowledge of the workings of textures and texture swaps etc. that ive been using for the past 3 months A LOT (Importing textures from various sources,Editing texture maps,creating new material files ,editing nifs to use the new files and materials etc.. ) ive edited and manipulated almost every static in the game but never had an issue until i used the HouseK parts.

MY biggest issue was ...Even though they looked fine after my texture editing and placement in the CK ,as soon as i tried to generate previs all hell broke loose.. Or without precombined data and previs in game they would revert to default colors etc..

So final thoughts on these particular pieces is that the DEV that made them used a different method at some stage that is incompatible .

The only way i got them to work was to always make sure Auto Sanitize is off when saving in nifskope and texture variations are done piece by piece and not in a scol and then and only then used as part of a scol...

Here is an example of a working scol using houseK parts using my method that works without issues..(and to be honest allows for a much more detailed job with great results)..

HRX16G.jpg

39lxGa.jpg

 

 

It's definitely impressive that you managed to do all of this through trial and error, but I personally wouldn't try to push the boundaries of this mess of an engine that much. Especially since we don't have any proper documentation on the inner workings of certain systems. I too would love to do much more with the SCOL system but it just seems to cause too many problems in the long run.

 

Link to comment
Share on other sites

Well yeah. Editor defned matswaps don't play nice with SCOLs. They don't play nice with precomb generation either.

Best bet is to export the SCOL to a NIF and edit that in nifskope. But it's tedious ofc.

Yes it is TEDIOUS A.F. !!! :P

I repeated that process 1600 times....in 2 months

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...