Semantic registry

An emulator has to reconstruct what every field of the game's data means. The risk is a model that reproduces the cases it was shown and grows special cases for the rest: increasingly coherent while increasingly wrong. This page tracks what we know about the meaning of five generic subsystems, how sure we are, and how much of the real data our implementation handles without per-id code. The format is defined in docs/design/semantic-registry.md; data provenance (where values come from) is in wildstar-delta.md.

Statuses: established (the client's code or several independent sources agree), probable (one strong source, nothing against), hypothesis (a candidate meaning with some evidence), unknown.

Summary

Quest objective types

What each QuestObjective column and objective type means, how sure we are, and which of our modules implement it.

Registry: apps/bezgelor_data/priv/semantics/quest_objectives.json; table QuestObjective.

Coverage (data rows our implementation handles generically, from the generalisation test):

• all rows: 7753 of 10031 (77%);
• rows of established or probable values: 7671 of 9648 (80%);
• special cases: 3 registered; the lint finds 3 per-id code paths in the implementation (0 unlisted).

Handled means our code has a generic route that could complete the row; whether that route is right is what the status says (a hypothesis can be handled by a reading the evidence contradicts).

Generalisation test: established or probable values with rows we don't handle

Special cases (per-id code paths)

Open questions: values the data uses whose meaning is unknown

• 19 UNUSED19 (2 rows): None: test rows.
• 27 Unknown27 (1 rows): Find the quest that holds it and its text.
• 29 Unknown29 (2 rows): Find the quests that hold them.
• 31 Unknown31 (260 rows): Issue #163: correlate data with the work-order quests' tradeskill and tier.

Prerequisites

What each Prerequisite column, type and comparison means. The client evaluates prerequisites itself, so its evaluator (WildStar64.exe 1.7.8.16042, FUN_1404a1ca0) is the main source; types it never evaluates are server-side.

Registry: apps/bezgelor_data/priv/semantics/prerequisites.json; table Prerequisite.

Coverage (data conditions our implementation handles generically, from the generalisation test):

• all conditions: 35876 of 49184 (73%);
• conditions of established or probable values: 35317 of 35537 (99%);
• special cases: 2 registered; the lint finds 0 per-id code paths in the implementation (0 unlisted).

Handled means our code has a generic route that could complete the condition; whether that route is right is what the status says (a hypothesis can be handled by a reading the evidence contradicts).

Types in PrerequisiteType.tbl that no Prerequisite row uses (41) are in the registry but not in this table.

Generalisation test: established or probable values with conditions we don't handle

Special cases (per-id code paths)

The lint finds none in apps/bezgelor_world/lib/bezgelor_world/spell/prerequisite.ex.

Registered outside the linted files:

• apps/bezgelor_data/lib/bezgelor_data/abilities.ex (Map.get(entry, :prerequisiteTypeId0) == 177), value 177: A second evaluator: reads type 177's value0 directly instead of going through Prerequisite.met?/2. (#221)
• apps/bezgelor_world/lib/bezgelor_world/spell/prerequisite.ex (aura_stacks), value 59: The fallback for a unit whose view carries the aura list without stack counts (creatures): each listed aura counts as one stack (#221)

Client differential

The client's own prerequisite evaluator runs under the Unicorn emulator on sampled real rows and character states (tools/semantics/prereq_differential.py); apps/bezgelor_world/test/semantics/prereq_differential_test.exs replays the recorded verdicts against our evaluator. Types modelled: 1, 2, 3, 6, 11, 15, 28, 52, 109, 116, 120, 243, 250. Known differences: 0.

Recorded: 6000 cases over 1500 of the 7971 eligible rows (client 1.7.8.16042, seed 20261012).

Open questions: values the data uses whose meaning is unknown

• 47 Unknown47 (1788 conditions): Server-side only: read the rows that use it (which spells, quests, events) and their objectIds/values to infer the subject.
• 76 Unknown76 (281 conditions): Server-side only: read the rows that use it (which spells, quests, events) and their objectIds/values to infer the subject.
• 275 Unknown275 (281 conditions): Decompile the client's per-type function named in the evidence to read what it compares.
• 245 Unknown245 (249 conditions): Decompile the client's per-type function named in the evidence to read what it compares.
• 71 Unknown71 (166 conditions): Read the inline case in FUN_1404a2100 for what it compares.
• 56 Unknown56 (124 conditions): Read the inline case in FUN_1404a2100 for what it compares.
• 24 InPhase (97 conditions): Decompile the client's per-type function named in the evidence to read what it compares.
• 25 CanSeePhase (48 conditions): Decompile the client's per-type function named in the evidence to read what it compares.
• 220 Unknown220 (46 conditions): Decompile the client's per-type function named in the evidence to read what it compares.
• 240 Unknown240 (31 conditions): Decompile the client's per-type function named in the evidence to read what it compares.
• 292 Unknown292 (24 conditions): Decompile the client's per-type function named in the evidence to read what it compares.
• 77 Unknown77 (9 conditions): Read the inline case in FUN_1404a2100 for what it compares.
• 90 Unknown90 (9 conditions): Decompile the client's per-type function named in the evidence to read what it compares.
• 98 Unknown98 (9 conditions): Server-side only: read the rows that use it (which spells, quests, events) and their objectIds/values to infer the subject.
• 189 Unknown189 (9 conditions): Server-side only: read the rows that use it (which spells, quests, events) and their objectIds/values to infer the subject.
• 203 Unknown203 (7 conditions): Server-side only: read the rows that use it (which spells, quests, events) and their objectIds/values to infer the subject.
• 290 Unknown290 (7 conditions): Decompile the client's per-type function named in the evidence to read what it compares.
• 241 Unknown241 (6 conditions): Decompile the client's per-type function named in the evidence to read what it compares.
• 55 Unknown55 (4 conditions): Read the inline case in FUN_1404a2100 for what it compares.
• 63 Unknown63 (4 conditions): Decompile the client's per-type function named in the evidence to read what it compares.
• 101 Unknown101 (4 conditions): Server-side only: read the rows that use it (which spells, quests, events) and their objectIds/values to infer the subject.
• 259 Unknown259 (4 conditions): Server-side only: read the rows that use it (which spells, quests, events) and their objectIds/values to infer the subject.
• 266 Unknown266 (4 conditions): Decompile the client's per-type function named in the evidence to read what it compares.
• 96 Unknown96 (3 conditions): Server-side only: read the rows that use it (which spells, quests, events) and their objectIds/values to infer the subject.
• 192 Unknown192 (3 conditions): Server-side only: read the rows that use it (which spells, quests, events) and their objectIds/values to infer the subject.
• and 21 more with 32 conditions between them: 42 IsGroupLeader, 48 Unknown48, 82 Unknown82, 97 Unknown97, 99 Unknown99, 100 Unknown100, 244 Unknown244, 248 Unknown248, 267 Unknown267, 268 Unknown268, 269 Unknown269, 271 Unknown271, 277 Unknown277, 278 Unknown278, 285 Unknown285, 286 Unknown286, 289 Unknown289, 291 Unknown291, 293 Unknown293, 294 Unknown294, 295 Unknown295.

Spell effects

What each Spell4Effects column, effect type and per-type data column (dataBits00-09) means, how sure we are, and which of our modules implement it. A row is handled generically when Caster.run_effect/6 (the effect dispatch) does something with it for a player caster and hostile or friendly targets, or when the row's own prerequisite stops it.

Registry: apps/bezgelor_data/priv/semantics/spell_effects.json; table Spell4Effects.

Coverage (data rows our implementation handles generically, from the generalisation test):

• all rows: 118577 of 131010 (91%);
• rows of established or probable values: 108275 of 111867 (97%);
• special cases: 2 registered; the lint finds 2 per-id code paths in the implementation (0 unlisted).

Handled means our code has a generic route that could complete the row; whether that route is right is what the status says (a hypothesis can be handled by a reading the evidence contradicts).

Types in the client's SpellEffectType enum that no Spell4Effects row uses (17) are in the registry but not in this table.

EffectCoverage.outcome/1 (the classification telemetry and the portal use) calls 118613 of the 131010 rows handled or visual; the dispatch handles 118577. Where they differ the row's conditions stop it (self-targeted crowd control, damage to oneself, unmodelled ForcedMove kinds) or the classification is broader than the handler.

Per-type data columns: established or probable

Every type's used columns have an entry in the registry (with the data's statistics and the tooltips that print them); these are the ones whose meaning is settled or strongly supported.

Generalisation test: established or probable values with rows we don't handle

Special cases (per-id code paths)

Client differential

The client's own effect value formula runs under the Unicorn emulator (tools/semantics/effect_oracle.py, functions EffectValue (0x140565600), stat part (0x140566d40), unit part (0x140566ad0), LevelBudget (0x14041f1b0)) on sampled real rows and unit states (tools/semantics/effect_differential.py); apps/bezgelor_world/test/semantics/effect_differential_test.exs replays the recorded values against DamageCalculator.base_value/3 and level_budget/1. Types covered: 5, 8, 10, 12, 29, 33, 118, 138. Known differences: 1.

Differences the differential found and we fixed:

• Absorption read dataBits00/01 as multiplier and base; the client reads no dataBits for it, and dataBits01 is a flat float (241 rows gave absorbs of about 10^9).
• The stat part rounded up; the client rounds half away from zero.
• Parameter type 18 squared its value; the client multiplies the level budget.
• Heals and the other non-damage types took the caster's DamageDealtMultiplier as is; the client uses at least 1.
• Non-player casters had no GameFormula 712 cap on the stat part.

Recorded differences:

• The client keeps the stat part in a signed 16-bit integer (movsx eax, r10w after 0x140566d40); stat parts beyond 32,767 wrap there. Unreachable for player stats (about 5,000 at most); not reproduced (designed-values.md). 123 of the 13,080 recorded cases (creature casters with extreme stats).

Recorded: 13080 cases over 6540 of the 34083 eligible rows (client 1.7.8.16042, seed 20261012).

Open questions: values the data uses whose meaning is unknown

• 7 Activate (2711 rows): No tooltip names its columns: find the client code that reads the type, or a retail capture of one of its 2708 spells.
• 15 UnitStateSet (752 rows): No tooltip names its columns: find the client code that reads the type, or a retail capture of one of its 673 spells.
• 23 ActionBarSet (405 rows): No tooltip names its columns: find the client code that reads the type, or a retail capture of one of its 389 spells.
• 82 ChangeDisplayName (268 rows): No tooltip names its columns: find the client code that reads the type, or a retail capture of one of its 251 spells.
• 55 ModifySpell (255 rows): No tooltip names its columns: find the client code that reads the type, or a retail capture of one of its 236 spells.
• 2 SpellCounter (200 rows): No tooltip names its columns: find the client code that reads the type, or a retail capture of one of its 200 spells.
• 51 SpellForceRemoveChanneled (175 rows): No tooltip names its columns: find the client code that reads the type, or a retail capture of one of its 104 spells.
• 34 ChangePhase (161 rows): No tooltip names its columns: find the client code that reads the type, or a retail capture of one of its 157 spells.
• 30 SapVital (142 rows): Read the 1 tooltip references to its columns (quoted in the column entries), then find the client code that reads the type.
• 13 Script (104 rows): No tooltip names its columns: find the client code that reads the type, or a retail capture of one of its 104 spells.
• 56 ModifySpellEffect (82 rows): No tooltip names its columns: find the client code that reads the type, or a retail capture of one of its 57 spells.
• 89 NpcForceFacing (79 rows): No tooltip names its columns: find the client code that reads the type, or a retail capture of one of its 31 spells.
• 60 ModifyCreatureFlags (75 rows): No tooltip names its columns: find the client code that reads the type, or a retail capture of one of its 72 spells.
• 77 AggroImmune (67 rows): No tooltip names its columns: find the client code that reads the type, or a retail capture of one of its 67 spells.
• 106 SummonTrap (64 rows): No tooltip names its columns: find the client code that reads the type, or a retail capture of one of its 58 spells.
• 132 Disembark (63 rows): No tooltip names its columns: find the client code that reads the type, or a retail capture of one of its 63 spells.
• 64 ShieldOverload (55 rows): No tooltip names its columns: find the client code that reads the type, or a retail capture of one of its 47 spells.
• 32 SpellImmunity (53 rows): No tooltip names its columns: find the client code that reads the type, or a retail capture of one of its 32 spells.
• 87 HazardModify (49 rows): Read the 1 tooltip references to its columns (quoted in the column entries), then find the client code that reads the type.
• 100 MimicDisguise (33 rows): No tooltip names its columns: find the client code that reads the type, or a retail capture of one of its 33 spells.
• 28 ForceFacing (32 rows): No tooltip names its columns: find the client code that reads the type, or a retail capture of one of its 32 spells.
• 142 VectorSlide (30 rows): No tooltip names its columns: find the client code that reads the type, or a retail capture of one of its 30 spells.
• 44 GiveLootTableToPlayer (29 rows): No tooltip names its columns: find the client code that reads the type, or a retail capture of one of its 29 spells.
• 58 AddSpellEffect (25 rows): No tooltip names its columns: find the client code that reads the type, or a retail capture of one of its 14 spells.
• 109 RestedXpDecorBonus (25 rows): No tooltip names its columns: find the client code that reads the type, or a retail capture of one of its 25 spells.
• and 43 more with 348 rows between them: 0 None, 6 SummonVehicle, 16 Resurrect, 25 ProxyChannel, 41 TradeSkillProfession, 45 NpcLootTableModify, 48 WarplotTeleport, 49 CraftItem, 57 AddSpell, 59 SuppressSpellEffect, 62 VacuumLoot, 67 TitleRevoke, 68 VendorPriceModifier, 69 ApplyLASChanges, 75 ChangeIcon, 85 PathActionExplorerDig, 86 HazardEnable, 88 HazardSuspend, 93 PathXpModify, 99 MimicDisplayName, 101 GrantXP, 105 SettlerCampfire, 108 CooldownReset, 113 RewardBuffModifier, 117 NPCForceAIMovement, 119 PathMissionIncrement, 120 GrantLevelScaledXP, 121 DelayDeath, 122 GrantLevelScaledPrestige, 124 WarplotPlugUpgrade, 126 SetMatchingEligibility, 128 GiveAugmentPowerToPlayer, 129 TemporarilyUnflagPvp, 130 SupportStuck, 131 MiniMapIcon, 134 ModifyRestedXP, 135 HousingPlantSeed, 143 ClampVital, 144 HealingAbsorption, 145 UnitPropertyConversion, 146 ActivateSpellCooldown, 148 SharedHealthPool, 149 Kill.

Public event objectives

What each PublicEventObjective column, flag bit and objective type means, how sure we are, and which of our modules implement it. A row is handled generically when the public event engine (BezgelorWorld.PublicEvent) can progress it from a game event or the clock using only the row's own data; a row driven by a content script (a dungeon, expedition, battleground or arena script that names it by id) is counted as scripted, not handled.

Registry: apps/bezgelor_data/priv/semantics/public_event_objectives.json; table PublicEventObjective.

Coverage (data rows our implementation handles generically, from the generalisation test):

• all rows: 1248 of 3703 (34%);
• rows of established or probable values: 1198 of 3581 (33%);
• special cases: 156 registered; the lint finds 156 per-id code paths in the implementation (0 unlisted).

Handled means our code has a generic route that could complete the row; whether that route is right is what the status says (a hypothesis can be handled by a reading the evidence contradicts).

Coverage by kind of event (an event belongs to the first definition file that names it; no_definition events have none and cannot be started on this server, no_event_row objectives name an event the client table lacks):

Types in the client's PublicEventObjectiveType enum that no PublicEventObjective row uses (0) are in the registry but not in this table.

Per-type data columns: established or probable

Every type's used columns have an entry in the registry (with the data's statistics and the tooltips that print them); these are the ones whose meaning is settled or strongly supported.

Generalisation test: established or probable values with rows we don't handle

Special cases (per-id code paths)

Client differential

The client's own display methods of PublicEventObjective (GetCount (0x14068E110), GetRequiredCount (0x14068EF30), ShowPercent (0x14068ED90), ShowHealthBar (0x14068EE80), ShouldShowRequiredCount (0x1406908B0), IsHidden (0x140690730), GetTotalTime (0x14068E020), GetMedalPoints (0x140690E80), ShouldShowOnMinimap / Edge (0x140690330 / 0x140690410)) run under the Unicorn emulator (tools/semantics/objective_oracle.py, via tools/semantics/objective_differential.py) on a fake objective built from a row and a status; apps/bezgelor_world/test/semantics/objective_differential_test.exs replays what the client answered for sampled real rows and a synthetic grid of every type, flag and status shape against BezgelorWorld.ClientObjectiveDisplay, our model of what the tracker shows. Known differences: 3.

Differences the differential found and we fixed:

• Checklist objectives (types 4 and 18) were sent as a plain count; the client reads the status count as a bitmask and shows its number of set bits (3 showed 2 entries, 4 showed 1, 5 showed 2). They now send a bitmask with that many low bits set.
• The client reads the table count as a signed 32-bit number: 8 rows hold 4294967295 and read as -1 (dungeon briefing talk-to objectives, whose definitions override the count).

Recorded differences:

• Exterminate (type 20) objectives with count 0: the tracker prints "Remaining: GetCount", which expects the count to be the units left; the engine sends units killed as the count and alive + killed as the dynamic max, so the tracker reads "n of m". Designed; both complete correctly (designed-values.md).
• The oracle replaces the lookup chain in front of the objective (the Lua userdata, the manager's vtable +0x30), the owning event's busy flag and team size, the live event record (value 7) and the game clock; the display rules are the client's.
• A TimedWin objective with flag 0x4000 and no failure time divides by zero in the client; no row has the combination, and the model returns 0.

Recorded: 2400 cases over 600 of the 3703 eligible rows and 2340 grid cases (client 1.7.8.16042, seed 20261012).

Creature default properties (max health)

A creature's unit properties are not sent by the client tables alone: the server derives them from the creature's level row (CreatureLevel), its archetype, difficulty and tier multipliers, and the creature's own values (Creature2OverrideProperties). The server sends the result (BaseHealth is the creature's maximum health). NexusForever's model is the multiplied level row; the retail captures show that max health also adds 14 per point of Stamina and that an override replaces the default as it stands. Coverage here counts the captured (creature, level) pairs whose Health the formula reproduces.

Registry: apps/bezgelor_data/priv/semantics/creature_properties.json; table CreatureLevel, Creature2ArcheType, Creature2Difficulty, Creature2Tier, Creature2OverrideProperties.

Coverage (tools/ground_truth/reconcile.py over the NexusForever retail captures: a captured (creature, level) pair is handled when the formula gives its Health (within 1.5%)):

• all captures: 8616 of 8734 (99%);
• captures of established or probable values: 8616 of 8734 (99%);
• special cases: 0 registered; the lint finds 0 per-id code paths in the implementation (0 unlisted).

Handled means our code has a generic route that could complete the capture; whether that route is right is what the status says (a hypothesis can be handled by a reading the evidence contradicts).

Fields

Generalisation test: established or probable values with captures we don't handle

Special cases (per-id code paths)

The lint finds none in apps/bezgelor_world/lib/bezgelor_world/creature_properties.ex.

Updated automatically from the registry data; see how.