TES4 masters

The highest-priority, non-bypassable sorter. Reads the binary plugin header and enforces master dependencies.

Background

Every Bethesda plugin file (.esm, .esp) starts with a TES4 record — a fixed header that identifies the plugin and lists its masters: plugins this one depends on. Masters must load before their dependents. This is a rule of the game engine, not an advisory convention.

MAST subrecords

Inside the TES4 record, each master is listed as a MAST subrecord containing the master plugin's filename (followed by a DATA subrecord the toolkit ignores). The parser walks only far enough into the file to extract these — it does not load any other records, so the operation is fast even on large ESMs.

Base-game masters are filtered out:

• Starfield.esm
• Constellation.esm
• OldMars.esm
• SFBGS*.esm (Bethesda Game Studios DLC-style masters)
• ShatteredSpace.esm

These are engine-guaranteed to load before any Creation, so emitting constraints about them would just be noise.

Constraint emission

For every non-base master, the sorter emits load_after(dependent, master) at priority 100. The constraint is hard: it wins over every other source.

Validation on Apply

Because you can reject moves individually in the Diff dialog, the final ordering you submit may differ from what Auto-Sort proposed. Before writing Plugins.txt, the tool re-runs the TES4 check on the accepted order. If any master dependency is violated, the Apply is refused and the offending pair is highlighted. There is no opt-out. The cost of a broken load order is much higher than the annoyance of re-approving.

Parser notes

The parser is strictly read-only and operates on a small prefix of the file. Corrupted headers are reported but do not crash the sort — the affected creation is flagged and sorted by Categories only. Compressed TES4 records (rare but legal) are decompressed in-memory.