Releases: SenjuWoo/FollowerForge
Release list
FollowerForge 3.7.0 — she can be a dragon now
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
FollowerForge 3.6.1 — you can unselect things now
Patch release on top of 3.6.0.
You can unselect things now
Reported by a user who added the wrong clothing, hit a must-fix build, went back to undo it — and found no way to.
- Clear button beside every optional picker: all seven armor slots, weapons, ammo, belongings, spells, perks, plus the single choices (face, combat style, legacy outfit, body, transform race/spell). Clearing one armor slot leaves the others alone. Race, voice, class and location have no Clear — they always need a value.
- Clear selection in the Expert Deck, and the deck now states how selection works: click a row to select, Ctrl+click to add or remove.
- The deck's tick column was headed "Selected" inside a read-only grid, so it looked like the control for selection and could never be clicked. It is now "In cart" — it reports state, it is not a button.
Root cause: "Remove selected" existed on Kin and custom lines and nowhere else, which taught people to look for a button 18 other pickers did not have. Click-again-to-deselect worked on the multi-select lists all along, but nothing said so.
Copy diagnostics
One button on the Review page (and in the Ctrl+K palette) puts a short plain-text report on your clipboard: manager and profile, how much was indexed, what you picked, and the last build's findings. Paste it into a bug report and it can usually be answered without a round-trip first.
Home folders are written as %USERPROFILE% / %LOCALAPPDATA%, so a report pasted into a public comment does not publish your Windows account name. A test asserts that.
Also fixed
- Windows narrower than ~1180px clipped the right-hand side of every page. The dossier hid itself but its 312px column did not shrink, so pages were measured 312px narrower than the window with no horizontal scroll to reach the rest.
- The build action row wraps instead of pushing a button off the edge.
- CI asked for the .NET 9 SDK for net10.0 projects — green only because the runner image preinstalls .NET 10, plus a 298 MB download every run.
Still not fixed
RaceMenu overlays (tattoos, warpaint, body paint) do not transfer to a built follower. Sculpt, tint and head shape do. A build-time warning for this is next.
478 tests. Built from f009a21; SHA-256 of the attached zip: EB48F7867CA19167E2A6720BECED21DF6B32DC5D58AF8860B3AF81F8F60695C6
FollowerForge 3.6.0 — Studio, Focus Cards, Expert Deck
The old seven-step tab wizard is gone. 3.6.0 is one Studio workspace: a dashboard, seven Focus categories, and an Expert Deck for installed-record catalogues.
3.4.0 / 3.5.0 behavior is still in (Paths, pronouns, gear FormIDs, werewolf revert after combat). Rebuild werewolf followers on the 3.5.0 script if you have not already.
Workspace
- Studio shows category readiness and the next useful action. An unfinished draft is not painted as broken: a missing name needs attention, empty loadout stays optional, Review only turns red after a failed build or a real setup problem.
- Seven categories, no nested tabs.
- Expert Deck searches name, EditorID, FormID, and plugin. Apply only replaces the family that deck showed, so armor slots and belongings slices no longer wipe each other.
- Guided / Expert (
Ctrl+E). Expert opens the primary catalogue. It does not hide fields. - Command palette (
Ctrl+K): jump categories, Build, Paths, MO2 setup, switch manager. Enter runs the highlighted command. - Five themes. Theme, experience, and window size live under
%LOCALAPPDATA%\FollowerForge, separate from follower profiles. Ctrl+0–Ctrl+7jumps categories. Escape only closes an open overlay.
Install
Extract FollowerForge-3.6.0-win-x64.zip anywhere outside Skyrim Data. Run FollowerForge.exe. Self-contained; no separate .NET install.
Verify
- CI: 461 tests passed on
FollowerForge 3.6.0(net10.0). - Local publish boot check: window stayed up.
- SHA-256
3EFA07D9FA98B2E955C8D67311E63D278626E72356797D56F2BF830AA7345CFD
Not claimed: a full real-user click-through of every catalogue, or a new in-game werewolf confirmation on this build.
FollowerForge 3.6.0 Preview — redesigned Studio UI
FollowerForge 3.6.0 — Preview (test build)
This is a PRERELEASE for UI testing. The redesigned interface has passed the
automated Release build, the 456-test regression suite, and a desktop boot gate —
but it has not been exercised in a real Skyrim build workflow yet. Please test
the new UI and report anything that feels wrong. The old 3.5.0 layout is preserved
in git; this preview can be rolled back.
What's new
- Studio dashboard replaces the old seven-step tab wizard: category overview, readiness,
environment status, and a follower dossier. - Focus Cards — the default editing surface for ordinary, bounded decisions.
- Expert Deck — a searchable installed-record browser with filters, FormIDs, multi-select,
an inspector, and a selection cart for dense catalogues (race, voice, class, locations, gear, ...). - Guided and Expert modes — Expert mode opens the full record catalogues without hiding
advanced controls. - Five themes: Obsidian Gold (default), Arcane Amethyst, Nordic Frost, Forge Teal, and Light.
- Ctrl+K command palette and Ctrl+0..7 navigation; UI preferences persist separately
from follower profiles and mod-manager settings. - Responsive dossier and full-window-width layout on large displays.
Fixes in the redesign
- Opening a single-choice catalogue (race, voice, class, locations, friends) no longer
crashes the app (InvalidOperationException— selection was synced viaSelectedItems,
which Avalonia only allows in Extended mode; sync is now selection-mode aware). - Light theme fixed (window variant follows the palette; default buttons previously rendered
white-on-cream). - Badge chips and setup windows follow the selected theme live; warning/error colours are
now visibly distinct per theme. - Overlays are fully opaque; sidebar labels no longer ghost through; lists size to content.
Preserved
- Every 3.5.0 follower-building field, the ESPFE/plugin build pipeline, CLI, native
dependencies, MO2/Vortex discovery, paths, FaceGen, dialogue, transformations, profile
JSON, and output safety — unchanged.
Validation status
- Automated: Release build passed · 456 tests passed · migration ledger · archive inspection
· desktop boot gate (published exe stays up). - Screenshot baseline captured for all five themes at 1440p.
- Not yet confirmed: end-to-end follower build in a real Skyrim install — that's what
this preview is for.
Files
FollowerForge-3.6.0-win-x64.zip(self-contained — no .NET needed)
FollowerForge 3.5.0 — werewolf revert, paths, pronouns, gear FormIDs
Two versions ship here: 3.4.0 (the three things a user reported against 3.3.0) and 3.5.0 (the werewolf bug that came in while 3.4.0 was being built). Both were written against the same session's test run, so they went out as one release.
Manual paths
3.3.0 only looked for xVASynth in C:\Program Files (x86)\Steam\steamapps\common\xVASynth, and built followers only ever landed under %LocalAppData%. Both are now fixable:
- Paths… button in the sidebar. Set the xVASynth folder and a custom output folder; both persist in
LocalAppData\FollowerForge\app-settings.json. Leave a box empty and automatic detection still applies. - xVASynth discovery now scans every Steam library folder the way the game-root finder already did, not just the default C: location.
FFORGE_XVASYNTHenv var and the CLI--xvasynthflag still win. - Custom output writes each follower as a subfolder of the chosen path, so pointing it at a Vortex or MO2 mods folder gives you one installable mod per follower. Staging stays under LocalAppData; the game's own
Datafolder and saves stay blocked. Default layout is unchanged.
Pronouns follow the follower
The Sex box on step 1 was asked but never used. The wizard now switches every she/her, her, his/hers, herself/himself across the rail, headings, hints, combo items and the build log to match. Female keeps the existing she/her copy; male gets the he/him equivalent.
Gear FormIDs
Armor, weapons, ammo, belongings and body-skin rows now show the catalogue FormID (XXXXXX:Plugin.esp) and EditorID when it differs from the display name. Identically named variants (Makeshift Eyeglasses…) can finally be told apart before building, and the search box matches FormIDs and plugin names too.
3.5.0 — werewolf revert after combat
Reported while 3.4.0 was in test: the werewolf option did not revert once the battle ended.
Root cause, read from Skyrim.esm and the vanilla source rather than guessed: WerewolfChangeFX ("Beast Form", 0F8208) runs WerewolfTransformVisual.psc, which does Utility.Wait(10) and then SetRace(Werewolf) on the target. FollowerForge cast that spell and did its own SetRace; on combat end Revert() switched the race back — and ten seconds later the vanilla visual script switched them right back to a wolf. A short fight could also end during the 2-second delay, so the transform finished after combat.
Fix:
- Werewolf no longer casts
WerewolfChangeFXat all; the race swap isSetRaceonly. - After the delay,
GetCombatState() == 0aborts, so the transform cannot complete after the fight. - The original race is stored and used for revert (with
SetRace()as fallback). - An
OnUpdatebackup covers the case where the engine never delivers combat-state 0. OnLoadundoes a leftover beast form, so a save made mid-transform cannot stick.
Rebuild the follower for the new script to apply; existing saves with a stuck-werewolf follower revert on load once the updated mod is installed.
Verify
- 388 tests pass (367 from 3.3.0 + 19 new for paths/pronouns/FormIDs + 2 new for the werewolf fix; one old assertion inverted because the old FX attachment is exactly what was wrong).
- Published exe passed the boot check before zipping.
FollowerForge-3.5.0-win-x64.zipSHA-256:68B381D2AD35A92672DBA8BD9E4B6EF08A7E6C28C6C08CBC3F295FC12CB7648D
FollowerForge 3.3.0 — arrows, stack counts, honest names
Four things were reported against 3.2.9. Two were real and total, one was half right, one was not us.
Arrows and bolts
IndexedRecordType had no Ammo member at all — AMMO records were never indexed, so arrows could not be picked, validated, or written. A bow follower was a follower with a stick.
Now indexed, with an Arrows & bolts tab in step 5 and a stack-count spinner (default 100).
Ammo goes in inventory only, deliberately. Checked against Faendal (013480:Skyrim.esm), the game's own archer follower: he carries Steel Arrow (01397F) in Items with a clothes-only outfit, and a query for vanilla outfits referencing that arrow returns zero. An earlier attempt to also write ammo into the generated outfit was removed rather than shipped.
Item stack counts
RecordRef gained an optional Count (default 1, so older profile JSON loads unchanged). The compiler had Count = 1 hardcoded. Belongings get their own count spinner; 0 or negative clamps to 1 instead of writing an empty stack.
Non-English letters — half right
Measured, not guessed:
| input | written bytes | result |
|---|---|---|
Ëlïna Ökÿ |
cb 6c ef 6e 61 20 d6 6b ff |
already correct (valid Windows-1252) |
Ζωή Аня |
3f 3f 3f 3f 3f 3f |
literal ? |
A plugin stores one single-byte codepage, so Cyrillic, Greek and CJK cannot survive; writing cp1251 instead would just move the breakage onto everyone whose game is not Russian. New NAME_CHARACTERS_LOST warning names the exact characters that will be lost. No per-language encoding support, by choice.
Body/face colour — not a 3.2.9 regression
Diffed 3.2.7 → 3.2.9 across the whole tree. The only compiler changes are cell placement, worldspace and FormVersion 44. Nothing in the face, tint, QNAM/TextureLighting, HeadTexture or skin path was touched. This is the pre-existing tone behaviour: a preset with a non-neutral SkinTone tints the head while the body keeps whatever skin the player installed. Diagnosing it needs the reporter's preset and a screenshot.
Also fixed
fforge indexno longer dies on a damaged cache. It quarantined and rebuilt in the wizard but threwSqliteExceptionin the CLI — so the one command that repairs the catalogue was the one command a corrupt catalogue could brick. Hit for real while testing this release.- Catalogue
index_version. A catalogue built by an earlier version is now stale, so existing users pick up the Ammo records automatically instead of opening an empty arrows list.
Verified
367 tests pass. Built with the published CLI and read back with houseCARL:
Items[2].Item.Item = 01397F:Skyrim.esm (SteelArrow) Count = 100
Items[0].Item.Count = 5
DefaultOutfit contains no ammo
check_errors: 0 dangling refs, 0 missing masters
🤖 Generated with Claude Code
FollowerForge 3.2.9 — anthro races, manual placement, cell FormVersion
Builds on 3.2.8. Fixes reported from a long CLI + MO2 session building custom anthro followers (BD Ungulate / BD Cat Races).
Fixed
- Playable races are no longer misread as creatures. A race with real FaceGen head data was forced to "Creature" just because its EditorID contained a word like
horse(e.g.BDHorseRace). - Manual placement respects the cell you gave it.
Placement.Cell+ X/Y/Z no longer ignores the cell and hardcodes WhiterunWorld. An optionalPlacement.Worldspacefield handles exterior worldspace-persistent cells. - Cell overrides force FormVersion 44, so the ship gate no longer fails on copied
Skyrim.esmcells that still carried formVersion 40.
Known, not fixed
- RaceMenu body overlays. The jslot data is parsed, but nothing calls
NiOverride.AddOverlaysand there is no bake path, so overlays stay invisible in game. Listed here rather than quietly claimed as working.
Update
Close FollowerForge, replace the folder with this build, re-index MO2 if prompted, rebuild. FollowerForge never writes into MO2 mods, profiles, or Skyrim Data.
357 tests pass. SHA-256 C7EA9E121910700E4603FD832200CDA3A9C03E6DF8008698DD5CD85E50C0D49F
FollowerForge 3.2.8 — MO2 builds find their masters
Builds under Mod Organizer 2 still looked for plugin masters (e.g. SOSVoices.esm) only in the Steam game Data folder. MO2 never puts them there — they live in enabled mod folders — so the build failed with:
Build failed: Required master 'SOSVoices.esm' is not installed in
'...\Skyrim Special Edition\Data'.
Fixed
ExpandMasterChainusesPluginDataPath(the FollowerForge hardlink plugin view) under MO2, afterMo2DataView.Ensure.ValidateInstalledMastersresolves masters through MO2 mod priority, not only gameData.RecordResolver/CellSourceResolveropen plugins from the same MO2 plugin view.- CharGen discovery during a build uses the MO2-aware scanner when the manager is MO2.
Vortex paths and behaviour are unchanged — PluginDataPath still equals GameDataPath.
Rollback: reinstall 3.2.7. MO2 settings under LocalAppData\FollowerForge are unchanged.
FollowerForge 3.2.7 — reliable MO2 instance and profile indexing
FollowerForge 3.2.7
- Added an MO2 setup window where you can browse to the exact ModOrganizer.ini and choose the profile FollowerForge should index.
- Fixed MO2 custom paths that use %BASE_DIR% or paths relative to the MO2 base directory.
- Your manual instance/profile choice is remembered and can be reset to automatic detection at any time.
- Manual choices now fail with the exact bad path instead of silently indexing a different profile or falling back to Vortex.
- Switching MO2 settings cancels the stale scan before re-indexing the selected profile.
- The catalogue cache now includes the exact MO2 profile and instance, so switching profiles cannot reuse another profile's index.
- Vortex behavior is unchanged.
MO2 users: after updating, click "MO2 setup..." once if automatic detection does not find the right instance/profile.
FollowerForge 3.2.6 — fixes a broken faction on every follower ever built
Rebuild your followers
PlayerFaction was written as 0x0000DB. The real FormID is 0x000DB1.
Every follower FollowerForge has ever built carries a link to a record that does not exist, and none of them are actually in the player faction. It compiles, validates and ships clean — the only way to see it is to resolve the link against the game.
If you have already released a follower built with an older version, rebuild and reupload it. Existing saves are not damaged (the engine ignores the dead link), but xEdit's error check flags it.
before: 1 dangling ref 000800:FF_VeraForge.esp -> 0000DB:Skyrim.esm
after: 0 dangling refs, 0 missing masters, 0 unscannable records
How it was found
By validating built output rather than reading code: two followers were compiled with the CLI and swept with houseCARL's load-order integrity check.
The design was already right — Lydia (HousecarlWhiterun 0A2C8E:Skyrim.esm) has 000DB1 as Factions[0], so vanilla followers do carry the player faction. Only the digits were wrong.
All 28 hardcoded vanilla FormIDs were then read back out of Skyrim.esm and matched to their EditorIDs. Only this one was wrong. VanillaFormIdTests pins them so a typo cannot slip back in.
Also in this release (from 3.2.5)
- Body tab in step 5: pick the skin ARMO she wears, or leave it empty (default) so she uses the player's installed body — what OBody needs to reshape her. It's a FormID reference, so asset-hub bodies cost no storage.
BODY_PINNEDnote warns that pinning makes that mod a hard requirement. - Skyrim is found on any drive. The old code checked one hardcoded C: Steam path.
GameRootResolvernow searches every fixed drive and every library insteamapps/libraryfolders.vdf. - Portable MO2 instances are found — previously only
%LOCALAPPDATA%\ModOrganizerwas checked, so the common setup was never detected.
325 tests pass. SHA-256 09C0426E50C2C0FE9C2D76ACC98A1E240E4CC61FE5A393A3368609CFDB5ABD12
🤖 Generated with Claude Code