Jump to content


Unofficial Patch Project
  • Posts

  • Joined

  • Last visited

About Jon

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

2814 profile views

Jon's Achievements


Clanholder (5/10)



  1. That's not strictly correct. That's one of two header differences, not to mention differences in many other blocks. I've already fixed all of it but I have no plans for a release at this time.
  2. What body it is doesn't really have anything to do with it. When you batch build it's just taking the geometry and morphing it, and leaving the broken texture set paths intact. So for a preset or different base body that supplies vanilla refits, they batch built and didn't use the UP versions with the fixed texture paths. What version of the plugin you have also has nothing to do with it. It's going to import what textures are referenced in the original and export them back out. The problem is in the original NIF and so anything is going to preserve this problem unless you add the texture path back in as Hana illustrated. Also, I'm a bit fuzzy with actual game details at this point, but the texture sets for bodies in the outfit NIFs hardly matter afaik, as the race/NPC/etc. records in the ESM file have texture sets that override all of this anyway. Otherwise the outfits couldn't do skin swaps (like elder, briarheart, whatever else has different skin textures). So, in most cases the game probably adds the missing specular mask back via the ESM's texture set swaps and the shininess in NifSkope from the missing _s map doesn't really matter.
  3. Actually, the vertex positions are still full precision. The new vertex format was introduced in FO4 and supports half and full precision. But SSE doesn't support the half precision format for positions for whatever reason even though it's part of that new class. Probably because of Havok/animation stuff. Or because BSTriShape was actually made for SSE first because it's NIF version 100, and half precision for vertices wasn't added until version 130 (FO4). But the normals, tangents, bitangents, UVs, vertex colors and bone weights all get moderately to severely compressed.
  4. A correctly structured Oldrim NIF does not need any changes to work in SSE. There was never any intent on allowing conversions in NifSkope, and there is still not. I helped ousnius make his tool, which we're finding more every day that converting to SSE is the opposite of optimizing... Most recently we've found the half float precision on UV coordinates to be woefully unforgiving for anything outside of the -2.0, 2.0 region, the worse the further out it gets. Arranging UV islands in different regions outside the unit square is fairly common. The only thing that is ridiculous about the old NIF format is using four floats to store vertex colors instead of 4 bytes, but everything else in the SSE format change destroys the precision of your model.
  5. It's fine in the test build on Discord. I had found another rendering issue I haven't released the fix for to GitHub yet, as I wanted to test more thoroughly this time. The next build I will upload also introduces an error color option for missing textures, so it looks like this for me: As I do not have all the textures for this face.
  6. I made two bugfix updates, one on the 19th and one today. The update today is important for anyone working with version < 20.1 NIFs.
  7. NifSkope 2.0 Dev 7 NifTools Discord Reddit post The changelog is massive so I won't even summarize it here. You can see it in either of the GitHub or Reddit links above, though I removed some non-Bethesda specific stuff from the Reddit changelog. Re: the NifTools Discord, I regularly provided new builds there as I developed Dev 7. If you want more frequent updates than the GitHub releases, you should join the server. Admittedly, the time between Dev 6 and Dev 7 was far too long. However, after Dev 6 I didn't even work on NifSkope for 6 straight months. That still leaves 7 months of feature creep while making Discord-only builds, and I will try to make more public GitHub releases going forward.
  8. @WalterHawkwood You're right, I ran into this issue recently while looking at non-Bethesda things for something and was already planning a fix. You should come to the NifTools Discord, as I am more likely to throw up a build with the fix as I have been releasing test builds there fairly often. You can get to it from the niftools.org homepage or the niftools.org forums. Sorry for not responding sooner. I don't come around here very often anymore with the advent of Discord and the new site and revamped forums.
  9. I'm still a bit confused I guess. This seems dangerous and I think way too many people see "cleaning" as some kind of safe, foolproof thing. Maybe the mod page needs slightly bigger "Turn Away" signs. Similar things happened with ousnius's converter as way too many people see it and say "Oh I may as well just run this on everything I own". If you regenerated precombined for a cell and then go and immediately take out everything you didn't edit or add yourself, you are effectively turning off precombined for the entire cell save for a few objects. The NIFs are in a path under the plugin name as you know, so it can't be down to filepath resolution (the game finding the vanilla _OC where the referenced mod's _OC is now absent). There's also only one timestamp for the cell precombined and your new ESP is going to reference all the newly regenerated files in the cell record. So you remove those references to the now-absent files (?). And now what happens? I don't see any mention of it merging back in the vanilla subrecords in order to have a complete precombined list. You say it will revert to using vanilla, but if the lists aren't merged can it really do that? I guess since I don't see this part explicitly explained in the desc or articles my first thought is that nobody even realizes it's an issue, so maybe the documentation should be a bit better to reflect this. I guess the other explanation is that the engine does remove the plugin name from the path resolution and goes back through every plugin to find the first matching _OC NIF? If that were the case, the _OC could be from another mod that edits the cell. Or does it only go back and look at vanilla paths? If it does go through other mods first this could lead to all kinds of problems depending on if this confuses the engine with what NIF to actually load. If it's not using the timestamp in the cell record since it can't, is it stopping at the plugin that has the matching _OC NIF and then figuring out what actual NIF file to load from that? Because we know that this is roughly why replaced NIFs don't show up because their identity is hardcoded into the cell record and the _OC file. Additionally, the Vis files from the top-most mod only know about Vanilla+Top-Most Mod's _OC files. So if along the way it matches the _OC from another mod, that _OC might differ from vanilla in actual content (e.g. object size, placement, number) and there could be issues. Depending on the actual answer to all these questions this could do away with whole-cell incompatibility between mods which both have precombined if they both clean up their mods. I'm most concerned about the _OC file resolution and if this allows for multiple mods' _OC in a cell and what this means for the Vis files (which presumably only get loaded from the top-most mod). It's at least nice to know you can handpick things in a cell to uncombine. I always assumed that was the case but I'm glad it's tested. If certain things are really problematic to a cell (buggy, placement, whatever), then it's good that you can just remove them and then fix the NIF or the reference. Also why wouldn't it work for something like SMIM? You replace vanilla NIF files, you have the CK regenerate the precombined so that it references the new NIFs, you remove all the precombined NIFs that don't contain SMIM files and fix the references in your plugin. Isn't that about right? ---- Edit: Also what about XPRI? Is there ever any overlap/conflict between _OC and _Physics files and XCRI/XPRI? (Off hand I can't remember if _OC is always devoid of physics blocks) What happens if you remove a reference from the XPRI? Edit2: I asked about the filename resolution in a much simpler fashion here: https://forums.nexusmods.com/index.php?/topic/5522717-fallout-4-optimization-and-performance-systems-explained/?p=49807002 ... In case that's easier to answer.
  10. What exactly do you mean by "cleaner"? The only tool I can envision being useful for precombined is to generate precombined from multiple plugins into one directory belonging to a "Merged" plugin. Needs to be that way for the timestamp so that the game actually loads them. If it's not that, then what? In any case it would require fully decoding BSPackedCombinedSharedGeomDataExtra as there are several important fields I never decoded. Particularly there are some kind of hashes that reference the objects in the cell but I never matched them up to any FormIDs. If you're doing some BTS stuff with these blocks or have already decoded the different format, I'd definitely like in on things. Also I literally just found out that the CK we were given doesn't even make precombined the same. It comes out 5-10x larger and uses a different block: BSPackedCombinedGeomDataExtra. (So my "worst case scenario" where I point out an SMIM for FO4 would need to include 2GB+ of this data for all the cells just jumped up to 10GB+.....) I take it "cleaner" might imply that you are updating the positions/bounds of the combined objects from the original refs, in which case that still means someone decoded how the ExtraData block references them. Of course maybe I'm being too hopeful that eham or sheson or someone is making some kind of tool. Maybe this is just about updating the precombined subrecords in the plugins in some way that I'm not able to envision. That's definitely the simpler answer, as the former would require also decoding and regenerating the vis files since even in the simplest case of fixing object placement this could lead to blinking meshes and things since the vis hasn't been updated.
  11. Ohs noes. I had no idea this was happening or I would have popped in for the end-of-the-world party. I have long refused to use Discord but I guess that's because I was forced to always have Skype open and didn't want two chat apps. I've since saved my soul stopped using that garbage so I guess now I have room to start using Discord...
  12. I don't mean to detract from your work in any way -- it's always good that there are many people working on a certain thing -- but so far that stuff is already known. The SSF File is that way simply because nif.xml doesn't have a string type which can handle it as no other string type uses a short (16-bit) value to hold the length. Basically, it boils down to laziness. The 0-6 is a bit more complicated than that, and the values don't strictly associate with a particular area across different Actors. Look at Deathclaw for example, or Radscorpion. Anyway those values are readily apparent as that's what I use to highlight the segment in the viewport when you select the Segment in the Segments array. The hashes are believed to be a hash of a string for the body part. Strings can be found in the SSF files which loosely associate with each hash, but we've already tried Bethesda's own string hashing functions on the strings and don't get the same hashes. Bethesda has their own CRC32 called BSCRC32 and it can be used case insensitively or not. Also there aren't 100 of them, there are about 264 going from ousnius's collection of them. I think we have other various analyses and data dumps floating around somewhere, but no real motivation/reason to compile this knowledge. And going through various outfits you'll notice that there are a few different hashes used for the same areas of the body and IIRC looking at the strings didn't really reveal why the hash would be different. Also across species sometimes what is considered a "head" has a different hash even though the associated strings in the SSF file still say "Head" and some NIFs don't even have an SSF file at all (e.g. BaseMaleHead) or the SSF file only lists a few of the actual body parts. So the SSF file is only part of the picture. The CK lets you see a lot of this data btw: In my testing just now I realized that the skeleton.nif has to be alongside the mesh before you load the CK Preview or the Bone dropdown doesn't propagate properly. You can't just load a new reference skeleton it seems. Anyway, the dropdown would appear to give all the strings that could possibly be associated with the hashes in the NIF files. But since we tried turning these strings into hashes a few different ways and didn't get any matches, the association would have to be made by hand for every single one. That was the point where I gave up. Some things to note: The "Biped Object" acts a lot like the enum from previous games. Stuff involved with dismemberment is 100+, there is some stuff between 30-60. Basically this: Except some of the values are off. Anyway, I suppose I will try to re-analyze the hashes against the bone strings some time in some bulk fashion. I could compile the hashes and the strings in each file, and for each file that has a specific hash, I would be able to intersect all their strings and if they all have a certain string in common, it will show. Of course a lot of outfits and things all have the same dummy bones so it wouldn't narrow it down fully. This is also assuming the dummy bone strings are enough. If I need to load the reference skeleton to get all the bone names then it will be hard to automate. I could also just reapproach the hashing. Originally I had someone on the F4SE team actually run Bethesda's own hashing functions via the engine DLLs that come with the FO4 exporter and they didn't match. I've since reversed the hashing function into my own program which I'm 100% sure is correct because they use the hashing functions in the BA2s, so I will retry them on the bone strings again just to be sure.
  13. I suggested "Tools" in the Announcement topic but your idea is even better since it's a little more broad. I had trouble finding my NifSkope and B.A.E. threads.
  14. @Arthmoor I had to go to "My Followed Content" to figure out where my NifSkope thread (and B.A.E. too) went. I think this is probably proof enough that with this reorganization we need a dedicated Tools/etc. forum next to The Elder Scrolls and Fallout 4 categories.
  15. Jon

    [RELz] Footprints

    Can more people report this as stolen please? Apparently just reporting it as the actual creator of the mod means nothing to Bethesda. https://bethesda.net/en/mods/skyrim/mod-detail/3992604 One of their comments explicitly admits that it's using my assets.
  • Create New...