Jump to content

cdcooley

Members
  • Content Count

    8
  • Joined

  • Last visited

  1. My point is that we aren't on the "next version of xEdit" yet and the decision to add master list entries that rely on a specific xEdit configuration without fully documenting that fact really is an additional source of confusion beyond the standard predictable level. But yes, the situation will resolve itself eventually.
  2. I'm one who didn't read it because the message says that's the guide for "quick auto clean" and I already know about cleaning and I didn't see a need for "automated" cleaning. More importantly none of that mentions you need a specific setting if you aren't using the fancy new auto-cleaning. The Loot message should be clear that you must use the autoclean or mention the setting needed if you're cleaning the old way.
  3. Thanks, that at least solves the mystery. It xExit requires that specific configuration then I wish whoever manages the Loot master list would hold off on dirty/clean entries using the new version because it's leading to a lot of confusion right now. Or at the very least document that that configuration setting in the Loot report.
  4. What's going on with the dirty/clean reporting? Was SSE 4.0.0 somehow broken? There weren't dirty edits before and there aren't now, so where did those 34 come from? People are coming to the Inigo page confused because "LOOT" is claiming the mod is dirty but then it can't be cleaned by SSEEdit. Here's what I currently see in the master list. dirty: # version: 2.4C - <<: *quickClean crc: 0x9CCE987C util: '[SSEEdit v4.0.0](https://www.nexusmods.com/skyrimspecialedition/mods/164)' itm: 34 clean: # version: 2.4C - crc: 0
  5. To be fair, the CK won't allow you to make the ESLs dependent on an ESP (unless you set the ESM flag bit) so using the official tools the problem can never occur, so they might not be interested in fixing it. If we're going to ask for something being fixed it would be better to see if they can allow user created ESLs to be loaded anywhere (and honor the ESM and ESL flag bits) so that they could be used like light weight ESPs and light weight ESMs. That's more of an enhancement than a bug fix, but the very fact that the current ESL support is based on file extension rather than the interna
  6. Why would there be any difference? From my testing it seems that the first ESL is getting loaded as FE000xxx, the second is FE001xxx, the third is FE002xxx even when the three files only have a single record. If the 2048 records per ESL file is based on the final three hex digits being in the 0x800-0xFFF range for the items and all ESLs are loading into slot FE that still leaves the remaining 3 hex digits for the ESL number giving exactly 4096 ESL plugins. Is there yet another quirky game behavior I've missed?
  7. How? The game just does it. And I'm not sure what you mean by hardcoded in that second question. The term master means two different but somewhat related things. There's a master flag bit in the header. The ESP involved in my example doesn't have that set and it doesn't matter whether the ESL does or not. In the past this master flag was what separated the load order into two distinct groups with everything having the master bit getting loaded before anything that didn't have it. The unofficial patch gets classified as a master because of that flag even though it has an ESP extension
  8. I've done some more testing after being pointed here and seeing what you guys have found. The tool we need to be using to look at this issue is the game's built-in mod Load Order screen. It seems that the ESM flag on ESL files really is ignored by the game. I had been testing my load order changes using Bash which was forcing files flagged as masters to load earlier. Without Bash running the master flag on an ESL does absolutely nothing to load order as far as I can determine. I now also confirm reports that all ESLs are loaded with the masters in the order they appear in your plugin
×
×
  • Create New...