Jump to content

NifSkope 2.0 Dev


Jon
 Share

Recommended Posts

  • 2 weeks later...

Thanks. By the way can you add support for BSSkyShader to suppress dozens of errors in NifScope when opening meshes\sky\clouds.nif from Skyrim. Just as unknown values would be more than enough and be able to see shape's wireframe when selecting.

 

Edit: Actually when there is no BSShader attached to shape, NifScope doesn't show it at all even when selecting it. If it can default to the basic gray solid color in this case to make them visible and selectable, that would be great.

Link to comment
Share on other sites

It seems that Pre-Alpha 4 has a broken UVW render window.  The UVW strips all appear in-place, but the texture does not render.  Both Arthmoor and I see this bug exhibited in our copies.  Is this a bug, or is something not configured properly on our end?

Link to comment
Share on other sites

For me, this problem does not occur.

Wn4W7Kgl.png

 

EDIT

 

@MadCat

@Arthmoor

Share this edited NIF.

 

EDIT2

- Both have GPU from AMD? (Just trying to find the cause of the problem)

- Are you using BSA or Loose Files for NifSkope to display textures?

- I once had a problem with properly loading of textures, delete all registry entries for NifSkope help me. ([HKEY_CURRENT_USER\Software\NifTools\NifSkope 2.0])

 

How to delete all registry entries for NifSkope 2.0

- Create a new file, for example (NifSkope.txt)

- Add this content

Windows Registry Editor Version 5.00

[-HKEY_CURRENT_USER\Software\NifTools\NifSkope 2.0]

- Change the extension of file to (NifSkope.reg)

- Start with administrator privileges.

Link to comment
Share on other sites

It seems that the problem occurs only when use Loose Files as texture resource for NifSkope.

Because when I erased all the BSA as a texture resource for NifSkope and used Loose Files have the same issue.

 

EDIT

So all custom meshes will not display correctly texture in UV Editor because they are not in BGS BSA.

kVEWIafl.png

 

Temporary solution for the original BGS Meshes is to use the BSA as texture resource for NifSkope.

Options -> Setings -> Resources -> Archives Tab

Z6RkXZGl.png

Remember to remove all directories to Loose Files in Options -> Setings -> Resources -> Paths Tab

Because only then texture will be correctly displayed in UV Editor. (for orginal BGS Meshes)

 

EDIT2

For custom meshes create BSA and add to NifSkope Options -> Setings -> Resources -> Archives Tab

aU4NUhGl.png

Link to comment
Share on other sites

Also all those exra columns (Array1, Array3, Condition, etc.) are gone in the latest version, and I couldn't find how to enable them back. I know that majority of NifScope users probably don't need them, but I find them useful.

Link to comment
Share on other sites

I'll look into the UV Editor issue.  I'm not having the issue either, but I use the archives and not loose files.

 

---

 

@zilav  Pretty sure I made a note of it in this thread or the release notes.  You go to Settings > General > NIF > Hide Metadata Columns.  (Uncheck it)

 

@Nico  That is due to XML changes, and those changes were determined to be more accurate to the underlying data.  Though, I should look into if any Spells look for the old names. 

Link to comment
Share on other sites

No more "4097", Nico.  It now actually labels what the flags are.

 

If you copy-pasted "4097" to quickly enable full tanspace array sets when prepping meshes for gametime, you can still do that.  Simply copy the text in the field after you switch it over (like the shader flag dropdown checkbox menu) and paste like you did with 4097.

 

 

I'll look into the UV Editor issue.  I'm not having the issue either, but I use the archives and not loose files.

 

That's fine for consulting vanilla assets, but some asset replacers have them loose. Modders may also want to use NIFSkope's UVW tools on their in-production assets while working on them and having to BSA-pack it after every texture file alteration is just extra hassle and is counteractive to streamlining the workflow.

Link to comment
Share on other sites

No more "4097", Nico.  It now actually labels what the flags are.

Wait, what??? Why???????????????????

The numbers were so easy to remember - 4097 or 1. Why change it? And the answer better not be "Because FO4"... :peer:

Link to comment
Share on other sites

The change in question was actually done over a year and a half ago, I just wasn't using the latest nif.xml for my releases:   https://github.com/niftools/nifxml/commit/3dd61a8b2c544de250f1d8693ba63158a0d873f9

 

Anyone is free to reverse those particular changes in their local nif.xml :)

 

To answer you more directly Hana, it's because "4097" is complete nonsense, as far as any actual meaning for the value is concerned.  Yes, that is the underlying integer value... if that were actually a ushort (16-bit),  but it's actually two bytes, the first byte being the number of UV sets.  The second value you just need to now make sure it is not "None", which corresponds to the only known value:  16.   So it's now just making sure Num UV Sets is 1+ and that the next field is simply "not None", which is actually far more intuitive and easier to remember than "4097" which seems like a completely arbitrary value.  Not to mention having it as a ushort allows you to set it to tons of values that don't have any meaning.  Splitting it into two bytes lets you intuitively set the Num UV Sets without having to guess what the resulting ushort would have to be and prevents invalid entries for the second byte... unless you manually enter a number value that doesn't exist in the enum.

 

So, tl;dr you just have to type "1" and "16" across two fields now.  Typing in 16 is probably faster than selecting the Tangents/Bitangents enum option. 

 

Edit:  Though, the naming leaves something to be desired (Extra Vectors Flags and "Tangents_Bitangents").  I didn't have anything to do with that commit, but I may push some naming changes for it before it becomes too widely adopted. 

Link to comment
Share on other sites

  • 2 weeks later...

Collisions are an embedded Havok file, the same as ragdoll and cloth physics.  To read/write them we technically need access to the 64-bit Havok SDK, which is not publicly available.  However, Figment had been working on it before his hiatus.  He dumped the contents of the collision/ragdoll/cloth to tagfiles (XML) via means which we can't legally integrate as part of any kind of release for any third-party programs.   But even privately there is still nothing that exists yet to turn the XML format back into binary and pack it into the NIF.

 

If you're talking about general import/export in the second half of your statement,  Figment has had Fallout 4 support in his Max plugin for some time.  https://github.com/figment/max_nif_plugin/releases

Link to comment
Share on other sites

Something happened between Dev 3 and Dev 4 that makes it balk about MD5 hashes with FX meshes.

 

 

 

An MD5 hash comparison indicates this file will not be 100% identical upon saving.  This could indicate underlying issues with the data in this file.

 

It does this on a number of magic FX meshes, and then it orphans a NiPSysData sub-block or two from... somewhere.

 

The file I most recently had this happen to is a Skyrim vanilla-extracted mesh: Meshes/magic/FirewallFX01.nif

 

I opened the same file with the last Dev 3 and got no such error, and no orphaned NiPSysData sub-block.

Link to comment
Share on other sites

The issue is actually less complicated than it appears.  Dev 3 had no Fallout 4 support whatsoever, nor did it even have the logic to create such an error.   The sole issue traces back to the nif.xml changes.   Both the nif.xml changes to support Fallout 4 and the logic to create an error message about the file integrity were added in Dev 4.   The only issue is the orphaning..  The error message is a byproduct of that (which couldn't happen in Dev 3 anyway).

 

I'll look into why it's happening. I don't really see anything jump out in the nif.xml commits though. 

Link to comment
Share on other sites

I'm not even sure if I own NV.  I think I do..  I think I backed up the BSAs somewhere before uninstalling it on Steam. :P   Yeah, I do. 

 

It's possible the data integrity was always off with those files, it's just now warning you.   Take that NIF, turn off auto-sanitize and immediately save a copy in an older version of NifSkope.  They should be binary identical.  If not, the data integrity was always bad and it's probably down to the blocks used in the LOD files.   I don't think any specific XML changes for Fallout 4 would have caused it to be an issue just recently.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...