Starfield Toolkit

A Windows GUI for managing Bethesda Creations — load order, updates, rule books, and Fast Lane compatibility, without ever touching your game files.

Sorter priority

Which sorter's opinion wins when two disagree, and why the priority numbers are what they are.

The hierarchy

SorterPriorityNatureSource of truth
TES4 masters100Hard, non-bypassablePlugin headers on disk
Rule books — user40+Targeted fixesYour JSON files
Rule books — curated30Targeted fixes, shippedBundled JSON files
LOOT20Curated community listCommunity YAML (GitHub)
Categories10Heuristic baselineBethesda API categories

Higher numbers win. If two constraints touch the same pair of creations, the one from the higher-priority source wins outright; the loser is recorded and shown in the Hint dialog.

Why TES4 is at 100

TES4 master dependencies are engine-enforced: if creation B lists creation A as a master and A is loaded after B, the game will either fail to load or behave unpredictably. The toolkit treats TES4 as a hard gate — not only does its priority beat every other sorter, but a proposal that violates it is refused at Apply time. Everything else is advisory; TES4 is law.

Why rule books outrank LOOT and Categories

Rule books exist precisely to fix the cases where Categories tiers a creation wrongly or where the LOOT Starfield masterlist hasn't caught up. Starfield is young, LOOT coverage is still evolving, and the category mapping is a blunt instrument — so a rule book entry is almost always a deliberate correction of one of those two sources. If rule books sat below them, a small, targeted re-tier (e.g. the curated single-rule book re-tiering PDY) would silently lose to the very sorter it was meant to override. Putting rule books above LOOT and Categories makes the override work without special-casing.

Within rule books there is a second-tier priority: user rule books beat curated ones, and later user rule books beat earlier ones. So your rule always wins against a canned one.

Soft vs hard constraints

tier(X, N) is a soft constraint: it asserts where X belongs in the category system, but a matching-priority load_after overrides it. This is what lets a rule book say "load X after Y" without you also having to re-declare X's tier — the category system's opinion is used for everything else and gently displaced where it conflicts.

What this means for the diff

Every moved item in the Diff dialog is tagged with the source that "won" it. If you see lots of TES4 tags, your current order has unresolved master dependencies (serious). If you see lots of LOOT, the community masterlist has opinions about your library. If you see mostly Categories, you're in the soft-constraint regime — and rule books give you a place to tune.