Core Team
  • Content count

  • Joined

  • Last visited

Community Reputation

3 Neutral


About jonwd7

  • Rank
    Advanced Member
  1. You're not going to get any kind of response here, especially because it involves Linux. I told you everything you needed to know in the Discord, so I don't know why you came here. As I said there, try using Qt 5.7. Since you just up and left, I never got to hear if you tried 5.7 and if it resolved the issues. I do know that the UI became a little wonky in 5.9/5.10 (on Windows) which is why I actually postponed upgrading, but the guides were already written at that point. Also, sorry, but I was going to remove your executable link for multiple reasons, but it turns out that Google thinks it was violating the TOS for some reason. Anyway, the multiple other reasons remain so please don't repost an executable. If you could, take the discussion back to Discord, and let me know if using 5.7 resolved anything.
  2. You didn't reorder the blocks. The entire NIF is in an extremely bad order, but what is relevant is that bhkRigidBody needs to have a higher ID than the shape it's referencing. The Havok blocks work in the opposite order. The rigid body needs the shape it references to already be created and for that to happen, the shape block needs to have a lower ID so it is loaded first. You copied vanilla blocks, yes, but you didn't copy their block order. Copy/Pasting branches is generic and their visual order you see in the original hierarchy is the order they will be pasted into the destination NIF. For Havok blocks, you need to reorder after the paste since their order needs to be reversed. Reorder Blocks used to be part of auto-sanitize, but it can break various things regarding rendering and texture set swapping so it's something that needs to be run manually. I can see about special casing of bhk reordering, but I don't see any way to do it that won't potentially affect the block numbers of the pre-existing shapes/nodes which shouldn't be touched for the same reasons Reorder Blocks was removed from auto-sanitizers.
  3. Just take the last connect point, select the row with the expand/collapse arrow, Ctrl-C, then do the same on the connect point you want to replace, Ctrl-V. This overwrites it. Then reduce your Num Connect Points by one.
  4. The error is extremely straightforward. It says CsNiNode is an unknown block, which is exactly what it sounds like. CsNiNode is some custom block by whoever made the Digimon games. It's not a real Gamebryo block.
  5. That's exactly why that space is there. I simply haven't gotten around to it.
  6. You could just update to Dev 7.
  7. @idextroyer I didn't pay full attention to this post until now, sorry. I didn't realize that someone had figured out all the hash mappings before me ("genz"). I had independently found those versions and saw that they used hashes for block type instead of strings. At the time, I could not find the hash used on the string and didn't want to spend the time finding the mappings like done by genz. However, looking at the data again, I was able to figure out which string hash was used. NifSkope development builds now fully support all of the block type hashes without any manual mapping, since I reverse engineered the hash used. I am on the fence about the required XML changes however. All of the NiGeometry changes for these custom 20.3 versions leave a bad taste. For things like niflib and PyFFI, all of the "Has" booleans need to be changed to bytes for the `== 15` etc. comparisons, and I don't like that. In NifSkope I can do `== 15` against a bool type as really it's still just an integer. So maybe I will just supply an alternate nif.xml for the builds.
  8. Mega necro bump, but I felt it necessary to share the findings we've made in Discord. TL;DR - It's honestly easier to simply remove the MoppBvTreeShape from the hierarchy and use the bhkCompressedShape/bhkNiTriStripsShape/etc. directly. Have only tested FO3 to any degree so far, but for Skyrim the collision still shows up correctly in Preview when extracting the BvTreeShape from the hierarchy. I have a hard time seeing any downsides as Havok's MOPP has always been explicitly and solely about memory reduction for consoles circa PS2/Wii era. The MOPP is actually a program which requires a virtual machine to run it. So each shape gets a program stored alongside it and this program has to run for all collision detection. So depending on shape complexity it's possible that having no MOPP at all is actually better. The MOPP is a binary tree however. So maybe on more complex shapes it does accelerate collision detection instead of causing more CPU cycles. I think I am going to try to test this out by batch removing all MOPP and seeing what happens to CPU % and FPS. For anyone curious I have also found the actual opcodes enum: enum hkpMoppCommands { HK_MOPP_RETURN = 0x0, HK_MOPP_SCALE1 = 0x1, HK_MOPP_SCALE2 = 0x2, HK_MOPP_SCALE3 = 0x3, HK_MOPP_SCALE4 = 0x4, HK_MOPP_JUMP8 = 0x5, HK_MOPP_JUMP16 = 0x6, HK_MOPP_JUMP24 = 0x7, HK_MOPP_JUMP32 = 0x8, HK_MOPP_TERM_REOFFSET8 = 0x9, HK_MOPP_TERM_REOFFSET16 = 0xA, HK_MOPP_TERM_REOFFSET32 = 0xB, HK_MOPP_JUMP_CHUNK = 0xC, HK_MOPP_DATA_OFFSET = 0xD, HK_MOPP_SPLIT_X = 0x10, HK_MOPP_SPLIT_Y = 0x11, HK_MOPP_SPLIT_Z = 0x12, HK_MOPP_SPLIT_YZ = 0x13, HK_MOPP_SPLIT_YMZ = 0x14, HK_MOPP_SPLIT_XZ = 0x15, HK_MOPP_SPLIT_XMZ = 0x16, HK_MOPP_SPLIT_XY = 0x17, HK_MOPP_SPLIT_XMY = 0x18, HK_MOPP_SPLIT_XYZ = 0x19, HK_MOPP_SPLIT_XYMZ = 0x1A, HK_MOPP_SPLIT_XMYZ = 0x1B, HK_MOPP_SPLIT_XMYMZ = 0x1C, HK_MOPP_SINGLE_SPLIT_X = 0x20, HK_MOPP_SINGLE_SPLIT_Y = 0x21, HK_MOPP_SINGLE_SPLIT_Z = 0x22, HK_MOPP_SPLIT_JUMP_X = 0x23, HK_MOPP_SPLIT_JUMP_Y = 0x24, HK_MOPP_SPLIT_JUMP_Z = 0x25, HK_MOPP_DOUBLE_CUT_X = 0x26, HK_MOPP_DOUBLE_CUT_Y = 0x27, HK_MOPP_DOUBLE_CUT_Z = 0x28, HK_MOPP_DOUBLE_CUT24_X = 0x29, HK_MOPP_DOUBLE_CUT24_Y = 0x2A, HK_MOPP_DOUBLE_CUT24_Z = 0x2B, HK_MOPP_TERM4_0 = 0x30, HK_MOPP_TERM4_1 = 0x31, HK_MOPP_TERM4_2 = 0x32, HK_MOPP_TERM4_3 = 0x33, HK_MOPP_TERM4_4 = 0x34, HK_MOPP_TERM4_5 = 0x35, HK_MOPP_TERM4_6 = 0x36, HK_MOPP_TERM4_7 = 0x37, HK_MOPP_TERM4_8 = 0x38, HK_MOPP_TERM4_9 = 0x39, HK_MOPP_TERM4_A = 0x3A, HK_MOPP_TERM4_B = 0x3B, HK_MOPP_TERM4_C = 0x3C, HK_MOPP_TERM4_D = 0x3D, HK_MOPP_TERM4_E = 0x3E, HK_MOPP_TERM4_F = 0x3F, HK_MOPP_TERM4_10 = 0x40, HK_MOPP_TERM4_11 = 0x41, HK_MOPP_TERM4_12 = 0x42, HK_MOPP_TERM4_13 = 0x43, HK_MOPP_TERM4_14 = 0x44, HK_MOPP_TERM4_15 = 0x45, HK_MOPP_TERM4_16 = 0x46, HK_MOPP_TERM4_17 = 0x47, HK_MOPP_TERM4_18 = 0x48, HK_MOPP_TERM4_19 = 0x49, HK_MOPP_TERM4_1A = 0x4A, HK_MOPP_TERM4_1B = 0x4B, HK_MOPP_TERM4_1C = 0x4C, HK_MOPP_TERM4_1D = 0x4D, HK_MOPP_TERM4_1E = 0x4E, HK_MOPP_TERM4_1F = 0x4F, HK_MOPP_TERM8 = 0x50, HK_MOPP_TERM16 = 0x51, HK_MOPP_TERM24 = 0x52, HK_MOPP_TERM32 = 0x53, HK_MOPP_NTERM8 = 0x54, HK_MOPP_NTERM16 = 0x55, HK_MOPP_NTERM24 = 0x56, HK_MOPP_NTERM32 = 0x57, HK_MOPP_PROPERTY8_0 = 0x60, HK_MOPP_PROPERTY8_1 = 0x61, HK_MOPP_PROPERTY8_2 = 0x62, HK_MOPP_PROPERTY8_3 = 0x63, HK_MOPP_PROPERTY16_0 = 0x64, HK_MOPP_PROPERTY16_1 = 0x65, HK_MOPP_PROPERTY16_2 = 0x66, HK_MOPP_PROPERTY16_3 = 0x67, HK_MOPP_PROPERTY32_0 = 0x68, HK_MOPP_PROPERTY32_1 = 0x69, HK_MOPP_PROPERTY32_2 = 0x6A, HK_MOPP_PROPERTY32_3 = 0x6B, HK_MOPP_JUMP_CHUNK32 = 0x70, }; So the unknown opcodes `0x01` though `0x04` have something to do with scale. I will be working on understanding MOPP for a while even though I'm feeling like the best course of action is to simply strip it. If I find anything else pertinent I will share it here.
  9. @ReaverLord It doesn't "magically generate" anything. There is no string. Your lack of knowledge about this issue does not give you free license to be rude (unless I'm somehow misreading your immense amount of sarcasm). "NPC LLegToe5" is not stored there at all. It is in fact the integer 17 (0x11 in hexadecimal). Also please observe that the size of the data is 4 bytes. NifSkope doesn't "magically generate" anything on copying this block data to another file. It copies the data--verbatim--to the other file. In this case, you're copying an integer value from one NIF to another. In the destination NIF, that integer value of 17 will point to another string index in the NIF header, and whatever is at index 17 in that file will show. It's been two years because I am uninterested in solving this particular issue. It's a lot more complex than you realize, clearly. Perhaps unmotivated is a better way to put it. And do you really think your approach is going to somehow motivate me? Because it will probably do the opposite. Also, if it could have been solved easily before I took over, it would have been. Strings changed to string indices after NIF version 20.1, circa 2007. There was a lot of development going on before and after Fallout 3 came out in 2008. Development went on until after Skyrim came out in 2011, and basically died in about 2012. I didn't take over until 2014, so currently it's still been less time than when there were many more active devs between 2007 and 2012. Maybe you should ask them why they didn't fix it in the 5 years they could have worked on it, and the 7 years before I came around.
  10. That's not the case. Nif.xml already has NiMesh/NiDataStream completely decoded, it's the meta-issues with the parser like the NiDataStream RTTI string in the header with the Usage/Access arguments (i.e. `NiDataStream\01U\01\A` where U and A are the values to extract to args), and actually creating all the basis around NiDataStream as a geometry format so that you can turn it into a Blender scene and vice versa. There is no issue with nif.xml in that regard. There are other issues with other blocks though, and I've been addressing them. But like I said on Discord, regardless of the nif.xml progress, it won't make NifSkope or Blender able to do anything with the geometry as neither have any support for NiDataStream.
  11. @cunningmoss6833 That's ChunkMerge, not NifUtilsSuite (the successor). He's referring to this thread Where the link is now dead. I will try to update that post with a new link but for now here is the latest version of 1.2.2. I believe @lantiko already asked for it in the Discord server but in case it's different people here it is:
  12. No, it's not just the BSFadeNode which is what I tried to tell you. It's the entire structure. I'm trying to tell you that your Windows theming changes have somehow broken what you should be experiencing. You clearly have a lot going on in your Windows theme.. You have a non-standard font. Non-standard colors, non-standard title bars. Your theme has stripped the Block List of its usual appearance (please compare it to my images). You'll notice that there should be an arrow next to the 0 BSFadeNode which due to your computer's theming issues has been removed. You can confirm that the full tree is there by selecting the 0 BSFadeNode and pressing asterisk on your NumPad, or using the up/down arrows above the Block List to expand the tree. Or, you can click on the mesh in the viewport and the Block List tree will expand. On open (note the arrow your Windows is for some reason lacking): If I click the mesh: If I press asterisk on numpad after selecting 0 BSFadeNode (or use the down arrow in the top right corner of the Block List): So no, I didn't misread your post. I know what you're asking, but I'm trying to illustrate that I believe your UI has fallen victim to your Windows theming changes because the default tree view is not correct on your computer. As for what you're asking, why are you asking it? I believe it's likely because of the issues I just pointed out above and not for any other reason. The list view is not correct compared to the tree view as it lacks the hierarchical information. As such its general usage is discouraged and hence why it's hard to switch to. The tree view is not just equally functional to the list view, it's more functional and shows more about the NIF structure than the list view. I would suggest you figure out your theming issues for why your tree view lacks the necessary arrows and try to use the tree view. If the additional click or keypress to expand the entire tree doesn't alleviate your issues, please elaborate on why exactly it's so important that NifSkope be in the list view instead of tree view. As I said before we were thinking about removing it as it has no use.
  13. 1. Your Windows theme is severely messed up and missing the arrows for the tree view in Block List. The tree view is the correct default view. The list view you prefer is not correct as it shows no hierarchy. You can click on the hat and the tree will expand. You can also select the "0 NiNode" row and hit asterisk on your NumPad or use the Up/Down Chevron buttons (the up/down 》 arrows) to expand/collapse the whole tree. I think you're likely only using the list view out of necessity because of your broken windows theme, and not because the list view has any inherent benefits. In fact we'd prefer to just remove that view to simplify things.. 2. You have the docks undocked... There is no way the viewport can possibly know you are covering it up with other windows. If you want the viewport to stop at the right Block List dock, then dock the Block List instead of leaving it floating. You can dock a window just as you undocked them, by dragging. 3. You're asking me to remove a feature because you don't like it? OK then... Maybe you'd notice that it stops at the 10 most recent files though instead of making such a peculiar request. 4. Your Block Details window is a complete waste of space as currently configured regardless of height. You don't need to see anything past the Value column, so half of the Block Details space is just a complete waste. And that's as short as I can allow it, sorry. The editors for shader flags and the like needs vertical space to show. Since you have it undocked anyway there's nothing stopping you from moving it halfway off the screen. I made the default UI like this because it's the most compact: Anything else you could do to it is just un-compactifying it.
  14. @Sorceress Try using a modern version of NifSkope... It's also hard to diagnose a file without the file. But try a NifSkope more recent than 2011 first, then upload the file if it still doesn't show.
  15. Updated my 010 templates to test all this out: