Source Verification

Define the claim to verify

Verification starts with a precise claim, not a source type. State whether you need to prove a symbol's existence, its argument contract, runtime owner, event ordering, route registration, or availability in the active build. Then collect evidence that addresses that claim directly.

Use the Source Evidence Ladder to compare the strength and limits of those evidence types; this page focuses on the trace and checks that turn them into a verified contract.

Verification workflow

Useful source areas

• scripts/client for account/avatar behavior, controllers, GUI, input, and helpers.
• scripts/common for descriptors, constants, events, item data, and shared types.
• scripts/client/gui/shared for caches, wrappers, events, and shared UI state.
• scripts/client/gui/Scaleform for legacy view aliases, DAAPI contracts, and controllers.
• scripts/client/gui/impl for Wulf views, state machines, generated view models, and modern UI.
• Feature-package roots for seasonal or mode-specific controllers, entity definitions, and lifecycle registration.
• Built Gameface assets and localization catalogs for front-end names and resource paths.

Verify Gameface resource paths

A resource declaration for the target WG version, its generated accessor, the runtime numeric ID, and the packaged coui:// file path form one contract. Verify all of them before changing an entrance or directory name.

• Resolve the native WG 2.4.1 gui/gen_resources path, or historical WG resource-map path, to the exact HTML file in the runtime VFS.
• Check HTML, CSS, and JavaScript existence directly instead of inferring structure from abbreviated load logs.
• Distinguish authoring or copy directories from the paths that actually become packaged VFS resources.
• On historical WG, allow required map regeneration and restart. On WG 2.4.1, verify strict JSON, unique declaration filenames, dotted-ID parity, and package mounting.

See Gameface diagnostics for the complete verification order.

Search efficiently

• Search imports and call sites together: imports show ownership; calls show expected use.
• Search all feature-package roots, not only the core scripts tree.
• Narrow by file type and subsystem before searching generated assets broadly.
• Do not treat a missing readable source file as proof that a runtime-generated module is absent.
• Confirm an event's implementation: exception behavior differs between ordinary and safe event types.

Do not pin guidance to an unverified interpreter patch

The client uses Python 2.7-era behavior, but a historical statement such as “Python 2.7.1 is always required” should not be copied forward without checking the target build and its bytecode expectations. Use the interpreter and compilation process proven compatible with the client version you support.

Treat secondary documentation as a discovery aid

External guides, archived references, forum posts, and examples can suggest useful paths, symbols, and tests. Verify every private symbol against the current client source and runtime behavior before presenting it as supported. Prefer the current call site and observed behavior over an older explanation.

Producer-to-consumer trace

For version-sensitive internals, do not stop at the symbol definition. Trace the value from the producer to the consumer that actually gives it meaning.

1. Find the class, helper, or generated model declaration.
2. Find construction and registration sites.
3. Find the event, callback, or setter that updates it.
4. Find the view, controller, or request path that consumes it.
5. Find cleanup and replay/reconnect handling.
6. Compare lobby, battle, replay, and reconnect paths before treating the behavior as stable.

Record useful compatibility limits

Private names, event order, routes, bridge payloads and resource paths can change. Explain the behavior a feature depends on and any known limitation, so another developer knows what to check.

Keep implementation examples separate from investigation logs. Describe what works and how to verify it; avoid repeating test runs, source-audit history or internal documentation markers throughout the guide.

When only historical information is available, label it as historical. Follow the registration, caller, firing site and teardown path again before relying on it.

Region and runtime portability

A tutorial written for another client region is a discovery lead, not proof of a current contract. Confirm the target region, package format, module paths, command definitions, event producers, and caller signatures before reusing code. Similar UI names do not prove that server commands or feature packages exist in both clients.

Separate an external example's useful system model from its hook and teardown choices. Verify the current method signature, preserve native fall-through, retain exact subscription identities, and supply cleanup for every callback, view, and wrapper. Dependency injection proves availability, not account synchronization or view readiness.

Do not treat an unfinished upstream page or an absent local provider as a verified implementation. Record what current source proves and which integration or runtime behavior remains unresolved. Use the evidence ladder to choose stronger evidence before implementation.

Resolve decompiled control-flow contradictions

Readable extracts can omit else/elif branches, return sentinels or tuple unpacking while retaining plausible method names. Reaching an arithmetic exception or empty mechanic map in such an extract does not establish a game-client defect. Trace registrations, callers, event firing and producer payloads before inferring intended behavior.

When stronger bytecode evidence is available, distinguish a full checked-method signature from direct inspection of selected instructions. An explicitly labelled in-memory reconstruction can test a missing branch, but it is not the unchanged source or an actual client run. Keep the original game-owned file intact and report the exact evidence scope.

Separate source definitions, Python ordering, isolated checks, resource data and observed behavior. A source link to one build does not verify runtime behavior in another, and a partial bytecode match does not establish full parity. Check method/property differences and false/zero/None sentinels explicitly: truthiness can hide the distinction.

For example, static inspection of original Python bytecode from WG 2.4.1.1 #989 confirms that Money.__add__ and __sub__ skip the absent-key assignment after updating an existing currency; the readable dump lost the else boundary. In the same inspected module, DynamicMoney.isCompound retains its self-call rather than delegating to the base method. Verify each suspicious branch against its own evidence before constructing a standalone check. These are selected-instruction findings: they establish neither whole-module parity nor a live failure through a particular consumer.

This distinction matters for calculation reconstruction, state routing and settings readiness.

Scope a source refresh to verified content

A moving default-branch link keeps the destination current; it does not verify the explanation beside it. Compare the affected implementation and its producers, callers and cleanup path against the latest public source. An absent filename in a truncated comparison response does not prove that the file is unchanged.

Verify the affected Git blob identities directly, or establish that the complete relevant subtree identity is unchanged using non-truncated tree listings. That proves unchanged versioned entries within that scope, not the whole repository. Check the local checkout separately and state any line-ending normalization used for blob comparisons.

Unchanged Python source does not verify compiled/frontend assets, native behavior or installed runtime. Feature packages outside the compared subtree require separate checks. Preserve historical runtime evidence with its actual scope, and update behavioral guidance when the inspected contract changes rather than merely replacing a source label.