Jon Posted December 30, 2015 Author Share Posted December 30, 2015 You're using an old version of NifSkope. BSConnectPoint::Parents has been decoded for some time. Link to comment Share on other sites More sharing options...
Layam Posted December 30, 2015 Share Posted December 30, 2015 O.o... shiny new nifscope. Many thanks. Link to comment Share on other sites More sharing options...
zilav Posted January 7, 2016 Share Posted January 7, 2016 Just noticed that you renamed materials in nif.xml in dev4 and this broke ChunkMerge in NifUtilsSuite, had to redownload and use explicitely nif.xml from dev3. Link to comment Share on other sites More sharing options...
Jon Posted January 7, 2016 Author Share Posted January 7, 2016 I was actually vehemently against those changes, as was figment. I just took the latest XML from the niftools repo to make merging back less painful. Link to comment Share on other sites More sharing options...
zilav Posted January 7, 2016 Share Posted January 7, 2016 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 More sharing options...
MadCat221 Posted January 11, 2016 Share Posted January 11, 2016 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 More sharing options...
Arthmoor Posted January 11, 2016 Share Posted January 11, 2016 And a picture to illustrate: Link to comment Share on other sites More sharing options...
InsanePlumber Posted January 11, 2016 Share Posted January 11, 2016 For me, this problem does not occur. 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 More sharing options...
MadCat221 Posted January 11, 2016 Share Posted January 11, 2016 AMD GPU here. Loose archive extraction for Skyrim. Also happens to vanilla BGS Skyrim NIFs, so it's not a specific mesh that's the problem. I'll try wiping the reg entry. Link to comment Share on other sites More sharing options...
InsanePlumber Posted January 11, 2016 Share Posted January 11, 2016 AMD GPU here. Loose archive extraction for Skyrim. Also happens to vanilla BGS Skyrim NIFs, so it's not a specific mesh that's the problem. I'll try wiping the reg entry. BGS? Please explain to me the shortcut. Link to comment Share on other sites More sharing options...
Nico coiN Posted January 11, 2016 Share Posted January 11, 2016 I guess BGS = Bethesda Game Studio. Anyway, core i5 + GTX 780 here and I'm also having the UV map issue. Link to comment Share on other sites More sharing options...
InsanePlumber Posted January 11, 2016 Share Posted January 11, 2016 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. Temporary solution for the original BGS Meshes is to use the BSA as texture resource for NifSkope. Options -> Setings -> Resources -> Archives Tab 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 Link to comment Share on other sites More sharing options...
Nico coiN Posted January 11, 2016 Share Posted January 11, 2016 I noticed some fields from the NiTriShapeData blocks are displayed differently. Is it something we should worry about ? Link to comment Share on other sites More sharing options...
Arthmoor Posted January 11, 2016 Share Posted January 11, 2016 AMD GPU, loose file nif. It's an edited dragon claw, but the problem persists, although it seems to be pretty hit and miss as to when it happens. Weird. Link to comment Share on other sites More sharing options...
zilav Posted January 11, 2016 Share Posted January 11, 2016 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 More sharing options...
Jon Posted January 11, 2016 Author Share Posted January 11, 2016 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 More sharing options...
MadCat221 Posted January 12, 2016 Share Posted January 12, 2016 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 More sharing options...
Hana Posted January 12, 2016 Share Posted January 12, 2016 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"... Link to comment Share on other sites More sharing options...
Jon Posted January 12, 2016 Author Share Posted January 12, 2016 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 More sharing options...
Necrocytosis Posted January 25, 2016 Share Posted January 25, 2016 We could also need some more info on the Collision meshes, not only you that would fall too though, we need the import/export functionality for blender/3ds max too. Hope Figment and neomonkeus have found something ^^ Link to comment Share on other sites More sharing options...
Jon Posted January 25, 2016 Author Share Posted January 25, 2016 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 Necrocytosis 1 Link to comment Share on other sites More sharing options...
MadCat221 Posted January 25, 2016 Share Posted January 25, 2016 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 More sharing options...
Jon Posted January 25, 2016 Author Share Posted January 25, 2016 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 More sharing options...
zilav Posted January 25, 2016 Share Posted January 25, 2016 Speaking of MD5 errors, dev4 started to show it for Fallout New Vegas LOD files, for example meshes\landscape\lod\wastelandnv\blocks\wastelandnv.level4.x8.y-12.nif If you don't have NV installed, I can PM it to you. Link to comment Share on other sites More sharing options...
Jon Posted January 25, 2016 Author Share Posted January 25, 2016 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. 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 More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now