modwright 0.1.0

package/knowledge/skyrimse/install.detection.yaml

@@ -0,0 +1,41 @@
+game: skyrimse
+topic: install.detection
+title: Where a Skyrim Special Edition install is recorded, by storefront
+facts:
+  - id: sse.install.detection.epic-manifests
+    claim: "An Epic Games Store install is found through the Epic Games Launcher's own manifests: one
+      `*.item` JSON file per installed app under the launcher data directory's `Manifests` folder,
+      where that directory is the registry value `HKLM\\Software\\Epic Games\\EpicGamesLauncher`
+      `AppDataPath` or, failing that, `%ProgramData%\\Epic\\EpicGamesLauncher\\Data\\`. A manifest
+      whose `AppName` is `ac82db5035584c7f8a2c548d98c86b2c` (Skyrim Special Edition) or
+      `5d600e4f59974aeba0259c7734134e27` (the Anniversary Edition update) names the install folder
+      in `InstallLocation`."
+    status: community
+    source: 'modorganizer-game_gamebryo src/gamebryo/gamegamebryo.cpp
+      `GameGamebryo::parseEpicGamesLocation` (read 2026-09-11): `findInRegistry(HKEY_LOCAL_MACHINE,
+      L"Software\\Epic Games\\EpicGamesLauncher", L"AppDataPath")`, the
+      `getKnownFolderPath(FOLDERID_ProgramData, false) + "\\Epic\\EpicGamesLauncher\\Data\\"`
+      fallback, `manifestDir += "Manifests"`, `QDir epicManifests(manifestDir, "*.item",
+      QDir::SortFlags(QDir::Name | QDir::IgnoreCase), QDir::Files)`, and `manifestJson["AppName"]` /
+      `manifestJson["InstallLocation"]`; the two app ids from modorganizer-game_skyrimse
+      src/gameskyrimse.cpp `GameSkyrimSE::identifyGamePath` ("AppName:
+      ac82db5035584c7f8a2c548d98c86b2c", "AE Update: 5d600e4f59974aeba0259c7734134e27")'
+    tags:
+      - install
+      - detect
+      - epic
+      - storefront
+      - manifest
+    detail: "MO2 reads the manifests only after the Bethesda and GOG registry keys came back empty;
+      ModWright reads them as one more candidate source and lets dedupeByRoot fold duplicates, as
+      every ModWright surface does. SKSE does not support the Epic build (fact
+      sse.skse.runtime.no-microsoft-store-or-epic-support), so an Epic install is detected so that
+      compat can say so, not because modding it is recommended. No real Epic install has been read;
+      the reader is tested against synthetic manifests in the launcher's shape. ModWright also reads
+      the `WOW6432Node` view of the launcher key, which MO2 does not: the launcher's installer is
+      32-bit, and the registry value only matters when the data directory is not the default one the
+      fallback already covers. The Microsoft Store install is still not searched, because neither
+      reference says where to look: MO2 has no Microsoft Store handling at all
+      (`GameSkyrimSE::gameVariants` is `{\"Steam\", \"GOG\", \"Epic Games\"}`), and libloadorder's
+      `is_microsoft_store_install` only recognizes an install it is already given, by
+      `appxmanifest.xml` in the game directory."

package/knowledge/skyrimse/loadorder.files.yaml

@@ -0,0 +1,242 @@
+game: skyrimse
+topic: loadorder.files
+title: Plugins.txt, the asterisk load order system, and what the mod managers do to it
+facts:
+  - id: sse.loadorder.files.asterisk-system
+    claim: 'Skyrim SE uses the "asterisk" load order system: order is the order of lines in Plugins.txt
+      and an entry is active when its line begins with `*`. Skyrim LE used the older textfile system
+      with a separate loadorder.txt; Oblivion and the Fallout 3 era used file timestamps.'
+    status: community
+    source: Ortham/libloadorder src/game_settings.rs, fn load_order_method (SkyrimSE maps to
+      LoadOrderMethod::Asterisk); doc/src/load_order_mechanisms.md
+    tags:
+      - load-order
+      - plugins-txt
+      - asterisk
+      - sse-vs-le
+    detail: The doc's framing of why this matters - "load order position is no longer an intrinsic
+      property of a plugin" - is the reason a Skyrim SE surface must read the order file rather than
+      inspect the Data directory.
+  - id: sse.loadorder.files.plugins-txt-path-is-storefront-dependent
+    claim: Plugins.txt lives under %LOCALAPPDATA% in a folder whose name depends on the storefront -
+      "Skyrim Special Edition" for Steam, "Skyrim Special Edition GOG", "Skyrim Special Edition
+      EPIC" and "Skyrim Special Edition MS" for the others.
+    status: community
+    source: Ortham/libloadorder src/game_settings.rs, fn skyrim_se_appdata_folder_name and fn
+      plugins_file_path; the same names appear in ModOrganizer2/modorganizer-game_skyrimse
+      src/gameskyrimse.cpp (GameSkyrimSE::gameDirectoryName)
+    tags:
+      - load-order
+      - plugins-txt
+      - path
+      - gog
+      - epic
+      - storefront
+    detail: libloadorder and MO2 both detect the storefront by probing the game install directory -
+      Galaxy64.dll means GOG, EOSSDK-Win64-Shipping.dll means Epic, otherwise Steam. The same folder
+      name is used for Documents\My Games\<name>. A surface that hardcodes the Steam name is wrong
+      for three of four storefronts.
+  - id: sse.loadorder.files.plugins-txt-is-windows-1252
+    claim: Plugins.txt is encoded Windows-1252 without a BOM. A plugin filename containing a character
+      outside Windows-1252 cannot be written to it at all.
+    status: community
+    source: Ortham/libloadorder doc/src/active_plugins.md ("Both active plugins files are encoded in
+      Windows-1252 ... some plugins have filenames which cannot be represented in Windows-1252, and
+      so cannot be activated without first renaming them"); src/load_order/mutable.rs
+      read_plugin_names, src/load_order/mod.rs strict_encode
+    tags:
+      - load-order
+      - plugins-txt
+      - encoding
+      - windows-1252
+      - gotcha
+    detail: libloadorder decodes with decode_without_bom_handling_and_without_replacement and encodes
+      with a strict_encode that returns Error::EncodeError rather than writing lossily. Reading the
+      file as UTF-8 mangles non-ASCII mod names.
+  - id: sse.loadorder.files.line-grammar
+    claim: An empty line or a line starting with `#` is ignored. A line starting with `*` names an
+      active plugin, with the filename following the asterisk immediately and no space. Any other
+      line names a plugin that is listed but inactive, which still holds a load order position.
+    status: community
+    source: Ortham/libloadorder src/load_order/asterisk_based.rs, fn plugin_line_mapper and fn save
+    tags:
+      - load-order
+      - plugins-txt
+      - parser
+      - syntax
+    detail: On write, the marker is a bare `*` then the name then a newline; inactive entries get no
+      marker.
+  - id: sse.loadorder.files.duplicate-and-ghost-handling
+    claim: If the same filename appears more than once, the last entry wins. Name matching is
+      case-insensitive and a trailing .ghost suffix is trimmed before comparison.
+    status: community
+    source: Ortham/libloadorder src/load_order/mutable.rs, fn total_insertion_order (comment "If the
+      same filename is listed multiple times, keep the last entry"), which uses UniCase and
+      trim_dot_ghost
+    tags:
+      - load-order
+      - plugins-txt
+      - parser
+      - duplicates
+      - ghost
+  - id: sse.loadorder.files.five-masters-are-implicit-and-absent
+    claim: Skyrim.esm, Update.esm, Dawnguard.esm, HearthFires.esm and Dragonborn.esm are hardcoded to
+      load first and are omitted from Plugins.txt entirely, as is every plugin named in <game
+      dir>\Skyrim.ccc. A reader must synthesise them at the head of the order.
+    status: community
+    source: Ortham/libloadorder src/game_settings.rs SKYRIM_SE_HARDCODED_PLUGINS, fn ccc_file_paths, fn
+      early_loading_plugins, fn implicitly_active_plugins; src/load_order/ asterisk_based.rs fn save
+      ("Skip early loading plugins"); MO2 GameSkyrimSE::primaryPlugins and CCPlugins
+    tags:
+      - load-order
+      - plugins-txt
+      - implicit
+      - creation-club
+      - skyrim-ccc
+      - gotcha
+    detail: Any index computed straight from the file's lines is low by at least five. Creation Club
+      content adds more. libloadorder's own doc states the ordering rule - official Bethesda
+      plugins, DLC and Creation Club plugins "are all hardcoded to always load in a certain order
+      before other plugins".
+  - id: sse.loadorder.files.no-loadorder-txt-for-sse
+    claim: There is no loadorder.txt for Skyrim Special Edition. libloadorder returns a path for it only
+      for Skyrim LE and Oblivion Remastered; a loadorder.txt found alongside an SSE install is a mod
+      manager's own artifact.
+    status: community
+    source: Ortham/libloadorder src/game_settings.rs, fn load_order_path (GameId::SkyrimSE falls into
+      the `_ => None` arm); doc/src/textfile_standard.md ("Unlike the other games, Skyrim (but not
+      the Special Edition) does not define the load order of inactive plugins")
+    tags:
+      - load-order
+      - loadorder-txt
+      - sse-vs-le
+      - gotcha
+  - id: sse.loadorder.files.unlisted-plugins-order-is-synthesized
+    claim: Plugins present on disk but absent from Plugins.txt are appended after every listed one,
+      inactive, ordered by file modification time ascending and, on a tie, by uppercased filename
+      descending. This ordering is libloadorder's synthesis, not game behaviour - the game loads
+      only active plugins and has no opinion about the rest.
+    status: inferred
+    source: Ortham/libloadorder src/load_order/mutable.rs fn total_insertion_order and
+      src/game_settings.rs sort_plugins_dir_entries with its comment, plus the test
+      find_plugins_in_directories_should_sort_files_by_modification_timestamp
+    tags:
+      - load-order
+      - plugins-txt
+      - inactive
+      - synthesis
+      - caveat
+    detail: Marked inferred because the "not game behaviour" half is a reading of what the code is for,
+      not a quoted statement. A tool that reports this ordering must label it as a tool convention
+      or it will be taken for an engine rule.
+  - id: sse.loadorder.files.master-hoisting
+    claim: Master plugins load before non-master plugins, with one exception - a non-master that a
+      master depends on is hoisted to load between that master and the one preceding it.
+    status: community
+    source: Ortham/libloadorder doc/src/load_order_mechanisms.md; implemented as fn hoist_masters in
+      src/load_order/mutable.rs
+    tags:
+      - load-order
+      - masters
+      - hoisting
+  - id: sse.loadorder.files.mo2-profile-owns-the-real-file
+    claim: Under Mod Organizer 2 the authoritative plugins.txt is the one in the active profile
+      directory, which MO2 maps onto the %LOCALAPPDATA% location for the processes it launches. MO2
+      also keeps a loadorder.txt there even though Skyrim SE does not use one.
+    status: community
+    source: ModOrganizer2/modorganizer-game_skyrimse src/gameskyrimse.cpp, GameSkyrimSE::mappings (maps
+      both plugins.txt and loadorder.txt from the profile path to
+      localAppFolder()/gameDirectoryName())
+    tags:
+      - load-order
+      - mo2
+      - profile
+      - plugins-txt
+      - virtual-filesystem
+    detail: A profile directory also holds modlist.txt, lockedorder.txt, archives.txt, settings.ini and
+      initweaks.ini. Editing the %LOCALAPPDATA% copy while MO2 is in use is silently ineffective for
+      an MO2-launched game.
+  - id: sse.loadorder.files.mo2-hides-mods-from-the-real-data-folder
+    claim: Mod Organizer 2 never places mod files in the game's Data folder. It uses USVFS, a user-space
+      virtual file system built on API hooking, so only processes MO2 launches see the merged tree.
+    status: community
+    source: github.com/ModOrganizer2/usvfs README ("aims to allow windows applications to create file or
+      directory links that are visible to only a select set of processes ... by using api hooking");
+      ModOrganizer2/modorganizer wiki "Moving things" FAQ ("Although Mod Organizer makes it look
+      like the files come from the game's Data folder, they're still physically on whatever drive
+      the mods folder is on")
+    tags:
+      - mo2
+      - usvfs
+      - virtual-filesystem
+      - data-folder
+      - gotcha
+    detail: An external inspector reading the real Data folder while MO2 is in use sees the vanilla game
+      and nothing else. The effective tree is mods/<mod name>/ (each mirroring Data),
+      profiles/<profile>/ and overwrite/.
+  - id: sse.loadorder.files.vortex-owns-and-watches-plugins-txt
+    claim: Vortex writes plugins.txt itself, with encoding latin1 and a first line reading "#
+      Automatically generated by Vortex". If that line is missing it logs "plugins file was changed
+      by foreign application" and prompts the user to keep or revert the change.
+    status: community
+    source: Nexus-Mods/Vortex extensions/gamebryo-plugin-management/src/util/PluginPersistor.ts, fn
+      serialize, fn filterFileData and the onFileChanged handler
+    tags:
+      - vortex
+      - plugins-txt
+      - deployment
+      - ownership
+      - gotcha
+    detail: For Skyrim SE, Fallout 4 and Starfield Vortex uses its "fallout4" format - native plugins
+      omitted, enabled ones prefixed `*`. It also writes a loadorder.txt (utf8) that Skyrim SE does
+      not use. An external tool that edits plugins.txt will raise a foreign-application prompt for
+      the user.
+  - id: sse.loadorder.files.vortex-hardlink-deploys-into-data
+    claim: Vortex's default hardlink deployment puts real directory entries in the game's Data folder,
+      indistinguishable from ordinary files. Symlink deployment is explicitly unsupported for every
+      Skyrim variant.
+    status: community
+    source: Nexus-Mods/Vortex wiki "Deployment Methods", sections "Hardlink Deployment" and "Symlink
+      Deployment" (the latter lists Morrowind, Oblivion, Skyrim variants and the Fallout titles as
+      incompatible)
+    tags:
+      - vortex
+      - deployment
+      - hardlink
+      - data-folder
+    detail: This is the opposite of MO2 - under Vortex, reading the real Data folder shows the full
+      deployed mod set. Vortex records what it deployed in vortex.deployment.json, written into the
+      deploy path with a backup copy in the staging folder.
+  - id: sse.loadorder.files.loot-cli-can-sort-unattended
+    claim: LOOT can sort and apply a load order without interaction using `LOOT.exe --game="Skyrim
+      Special Edition" --auto-sort`. The --game value is case sensitive and is the game's LOOT
+      folder name, and --auto-sort requires it.
+    status: community
+    source: loot/loot docs/app/usage/initialisation.rst, section "Initialisation" ("automatically sort
+      the load order, apply the sorted load order, then quit")
+    tags:
+      - loot
+      - cli
+      - sorting
+      - unattended
+      - toolchain
+    detail: MO2 registers exactly this argument for its bundled LOOT. It is still the GUI binary, there
+      is no headless build, and the process exit code on failure is not documented. Sorting fails
+      outright on a cyclic interaction.
+  - id: sse.loadorder.files.loot-masterlist-paths
+    claim: LOOT keeps its data under %LOCALAPPDATA%\LOOT, with per-game files in games\<folder name>\.
+      Skyrim SE's default folder name is "Skyrim Special Edition" and its masterlist is fetched from
+      https://raw.githubusercontent.com/loot/skyrimse/v0.29/masterlist.yaml.
+    status: community
+    source: loot/loot src/gui/state/loot_paths.cpp getDataPath; src/gui/state/game/game.cpp
+      getLOOTGamePath; src/gui/state/game/game_id.cpp getDefaultLootFolderName;
+      src/gui/state/game/game_settings.cpp getDefaultMasterlistRepositoryName and
+      getDefaultMasterlistUrl with DEFAULT_MASTERLIST_BRANCH = "v0.29"
+    tags:
+      - loot
+      - masterlist
+      - path
+      - url
+    detail: The per-game folder name is user-configurable and differs between two installs of the same
+      game, so an external tool should read %LOCALAPPDATA%\LOOT\settings.toml rather than hardcode
+      it. The branch in the URL is LOOT's metadata-syntax version, bumped per release.

package/knowledge/skyrimse/plugins.esl.yaml

@@ -0,0 +1,189 @@
+game: skyrimse
+topic: plugins.esl
+title: Light plugins (ESL) — the flag, the FormID ranges, HEDR 1.71, and the load limits
+facts:
+  - id: sse.plugins.esl.flag-is-bit-9-of-the-tes4-header
+    claim: A plugin is light when bit 9 (0x00000200) of its TES4 record header flags is set. The flag is
+      Skyrim-SE-only — xEdit declares it as IsSSE('ESL','') and no earlier game has it.
+    status: community
+    source: TES5Edit wbDefinitionsTES5.pas, wbRecord(TES4, 'Main File Header', ...) flag list;
+      en.uesp.net "Skyrim Mod:Mod File Format/TES4" lead ("if set, the file is treated as a light
+      master")
+    tags:
+      - esl
+      - light-plugin
+      - flags
+      - tes4
+      - parser
+  - id: sse.plugins.esl.extension-does-not-determine-lightness
+    claim: Lightness cannot be decided from the file extension. An .esl is always light because the
+      extension forces the flag, but an .esp with the light flag set is also light, and it counts
+      against the 4096 light budget rather than the 255 full one.
+    status: community
+    source: libloadorder doc/src/plugin_types.md, "Skyrim Special Edition, Skyrim VR, Fallout 4, Fallout
+      4 VR" ("A plugin is a light non-master plugin if its file extension is .esp and it has its
+      light plugin flag set"); Wrye Bash skyrimse/__init__.py extension_forces_flags = True; xEdit
+      whatsnew.md "the .esl extension which implicitly always sets the ESL flag"
+    tags:
+      - esl
+      - light-plugin
+      - extension
+      - gotcha
+      - load-order
+      - counting
+    detail: Any tool that classifies plugins by extension will miscount the caps. esplugin's own test is
+      `self.is_light_flag_set() || self.file_extension() == FileExtension::Esl`.
+  - id: sse.plugins.esl.fe-space-is-twelve-plus-twelve-bits
+    claim: "Light plugins load into the 0xFE mod-index slot, and their FormIDs are mapped into the FExxx
+      space: 12 bits of light index (4096 slots) and 12 bits of object id (4096 objects per light
+      plugin)."
+    status: community
+    source: TES5Edit whatsnew.md, "What's new in xEdit 4.0.0? > ESL support" ("up to 253 'full' modules
+      (00 to FD) and 4096 'light' modules (FE000 to FEFFF) loaded at the same time")
+    tags:
+      - esl
+      - formid
+      - fe-space
+      - load-order
+      - limits
+    detail: esplugin's mask constant for the same space is small_mask = 0xFE00_0000.
+  - id: sse.plugins.esl.formid-prefix-is-not-load-order
+    claim: The leading digits of a FormID can no longer be used to infer load order. Light modules can
+      load before full modules; they merely occupy the FE index at runtime.
+    status: community
+    source: TES5Edit whatsnew.md, "ESL support" ("the first digits of the FormID are NOT a reliable way
+      to determine load order anymore"); loot.github.io "Introduction To Load Orders" (light plugins
+      "are listed as position FE, but actually load in the position dictated by the load order")
+    tags:
+      - esl
+      - formid
+      - load-order
+      - gotcha
+    detail: The order file is authoritative for position; the FormID prefix is not. A load-order report
+      must take its ordering from Plugins.txt, never from FormIDs.
+  - id: sse.plugins.esl.hedr-1-71-unlocks-the-expanded-range
+    claim: HEDR version 1.71 is what signals the expanded light-plugin object-index range introduced in
+      Skyrim SE 1.6.1130. Below 1.71 a light plugin's new records must have object indices in
+      0x800-0xFFF; at 1.71 and above the range opens downward.
+    status: community
+    source: libloot changelog 0.22.3 (2023-12-06) ("the extended FormID range introduced in Skyrim SE
+      v1.6.1130.0 for light plugins with a header version of 1.71. Via esplugin"); Ortham/esplugin
+      src/plugin.rs valid_light_form_id_range; Wrye Bash skyrimse/__init__.py
+      object_index_range_expansion_ver = 1.71
+    tags:
+      - esl
+      - hedr
+      - formid
+      - 1-6-1130
+      - version
+    detail: esplugin's code reads `Some(v) if v < 1.71 => 0x800..=0xFFF, Some(_) => 0..=0xFFF`. Before
+      the change the reserved range 0x0000-0x07FF gave light plugins a 2048-record limit; after it,
+      4096.
+  - id: sse.plugins.esl.expanded-floor-is-disputed
+    claim: Sources disagree on the expanded range's lower bound. esplugin's code and Wrye Bash's
+      docstring put it at 0x000; xEdit's release notes write it as 001-7FF. Wrye Bash also requires
+      the plugin to have at least one master for the expansion to apply, a condition neither of the
+      others states.
+    status: community
+    source: Ortham/esplugin src/plugin.rs (0..=0xFFF); Wrye Bash Mopy/bash/game/__init__.py
+      ObjectIndexRange docstring ("EXPANDED_CONDITIONAL ... and at least one master can use the
+      range 0x000-0x7FF"); TES5Edit whatsnew.md 4.1.5b ("Extended FormID Range (001-7FF)")
+    tags:
+      - esl
+      - formid
+      - disputed
+      - validator
+      - open-question
+    detail: A validator should use 0x001 as the floor, which is the conservative reading and cannot
+      produce a false failure against either source. Settling it needs a real 1.6.1130+ install and
+      a look at what _ResourcePack.esl actually contains.
+  - id: sse.plugins.esl.validity-counts-new-records-only
+    claim: A plugin is ESL-flag-safe when every NEW record's FormID object index falls in the valid
+      range. Records that merely override a master's forms are exempt, however high their object
+      index.
+    status: community
+    source: libloot changelog 0.14.0 (2018-12-09) ("Validity is defined as having no new records with a
+      FormID object index greater than 0xFFF"); Ortham/esplugin src/plugin.rs
+      is_valid_as_light_plugin, which filters on !f.is_overridden_record()
+    tags:
+      - esl
+      - validation
+      - formid
+      - override
+      - validator
+    detail: "esplugin's tests make the asymmetry explicit: an override outside the range keeps the
+      plugin valid, a new FormID above 0xFFF does not. Wrye Bash's user-facing message for the
+      failure is \"This plugin contains records with FormIDs greater than 0xFFF.\""
+  - id: sse.plugins.esl.masters-at-1-71-force-the-plugin-to-1-71
+    claim: A plugin whose masters carry header version 1.71 should itself be 1.71, or referencing or
+      overriding any record whose FormID falls in the extended range produces errors.
+    status: community
+    source: TES5Edit whatsnew.md 4.1.5b, "Extended FormID Range in Skyrim Special Edition", the
+      "Important" note
+    tags:
+      - esl
+      - hedr
+      - masters
+      - version
+      - validator
+  - id: sse.plugins.esl.1-71-plugins-crash-old-game-builds
+    claim: The December 5 2023 Creations update incremented plugin header versions from 1.70 to 1.71 in
+      order to raise a light plugin's new-record maximum from 2048 to 4096. Using a 1.71 plugin on
+      an older game build will likely crash.
+    status: community
+    source: github.com/Nukem9/skyrimse-backported-esl-support README, section "Purpose"
+    tags:
+      - esl
+      - hedr
+      - 1-6-1130
+      - crash
+      - compatibility
+      - creations-update
+    detail: Verbatim - "Attempting to use a version 1.71 plugin on an old game build will likely crash."
+      This is why a HEDR-version check against the installed runtime deserves a blocking severity
+      rather than a warning.
+  - id: sse.plugins.esl.active-full-limit-drops-to-254
+    claim: The active full-plugin limit is 255 when no light plugin is active and 254 once one is,
+      because the FE index is carved out of the full space. Light plugins have their own separate
+      limit of 4096 active.
+    status: inferred
+    source: Ortham/libloadorder src/load_order/mutable.rs max_active_full_plugins (255 / 254 / 253
+      branches) and src/load_order/writable.rs MAX_ACTIVE_LIGHT_PLUGINS = 4096, with the tests
+      activate_should_lower_the_full_plugin_limit_if_a_light_plugin_is_present
+    tags:
+      - esl
+      - limits
+      - load-order
+      - counting
+      - disputed
+    detail: Marked inferred because libloadorder's own prose contradicts its code - the docs say light
+      plugins "do not count towards the 255 active plugin limit" while the code demonstrably lowers
+      the cap. The code and its tests are the stronger evidence. The 253 figure that also appears is
+      the master-list limit, not the active limit.
+  - id: sse.plugins.esl.master-list-limit-is-253
+    claim: A Skyrim SE plugin may list at most 253 masters, not 255, because the FE slot is reserved for
+      light plugins inside master lists as well as in the load order.
+    status: community
+    source: Wrye Bash Mopy/bash/game/skyrimse/__init__.py, master_limit = 253 with the comment "Because
+      the FE slot is reserved for ESLs - yes, including in master lists"; the base
+      Mopy/bash/game/__init__.py has master_limit = 255
+    tags:
+      - esl
+      - masters
+      - limits
+      - validator
+  - id: sse.plugins.esl.compact-formids-is-the-fix
+    claim: xEdit's "Compact FormIDs for ESL" function renumbers a plugin's new records into the valid
+      light range; from xEdit 4.0.3 an expert option extends the target space to 001-FFF instead of
+      800-FFF.
+    status: community
+    source: TES5Edit whatsnew.md, "What's new in xEdit 4.0.0? > Compact FormIDs for ESL" and "What's new
+      in xEdit 4.0.3? > Minor changes"
+    tags:
+      - esl
+      - xedit
+      - compact
+      - tooling
+      - remediation
+    detail: xEdit refuses to save a plugin with the ESL flag set when it contains new records with an
+      ObjectID above $FFF, and warns when loading an incorrectly flagged module.