Variant Loader

[KABoissonneault]

New system to make LL handle block/location variants through a more global "rules" system, rather than letting users do specific variant assignments themselves.

DFU's WorldDataVariant

• WDV is what we're dealing with. What items (ie: files) and what operations WDV allows limits what we can do without sending PRs to Gavin

Items:

• Location variant (ex: Daggerfall_wod)
• New Location
• Block variant (ex: ALCHALAA00_wod)
• Building variant (ex: ALCHALAA00.0_wod)

Operations:

• SetLocationVariant(location, variant) -> change Daggerfall to Daggerfall_wod
• SetNewLocationVariant(region, locationName, variant)
• SetBlockVariant(blockName, variant) -> change all ALCHALAA00 to ALCHALAA00_wod
• SetBlockVariant(blockName, variant, locationKey) -> change all ALCHALAA00 to ALCHALAA00_wod in Daggerfall
• SetBuildingVariant(blockName, recordIndex, variant) -> set building 0 in all ALCHALAA00 to _wod variant
• SetBuildingVariant(blockName, recordIndex, variant, locationKey) -> set building 0 in ALCHALAA00 in Daggerfall to _wod variant

Notes:

• Building variants apply to all variants of a given block! ALCHALAA00_wod must still work with ALCHALAA00.0_wod

VariantLoader

Tools:
RMBVariantScriptGenerator

• Generates variant scripts from rule specifications.
• Also generates location variants if needed (see local rules)
• Block variants are all provided by the user before running this tool
  RMBVariantRules -> RMBVariantScripts + location variants

VariantLoader

• Runtime system in LocationLoader.dfmod
• Reads RMBVariantScripts from all mods and applies instructions
• WorldDataVariant.SetBlockVariant(...) / WorldDataVariant.SetLocationVariant(...)
• Scripts are applied by mod order (if a mod has multiple scripts, their order is random)
  Question: Global scripts, script per region, script per map pixel?
  Scenario:
  Scenario 1
  • World of Daggerfall has script Daggerfall.rmbs.txt which sets ALCHALAA00 to variant _wod in location key 12317
  • Alchemy Expanded depends on World of Daggerfall, and therefore has "higher priority" (lower on the list)
  • Alchemy Expanded has HighRock.rmbs.txt, which sets ALCHALAA00 to _ae in location key 12317
  • When location 12317 is loaded, Alchemy Expanded wins, and the WoD instruction is ignored (clashing location and block target)
    Scenario 2
  • World of Daggerfall has script Daggerfall.rmbs.txt which sets ALCHALAA00 to variant _wod in location key 12317
  • Alchemy Renovated has a building replacement as ALCHALAA00.RMB-60-building0_ar.json
  • Building variant still applies to ALCHALAA00_wod

Items:
RMBVariantRules

• CSV file with .rmb.csv extension
• Each line forces a "target" block to a specified variant, if conditions are met
• Rules are not built into the mod - they're used only for the generator
  Rules
• We can divide conditions in three type
  Global
• Rule applies to all the blocks with the target in the location
• The effect can be applied with WorldDataVariant.SetBlockVariant(blockName, variant, locationKey)
• A block variant is sufficient
  Local
• Rule applies only to certain blocks with the target in the location,
  ex: North Edge, No Edge, ...
• The effect cannot be applied with WorldDataVariant.SetBlockVariant(blockName, variant, locationKey)
• Therefore, we need a location variant
  Runtime
• Rule applies depending on runtime conditions,
  ex: quest active
• Depending on other conditions, might be global or local. Global rules still work as block variants, and local rules as location variants
• This requires extra runtime to apply and remove the variant as needed

Format
OLD_BLOCK VARIANT RULE1 ... RULEN
ex: ALCHALAA00 _dhw Daggerfall HauntedWoods

• ALCHALAA00 is the target block. When the region is Daggerfall and the climate is haunted woods, the _dhw variant (ex: ALCHALAA00_dhw) should be set

RMBVariantScript

• Text file with .rmbs.txt extension. Each line has a specific format
• Set of instructions for knowing what variants to apply where
• Instruction may have runtime constraints (ex: quest id)
• Scripts are part of a built mod
  Issues:
• For any runtime rule we invent, extra data needs to be hardcoded here. VariantLoader will not try to find what rules it was generated from.
• We might not invent that many
  Format
  <locationkey> <blockname> <blockvariant> [quest <quest_id>]
  or <locationkey> variant <locvariant> [quest <quest_id>]