modwright 0.1.0

package/knowledge/baldursgate3/compatibilityframework.api.yaml

@@ -0,0 +1,176 @@
+game: baldursgate3
+topic: compatibilityframework.api
+title: Compatibility Framework injection API (Selectors, Strings, Subclasses)
+facts:
+  - id: bg3.compatibility-framework.api.purpose-inject-not-overwrite
+    claim: The Compatibility Framework's stated purpose is letting Script-Extender-enabled mods "insert
+      values into Progressions and Spell/Skill/PassiveLists at Runtime", so a mod "can inject their
+      mod's data into existing Progressions or Lists without overwriting data, allowing for total
+      compatibility." It was "Initially designed for Subclass Compatibility".
+    status: community
+    source: github.com/BG3-Community-Library-Team/BG3-Compatibility-Framework Readme.md (opening paragraph)
+    tags:
+      - compatibility-framework
+      - purpose
+      - overwrite
+      - progressions
+    detail: "Why this is the default scaffold shape rather than raw list edits is ModWright's own
+      conclusion, not the README's: ModWright research calls raw overwrites \"the single most common
+      cross-mod incompatibility in this category.\""
+  - id: bg3.compatibility-framework.api.load-order-bottom
+    claim: The Compatibility Framework should be loaded at the bottom of a mod list, per its own
+      installation instructions.
+    status: community
+    source: github.com/BG3-Community-Library-Team/BG3-Compatibility-Framework Readme.md §Installation >
+      Load Order ("Compatibility Framework should be loaded at the bottom of your mods list.")
+    tags:
+      - compatibility-framework
+      - load-order
+  - id: bg3.compatibility-framework.api.config-file-location
+    claim: "The Compatibility Framework reads a per-mod config from either
+      Mods/ModName/ScriptExtender/CompatibilityFrameworkConfig.yaml or
+      Mods/ModName/ScriptExtender/CompatibilityFrameworkConfig.json, as an alternative to calling
+      its Lua API directly; every entry starts with FileVersion: 1, and YAML is the recommended form
+      as of v2.8.0.0."
+    status: community
+    source: BG3-Compatibility-Framework wiki, _Class-Module.md ("You may do this with a
+      CompatibilityFrameworkConfig.json or CompatibilityFrameworkConfig.yaml file placed in your
+      Mods/ModName/ScriptExtender/ folder"), _Selector-API.md and _Boosts-and-Passives.md (both
+      headed "YAML Configuration (Recommended - v2.8.0.0)")
+    tags:
+      - compatibility-framework
+      - config-file
+      - scriptextender
+    detail: 'Confirmed against the repo itself:
+      CompatibilityFramework/Mods/SubclassCompatibilityFramework/
+      ScriptExtender/Lua/ConfigLayer/_ConfigLoader.lua builds its path from
+      "Mods/%s/ScriptExtender/CompatibilityFrameworkConfig." and tries both extensions.'
+  - id: bg3.compatibility-framework.api.selectors-target-progression-or-feat-by-uuid
+    claim: A Selectors config entry lives inside a Progressions or Feats list entry (identified by UUID
+      or, for multiple targets at once, UUIDs) and has required fields Action ("Insert" or "Remove")
+      and Function (one of SelectSpells, AddSpells, SelectSkills, SelectAbilities,
+      SelectAbilityBonus, SelectEquipment, SelectSkillsExpertise, or SelectPassives); Insert
+      additionally requires Params, Remove requires the target list's UUID instead.
+    status: community
+    source: BG3-Compatibility-Framework wiki, _Selector-API.md §Selector fields reference (Action /
+      Function / Params / UUID rows)
+    tags:
+      - compatibility-framework
+      - selectors
+      - config-schema
+  - id: bg3.compatibility-framework.api.target-uuid-must-not-point-at-mergedinto-data
+    claim: A Selectors/Strings/Subclasses config entry's target UUID or UUIDs must never point at data
+      carrying a MergedInto attribute — it should point at the data that MergedInto data merges into
+      instead, or the injection targets the wrong (superseded) entry.
+    status: community
+    source: 'BG3-Compatibility-Framework wiki, _Selector-API.md, _Boosts-and-Passives.md,
+      _Class-Module.md (all three: "The target UUID or UUIDs should never point to data that has a
+      MergedInto attribute. Instead, you should point them to the data that they merge into.")'
+    tags:
+      - compatibility-framework
+      - mergedinto
+      - gotcha
+  - id: bg3.compatibility-framework.api.replacepassives-read-as-selectpassives
+    claim: The game engine reads a ReplacePassives selector as SelectPassives internally; when using the
+      Compatibility Framework to manipulate what looks like a ReplacePassives selector, it may need
+      to be targeted as a SelectPassives selector instead.
+    status: community
+    source: 'BG3-Compatibility-Framework wiki, _Selector-API.md (opening note: "The game reads
+      ReplacePassives as SelectPassives - when manipulating a ReplacePassives selector, you may need
+      to make it a SelectPassives selector instead")'
+    tags:
+      - compatibility-framework
+      - replacepassives
+      - selectpassives
+      - gotcha
+  - id: bg3.compatibility-framework.api.modguid-makes-entry-conditional
+    claim: Adding a modGuid field to a Selectors/Strings config entry makes that specific insertion
+      conditional on another mod being loaded — the entry is skipped entirely if the named mod (by
+      its meta.lsx UUID) is not present.
+    status: community
+    source: BG3-Compatibility-Framework wiki, _Selector-API.md and _Boosts-and-Passives.md fields
+      references ("modGuid | No | UUID of a required mod; entry is skipped if that mod is not
+      loaded")
+    tags:
+      - compatibility-framework
+      - modguid
+      - conditional
+  - id: bg3.compatibility-framework.api.strings-type-covers-four-fields
+    claim: A Strings config entry (for inserting/removing values on a Progression or Feat) requires
+      Action ("Insert" or "Remove") and Type, where Type must be one of Boosts, PassivesAdded,
+      PassivesRemoved, or Requirements — the same YAML/JSON entry shape and the same underlying API
+      call handle all four Types.
+    status: community
+    source: 'BG3-Compatibility-Framework wiki, _Boosts-and-Passives.md §Fields reference (Type row:
+      "Boosts, PassivesAdded, PassivesRemoved, or Requirements") and §API ("Behind the scenes, these
+      all work in the same way, so the same API call can be used for all of them")'
+    tags:
+      - compatibility-framework
+      - strings
+      - boosts
+      - passivesadded
+      - requirements
+  - id: bg3.compatibility-framework.api.subclass-addition-fully-automatic-since-2-6-5-8
+    claim: As of Compatibility Framework 2.6.5.8, adding a subclass requires no explicit registration
+      call at all — any valid ClassDescription entry with a ParentGuid pointing at its parent
+      class's ClassDescription is picked up automatically.
+    status: community
+    source: BG3-Compatibility-Framework wiki, _Class-Module.md §Subclass Addition ("Adding subclasses is
+      now automatic as of 2.6.5.8, and requires no action on a mod author's part")
+    tags:
+      - compatibility-framework
+      - subclass
+      - version-floor
+      - automatic
+  - id: bg3.compatibility-framework.api.subclass-removal-requires-explicit-config-since-2-7-0-0
+    claim: "Removing a subclass from a Progression (added in Compatibility Framework 2.7.0.0) is not
+      automatic and must be done explicitly, either via a Progressions/Subclasses config entry
+      (Action: Remove, the subclass's ClassDescription UUID) or by calling the Api.RemoveSubClasses
+      Lua endpoint directly."
+    status: community
+    source: 'BG3-Compatibility-Framework wiki, _Class-Module.md §Subclass Removal ("To Remove Subclasses
+      from a Progression (Implemented in 2.7.0.0), you have two options: The Config Method or
+      directly calling the API")'
+    tags:
+      - compatibility-framework
+      - subclass
+      - removal
+      - version-floor
+  - id: bg3.compatibility-framework.api.removesubclasses-class-param-accepts-name-or-uuid
+    claim: Api.RemoveSubClasses's per-entry "class" field accepts either the lowercase name of the
+      parent class (one of barbarian, bard, cleric, druid, fighter, monk, paladin, ranger, rogue,
+      sorcerer, warlock, wizard) or the UUID of the Progression at which subclass options for that
+      class become available.
+    status: community
+    source: 'BG3-Compatibility-Framework wiki, _Class-Module.md §API > Api.RemoveSubClasses (the "class"
+      field: "The lower-case name of your classes Parent class" or "The UUID of the Progression at
+      which the subclass options for the parent class become available")'
+    tags:
+      - compatibility-framework
+      - api
+      - removesubclasses
+  - id: bg3.compatibility-framework.api.insert-remove-boost-passive-endpoints
+    claim: Api.InsertBoosts, Api.InsertPassives, and Api.InsertPassivesForRemoval all route to the same
+      underlying logic and take the same payload shape (modGuid, Target, FileType, Type, Strings);
+      the mirrored removal endpoints Api.RemoveBoosts, Api.RemovePassives, and
+      Api.RemovePassivesForRemoval work the same way in reverse.
+    status: community
+    source: BG3-Compatibility-Framework wiki, _Boosts-and-Passives.md §API > Adding Strings, > Removing
+      Strings
+    tags:
+      - compatibility-framework
+      - api
+      - insertboosts
+      - insertpassives
+  - id: bg3.compatibility-framework.api.yaml-anchors-share-selector-definitions
+    claim: The YAML config format supports standard YAML anchors and aliases to reuse one
+      Selectors/Strings definition across multiple Progression/Feat targets; each alias produces an
+      independent deep copy, so editing one applied instance does not affect the others.
+    status: community
+    source: 'BG3-Compatibility-Framework wiki, _Selector-API.md §YAML Anchors & Aliases and
+      _Boosts-and-Passives.md §YAML Anchors & Aliases (both: "Each alias produces an independent
+      deep copy.")'
+    tags:
+      - compatibility-framework
+      - yaml
+      - anchors

package/knowledge/baldursgate3/crash.causes.yaml

@@ -0,0 +1,90 @@
+game: baldursgate3
+topic: crash.causes
+title: Crash and freeze causes found in production
+facts:
+  - id: bg3.crash.islinkedspellcontainer-unlinked
+    claim: The SpellFlags value IsLinkedSpellContainer without any linked spells is an instant
+      null-deref crash. Use vanilla-proven flags (e.g. SpellFlags
+      "HasSomaticComponent;HasVerbalComponent") instead.
+    status: verified
+    source: ModWright field verification
+    tags:
+      - crash
+      - spells
+      - flags
+      - spellflags
+    detail: "Symptom on an earlier mod: CTD in the SYS_CC_I character-creation level when the origin was
+      selected; bin\\network.*.log showed that no level transition to TUT_Avernus_C ever started.
+      Fixed by swapping the flag for HasSomaticComponent;HasVerbalComponent. A later mod's dev-loop
+      notes carry it as rule 3 of the five rules that caused CTDs on that earlier mod."
+  - id: bg3.crash.spell-missing-spellanimation
+    claim: 'Never author a spell without a SpellAnimation, or a `using` parent that has one. Without it
+      the CastTextEvent "Cast" keyframe never fires: the spell "casts" but never resolves (eyes
+      glow, nothing happens).'
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - crash
+      - spells
+      - spellanimation
+      - silent-failure
+    detail: 'No error is logged; the entry loads fine and only misbehaves in-engine. "This bit us hard."
+      Fix: give every spell an explicit SpellAnimation or a `using` parent that carries one.'
+  - id: bg3.crash.dangling-tag-guid
+    claim: A custom tag GUID used in Origins.lsx ReallyTags must have a Tags.lsx definition; an
+      undefined tag UUID is believed to null-deref in tag lookup when the character is selected. Use
+      vanilla tags or define your own.
+    status: unverified
+    source: ModWright research
+    tags:
+      - crash
+      - tags
+      - origins
+      - references
+    detail: The source lists this among "likely crash causes ... not yet tested" — it was fixed at the
+      end of the final session on an earlier mod and the fix was never run. The dev-loop notes of a
+      later class mod restate it as one of the five rules that caused CTDs on that earlier mod, but
+      no passage records an isolated in-engine test.
+  - id: bg3.crash.dangling-spelllist-reference
+    claim: A SpellLists.lsx entry naming a spell that was removed from Spells.txt is a dangling
+      reference and is believed to cause a null lookup. SpellLists.lsx must stay in sync with
+      Spells.txt.
+    status: unverified
+    source: ModWright research
+    tags:
+      - crash
+      - spells
+      - spelllists
+      - references
+    detail: "Same status as the dangling tag GUID: fixed at the end of the final session on an earlier
+      mod, never tested. A later class mod's dev-loop notes restate it as a rule. A reference
+      checker (a script that cross-checks SpellLists.lsx against Spells.txt) catches it before
+      packing regardless."
+  - id: bg3.crash.arearadius-hp-budget-targeting
+    claim: AreaRadius / HP-budget targeting spells (e.g., Target_Sleep) FREEZE the game if reskinned to
+      single-target with a huge MaximumTotalTargetHP — the target-preview scan chokes.
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - crash
+      - spells
+      - targeting
+      - ui-freeze
+    detail: For a single-target no-save effect, base the spell on a clean single-target spell such as
+      Target_CrownOfMadness instead of reskinning an AreaRadius/HP-budget base.
+  - id: bg3.crash.xml-comments-loca-parse
+    claim: NEVER put XML comments (<!-- -->) in a Localization .xml — the loca parser CTDs the game
+      whenever the owning module is ACTIVE. Module inactive = no crash (the loca never parses).
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - crash
+      - localization
+      - xml
+      - comments
+    detail: 'Symptom timing varies with WHEN the module activates: pre-menu (module pre-enabled at boot)
+      or ~67% of save-load (module enabled via the save screen Mod Verification checkbox). The
+      "module inactive = no crash" behaviour is what makes this maddening to bisect.'

package/knowledge/baldursgate3/dialogue.dialogbank.yaml

@@ -0,0 +1,120 @@
+game: baldursgate3
+topic: dialogue.dialogbank
+title: Non-override dialogue editing via DialogBank and TimelineBank resource headers
+facts:
+  - id: bg3.dialogue.dialogbank.isolated-lsx-header-for-dialogbank-edits
+    claim: To retarget a single Dialog Assets Resource Bank entry without an override mod, create a
+      standalone .lsx containing only that one edited resource, with the exact header `<region
+      id="DialogBank"><node id="DialogBank"><children>...</children></node></region>` inside a
+      `<save><version major="4" minor="0" revision="9" build="0"
+      lslib_meta="v1,bswap_guids,lsf_adjacency" />` wrapper — not the full vanilla file with every
+      other bank entry included.
+    status: community
+    source: bg3-community/Tutorials/dialogue-files-tutorial.md:159-172, §Creating Dialog Mods With
+      Compatibility In Mind (DialogBank header code block)
+    tags:
+      - dialogue
+      - dialogbank
+      - lsx
+      - header
+      - non-override
+  - id: bg3.dialogue.dialogbank.timelinebank-header-for-generateddialogtimelines-edits
+    claim: The equivalent isolated-.lsx technique for a GeneratedDialogTimelines entry uses a
+      `TimelineBank` region/node instead of `DialogBank`, with the same save/version wrapper
+      attributes — a distinct region id per bank type, not a shared one.
+    status: community
+    source: bg3-community/Tutorials/dialogue-files-tutorial.md:176-190, §Creating Dialog Mods With
+      Compatibility In Mind (TimelineBank header code block)
+    tags:
+      - dialogue
+      - timelinebank
+      - generateddialogtimelines
+      - lsx
+      - header
+  - id: bg3.dialogue.dialogbank.repoint-by-editing-sourcefile-path-only
+    claim: The recommended non-override technique is to leave a DialogBank/TimelineBank resource's other
+      fields untouched and only change its file-path attribute to point into the mod's own folder
+      instead of the original Gustav/GustavDev/Shared/SharedDev path, then move the actual edited
+      file to that new path — not to duplicate or rename the resource entry itself.
+    status: community
+    source: bg3-community/Tutorials/dialogue-files-tutorial.md:196, §Creating Dialog Mods With
+      Compatibility In Mind ("You'll then want to update the file path for these resources,
+      replacing the original Gustav/GustavDev/Shared/SharedDev folder in the file path with your mod
+      folder name."; the next sentence adds moving the edited files to that new path)
+    tags:
+      - dialogue
+      - dialogbank
+      - repoint
+      - non-override
+    related:
+      - id: bg3.dialogue.dialogbank-namespaced-pattern
+        detail: Generalizes the existing verified fact's mod-specific recipe (byte-for-byte copies of
+          vanilla Resource nodes with only SourceFile re-pointed) into the community tutorial's
+          stated general technique for any DialogBank/TimelineBank entry, independent of the
+          specific example.
+  - id: bg3.dialogue.dialogbank.only-include-resources-actually-being-edited
+    claim: A non-override DialogBank/TimelineBank/GeneratedDialogTimelines .lsx should contain only the
+      resource entries actually being changed, never a full copy of the vanilla bank — "you should
+      only include the entries for the dialog timelines you're editing in your mods," since these
+      vanilla files are described as "huge."
+    status: community
+    source: bg3-community/Tutorials/dialogue-files-tutorial.md:125-133, §Generated Dialog Timelines and
+      §Dialog Assets Resource Banks
+    tags:
+      - dialogue
+      - dialogbank
+      - generateddialogtimelines
+      - minimal-diff
+  - id: bg3.dialogue.dialogbank.dialogbank-sourcefile-repoints-to-lsj-path
+    claim: A DialogBank Resource node's file-path attribute must be repointed to a .lsj path
+      (Mods\<mod>\Story\ Dialogs\<rel>.lsj) even when the mod ships no .lsj file at all — the engine
+      follows that .lsj-shaped path and resolves through it to the actual DialogsBinary .lsf, which
+      is why a working DialogBank entry can reference a file that does not exist on disk in that
+      exact form.
+    status: community
+    source: bg3-community/Tutorials/dialogue-files-tutorial.md:143-145, §What Goes Into Dialog... "A
+      note" callout ("Even entirely new modded dialog files can be referenced without an .lsj file,
+      even when the file path is set to look for an .lsj file."; the same callout states the banks
+      refer to the .lsj paths and that the game resolves the corresponding DialogsBinary .lsf
+      through them)
+    tags:
+      - dialogue
+      - dialogbank
+      - lsj
+      - lsf
+      - resolution
+    related:
+      - id: bg3.dialogue.dialogbank-namespaced-pattern
+        detail: Explains the mechanism behind the existing fact's "SourceFile re-pointed to
+          Mods/<mod>/Story/Dialogs/<rel>.lsj" step — that .lsj path resolves to the accompanying
+          .lsf even with no .lsj physically present, which is why the namespaced pattern needs no
+          .lsj to ship.
+  - id: bg3.dialogue.dialogbank.timeline-and-scene-must-move-together
+    claim: When repointing a GeneratedDialogTimelines entry, the Dialog Timeline and its paired Dialog
+      Scene file must both be relocated into the new (mod-namespaced) file path together — "if
+      they're not in the same file path, the game will reference the vanilla files, instead of your
+      edited ones."
+    status: community
+    source: bg3-community/Tutorials/dialogue-files-tutorial.md:198, §Creating Dialog Mods With
+      Compatibility In Mind ("If they're not in the same file path, the game will reference the
+      vanilla files, instead of your edited ones."; the preceding sentence is the bolded instruction
+      to place them together)
+    tags:
+      - dialogue
+      - timeline
+      - dialog-scene
+      - silent-failure
+  - id: bg3.dialogue.dialogbank.nested-dialogue-eases-compat-over-timeline-edits
+    claim: Nested Dialog files (separate dialogue files linked from a parent DialogsBinary, e.g.
+      companion romance content) are explicitly recommended over editing a shared Dialog Timeline
+      for compatibility, because "editing the DialogsBinary files to link to nested dialogue is much
+      simpler, and will allow for much easier compatibility patching between mods" than merging two
+      mods' edits to the same Timeline file.
+    status: community
+    source: bg3-community/Tutorials/dialogue-files-tutorial.md:365-370, §How To Edit > "Linking Nested
+      Dialogue"
+    tags:
+      - dialogue
+      - nested-dialog
+      - compatibility
+      - timeline

package/knowledge/baldursgate3/dialogue.files.yaml

@@ -0,0 +1,236 @@
+game: baldursgate3
+topic: dialogue.files
+title: The five dialogue file types, their locations, and non-override editing headers
+facts:
+  - id: bg3.dialogue.files.five-dialogue-specific-file-types
+    claim: "A BG3 scene is built from five distinct dialogue-specific file types: DialogsBinary files,
+      Dialog Timeline files, Dialog Scene files, GeneratedDialogTimelines files, and Dialog (Assets
+      Resource Bank) files. The tutorial calls the first three \"most likely what you'll be
+      editing\" and the last two \"what help the game reference the first three files.\""
+    status: community
+    source: bg3-community/Tutorials/dialogue-files-tutorial.md §What Goes Into Dialog in Baldur's Gate 3?
+    tags:
+      - dialogue
+      - file-types
+      - overview
+  - id: bg3.dialogue.files.scene-lsf-not-lsx-is-the-real-file
+    claim: Extracting a Dialog Scene produces both a .lsf and a same-named .lsx; the .lsf is the one the
+      tutorial says to edit. Those .lsx files (and the Dialogs .lsj files alongside them) are
+      described as what Larian's engine uses to generate the DialogsBinary and Dialog Scene .lsf
+      files.
+    status: community
+    source: bg3-community/Tutorials/dialogue-files-tutorial.md:54-58, §What Goes Into Dialog... ("The
+      Dialog Scene files with the .lsf file extension are what you'll want to edit, NOT the .lsx
+      files")
+    tags:
+      - dialogue
+      - dialog-scene
+      - lsf
+      - lsx
+      - gotcha
+    detail: 'Checked against the source (2026-09-08): an earlier wording ended "and editing it has no
+      effect on the shipped scene". The same paragraph says the opposite for the .lsj half of that
+      pair — "the Dialogs .lsj files can be edited and included in your mod without an accompanying
+      DialogsBinary .lsf file, and create a working scene" — so the no-effect clause has been
+      removed. The page does not say what shipping an edited Scene .lsx alone does.'
+  - id: bg3.dialogue.files.timeline-and-dialogsbinary-paths
+    claim: Dialog Timeline files live under Data\Public\<Module>\Timeline\Generated (Gustav, GustavDev,
+      and sometimes Shared/SharedDev); DialogsBinary files live under
+      Data\Mods\<Module>\Story\DialogsBinary (Gustav, GustavDev), further split into subfolders by
+      game section (e.g. Act 3, Tutorial, Companion dialog).
+    status: community
+    source: bg3-community/Tutorials/dialogue-files-tutorial.md §A Summary of Dialog Timeline Files, and
+      the DialogsBinary paragraph immediately after it
+    tags:
+      - dialogue
+      - file-paths
+      - timeline
+      - dialogsbinary
+  - id: bg3.dialogue.files.scene-dialogsbinary-timeline-share-filename
+    claim: For a given scene, the DialogsBinary, Dialog Timeline, and Dialog Scene files all share the
+      same base file name; the Dialog Scene file's name is that same base name with the literal word
+      "Scene" appended.
+    status: community
+    source: bg3-community/Tutorials/dialogue-files-tutorial.md §Dialog Scene files ("will all have the
+      same file name, with the Dialogue Scene files just appending the word Scene to that same file
+      name")
+    tags:
+      - dialogue
+      - naming-convention
+      - dialog-scene
+  - id: bg3.dialogue.files.default-scene-inheritance-path
+    claim: A Dialog Scene file can inherit camera/lighting/character-presence settings from a base scene
+      file, most commonly the default one at Public\Shared\Timeline\Scenes\Default\, "often linked
+      at the bottom of the file."
+    status: community
+    source: bg3-community/Tutorials/dialogue-files-tutorial.md §Dialog Scene files
+    tags:
+      - dialogue
+      - dialog-scene
+      - inheritance
+      - default-scene
+  - id: bg3.dialogue.files.resource-bank-still-points-at-lsj-even-for-lsf-only-mods
+    claim: "A Dialog Assets Resource Bank entry's file path always names the Dialogs .lsj file, never
+      the DialogsBinary .lsf directly — even when a mod ships only a new/modified .lsf and no .lsj
+      at all, the engine still resolves through that .lsj-shaped path to find the .lsf. Pointing a
+      Resource Bank entry at the .lsf path instead breaks the scene: \"the game won't be able to
+      play the scene.\""
+    status: community
+    source: bg3-community/Tutorials/dialogue-files-tutorial.md:143-145, §What Goes Into Dialog..., "A
+      note" callout ("If you refer to the DialogsBinary .lsf file instead in these resources, the
+      game won't be able to play the scene!"; the surrounding paragraph states the banks still name
+      the .lsj paths and that the game resolves the .lsf through them, even with no .lsj present)
+    tags:
+      - dialogue
+      - dialog-assets-resource-bank
+      - lsj
+      - lsf
+      - gotcha
+    related:
+      - id: bg3.dialogue.dialogbank.dialogbank-sourcefile-repoints-to-lsj-path
+        detail: Both facts independently describe the same lsj-path-even-without-an-lsj-file resolution
+          behavior; this one is the general statement from the dialogue-files tutorial, the other is
+          the specific DialogBank Resource-node header this general rule applies to.
+  - id: bg3.dialogue.files.override-mods-invisible-to-igmm-and-unordered
+    claim: A dialogue override mod (files placed at the exact vanilla path) shows with an orange
+      background in BG3 Mod Manager but never appears in Larian's in-game mod manager at all, and
+      cannot be reliably reordered relative to other override mods even inside BG3 Mod Manager —
+      "which override mod takes priority seems to be random."
+    status: community
+    source: bg3-community/Tutorials/dialogue-files-tutorial.md:205, §Creating Dialog Mods With
+      Compatibility In Mind ("Which override mod takes priority seems to be random, which means
+      override mods also can't be reliably patched for compatibility."; the two preceding sentences
+      state that override mods do not appear in the IGMM and cannot be reliably ordered in BGMM)
+    tags:
+      - dialogue
+      - override
+      - load-order
+      - compatibility
+    related:
+      - id: bg3.dialogue.override-packing-rule-was-wrong
+        detail: Complements the existing verified fact (that dialog overrides CAN be packed and don't CTD)
+          with a separate, still-open caveat from the community side about override load-order being
+          unpredictable — packing safely and ordering predictably are different problems.
+  - id: bg3.dialogue.files.compat-patch-needs-unique-mod-folder-name
+    claim: When patching two dialogue mods for compatibility by merging their edits into one shared
+      file, the patch's own mod folder name must be unique — "mods that use the same mod folder name
+      can cause your mod load order to reset."
+    status: community
+    source: bg3-community/Tutorials/dialogue-files-tutorial.md §Creating Dialog Mod Compatibility
+      Patches ("The mod folder for the patch should be unique; mods that use the same mod folder
+      name can cause your mod load order to reset")
+    tags:
+      - dialogue
+      - compatibility-patch
+      - mod-folder
+      - load-order
+      - gotcha
+  - id: bg3.dialogue.files.eleven-dialogue-node-types
+    claim: "The tutorial documents 11 DialogsBinary node types: TagGreeting, TagAnswer, TagQuestion,
+      TagCinematic, ActiveRoll, PassiveRoll, RollResult, Alias, Jump, Nested Dialog, and RootNodes —
+      more than the subset already recorded (TagGreeting, TagQuestion, TagAnswer, ActiveRoll,
+      RollResult, Jump, Alias), adding TagCinematic, PassiveRoll, Nested Dialog, and RootNodes."
+    status: community
+    source: bg3-community/Tutorials/dialogue-files-tutorial.md:236-294, §Documentation (node type list
+      and per-type entries)
+    tags:
+      - dialogue
+      - node-graph
+      - node-types
+    detail: "The page hedges its own list: 11 types are \"all I've found at this point\", with an
+      explicit \"There might be something I've missed\" — treat it as the largest attested list, not
+      a closed set."
+    related:
+      - id: bg3.dialogue.node-structure
+        detail: Extends the existing verified fact's node-type list with four additional documented node
+          types not previously recorded (TagCinematic, PassiveRoll, Nested Dialog, RootNodes).
+  - id: bg3.dialogue.files.jump-jumptargetpoint-1-vs-2
+    claim: "A Jump node's jumptargetpoint attribute controls whether the jump lands ON the target line
+      or skips past it: jumptargetpoint 1 takes you to the target line itself, jumptargetpoint 2
+      skips over it — used specifically to bypass a PassiveRoll node \"which will keep retriggering
+      unless they're bypassed by a Jump node.\""
+    status: community
+    source: bg3-community/Tutorials/dialogue-files-tutorial.md §Jump ("a jumptargetpoint of 1 will take
+      you to the line, while a jumptargetpoint of 2 will skip over it")
+    tags:
+      - dialogue
+      - jump
+      - jumptargetpoint
+    related:
+      - id: bg3.dialogue.node-structure
+        detail: "Confirms the existing verified fact's shorthand (\"jumptargetpoint: 2 = target's
+          children\") by spelling out both values (1 = land on the line, 2 = skip over it) and the
+          PassiveRoll use case that motivates using 2."
+  - id: bg3.dialogue.files.checkflags-usage-type-by-flag-kind
+    claim: "A dialogue flag's usage type corresponds to which kind of flag it is: Global flags are
+      \"often given usage type 5\"; HasMet-style flags (whether one character has met another) are
+      \"usually given usage type 6,\" corresponding to the \"Dialog\" flag type seen in
+      DialogsBinary files. Matching the usage type to an existing same-kind flag when authoring a
+      new custom flag keeps the convention consistent."
+    status: community
+    source: bg3-community/Tutorials/dialogue-files-tutorial.md:354-356, §How To Edit > "Making custom
+      game flags" (usage type 6 for HasMet flags, usage type 5 for Global flags, and the advice to
+      copy the usage type from an existing flag of the same type)
+    tags:
+      - dialogue
+      - checkflags
+      - flags
+      - usage-type
+    detail: The page hedges the meaning of the Dialog flag type itself ("I believe this flag type is
+      used to mark flags that are tested in dialog specifically... but I'm not entirely sure yet"),
+      so treat the type-to-usage mapping as a convention to copy, not a rule the engine is known to
+      enforce.
+  - id: bg3.dialogue.files.flag-scope-kinds-tag-global-local-object
+    claim: "checkflags/setflags distinguish four flag scopes: Tag flags test what tags a character has;
+      Global flags are true/false for the whole game, not per-character; Local flags \"seem to be\"
+      set on the player character specifically (the page's own hedge); Object flags test whether the
+      specific character being spoken to has a flag set — Object flags are \"distinct from tags;
+      flags are conditional, and are usually set during gameplay, as opposed to tags, which are used
+      to determine different qualities of a character.\""
+    status: community
+    source: bg3-community/Tutorials/dialogue-files-tutorial.md:344, §How To Edit > "Checking game flags"
+    tags:
+      - dialogue
+      - checkflags
+      - flag-scope
+      - tag
+      - global
+      - local
+      - object
+  - id: bg3.dialogue.files.scriptflags-lsx-must-stay-lsx
+    claim: Script flags (for testing OR/NOR combinations of conditions that plain checkflags AND/NOT
+      logic cannot express) are declared in Mods\<Mod>\Story\Dialogs\ScriptFlags\ScriptFlags.lsx;
+      this file "should be left an .lsx file, and should not be converted to .lsf in order to
+      function" — unlike DialogsBinary files, which must be .lsf.
+    status: community
+    source: bg3-community/Tutorials/Dialogue/script-flags.md §Making script flags ("This file should be
+      left an .lsx file, and should not be converted to .lsf in order to function")
+    tags:
+      - dialogue
+      - scriptflags
+      - lsx
+      - silent-failure
+  - id: bg3.dialogue.files.scriptflag-check-syntax-c-numbered-conditions
+    claim: A ScriptFlags entry lists one or more CONDITION lines, each implicitly numbered by position
+      (c1, c2, c3, ...), and a single CHECK line whose string combines them with & (AND), | (OR),
+      and parentheses for grouping — e.g. CHECK "(c1&c3)|(c2&c4)" evaluates true if either the
+      first-and-third conditions are both true, or the second-and-fourth are.
+    status: community
+    source: bg3-community/Tutorials/Dialogue/script-flags.md §Making script flags (worked example, CHECK
+      "(c1&c3)|(c2&c4)"), §Evaluating script flag conditions
+    tags:
+      - dialogue
+      - scriptflags
+      - syntax
+      - condition
+      - check
+  - id: bg3.dialogue.files.dialogvariables-lsx-path
+    claim: New dialogue variables (strings, numeric countdowns, etc. testable from script flags and
+      Osiris) are declared in Mods\<Mod>\Story\Dialogs\DialogVariables\DialogVariables.lsx,
+      referenced elsewhere by their own UUID the same way flags are.
+    status: community
+    source: bg3-community/Tutorials/Dialogue/script-flags.md §Dialog variables
+    tags:
+      - dialogue
+      - dialogvariables
+      - file-path