Unofficial Patch Project
  • Content count

  • Joined

  • Last visited

1 Follower

About Jon

  • Rank

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

531 profile views
  1. 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: ... In case that's easier to answer.
  2. 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.
  3. 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...
  4. 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.
  5. 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.
  6. @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.
  7. Can more people report this as stolen please? Apparently just reporting it as the actual creator of the mod means nothing to Bethesda. One of their comments explicitly admits that it's using my assets.
  8. VF1-8 are just copies of the vertex description (called vertexDesc in the engine) which is a 64-bit integer that holds various vertex properties. This is split up into 8 bytes because it's easier for NifSkope to deal with and it doesn't have a 64-bit integer type anyway. I already annotated what I believe are the identifying hashes, but I'm pretty sure they didn't match any known FormIDs. I could be wrong about the alignment though and they might be there. I don't think I directly compared the FormID of the ref or the STAT to their actual extradata in the NIF, but I did search for FormIDs from the unknown bytes in the NIF. However I just looked at your 0000E2C6_3BB2127F_OC example and couldn't find the REFR or STAT FormIDs anywhere in that NIF at any alignment or endianness. It could potentially be a hash of the EditorID, BillboardWilsonAtomatoys01 which is either bscrc32 1641902539 bscrc32_lower 1178041431 ... but neither of those ints exist in the _OC NIF either.
  9. So now I have to go through the painstaking process of creating some broken NIFs that need sanitizing that also have or don't have connectpoints in the correct way based on your instructions and just hope I did so correctly in order to hope at reproducing the crash. And now you duck out because it "works for now" and what I need from you means zilch now that I've stopped your crashing. Instead of you just doing the kind and selfless thing and taking 5 minutes to upload the files in question. And before you go way over-the-top personal with your reply as you seem to like to do (you weren't "getting on my nerves" before)... this is how 99% of bug reports go and so it's just a general observation. Seems people don't actually care about the program or the programmer, they just want to rid themselves of the bug. So, I won't be troubleshooting bugs or crashes in this topic anymore. In the future please use the official GitHub Issues tracker.
  10. @InsanePlumber That was maybe true before I removed some annoying things from the list of auto-sanitizers, like Reorder Blocks which can break a lot of things. Sanitizing doesn't break anything anymore. There's no evidence the sanitization is causing the crash either, but it would be good if he disables it to rule it out. He should probably ask himself why every single NIF he's throwing at it needs sanitization though... And for the last time @KKthebeast, I need the actual NIFs you're trying this out on if I'm to even bother attempting reproducing it. "One or more block has had their name sanitized" means that your NIFs are technically broken, and maybe the crash is only happening on your broken NIFs.
  11. If you mean actually crashing left and right and you're not being hyperbolic, it's a platform issue on your end. Totally delete your NifSkope folder and make sure to install only what is in the latest official release into that location. As for the steps to reproduce you gave, they're far too vague and possibly reliant on the actual NIF contents.
  12. @InsanePlumber Probably not, no. Since the outset, adding features into such an old codebase has become increasingly costly to where there's really nothing left that I can justify adding. Every big thing I've wanted to do would require a rewrite of massive parts of the codebase, or just trying to mash it into place as best I can. Mashing things into place has been my MO for the most part, but it worked because those things were simpler. Given that the Havok binary that is embedded into NIF files for the FO4 collision cannot be encapsulated with the XML definitions used in nif.xml I would have to "mash in" an entirely new binary loader to take over where the XML parser and NifModel save/load cannot go even though the two are heavily coupled to the UI and all the data manipulation functions. Basically the way the data is shown in the UI via the NifModel/NifData class is heavily reliant on the nif.xml definitions and it's too tightly linked with all the other components. This is in my opinion very flawed, even ignoring it being extremely slow and memory consuming. Basically the UI *is* the data model and vice versa, and this is filled entirely upon load even though you never can actually see all of the NIF data at once. The primary benefit was *potentially* being able to read newer NIFs without having to recompile NifSkope but very rarely has only nif.xml needed updating. The only real need for quick updating via nif.xml was development/decoding and now I've made the much better 010 templates for such purposes. So, I think I'm pretty much done with major additions to NifSkope without a complete rewrite. Everything is too tightly coupled to rewrite one component at a time, especially the UI<->Data coupling. NifSkope is basically a glorified spreadsheet. This is extremely slow, because all the data manipulation ("Spells", etc) and retrieval is acting upon this glorified (and generic) spreadsheet instead of something object-oriented and de-coupled from the UI. If I do "start over" it will almost certainly be a totally new program. NifSkope has the benefit of being generic like I said. It can support dozens of NIF versions. I would focus solely on NIFs going forward, with the potential to extend down to (Oblivion) at minimum. I won't use nif.xml and I won't use niflib as it's tied to nif.xml via code generation. That was actually my primary reason for the 010 template repository, and I've already decoded more than is even in nif.xml for (which is just plain wrong about some important things). In fact I'm "so done" with nif.xml and the old codebase that I can't even bring myself to update nif.xml from my 010 templates. Trying to wrap my head around version conditions for dozens of other games makes it hard to update nif.xml safely. TL;DR - I decided a while ago to stop trying to add things to NifSkope. My code and the results both suffered and I no longer agree with the fundamental structure of the program. I will maintain it but any significant development time will probably be going to a new program.
  13. Underscores in Cell Editor IDs break save sorting in SkyrimSE. So... yeah. That seems significant enough to be patched.
  14. I skipped over DA03BarbasDogRace "Dog" [RACE:000CD657] for the canine effect. Simple fix.
  15. Oh I suppose that makes more sense then. I immediately discounted it being USSEP because why would it be tracking UPs from the old game and never gave it a second thought. The concern still remains though. I feel like more people think they know what they're doing and look at their logs than people who try using old UPs in SSE. But as you deal with it day in and day out you probably have a better idea of that.