modwright 0.1.0

package/knowledge/baldursgate3/progressions.yaml

@@ -0,0 +1,92 @@
+game: baldursgate3
+topic: progressions
+title: Class progressions, retroactive grants, and progression descriptions
+facts:
+  - id: bg3.progressions.structure
+    claim: Class/subclass tables are <node id="Progression"> rows keyed by Level + TableUUID, granting
+      via Selectors (AddSpells/SelectSpells/SelectSkills/SelectAbilityBonus) and
+      PassivesAdded/PassivesRemoved/Boosts. They live in Public/<Mod>/Progressions/Progressions.lsx.
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - progressions
+      - class
+      - structure
+      - lsx
+    detail: Progressions/ClassDescriptions .lsx are read at session load only — reload to the main menu
+      or a fresh save, never mid-session.
+  - id: bg3.progressions.not-retroactive
+    claim: Progression grants are NOT retroactive. Adding a feature/spell at level N does not appear on
+      a character already past N without a respec (Withers). Test level-gated additions on a fresh
+      character leveled up, or respec.
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - progressions
+      - retroactive
+      - respec
+      - testing
+    detail: A common source of "my feature isn't showing" on existing saves. Every testing checklist in
+      a class mod repeats it.
+  - id: bg3.progressions.class-anchor-description
+    claim: A mod class needs a class-name anchor ProgressionDescription (ExactMatch="<Class>",
+      Hidden=false, scoped to the class table) or the CC/level-up viewmodel never creates the class
+      feature GROUP and NOTHING boost-derived renders (not even proficiencies). Vanilla classes get
+      this implicitly; mod classes must ship it (Cantripster's pattern).
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - progressions
+      - class
+      - description
+      - features
+    detail: "Related, and separately confirmed in-game: the Class Features panel is passive-driven — it
+      renders passives flagged Highlighted;ForceShowInCC. Making the class's spellcasting passive
+      such a passive made the panel appear (confirmed by screenshot). The spell-SLOT card
+      specifically still did not render and remained an open question."
+  - id: bg3.progressions.subclass-anchor-description
+    claim: Subclass progression tables get their own class-name-anchor ProgressionDescription too
+      (ExactMatch = subclass Name, scoped to the subclass ProgressionTableId, Hidden=false) —
+      vanilla ships these (Champion, Assassin, Monk, …). Add one per mod subclass so the subclass
+      feature GROUP renders under its name at level-up.
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - progressions
+      - subclass
+      - description
+    detail: A class mod added one for each of its two subclasses (Hidden=false), mirroring the
+      base-class anchor fix. The mechanism is by analogy with the base-class anchor plus vanilla
+      precedent; the subclass render itself was gated with the rest of that phase.
+  - id: bg3.progressions.no-spell-replacement-idiom
+    claim: There is NO in-progression spell-REPLACEMENT / spell-removal idiom in stats. RemoveSpells has
+      zero occurrences across the entire vanilla stats + progressions extract, and no vanilla
+      subclass upgrades a granted spell to a stronger one in-progression. Ship the upgrade
+      additively (grant it, leave the original) or do the removal in Script Extender.
+    status: inferred
+    source: ModWright research
+    tags:
+      - progressions
+      - spells
+      - removal
+      - additive
+    detail: "A class mod shipped the additive form: its level-8 grant of Greater Invisibility does not
+      remove its level-2 spell; both remain 1/long-rest castable."
+  - id: bg3.progressions.addspells-no-levelup-card
+    claim: A direct AddSpells grant renders no level-up card. To make a granted spell show as a Class
+      Features card, pair it with a display-only Highlighted;ForceShowInCC passive (reuse the
+      spell's name/desc handles).
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - progressions
+      - spells
+      - addspells
+      - levelup-card
+    detail: "The passive grants nothing; it exists only to render the card. Related open item, tracked
+      as its own fact: bg3.spells.untilrest-levelup-card."

package/knowledge/baldursgate3/publishing.modio-nexus.yaml

@@ -0,0 +1,170 @@
+game: baldursgate3
+topic: publishing.modio-nexus
+title: Publishing to mod.io and Nexus — media specs and the SE-on-mod.io myth
+facts:
+  - id: bg3.publishing.se-mod-io-myth
+    claim: "Near-universal community claim: \"the Toolkit doesn't support Script Extender, therefore SE
+      mods can't go on mod.io.\" It is wrong — it conflates authoring SE content in the Toolkit
+      (genuinely unsupported) with packing it."
+    status: contradicted
+    source: ModWright research
+    tags:
+      - publishing
+      - se
+      - toolkit
+      - mod.io
+      - community-myth
+    detail: "Kept so the myth is not repeated. Superseded by bg3.publishing.se-mods-can-ship-on-modio.
+      What IS real: no console curation (SE is PC-only) — don't tick PS5/Xbox in File Manager."
+  - id: bg3.publishing.se-mods-can-ship-on-modio
+    claim: SE mods CAN be published to mod.io. Toolkit Publish packs whatever sits in the project
+      folder, Mods/<Mod>/ScriptExtender/Lua/ included, and SE itself is a separately installed DLL,
+      so nothing prohibited ships in the pak.
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    supersedes: bg3.publishing.se-mod-io-myth
+    source: ModWright field verification
+    tags:
+      - publishing
+      - se
+      - toolkit
+      - mod.io
+    detail: "Counter-example: Bliss (https://mod.io/g/baldursgate3/m/bliss), live since Sep 2024, 35k+
+      downloads, states on its own page that it requires SE. The MECHANISM was flagged as inferred
+      (\"verify with a throwaway Toolkit project published and left not-live before betting on
+      it\"); the practical proof here is a class mod's own Toolkit publish, whose pak was extracted
+      and diffed after upload."
+  - id: bg3.publishing.mod-io-name-limit
+    claim: mod.io mod name ≤ 50 chars — a HARD limit; publish fails over it.
+    status: community
+    source: https://docs.mod.io/restapiref/
+    tags:
+      - publishing
+      - mod.io
+      - name
+    detail: The API reference is "the only place these are actually written down"; not re-verified
+      against a failed publish here.
+  - id: bg3.publishing.mod-io-summary
+    claim: mod.io summary ≤ 250 chars, plain text.
+    status: community
+    source: https://docs.mod.io/restapiref/
+    tags:
+      - publishing
+      - mod.io
+      - summary
+    detail: One-liner pitch, no markup. Description, by contrast, supports and is encouraged to use HTML.
+  - id: bg3.publishing.mod-io-logo
+    claim: "mod.io logo (mandatory): jpg/jpeg/png, ≤ 8 MB, min 512x288, 16:9; author at 1920x1080.
+      mod.io derives 320x180 / 640x360 / 1280x720 thumbnails — a square source crops badly in every
+      tile."
+    status: community
+    source: https://docs.mod.io/restapiref/
+    tags:
+      - publishing
+      - mod.io
+      - logo
+      - image
+    detail: The 16:9 aspect is the load-bearing part; make a landscape image, not a square icon.
+  - id: bg3.publishing.mod-io-gallery
+    claim: "mod.io gallery: PNG recommended by Larian, 16:9 1920x1080, ≤ 8 MB each; bulk-uploadable as
+      images.zip."
+    status: community
+    source: https://docs.mod.io/restapiref/
+    tags:
+      - publishing
+      - mod.io
+      - gallery
+      - images
+    detail: "Open caveat: the API documents the gallery as accepting jpg/jpeg/png only, so an animated
+      gif may be rejected there even though Nexus takes it — check at upload."
+  - id: bg3.publishing.mod-io-video
+    claim: "mod.io video: YouTube links only, and web-only — they don't show in the in-game Mod Manager."
+    status: community
+    source: https://docs.mod.io/restapiref/
+    tags:
+      - publishing
+      - mod.io
+      - video
+    detail: Neither mod.io nor Nexus hosts a raw video file; both embed YouTube links.
+  - id: bg3.publishing.modmanager-tile-source
+    claim: The in-game mod-manager tile is fetched from mod.io, not read from the pak — a locally
+      sideloaded pak always shows the X placeholder no matter what art is inside it.
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - publishing
+      - mod-manager
+      - tile
+      - modio
+    detail: "Observed directly: sideloaded paks show the X placeholder; the tile comes from the mod.io
+      logo image."
+  - id: bg3.publishing.nexus-image-specs
+    claim: "Nexus/Vortex: the images area is built for 16:9 at 1920x1080, and the first image becomes
+      the tile that both Vortex and the site show (no separate Vortex asset exists). Per-image cap
+      is 8 MB, and gif — not webp — is the animated format Nexus accepts. Optional custom page
+      header is 1400x396. Videos get their own tab from YouTube URLs."
+    status: community
+    source: ModWright research
+    tags:
+      - publishing
+      - nexus
+      - vortex
+      - images
+    detail: "Factual correction: an earlier estimate put the per-image byte cap at \"~1.5–2 MB — confirm
+      at upload, it's the one number that moves\". 8 MB was then confirmed against the site, and the
+      capture script's -MaxMB default was changed to 8 to match. The 8 MB figure supersedes the
+      estimate."
+  - id: bg3.publishing.toolkit-publish-checklist
+    claim: "Before a Toolkit publish: (1) purge non-standard extras from the project (a binary .lsf twin
+      of the icon atlas .lsx, *.tmp.lsx next to _merged.lsf banks, duplicate loca XML, *.bak, and
+      Mods/<proj>/Globals|Levels vanilla-identical level overrides the Toolkit writes whenever you
+      select an object in the level editor); (2) sync hand edits into BOTH places the Toolkit reads
+      — Data\\Editor\\Mods\\<proj>\\Stats\\**\\*.stats and
+      Data\\Public\\<proj>\\Stats\\Generated\\...\\*.txt, plus the atlas .lsx; (3) remove the
+      Data\\Mods\\<proj> / Data\\Public\\<proj> junctions; (4) verify the output pak by Divine
+      list/extract."
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - publishing
+      - toolkit
+      - checklist
+    detail: "Example verification for one mod: expect 22 Story/DialogsBinary + the bank, 10 stats .txt,
+      12 Lua, no Levels/Globals, no .tmp.lsx / .lsf atlas / .bak. Then download the file row from
+      the mod.io Files tab (each row has its own link — the main Download button may serve an OLD
+      file) and confirm the inner pak is byte-identical to the local one."
+  - id: bg3.publishing.toolkit-dialogbank-fix
+    claim: If the Toolkit drops the DialogBank, rerun the Toolkit variant with --with-lsj (which adds
+      Story/Dialogs/<rel>.lsj so the DialogResource has a real source file) and publish again.
+    status: unverified
+    source: ModWright research
+    tags:
+      - publishing
+      - toolkit
+      - dialogbank
+    detail: "A pre-written contingency, not an executed one: the 2026-09-04 publishes kept the bank
+      (extract+diff confirmed 22 resources), so the --with-lsj path was never exercised."
+  - id: bg3.publishing.modio-subscription-redownloads-a-retired-pak-after-a-launch
+    claim: "While a mod's author stays subscribed to their own mod on mod.io, renaming the mod.io copy
+      (<name>_<uuid-prefix>-<hash>.pak in the profile Mods folder) out of the way is undone by the
+      next game launch: the launcher downloads it again as a fresh file, and the module UUID is
+      duplicated once more. Until the subscription is dropped, retiring the copy is a per-session
+      chore before every deploy."
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - mod-io
+      - subscription
+      - duplicate-uuid
+      - deploy
+      - profile-mods
+    detail: "Unsubscribing is the obvious durable fix but was not tried, so it is a suggestion, not an
+      observed one. What the launch shows is only that the re-download happens while the
+      subscription stands, and that ModWright's duplicate-module-uuid guard catches it. Not every
+      launch, either: after the 2026-09-11 evening launches and a 2026-09-12 launch no new copy
+      appeared and the deploy was not refused, so whatever brings it back is narrower than the game
+      starting. The launcher's own sync is the obvious candidate but was not observed, and which
+      route the game was started by on each occasion was not recorded."

package/knowledge/baldursgate3/publishing.toolkit-modio.yaml

@@ -0,0 +1,135 @@
+game: baldursgate3
+topic: publishing.toolkit-modio
+title: Publishing a mod from the Toolkit — dependencies, conflicts, and mod.io flow
+facts:
+  - id: bg3.publishing.toolkit-modio.larian-and-modio-account-linkage-required
+    claim: Publishing to mod.io from the Toolkit requires both a Larian account and a mod.io account,
+      connected to each other, set up before starting the publish process; only loading the mod
+      project (not a level) is needed before publishing.
+    status: community
+    source: docs.baldursgate3.game/Getting_Started:_Publishing_a_Mod §Introduction
+    tags:
+      - publishing
+      - toolkit
+      - larian-account
+      - modio-account
+  - id: bg3.publishing.toolkit-modio.name-description-thumbnail-mandatory
+    claim: In the Toolkit's Project Settings, the Name, Description, and Thumbnail fields are mandatory
+      before a mod can be published; all of these can still be edited afterward on mod.io itself.
+    status: community
+    source: docs.baldursgate3.game/Getting_Started:_Publishing_a_Mod §Project Settings
+    tags:
+      - publishing
+      - toolkit
+      - project-settings
+      - required-fields
+  - id: bg3.publishing.toolkit-modio.dependencies-set-in-two-separate-places
+    claim: Setting a dependency in the Toolkit's Project Settings is a different, separate action from
+      setting a dependency on mod.io — both must be done to fully wire up a dependency relationship
+      for players; the Toolkit's dependency list governs load order, while mod.io's dependency list
+      governs automatic download of required mods for players.
+    status: community
+    source: docs.baldursgate3.game/Getting_Started:_Publishing_a_Mod §Dependencies, §Editing Your Mod on
+      Mod.io § Dependencies
+    tags:
+      - publishing
+      - dependencies
+      - toolkit
+      - modio
+      - load-order
+  - id: bg3.publishing.toolkit-modio.dependency-changes-require-toolkit-restart
+    claim: Changing a project's dependencies in the Toolkit requires closing and reopening the Toolkit
+      before those changes appear reflected in the Resource Manager — the dependency change does not
+      take effect live.
+    status: community
+    source: docs.baldursgate3.game/Getting_Started:_Publishing_a_Mod §Dependencies
+    tags:
+      - publishing
+      - dependencies
+      - toolkit
+      - gui-only
+      - gotcha
+  - id: bg3.publishing.toolkit-modio.conflict-disables-mod-and-cascades-to-its-own-dependencies
+    claim: Declaring mod A as a conflict of mod B causes the game to automatically disable mod B when
+      mod A is also active; disabling mod B in turn disables B's own dependencies too, unless
+      another active mod also depends on them (in which case those shared dependencies stay
+      enabled).
+    status: community
+    source: docs.baldursgate3.game/Getting_Started:_Publishing_a_Mod §Conflicts
+    tags:
+      - publishing
+      - conflicts
+      - cascading-disable
+  - id: bg3.publishing.toolkit-modio.save-before-closing-project-settings
+    claim: Changes made on the Dependencies and Conflicts tabs of Project Settings must be explicitly
+      saved before closing the window, or they are lost.
+    status: community
+    source: docs.baldursgate3.game/Getting_Started:_Publishing_a_Mod §Conflicts
+    tags:
+      - publishing
+      - project-settings
+      - save
+  - id: bg3.publishing.toolkit-modio.publish-local-vs-publish-to-modio
+    claim: "\"Publish Local\" packages a .pak file to a location you choose without any authentication
+      and without uploading anywhere; publishing \"to mod.io\" is a separate authenticated flow (via
+      Steam or a Larian account) that both packages and uploads the mod, showing a progress bar and,
+      on success, a specific success line in the Toolkit's Message Log panel."
+    status: community
+    source: docs.baldursgate3.game/Getting_Started:_Publishing_a_Mod §Publishing Locally, §Publishing to
+      Mod.io
+    tags:
+      - publishing
+      - publish-local
+      - modio
+      - authentication
+  - id: bg3.publishing.toolkit-modio.scan-gate-blocks-going-live
+    claim: Immediately after publishing to mod.io, a mod's File Manager page shows a "Needs
+      File"/scan-pending state (a clock icon under "Scan") and the mod cannot be set live until
+      Larian's automated scan of the uploaded file completes — mod profile fields (name, summary,
+      description, tags, media) can still be edited during this waiting period.
+    status: community
+    source: docs.baldursgate3.game/Getting_Started:_Publishing_a_Mod §Editing Your Mod on Mod.io
+    tags:
+      - publishing
+      - modio
+      - scan
+      - go-live
+  - id: bg3.publishing.toolkit-modio.media-recommends-png-youtube-web-only
+    claim: "Larian's own publishing doc confirms both existing media facts: it recommends \"sticking to
+      .png files\" for gallery images (bg3.publishing.mod-io-gallery, \"PNG recommended by Larian\")
+      and states that YouTube videos \"will only be displayed on the web, not in-game\"
+      (bg3.publishing.mod-io-video)."
+    status: community
+    source: docs.baldursgate3.game/Getting_Started:_Publishing_a_Mod §General Settings > Media
+    tags:
+      - publishing
+      - modio
+      - media
+      - screenshots
+    detail: "Kept as the confirming citation only: the byte caps and pixel dimensions in
+      bg3.publishing.mod-io-logo / -gallery come from the mod.io REST API reference and are not
+      restated here."
+  - id: bg3.publishing.toolkit-modio.go-live-is-a-separate-manual-step
+    claim: Publishing and uploading a mod to mod.io does not itself make it visible/downloadable — a
+      separate "Go live" button on the mod's mod.io page must be clicked after verifying details; a
+      mod can be left un-live indefinitely while its details are edited, as long as Save is pressed
+      before leaving the page.
+    status: community
+    source: docs.baldursgate3.game/Getting_Started:_Publishing_a_Mod §Setting the Mod Live
+    tags:
+      - publishing
+      - modio
+      - go-live
+      - workflow
+  - id: bg3.publishing.toolkit-modio.mod-folder-must-be-under-localappdata
+    claim: For a mod to appear in the Toolkit's Dependencies/Conflicts selection lists, it must be
+      present (as a downloaded mod folder) under %localappdata%\Larian Studios\Baldur's Gate 3\Mods\
+      — a mod not visible there needs to be downloaded first before it can be picked as a dependency
+      or conflict.
+    status: community
+    source: docs.baldursgate3.game/Getting_Started:_Publishing_a_Mod §Dependencies, §Conflicts
+    tags:
+      - publishing
+      - toolkit
+      - mod-folder
+      - dependencies

package/knowledge/baldursgate3/races.progression.yaml

@@ -0,0 +1,228 @@
+game: baldursgate3
+topic: races.progression
+title: Race Progression tables, UUID linkage, and race setup
+facts:
+  - id: bg3.races.progression.uuid-vs-tableuuid
+    claim: "Every Progression node has two distinct UUIDs: its own UUID identifies that single
+      Progression node only, while TableUUID is shared by every Progression node belonging to the
+      same race/subrace or class/subclass and is what the owning entity's ProgressionTableUUID field
+      points to. Referencing the node UUID targets only that one level; referencing the TableUUID
+      targets the whole progression table."
+    status: community
+    source: wiki.bg3.community/en/Information/Progression/Progressions
+    tags:
+      - progressions
+      - uuid
+      - tableuuid
+      - races
+    detail: 'Worked example from the page: TableUUID "ba2afe85-acba-4ea1-a238-2b4543f47821" is shared by
+      every base Paladin Progression node (Level 1, Level 4, Level 12, ...), while UUID
+      "b60618d1-c262-42b5-9fdd-2c0f7aa5e5af" refers only to the non-multiclass Level 1 Paladin
+      node.'
+  - id: bg3.races.progression.race-links-via-progressiontableuuid
+    claim: "A Race node's ProgressionTableUUID field must be set to the TableUUID shared across the
+      Progression nodes meant for that race — the final wiring step: \"In Races.lsx, where we
+      defined the race, we need to go take a look at our race's ProgressionTableUUID. Here, we'll
+      want to copy/paste our TableUUID from our Progressions nodes.\""
+    status: community
+    source: github.com/BG3-Community-Library-Team/BG3-Community-Library/wiki/Building-a-Race-Mod §Racial
+      Progressions > Applying the Progression
+    tags:
+      - progressions
+      - tableuuid
+      - races
+      - uuid-linkage
+    detail: The page presents it as the step that makes the race "fully-featured"; it does not state a
+      symptom for getting it wrong, so treat "no abilities at level-up" as the expected consequence,
+      not a documented one.
+  - id: bg3.races.progression.race-root-required-fields
+    claim: A Races.lsx Race node requires (at minimum) Description and DisplayName (TranslatedString
+      handles), a DisplayTypeUUID (typically mirroring ParentGuid), Name (FixedString,
+      conventionally prefixed to avoid collisions), ParentGuid (guid of the parent race, e.g.
+      Humanoid), ProgressionTableUUID (guid), RaceSoundSwitch (FixedString), and its own UUID
+      (guid).
+    status: community
+    source: github.com/BG3-Community-Library-Team/BG3-Community-Library/wiki/Building-a-Race-Mod §Race
+      Entry (annotated Shadar-Kai Race node)
+    tags:
+      - races
+      - races-lsx
+      - required-fields
+  - id: bg3.races.progression.internal-name-prefix-convention
+    claim: Race internal Name (and Tag Name) fields are conventionally prefixed (e.g. "CL_") to avoid
+      collisions with other mods' race and tag names, since Name is a FixedString the game and other
+      mods can reference by exact string.
+    status: community
+    source: github.com/BG3-Community-Library-Team/BG3-Community-Library/wiki/Building-a-Race-Mod §Race
+      Entry ("Write an internal name, prefixed with CL_ to help ensure there aren't any collisions
+      with other mods"), §Anatomy of a Tag (tag Name "CL_ShadarKai")
+    tags:
+      - races
+      - naming-convention
+      - tags
+  - id: bg3.races.progression.tag-filename-differs-from-internal-uuid
+    claim: A race Tag's filename is a UUID generated separately from — and distinct from — the Tag
+      node's own internal UUID attribute; a RootTemplate or Race referencing that tag must reference
+      it by the filename UUID, not by the tag's internal UUID field.
+    status: community
+    source: github.com/BG3-Community-Library-Team/BG3-Community-Library/wiki/Building-a-Race-Mod §Tags >
+      Anatomy of a Tag, §Using the Tag
+    tags:
+      - races
+      - tags
+      - uuid
+      - gotcha
+    detail: "Verbatim: \"UUID: This is an ID for your tag. However, this is not how you'll reference the
+      tag in other files - you'll instead want to use its Filename, which is a different UUID.\" The
+      same distinction applies to a class's Tags reference — see
+      bg3.feats.classes.tags-live-in-children-node."
+  - id: bg3.races.progression.charactervisuals-lsf-must-convert-to-lsx
+    claim: Character Visuals for a race are stored as _merged.lsf files that must be converted to .lsx
+      to be hand-edited, then converted back to .lsf before packing the mod.
+    status: community
+    source: github.com/BG3-Community-Library-Team/BG3-Community-Library/wiki/Building-a-Race-Mod
+      §Character Visuals, §Wrapping Up
+    tags:
+      - races
+      - character-visuals
+      - lsf
+      - lsx
+    detail: They arrive bundled as Public/ModName/Content/[PAK]_CharacterVisuals/_merged.lsf; convert
+      the whole file, edit, then "convert our _merged.lsx files back into _merged.lsf" before
+      packing.
+  - id: bg3.races.progression.four-body-variants-required
+    claim: A complete playable race needs 6 Root Templates (Base Female, Base Male, Female Player,
+      Female Player Strong, Male Player, Male Player Strong) and 6 Character Visual Resource nodes —
+      2 base plus 4 player variants — and 4 CharacterCreationPresets nodes, "one each for Feminine,
+      Masculine, Feminine Strong, and Masculine Strong".
+    status: community
+    source: "github.com/BG3-Community-Library-Team/BG3-Community-Library/wiki/Building-a-Race-Mod §Root
+      Templates (\"you'll typically have 6 per race\"), §Character Visuals (\"There will be 6 total
+      Resource nodes you'll want: 2 Within Community Library, and 4 within your Implementation
+      Mod\"), §Character Creation > Creating Presets"
+    tags:
+      - races
+      - character-creation
+      - body-type
+    detail: "The split is deliberate in the Community Library workflow: the 2 base templates/visuals
+      live in the Community Library so other mods can build NPCs on them, the 4 player ones in your
+      implementation mod. A Strong player template additionally carries EquipmentRace (\"Without it,
+      there'll be a ton of clipping\") and GeneratePortrait."
+  - id: bg3.races.progression.ccpreset-vo-lines-table-default
+    claim: CharacterCreationPresets.lsx's VOLinesTableUUID field controls which voice-preview lines play
+      in character creation; the community template recommends leaving it at the default table UUID
+      (14df8f45-90af-4bd0-8024-42624da9976e) for a standard playable race.
+    status: community
+    source: wiki.bg3.community/en/Tutorials/Races/Creating-A-Basic-Race-Mod
+    tags:
+      - races
+      - character-creation-presets
+      - voice
+      - uuid
+  - id: bg3.races.progression.camera-closeups-need-adjustment-for-nonstandard-height
+    claim: "CharacterCreationPresets' CloseUpA/CloseUpB/Overview camera values need adjusting for a
+      non-standard stature: \"The default camera values given are fine for standard body humans,
+      elves, half-elves, drow, and tieflings. However, if you are making a shorter or taller race,
+      you will need to adjust those camera values so that the camera will zoom in the correct
+      place.\""
+    status: community
+    source: wiki.bg3.community/en/Tutorials/Races/Creating-A-Basic-Race-Mod
+    tags:
+      - races
+      - character-creation-presets
+      - camera
+  - id: bg3.races.progression.progressiontype-numeric-values
+    claim: "A Progression node's ProgressionType attribute distinguishes what kind of entity it belongs
+      to: 0 = Class Progression, 1 = Subclass Progression, 2 = Race Progression."
+    status: community
+    source: wiki.bg3.community/en/Tutorials/Classes/Basic-Class-Creation §Subclasses ("0 is for classes,
+      1 is for subclasses, 2 is for races"); confirmed by the Community Library wiki,
+      Building-a-Race-Mod §Racial Progressions (race Progression nodes carry ProgressionType uint8
+      value="2")
+    tags:
+      - progressions
+      - progressiontype
+      - races
+      - classes
+  - id: bg3.races.progression.character-visuals-slots-set-default-mesh
+    claim: "A race's per-body-type Character Visuals Resource node carries child Slots nodes, each
+      pairing a Slot name (Head, Hair, ModestyLeaf, Private Parts, ...) with a VisualResource UUID;
+      that UUID is what ties the slot to the CharacterCreationAppearanceVisuals file, which the page
+      states as: \"Matched to the CharacterCreationAppearanceVisuals file using the VisualResource
+      UUID.\""
+    status: community
+    source: wiki.bg3.community/en/Tutorials/Races/Creating-A-Basic-Race-Mod
+    tags:
+      - races
+      - character-visuals
+      - slots
+      - default-appearance
+  - id: bg3.races.progression.roottemplate-race-attribute-must-match
+    claim: "The Race attribute on a race's BASE Root Templates must be the UUID of that race's Races.lsx
+      entry (\"Race: This will be the UUID field of your Race entry in Races.lsx\"); the
+      player/implementation Root Templates in the worked example carry no Race attribute at all and
+      inherit through ParentTemplateId. The tag wiring step is scoped the same way: \"Whichever Root
+      Templates you've added that have a Race field, you'll want to open and perform these actions
+      on.\""
+    status: community
+    source: github.com/BG3-Community-Library-Team/BG3-Community-Library/wiki/Building-a-Race-Mod §Base
+      Root Templates, §Implementation Root Templates, §Ensuring the Tags reach the Root Template
+      correctly
+    tags:
+      - races
+      - roottemplate
+      - uuid-linkage
+    detail: "Corrected from \"every RootTemplate ... base and player variants alike\": the page's
+      implementation templates (Elves_Female_ShadarKai_Player, ..._Player_Strong) set
+      ParentTemplateId to the base template and omit Race. A validator should require Race on
+      templates that declare one, not on all of them."
+  - id: bg3.races.progression.charactercreationpreset-required-fields
+    claim: "A CharacterCreationPresets.lsx CharacterCreationPreset node's fields, per the community race
+      template: BodyShape (uint8), BodyType (uint8), CloseUpA/CloseUpB/Overview (LSString camera
+      resource names), RaceUUID (the owning race's Races.lsx UUID), RootTemplate (a guid pointing
+      into the race's own RootTemplates file, not the race's Races.lsx UUID), SubRaceUUID (all-zero
+      00000000-0000-0000-0000-000000000000 when the preset has no subrace), UUID (this preset's own
+      unique id), and VOLinesTableUUID."
+    status: community
+    source: bg3-community/Tutorials/Races/Creating-A-Basic-Race-Mod.html §Understanding The Files,
+      CharacterCreationPresets.lsx (annotated Female/Male Standard preset nodes)
+    tags:
+      - races
+      - character-creation-presets
+      - required-fields
+    related:
+      - id: bg3.races.progression.ccpreset-vo-lines-table-default
+        detail: Same file/node this existing fact's VOLinesTableUUID field belongs to; adds the complete
+          field list around it, including that RootTemplate here is a distinct UUID from RaceUUID
+          (one points at Races.lsx, the other at the race's RootTemplates file).
+  - id: bg3.races.progression.bodyshape-bodytype-numeric-values
+    claim: CharacterCreationPreset's BodyShape attribute uses 0 for "Standard" (the community template's
+      only documented value); BodyType uses 0 for Male and 1 for Female, per the template's own
+      inline comments on its Male/Female Standard preset pair.
+    status: community
+    source: bg3-community/Tutorials/Races/Creating-A-Basic-Race-Mod.html §Understanding The Files,
+      CharacterCreationPresets.lsx (comments "0 = Standard" on BodyShape; "1 = Female" / "0 = Male"
+      on BodyType)
+    tags:
+      - races
+      - character-creation-presets
+      - bodyshape
+      - bodytype
+      - enum
+    detail: Only Standard (0) is demonstrated in the template; whether other BodyShape values exist
+      (e.g. for a Strong variant) is not stated on this page — see
+      bg3.races.progression.four-body-variants-required for the separate Strong-variant pattern,
+      which uses distinct Root Templates rather than a BodyShape value.
+  - id: bg3.races.progression.tan-square-icon-is-expected-patch7-placeholder
+    claim: As of Patch 7, a freshly created custom race's selection icon in Character Creation renders
+      as a tan square placeholder — the tutorial states this explicitly is "normal" and not a sign
+      of a broken race setup, before any custom race icon has been authored.
+    status: community
+    source: bg3-community/Tutorials/Races/Creating-A-Basic-Race-Mod.html §Seeing What We've Got ("as of
+      Patch 7, the custom race icon may appear as a tan square. That is normal.")
+    tags:
+      - races
+      - icon
+      - placeholder
+      - patch7
+      - gotcha