Your follower can turn into a creature now — and the build stops refusing a combination it always supported.
She can be a dragon
Combat transformation had been quietly filtering out every creature race, which left "custom race / spell" offering only the same people-races she could already be. Dragons, wolves, trolls, spriggans — none of them were reachable.
The filter was in the wrong place. Creature races are hidden from the identity picker because they carry no head data, so no face can be built for one. That constrains the race she is. It says nothing about the race she turns into: the face belongs to her base race, and FF_Transform only calls SetRace() once a fight starts. Vanilla werewolf, which this feature already offered, is itself classified as a creature.
On a live 2,920-plugin catalogue that is 191 races before and 944 after.
Four call sites fed that list and had drifted apart — the focus card, its search box, the Expert Deck, and selection restore. They now share one source, creatures first. Creature rows carry FormID + EditorID, because five installed mods each ship something called BabyDragonRace.
The real cause of the "Must be fixed" report
3.6.1 fixed the symptom a user reported — nothing could be unselected — but only guessed at the error that trapped them. This is the actual cause.
Choosing any armour together with a legacy outfit was a guaranteed hard build failure, one error per piece, every time. FollowerCompiler branches: a chosen OTFT wins outright, and only otherwise is a private StartingEquipment outfit generated. FollowerValidator ran the generated-outfit check unconditionally — searched the freshly written plugin for an outfit that lives in Skyrim.esm, found nothing, and called every piece missing.
The validator now mirrors the branch, and the combination is one warning naming the outfit instead of two vague ones. LEGACY_OUTFIT_WITH_EQUIPMENT said the engine "may choose" the outfit over inventory gear; it does choose it, so that warning is gone.
The body shape that never came across
A RaceMenu preset can carry a whole body in its bodyMorphs block — OBody and BodySlide write their sliders there. A plugin has nowhere to store it: an NPC record holds head data, not a body. It has always been dropped silently.
The build now counts the sliders you actually shaped and points at BodySlide or OBody. Untouched sliders are excluded, because RaceMenu writes the whole set whether it was used or not (a reference preset here holds 119 entries, of which 86 are shaped) — counting them all would warn on every build. The same warning names RaceMenu overlays, which do not transfer either.
Verification
- 489 Release tests pass (478 inherited + 11 new), green in CI on this exact commit
- End-to-end CLI build of the reported combination — legacy outfit + two armour pieces + a creature transform race — is BUILD OK with one warning and no errors
- The published plugin's VMAD carries
BeastRace = 0x000CDD84at master index 0; ship gate readsHEDR=1.71 numRecords=11 formVersion=44 ESL=True - Race counts read from the live catalogue on a real machine, not from fixtures
Not confirmed: a creature transform surviving a real fight in game. SetRace() on a follower is engine behaviour this build cannot exercise — the plugin side is verified byte for byte, the gameplay side is not.
Still open: RaceMenu overlays cannot be detected here. Neither reference preset carries an overlay block, so the key name is unconfirmed and was not guessed.
Download
FollowerForge-3.7.0-win-x64.zip — self-contained, no .NET install required.
Size : 99,252,454 bytes
SHA-256 : A2A1A0675F6DB84D8D7E5E12E3ABD8FEC74DF48813C705A91E627F8BBA3FA55E
Built : 3.7.0+eb4c2deb200f6d5a5ce31babe019397f401a2080
FollowerForge is a Windows application, not a Skyrim mod. Do not install it into Skyrim Data, Vortex, or MO2 as game content.
🤖 Generated with Claude Code