Unofficial Patch Project
  • Content count

  • Joined

  • Last visited

1 Follower

About Jon

  • Rank

Profile Information

  • Gender
    Not Telling
  1. 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.
  2. 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.
  3. @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.
  4. 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.
  5. @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.
  6. Underscores in Cell Editor IDs break save sorting in SkyrimSE. So... yeah. That seems significant enough to be patched.
  7. I skipped over DA03BarbasDogRace "Dog" [RACE:000CD657] for the canine effect. Simple fix.
  8. 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.
  9. I posted a bug in the tracker, but I have a non-bug to ask about. Mainly are you intentionally keeping the codebases for SSE and SLE the same? Every savegame load I get And while obviously there is zero harm in it being there I just wanted to make sure it was intended. I started to skim through your 570 SSE Nexus comments but had to stop for my IQ's sake. I did see at least one person point to these "errors" as proof that your mod was causing crashes. (lol) You could possibly leverage Debug.GetVersionNumber() to filter out which ESPs are checked for, but obviously that's smelly. You could compare it to the supported versions for Oldrim and if it doesn't match then it's SSE. But it's especially smelly since I have no idea what that function returns on console.. if you are using the same codebase for that too. Though it will almost certainly return a string which doesn't match the listed Oldrim versions, and thus will count as SSE anyway. Like i said, doesn't really bother me all that much, but I fear how it might invigorate the know-it-all mod users who turn their Papyrus logging on.
  10. Arth is well aware.
  11. You must be running through that area to get there then, because you've unloaded the LOD for that group of trees. The reason there is no reflection at all is because you got close enough to the trees in the background and the full detail models have already been loaded. In Skyrim (old and new) the tree reflections actually vanish when you get too close to them. Disregarding SSR, *only* LOD can be reflected in water which is a huge step back from Oblivion. So go there, move back quite a ways, and then save. Reload the save so that those cells are completely unloaded and the LOD is in its place. If there are still no reflections at all, you are still too close. Your "I don't have this issue" picture would be demonstrating tree reflections that aren't giant rectangles and that have proper alpha.. not completely absent tree reflections. And btw, only bother trying to reproduce this any further for you, not for me. I am already sure you have the issue, given the two billboards I pointed out in your image. Those two trees are somewhere behind the hill, as that hill's LOD is not loaded so it's not in the reflection.
  12. @alt3rn1ty So... you and some others who have opened the female head MSN and have discovered the red and blue channels are switched... are just using some kind of broken plugin. With the Intel plugin the blue channel is exactly where it should be. So... basically there's no real issue with the MSN files. Though there is still a neck seam, it's just not because of swapped channels. I should have verified this myself way back when, but it was ousnius who finally looked for himself and saw no issues.
  13. You went a bit too close to those trees at some point (or have uGrids up) so the LOD trees are unloaded (Tree reflections actually DISAPPEAR as you get close to trees...). Though you do have the issue in other trees: (They must be behind the hill)
  14. Can anyone still on 1.2 confirm this issue does NOT happen for them? And can others on 1.3 confirm the issue DOES happen for them? I feel like I would have noticed this if it were present in 1.2, but it's possible the bug has been there all along. In either case, someone else noticed it and posted in the 1.3 beta forum: If it bothers you as much as it bothers me, please voice your concerns in that thread. Edit: Was just informed it was actually a problem in 1.2 as well.
  15. I think this is a new bug, and it's a terrible one. I noticed that tree LOD reflections in water are not using their alpha. I reset my INIs completely, uninstalled everything and it didn't change anything. I outline the billboard for the tree in the second picture, and outline the actual part that's the tree. I definitely do not remember this being a problem in Oldrim. Edit: It's also possible this is an issue with just the 1.3 beta. I've added a post to this topic: