modwright 0.1.0

package/knowledge/baldursgate3/items.cloth-physics.yaml

@@ -0,0 +1,167 @@
+game: baldursgate3
+topic: items.cloth-physics
+title: Cloth physics on worn armor (proxy cloth mesh, vertex paint, ClothParams, ClothProxyMapping)
+facts:
+  - id: bg3.cloth.proxy-cloth-mesh-in-gr2
+    claim: Cloth physics on worn armor is driven by a separate, INVISIBLE, coarse submesh in the same
+      GR2 whose name ends in _Cloth_Mesh (the "cloth proxy"); the visible render mesh is deformed by
+      it. The proxy uses the engine default material 9e2966c7-b61c-4bc1-bef1-a79cb5fde067
+      (Engine_Default_Mesh_Lit_Opaque) and ships per LOD.
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: wiki.bg3.community/Information/Meshes/Armour-Meshes + the vanilla resource
+    tags:
+      - cloth
+      - physics
+      - gr2
+      - proxy-mesh
+      - armor
+    detail: 'The wiki glossary: "When a sub-mesh ends with _Cloth_Mesh, this is (with very rare
+      exceptions) the cloth mesh, which is an invisible submesh that gives the game information on
+      how to simulate the cloth physics for the other parts of that mesh." A custom robe therefore
+      needs its swinging parts (tie ends, beads, skirt) modelled a second time as a low-poly proxy,
+      not just painted on the render mesh.'
+  - id: bg3.cloth.vertex-paint-red-amount-blue-damping
+    claim: "Cloth is controlled by vertex colour: RED turns physics on and sets how free a vertex is (0
+      = pinned), BLUE slows/damps it; GREEN is reserved for the VertCut body-mask. The cloth proxy
+      is painted in red bands (vanilla robe: 0 / .25 / .5 / .65 / .8 / 1, blue 0 / .25 / .5); the
+      visible render mesh is painted red = 1 on every cloth-driven vertex and 0 elsewhere."
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: 'wiki.bg3.community/Information/Meshes/Vertex-Painting-Meshes ("Red and Blue affect cloth
+      physics"; the community summary: red turns physics on, more red = more active, blue makes it
+      slower) + the vanilla data'
+    tags:
+      - cloth
+      - physics
+      - vertex-color
+      - weight-paint
+    detail: 'Paint with flood fills per face selection, not soft brushes: in-between values are handled
+      badly by the engine (the wiki reports such verts "stuck to the ground" for the mask channel).
+      Export-side colour-space caveat as for VertexColorMaskSlots: via Collada the R/B components
+      survive as painted; via glTF they are gamma-adjusted.'
+  - id: bg3.cloth.visualbank-clothparams-node
+    claim: "The VisualBank Resource carries one ClothParams child per cloth proxy mesh (and per LOD):
+      its UUID attribute is the proxy's ObjectID string (e.g.
+      HUM_F_ARM_Robe_A_Body.HUM_F_ARM_Robe_A_Body_Cloth_Mesh.2) and it holds the 39 simulation
+      attributes."
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: Shared.pak [PAK]_Female_Armor _merged.lsf
+    tags:
+      - cloth
+      - physics
+      - visualbank
+      - clothparams
+    detail: 'Vanilla robe values (a sane starting point for light cloth): AngularDrag/LinearDrag .0001,
+      AngularInertia/ LinearInertia/CentrifugalInertia .5, AnimDriveSpringForce 225,
+      AnimDriveDampingForce 75, AnimInfluenceMultiplier 1, BendingStiffness 1, LinearStiffness 1,
+      Damping .04, DragCoefficient .4, LiftCoefficient .01, FluidDensity .1, Friction .1,
+      CollisionMassScale 1, CompressionLimit .8, StretchLimit 1.2, SelfCollisionDistance 0,
+      SelfCollisionStiffness 0, SolverFrequency 30, StiffnessFrequency 350, StiffnessMultiplier 1,
+      TetherConstraintScale 1, TetherConstraintStiffness 1, EnableCCD False, EnableVirtualParticles
+      False, all wind fields 0/False. The "Fabric Manufacturer" SE utility (Nexus 18884) exposes
+      these as live sliders and exports them.'
+  - id: bg3.cloth.proxy-mapping-blob-three-nearest
+    claim: "ClothProxyMapping links a cloth proxy to the render mesh it drives: MapKey = proxy ObjectID;
+      MapValue/Object has Name = render-mesh ObjectID, NbClosestVertices = N and ClosestVertices =
+      base64(zlib(uint16[N])). The blob is N/3 triples, one per proxied render vertex: slot 1 is
+      ALWAYS a valid proxy-vertex index, slots 2-3 are extra nearest neighbours or 0xFFFF. Indices
+      address the proxy's WELDED vertex list (max index + 1 equals the proxy's unique-position count
+      where the GR2 has no split verts: Robe_A_1 504/504, Padded LOD0 315/315)."
+    status: inferred
+    source: "Decoded 2026-09-14 from Shared.pak [PAK]_Female_Armor + the GR2s of HUM_F_ARM_Robe_A,
+      Robe_A_1, Robe_D, Padded_A_1 and Robe_C_3 (12 mappings, all LODs): N divisible by 3 in all 402
+      entries of the file; slot-1 valid count == N/3 in all 12; zlib-inflates to exactly 2*N bytes."
+    tags:
+      - cloth
+      - physics
+      - visualbank
+      - clothproxymapping
+      - scratchbuffer
+      - binary
+    detail: "WHICH render vertices are proxied is only partly decoded: N/3 is always a little above the
+      count of red-painted render verts (Robe_A_1: 1235 vs 1183 red, and it EQUALS red verts + their
+      one-ring neighbours, 1235, for both LODs of that mesh), but the one-ring rule
+      over-/under-shoots the other four robes by 3-10% (Robe_D 402 vs 379, Padded 1550 vs 1464,
+      Robe_C_3 3222 vs 3121) — likely because lslib's glTF export does not reproduce the GR2's exact
+      vertex list. Order within the list is presumed to be render-vertex order. The Toolkit
+      generates this blob from its Proxy Simulation tab; a hand-generated one (a script writing
+      \"red + one ring, vertex order, three nearest welded proxy verts\") is an EXPERIMENT with
+      crash risk, not a recipe."
+  - id: bg3.cloth.lslib-divmodeltype-cloth-flag
+    claim: "lslib/divine marks a GR2 mesh as cloth from the COLLADA source: under the geometry's <mesh>
+      an <extra> <technique profile=\"LSTools\"> with <DivModelType>Cloth</DivModelType> sets
+      MeshFlags Cloth and ExtendedData Cloth=1. Other DivModelType values: Rigid, MeshProxy,
+      ProxyGeometry, Spring, Occluder, Cloth01, Cloth02, Cloth04, ClothPhysics (cloth flag bits);
+      same technique also takes ExportOrder, LOD, LODDistance, IsImpostor."
+    status: verified
+    verified_on: lslib master (ColladaImporter.cs FindExporterExtraData / LoadLSLibProfileMeshType),
+      read 2026-09-14
+    source: github.com/Norbyte/lslib LSLib/Granny/Model/ColladaImporter.cs
+    tags:
+      - cloth
+      - lslib
+      - divine
+      - collada
+      - gr2
+      - mesh-flags
+    detail: Blender's built-in COLLADA exporter writes no such technique; the dos2de_collada_exporter
+      addon does (its per-mesh "Cloth" custom property). A pipeline using the stock exporter can
+      inject the <extra> block into the .dae before divine dae->gr2. Which cloth flag bits vanilla
+      proxies carry was not checked.
+  - id: bg3.cloth.toolkit-proxy-simulation-tab
+    claim: In the Toolkit, a GR2 that contains a cloth proxy mesh is wired by opening the mesh in the
+      Resource Manager and, in its Proxy Simulation tab, dragging the render mesh and dropping it
+      under the bolded cloth mesh; that is what produces the ClothProxyMapping (and default
+      ClothParams) in the VisualBank.
+    status: community
+    source: wiki.bg3.community/Tutorials/Toolkit/Toolkit_Tips (search summary, 2026-09-14)
+    tags:
+      - cloth
+      - physics
+      - toolkit
+      - proxy-simulation
+    detail: "Recommended route for a hand-built pipeline: author the GR2 (render mesh + proxy, both
+      painted) with lslib, do the proxy link in the Toolkit once, then lift the generated
+      ClothParams + ClothProxyMapping nodes into the mod's own _merged.lsx. The step-by-step is
+      \"Add Cloth Physics To Any Armor\" (Nexus article 311)."
+  - id: bg3.cloth.single-bone-mesh-crashes-with-physics
+    claim: A mesh weighted 100% to a single bone crashes the game when cloth physics is added to it.
+    status: community
+    source: search summary of the community cloth-physics tutorial listing, 2026-09-14 (not
+      independently verified)
+    tags:
+      - cloth
+      - physics
+      - crash
+      - weights
+  - id: bg3.cloth.colliders-live-on-the-body
+    claim: Cloth collides with a ClothColliderBank (bone-attached spheres with links) that ships with
+      the BODY mesh's _merged.lsf; an armor VisualBank resource leaves ClothColliderResourceID empty
+      and inherits the body's.
+    status: community
+    source: bg3.wiki/wiki/Modding:Cloth_colliders; vanilla robe resource ClothColliderResourceID=""
+    tags:
+      - cloth
+      - physics
+      - collider
+    detail: Only a custom BODY needs its own collider bank (the wiki gives FS_NKD_Body_ClothCollider as
+      a template); sphere Radius tunes how far cloth is held off the limb.
+  - id: bg3.cloth.cloaks-collide-with-the-body-colliders-so-standoff-collars-clip
+    claim: "Because a worn mesh has no ClothColliderResourceID of its own
+      (bg3.cloth.colliders-live-on-the-body), an equipped cloak's cloth collides only with the naked
+      body's ClothColliderBank spheres (HUM_F_NKD_Body_ClothCollider,
+      36550e8b-4302-b290-954d-626f53ee7c91: bone-attached Spheres with Position, Radius and Links �
+      Ankle, Knee, Hip_*_Twist, Root_M ...). Any part of a custom robe that stands off the body,
+      such as a raised collar or upper back, is therefore passed through by the cape. The untested
+      remedy is a ClothColliderBank resource for the robe (spheres on neck / upper spine / shoulders
+      sized to the collar) referenced from the robe's VisualBank resource."
+    status: inferred
+    source: ModWright research
+    tags:
+      - cloth
+      - physics
+      - collider
+      - cloak
+      - clipping

package/knowledge/baldursgate3/items.roottemplates.yaml

@@ -0,0 +1,320 @@
+game: baldursgate3
+topic: items.roottemplates
+title: Level-placed item instances, CC item slots, and TreasureTable mechanics
+facts:
+  - id: bg3.items.roottemplates.level-instance-is-a-separate-gameobjects-node
+    claim: Placing an item instance in a level (as opposed to defining the item's own RootTemplate) is a
+      separate GameObjects node, in a Levels\<LevelName>\Items\_merged.lsf.lsx file, whose
+      TemplateName attribute is the MapKey of the RootTemplate being instantiated — the instance
+      gets its OWN new MapKey (a fresh UUID) distinct from the template it points at.
+    status: community
+    source: 'bg3-community/Information/Items/Item-Level-Positioning.md §Item Data File (worked
+      GameObjects example: "TemplateName: This is the MapKey of the object you are copying")'
+    tags:
+      - items
+      - roottemplate
+      - level-placement
+      - gameobjects
+      - uuid
+    related:
+      - id: bg3.items.visualbank.roottemplate-mapkey-links-stats-entry
+        detail: Distinguishes the RootTemplate's own definitional MapKey (which a stats entry's RootTemplate
+          value must equal) from a level instance's TemplateName, which references that same MapKey
+          from a completely different file to place a copy in the world.
+  - id: bg3.items.roottemplates.level-instance-required-fields
+    claim: "The page's worked level-placed GameObjects node carries: LevelName (FixedString, matching
+      the parent Levels\\<Name> directory — readable in-game via
+      _P(Osi.GetRegion(GetHostCharacter()))), MapKey (a freshly generated UUID for the new
+      instance), Name (a display/debug name for the created object), TemplateName (the source
+      RootTemplate's MapKey), Type (FixedString, e.g. \"item\"), plus Flag and
+      _OriginalFileVersion_, a LayerList/Layers/Object child node whose own MapKey repeats the
+      LevelName, and a Transform child node with Position/RotationQuat/Scale. The page annotates the
+      first six but does not say which are strictly required."
+    status: community
+    source: bg3-community/Information/Items/Item-Level-Positioning.md §Item Data File
+    tags:
+      - items
+      - roottemplate
+      - level-placement
+      - required-fields
+  - id: bg3.items.roottemplates.rotationquat-must-be-precomputed-externally
+    claim: A level instance's Transform/RotationQuat attribute takes a quaternion, not a rotation angle,
+      and there is no in-game command that outputs one directly — it must be converted externally
+      from a Y-axis degree value (e.g. via a browser rotation-converter tool). 90 degrees converts
+      to "0 0.7071068 0 0.7071068", written space-separated like Position (the page states the
+      no-commas rule for Position explicitly, and every quaternion it prints follows the same
+      spacing).
+    status: community
+    source: bg3-community/Information/Items/Item-Level-Positioning.md §Converting Rotation to
+      RotationQuat ("there isn't a command in game to give you that, so you have to convert it
+      externally")
+    tags:
+      - items
+      - roottemplate
+      - transform
+      - rotationquat
+      - gotcha
+    detail: The page ships a lookup table of pre-converted 30-degree increments from 0 to 330 for
+      convenience, avoiding the external converter for common angles.
+  - id: bg3.items.roottemplates.scale-attribute-is-a-multiplier
+    claim: "A level instance's Transform/Scale attribute (type float) is a multiplier on the original
+      object's size: 1 = 100% (original size), 0.5 = half size, 2.0 = double size."
+    status: community
+    source: bg3-community/Information/Items/Item-Level-Positioning.md §Item Data File
+    tags:
+      - items
+      - roottemplate
+      - transform
+      - scale
+  - id: bg3.items.roottemplates.cc-item-slot-names-vs-in-game-labels
+    claim: 'Character-Creation-visible item slots use internal names that differ from their in-game
+      display labels: Head shows as "Face"; Beard shows as "Facial Hair"; Piercing shows as
+      "Piercing Style"; DragonbornTop shows as "Crest"; DragonbornChin shows as "Chins";
+      DragonbornJaw shows as "Jaws"; Private Parts shows as "Genitals". Hair, Horns, and Tail keep
+      the same name in both places.'
+    status: community
+    source: bg3-community/Information/Items/CC-Item-Slots.md §Character Creation (CC) Slots
+    tags:
+      - items
+      - cc-slots
+      - naming-convention
+  - id: bg3.items.roottemplates.cc-slot-choice-does-not-constrain-item-behavior
+    claim: Any visual can be assigned to any Character Creation slot with identical in-game behavior
+      regardless of the slot's intended purpose ("it does not matter what type of item is added to a
+      slot... it will behave the same way each time") — the only functional consequence of slot
+      choice is which UI section the player must open to select it, plus a caveat that a colorable
+      item still needs its own colorable UI section wired up separately.
+    status: community
+    source: bg3-community/Information/Items/CC-Item-Slots.md §Description
+    tags:
+      - items
+      - cc-slots
+      - behavior
+  - id: bg3.items.roottemplates.no-way-to-add-new-cc-slots
+    claim: There is currently no known way to add a new Character Creation slot beyond the fixed set the
+      game ships — "doing so would probably require extensive UI editing, if it is possible at all."
+    status: community
+    source: bg3-community/Information/Items/CC-Item-Slots.md §Description
+    tags:
+      - items
+      - cc-slots
+      - limitation
+  - id: bg3.items.roottemplates.spawn-inventory-requires-inventorylist-or-tradetreasures-node
+    claim: "Before a TreasureTable can populate a game object's inventory, that object needs a specific
+      child node added: InventoryList/InventoryItem (for containers/items) or
+      TradeTreasures/TreasureItem (for NPCs), each with an Object attribute (FixedString) naming the
+      TreasureTable to roll. Without this node, an otherwise-correct TreasureTable.txt entry is
+      never consulted."
+    status: community
+    source: bg3-community/Tutorials/Items/Treasuretables.md ("Before anything with treasuretables can
+      happen... a gameobject needs this attribute node added to it")
+    tags:
+      - items
+      - treasuretable
+      - inventorylist
+      - tradetreasures
+      - required-fields
+  - id: bg3.items.roottemplates.treasuretable-subtable-weighting-math
+    claim: A TreasureTable "new subtable" string is "Amount;WeightedChance" pairs separated by ";" —
+      each pair's second number is its weight relative to the sum of all pairs' second numbers in
+      that subtable (e.g. "1,2;2,1" sums to 3, so the first set fires 2-in-3 times and the second
+      1-in-3), and the chosen pair's first number is how many items get rolled from the object list
+      beneath it, using each listed object's own leading number as its OWN relative weight within
+      that roll.
+    status: community
+    source: bg3-community/Tutorials/Items/Treasuretables.md (worked "1,2;2,1" example and its weighting
+      explanation)
+    tags:
+      - items
+      - treasuretable
+      - subtable
+      - weighting
+    detail: A nested treasuretable reference (an object category name prefixed "T_" instead of "I_")
+      re-rolls its own subtables independently each time it is selected — the worked example shows a
+      16-out-of-20 pick of a "T_"-prefixed table getting rolled twice because the outer subtable's
+      chosen pair asked for 2 items.
+  - id: bg3.items.roottemplates.treasuretable-subtable-chance-negative-one-always-shows
+    claim: Setting a TreasureTable subtable's chance string to "-1" makes every object listed underneath
+      it always appear, bypassing both the normal weighted-roll chance and any
+      player-level/uniqueness gating that would otherwise filter it out.
+    status: community
+    source: bg3-community/Tutorials/Items/Treasuretables.md ("If you set the subtable chance to -1, it
+      always shows everything underneath, even if its unique or the player doesn't qualify due to
+      level")
+    tags:
+      - items
+      - treasuretable
+      - subtable
+      - always-show
+  - id: bg3.items.roottemplates.treasuretable-canmerge-appends-without-redefining
+    claim: Adding "CanMerge 1" directly under a "new treasuretable" declaration with the SAME table name
+      appends the following subtable(s) to the existing table's contents rather than replacing it —
+      the documented way to add drops to a table (including a vanilla one) without needing to
+      reproduce its original entries.
+    status: community
+    source: bg3-community/Tutorials/Items/Treasuretables.md §"You can also add to existing
+      treasuretables via CanMerge"
+    tags:
+      - items
+      - treasuretable
+      - canmerge
+      - extension
+  - id: bg3.items.roottemplates.treasuretable-definition-ends-at-next-entry-or-eof
+    claim: A TreasureTable.txt entry has no explicit end marker — its definition runs until either the
+      file ends or a new "new treasuretable" line starts, which the page compares to how
+      stats/spells/boosts .txt files behave.
+    status: community
+    source: bg3-community/Tutorials/Items/Treasuretables.md:110 ("A treasuretable only ends whenever the
+      file ends or you start a new treasuretable entry.")
+    tags:
+      - items
+      - treasuretable
+      - txt-format
+      - parsing
+  - id: bg3.items.roottemplates.loose-lsx-in-roottemplates-is-not-loaded-a-separate-lsf-is
+    claim: "The game does not read a loose .lsx file under Public/<Mod>/RootTemplates: a GameObjects
+      node shipped that way is unknown to Ext.Template.GetTemplate and Osi.CreateAt returns nothing
+      for its MapKey. The same node converted with divine to a .lsf file of its own name, placed
+      beside _merged.lsf in the same pak, is loaded, resolves, and spawns; RootTemplates need not be
+      merged into _merged.lsf, but they must be .lsf."
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - roottemplates
+      - lsx
+      - lsf
+      - packaging
+      - scaffold
+    detail: "Consequence for ModWright: the baldursgate3.new-item scaffold writes
+      Public/<Mod>/RootTemplates/<Item>.lsx and the mod's build had no divine-lsx-to-lsf step, so
+      the scaffolded template never reached the engine even though the stats entry (which the row's
+      bg3.stat.exists probe checks) loads fine. The build already offers a divine-lsx-to-lsf step
+      (src/core/build/steps/bg3.ts); the scaffold now ensures it and a bg3.template.exists probe
+      backs the row (both landed 2026-09-10 and confirmed live on 2026-09-11). Other Public/<Mod>
+      folders a mod ships as .lsx (Lists, Progressions, ClassDescriptions, GUI atlases) do load as
+      .lsx; RootTemplates is the folder where only .lsf counted here."
+  - id: bg3.items.roottemplates.multiple-inventoryitem-nodes-roll-independently
+    claim: A single object can carry multiple InventoryList/InventoryItem child nodes, each naming a
+      different TreasureTable, and every listed table is rolled and its results all added to the
+      same inventory.
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - items
+      - treasuretable
+      - inventorylist
+      - multiple-tables
+    detail: 'Checked against the source (2026-09-08): an earlier wording added that "every listed table
+      is rolled independently and its results all added to the same inventory, rather than only the
+      first or a randomly chosen one being used". §"The 0.5th way" is a bare code block with no
+      prose at all — the two-node XML shape is attested, the rolling semantics are only the obvious
+      reading of it, so this is downgraded to inferred until someone spawns such an object and looks
+      in its inventory.'
+  - id: bg3.items.roottemplates.gameobjects-node-needs-type-stats-and-parenttemplateid-to-load
+    claim: "A RootTemplate GameObjects node that carries only MapKey, Name and VisualTemplate is not
+      loaded by the engine even when it ships as a correctly converted .lsf:
+      Ext.Template.GetTemplate returns nil for its MapKey and Osi.TemplateAddTo adds nothing. The
+      same node with Type \"item\", Stats \"<entry>\" and a ParentTemplateId (the vanilla template
+      of the stats entry's `using` parent) loads, resolves (templateType item) and spawns an item
+      that inherits the parent template's behaviour."
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - roottemplates
+      - gameobjects
+      - parenttemplateid
+      - scaffold
+      - template-exists
+    detail: "Which of Type, Stats and ParentTemplateId is individually required was not isolated (all
+      three were added at once, matching every loaded template on record: vanilla
+      WPN_HUM_Dagger_A_0, a class mod's own _merged.lsf nodes, and the 2026-09-10 chest repro). The
+      baldursgate3.new-item scaffold writes all three, taking the parent stat's RootTemplate as
+      ParentTemplateId."
+  - id: bg3.items.roottemplates.item-displayname-description-icon-live-on-the-roottemplate-not-the-stats-entry
+    claim: "An Armor or Weapon item's DisplayName, Description and Icon belong on its RootTemplate
+      GameObjects node (DisplayName/Description as TranslatedString attributes with handle=\"h…\"
+      version=\"1\", Icon as a FixedString), not as data lines on the stats entry: no vanilla Armor
+      or Weapon stats entry carries any of the three, and the Script Extender's stats object for a
+      Weapon has no DisplayName property at all (Ext.Stats.Get(\"WPN_Dagger\").DisplayName raises
+      \"Property does not exist\"), so a probe reading it can never pass. SpellData entries are
+      different: their DisplayName/Description are stats fields."
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - roottemplates
+      - displayname
+      - description
+      - icon
+      - localization
+      - stats
+      - scriptextender
+    detail: The scaffold's loca rows are unchanged (contentuid = the bare handle, version its own
+      attribute); the template references the same bare handle. The bg3.stat.fields probe on an item
+      row should ask only for fields the stats object really has (RootTemplate, Slot); ModWright's
+      baldursgate3.new-item does so.
+  - id: bg3.items.roottemplates.equipmenttypeid-must-be-guid-typed
+    claim: On a RootTemplate GameObjects node, EquipmentTypeID must be declared type="guid". Written as
+      type="FixedString" — the type its UUID-holding siblings VisualTemplate, ParentTemplateId and
+      MapKey correctly use, which is exactly what makes the mistake easy — the engine SILENTLY
+      ignores the attribute and falls back to default one-handed weapon handling (held in one hand,
+      no back-sheath, wrong attack animation), logging nothing. The wrong type is not a parse error
+      and does not fail the build; only the item's behaviour is wrong. A vanilla-corpus audit
+      (below) shows the other GUID-typed GameObjects attributes are Faction, EquipmentRace, AiHint,
+      DeathEffect, ColorPreset, and Race ON A CHARACTER template — but NOT Race on an item template,
+      where Race is a plain int8 flag (value 0/2/-1), not a GUID. The same silent-fallback failure
+      on those attributes is inferred by analogy; only the EquipmentTypeID case was field-observed.
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - items
+      - roottemplate
+      - gameobjects
+      - equipmenttypeid
+      - race
+      - faction
+      - guid
+      - attribute-type
+      - silent-fallback
+      - gotcha
+    related:
+      - id: bg3.weapons.custom-equipment-type
+        detail: Establishes what EquipmentTypeID references (the custom EquipmentType's UUID, which drives
+          idle/ sheath handling and the fallback animation set) — i.e. why the engine treats it as a
+          GUID and a FixedString mis-declaration loses the reference.
+    detail: "ModWright's bg3.items.roottemplate-guid-attribute-type validator (block) catches this from
+      the project's own .lsx with no index or toolchain: it walks every Templates/GameObjects node
+      and flags any attribute in a curated allowlist of always-guid RootTemplate attributes
+      (EquipmentTypeID, Faction, EquipmentRace, AiHint, DeathEffect, ColorPreset, and Race gated to
+      a character-Type node) whose declared type is not \"guid\", naming the file, the attribute and
+      the one-line fix. The Race gate is the load-bearing detail: an item template's Race is int8,
+      so an ungated rule would emit a block finding — with a \"change to guid\" fix — on every
+      faithful vanilla weapon/armor clone. The allowlist is deliberately narrow — the six
+      UUID-holding siblings (VisualTemplate, ParentTemplateId, MapKey, Icon,
+      CharacterVisualResourceID, PortraitVisualResourceID) are FixedString in vanilla, so a \"any
+      UUID-looking value must be guid\" rule would false-positive on all of them — and is extended
+      only as more always-guid attributes are confirmed. Object is excluded (guid, but only ever on
+      a child Tag/InventoryItem node, never on the GameObjects node itself); DisarmDifficultyClassID
+      is excluded (mixed guid/int32 in the corpus)."
+  - id: bg3.items.roottemplates.statuslist-gives-an-item-a-permanent-status
+    claim: "An item template's StatusList child (node \"StatusList\" > \"Status\" with attribute Object
+      = a status name) applies that status to every item created from the template, which is how the
+      Everburn Blade and three other vanilla weapons burn forever: their StatusList names
+      MAG_FIRE_ALWAYS_DIPPED_FIRE, a BOOST status `using DIPPED_FIRE` with
+      StatusEffectOverrideForItems 44d77ebf-fc9e-407d-b20f-257019351f2a (the dip flame),
+      StackPriority 10 and Boosts WeaponDamage(1d4, Fire). A mod status `using` it with Boosts \"\"
+      keeps the flame without the damage. Existing item instances are not retro-fitted; apply the
+      status once with Osi.ApplyStatus(<item>, \"<status>\", -1.0, 1)."
+    status: inferred
+    source: ModWright research
+    tags:
+      - roottemplates
+      - statuslist
+      - status
+      - weapon
+      - vfx
+      - everburn