airbreather

Kelmych's link doesn't work for me (this one does). At least one of these manual edits (the XEZN change in [CELL:00016BCF]) seems like it might impact the game? It was important enough for Bethesda to make this change in Update.esm. The others seem probably harmless, though it's admittedly fun to delete something that says "AAADeleteWhenDoneTestJeremy" on it. It seems to me like it would be a good idea to at least mention the idea on the wiki page, whether it's "here's another change that some people say you should make" or even if it's just "other guides suggest to do blah blah blah, but don't bother; it won't change or improve anything". I didn't learn about this issue until I Googled MD5 checksums to make sure I've got the right expected output for my little automation project and stumbled upon this page.

Hey, I'm looking into doing some automated plugin cleaning as part of a larger effort to automate as much of STEP as I can help with. In doing so, I've stumbled upon some odd things that xEdit does which I don't completely understand, and I was wondering if someone could shed some light on it. I'll list the full repro steps, but it should be the standard cleaning process, minus the UDR step. Test case (xEdit 3.1.3): Run xEdit with untouched Skyrim.esm and Update.esm files. The files I'm looking at have MD5 checksums 15958064e1272509933b51d086bbd5b4 and 2476e42699d4d9236ddd2ea8b31f612d, respectively. When prompted, ensure that nothing is checked except for Skyrim.esm and Update.esm and hit OK. When loading is finished, right-click Update.esm and select Apply Filter for Cleaning. When that's finished, right-click Update.esm again and select Remove "Identical to Master" records. Promise the nag screen that you know what you're doing. Attempt to close the window. When prompted, ensure that Update.esm is checked; if you don't have a backup of Update.esm, you might also want to make sure that "Backup plugins" is checked as well so that you can run through this again.At this point, your Update.esm file should now be 1332304 bytes long (down from 1518686) and have a MD5 checksum of cd5e3ba29f51a5fb903fea192d75507f. If not, one of us did something wrong. OK. That cleaned file is what I want to talk about. Unless I made some really horrible mistakes on my end, in addition to simply removing ITMs and updating the TES4 record, the above process has also made the following changes: Records in the GMST, WEAP, NPC_, QUST, IDLE, PACK, CPTH, and SCEN top groups, as well as the groups that represent temporary children of cells 0006DAA0 and 0000923C were reordered so that they are sorted in increasing order by Id. The {Ext block Y=-1, X=0} and {Ext block Y=0, X=0} sub-groups of the {Children of [WRLD:0000003C]} group were moved to the bottom of their parent group. In the [WEAP:000BE25E] record, two bytes in the DNAM field were zeroed out. In the [REFR:00109CD2] record, the payload was entirely wiped out. It used to have a NAME field, but it doesn't anymore. The following records used to have comparatively large OFST fields that have also been entirely wiped out: [WRLD:0000003C], [WRLD:0001691D], [WRLD:00034240], [WRLD:00094B35] In the [DOBJ:00000031] record, the DNAM field's payload has shrunk from 2656 bytes to just 40 bytes.My specific points of confusion (note that I'm not a "real" modder, so I'm looking at all of this from a "here's a bunch of bytes" perspective): Are #1 and #2 intentional?If so, is there a reason not to sort records in, say, RACE or MGEF (probably a few others too) which seems to have its records ordered any which way?If not, is this a problem?It looks like the things that got sorted are just the things that had records deleted from them, so I'm guessing xEdit is just rewriting the edited groups based on its internal data model.Is #3 desirable?If so, wouldn't this be better for something like USLEEP to take care of, rather than the Update.esm cleaning process?If not, is it actually a bug in xEdit?What's the deal with #4?I'm just completely confused about why we would want to do this. Is this something that people don't usually see because it gets UDR'd later or something?The release notes for 3.0.32 make it sound like #5 was intentional. Can you please help me understand what OFST is and why it's OK to aggressively delete it by default?I've been using the UESP wiki as my primary source for everything, and the WRLD page leaves OFST as a big fat "unknown", so if nothing else, I'd like to at least update it to mention that xEdit seems to be able to just delete it with no apparent negative repercussions.Is #6 desirable?3.1.0's patch notes say "Improved DOBJ handling", but in theory based on my knowledge of what's going on here, this action shouldn't require any changes to DOBJ.Though the original version does look like it has an "interesting" amount of padding.Sorry for the barrage here. From my perspective, I expected xEdit to make as few changes as possible when asked to just remove ITMs, so I was really surprised to see all these "extra" changes.

Looking through again, I wasn't using the latest TES5Edit, and there may have been some other dirty changes left over in my TES5Edit folder. Dumping that and all DynDLOD stuff and regenerating those things seems to have fixed it.

So I was about to open a new issue over here, but I figured I'd run it by you guys first to see if there's anything I'm missing. I was just going to paste below what I was about to post and reformat it, but along the way I discovered something that makes me lean towards it being a STEP issue (though I'm still very unsure because of all the different postprocessing that we do during a STEP setup and the fact that ModOrganizer loves to overwrite file data without changing the metadata). I ran into this stack trace when trying to generate LODs for STEP 2.2.9.2: System.IO.EndOfStreamException: Unable to read beyond the end of the stream. at System.IO.BinaryReader.FillBuffer(Int32 numBytes) at System.IO.BinaryReader.ReadUInt16() at LODGenerator.NifMain.NiHeader.Read(BinaryReader reader) at LODGenerator.NiFile.Read(String gameDir, String fileName, LogFile logFile) at LODGenerator.LODApp.<>c__DisplayClass4.<GenerateLOD>b__2(Object state) at System.Threading.ThreadHelper.ThreadStart_Context(Object state) at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Threading.ThreadHelper.ThreadStart(Object obj) It was during the generation for Tamriel, of all things. Being a .NET developer by trade, I know what this means, so I attached a debugger after the exception was thrown. It revealed that NifHeader.headerString at the time of the crash was: "DDS |\0\0\0\a\u0010\b\0\0\u0001\0\0l\0\0\0\0l\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 \0\0\0\u0004\0\0\0DXT3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\u0010\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\u0002\u0011\u0002\u0011\0\0\0\0\0\0\0\0\0\0\0\0\u0002\u0011\u0002\u0011\0\0\0\0\0\0\0\0\0\0\0\0\u0002\u0011\u0002\u0011\0\0\0\0\0\0\0\0\0\0\0\0\u0002\u0011\u0002\u0011\0\0\0\0\0\0\0\0\0\0\0\0\u0002\u0011\u0002\u0011\0\0\0\0\0\0\0\0\0\0\0\0\u0002\u0019\u0002\u0011****\0\0\0\0\0\0\0\0\"\u0019\u0002\u0019\u0095\u0095\u0095*\0\0\0\0\0\0\0\0\"\u0019\u0002\u0019" That seemed a bit long and awkward for something that's stored as a string, so pulling up some of the files, I noticed that the ones I randomly picked would tend to start with "DDS |" followed by 0x00, 0x00, 0x00, 0x0a, 0x10, 0x0a (dec: 10) which would cause this code to stop reading the header. Pulling up SkyFalls + SkyMills \ Textures \ Terrain \ Blackreach \ Objects \ blackreach.objects.dds, it seems to start with "DDS |", followed by 0x00, 0x00, 0x00, 0x07, 0x10, 0x08 and then a few hundred more bytes before a seemingly wild 0x0a shows up. That didn't satisfy me much, so I retried by grabbing the source code, running VS2015 under ModOrganizer, unticking "Optimize Code" in the debug build, and re-ran it with a debugger attached so I could get the details about exactly what's going wrong. The offender is TreePineForest03_0004B016.dds from "STEP Mod Compilation and v2.2.9.2i Patches", apparently (attached what I've got). Opening random .dds files in the folder where that came from, it would appear that most of textures in here have the same kind of preamble. So either I've made a mistake, I've gone mad, the world's gone mad, or xLODGen is perhaps only expecting to deal with a subset of the DDS spec. I've set up STEP 2.2.9 successfully in the past, including the DynDOLOD stuff, but this is the first time I've dealt with the STEP Compilation. I have yet to try 2.2.9.2 again from scratch. More Info: Windows 7 x64 .NET Framework version 4.6.01055 (4.6.1 / release 394271) LODGen.exe 0.8, MD5: 036bdaf45e1299a776fe719bd90f0a2d Edit: really, truly attached what I've got. TreePineForest03_0004B016.zip