When investigating a client feature, work from the current extracted client sources and resources available to you. Search broadly for definitions, callers, registrations, identifiers, and lifecycle ownership, but modify only your own mod source.

Client source vocabulary

These names are common landmarks when moving from a first mod into current client source. Treat them as orientation, then verify the exact contract by following registrations, callers, and runtime evidence.

Landmark What it usually means
gui/Scaleform Scaleform and DAAPI applications, aliases, views, and Flash-facing controllers.
gui/impl Modern Wulf UI implementation, generated view models, routes, and UI services.
Generated models and accessors Contracts produced from client resources; useful for names, but still build-dependent.
BigWorld Engine bridge for player access, callbacks, entities, spaces, resources, graphics, and native helpers.
ResMgr Virtual resource and DataSection access; existence of a section does not prove a higher-level UI or gameplay owner is ready.
Account, Avatar, Arena Lobby owner, battle player owner, and battle-wide owner. Do not use their identifiers interchangeably.

Evidence landmarks, not conclusions

Definitions, generated contracts, entity files, resources, and built UI assets tell you where to continue tracing. They do not establish runtime ownership or readiness by themselves. Use Source Verification for the verification workflow and the Source Evidence Ladder to weigh the evidence you collect.

Core source map

Verify import roots against current callers

A familiar symbol name does not prove that an older re-export still exists. Follow current imports: g_playerEvents is imported from the top-level PlayerEvents module, and importing it from gui.shared can fail.

  • Search both the symbol and candidate module paths.
  • Prefer repeated current caller imports over an old tutorial or compatibility alias.
  • Treat top-level modules and package re-exports as separate contracts.
  • Keep the import version-sensitive even when the event object's public name is unchanged.

Feature-extension packages

Optional modes and seasonal systems often live in feature-owned extension roots beside the core scripts tree. Search the current client by registration, interface, entity, or route name instead of assuming a historical package name still owns the feature.

Common extension structure:

  • extension.xml declares the feature name, enabled state, personality, static/dynamic components, entities, and sometimes CGF modules.
  • Personality modules commonly expose preInit(), init(), start(), and fini(). Inspect these to learn when controllers, views, aliases, handlers, and services are registered or removed; package import alone does not imply full feature readiness.
  • scripts/client contains client implementations and GUI/controller code.
  • scripts/common contains shared constants and data contracts.
  • scripts/component_defs and scripts/entity_defs declare networked properties and methods.

Version-sensitive: the presence of a feature package or an enabled declaration in extracted client files does not guarantee that every realm, client build, or runtime context exposes it. Confirm actual registration and readiness at runtime.

Entities and components

  • Core network entity contracts are under scripts/entity_defs.
  • Feature packages add contracts under their own scripts/component_defs and scripts/entity_defs.
  • A .def file can establish whether a value is a property, which side owns it, whether it is exposed to the client or replay, and which remote methods exist.
  • Follow a contract from extension.xml to its .def, then to the matching Python implementation and its call sites. A Python method name alone does not establish ownership, availability, or network direction.
  • Entity, inventory, compact descriptor, vehicle type, account, and arena IDs use different namespaces. Definition files help verify the intended type before values are compared or serialized.
  • For script components, distinguish core or feature registration, the complete .def, static versus dynamic access, Python callbacks, and optional CGF registration. Separate construction from world, appearance, avatar, and visual readiness.

GUI resources and localization

  • Modern resource access commonly starts with from gui.impl.gen import R or from gui.impl.gen.resources import R.
  • Dynamic resource branches use DynAccessor; .dyn(...) can return an invalid accessor, so validate optional dynamic resources before use.
  • DynAccessor truthiness and existence are not identical in the inspected implementation: non-negative IDs are truthy, while exists() requires a positive ID. Prefer isValid()/exists() according to the contract instead of treating every truthy accessor as a concrete resource.
  • Generated view-model classes describe field names, types, collections, and transaction/update conventions expected by Wulf/Gameface views.
  • Scaleform aliases and protocol constants are often under scripts/client/gui/Scaleform/genConsts and related DAAPI packages.
  • For a displayed string or image, trace both the Python R/backport usage and the corresponding localization or resource namespace.

Source-verification workflow

For a new hook or integration:

  1. Start from the current client implementation or a current runtime observation. Public examples and older mods are discovery aids, not proof.
  2. Locate the target definition and inspect its callers, imports, registrations, and lifecycle owner. Do not rely on a method name in isolation.
  3. When working from extracted client sources, inspect the nearby interfaces, service contracts, and dependency-registration code that own the implementation.
  4. For events, trace where the event is created, fired, subscribed, unsubscribed, and cleared. Confirm the event type and expected callback lifetime.
  5. For optional modes or seasonal features, verify that the relevant package is present, enabled for the current client build, and ready before use.
  6. For GUI changes, identify whether the target is Scaleform, Wulf, or Gameface, then inspect its view model, alias or resource contract, and lifecycle owner.
  7. For item or vehicle data, trace IDs and compact descriptors through current item definitions, GUI wrappers, and cache APIs.
  8. Treat decompiled code, archived examples, and generated output as secondary evidence. Guard private or optional APIs with narrow fallbacks.
  9. Record only conclusions that can be reproduced from current source or runtime behavior. Mark uncertain observations as unverified until they can be confirmed.

Efficient source searches

  • Search by exact class, event, method, compact-descriptor field, resource accessor, or message key before searching broad concepts.
  • Search all relevant source roots, not only scripts/client; extension packages can provide the imported module.
  • Use import sites and call sites together. Imports reveal package ownership; calls reveal expected arguments and lifecycle.
  • Generated assets and localization make broad file listings noisy. Narrow by extension and subsystem (*.py, *.def, extension.xml, relevant JSON/XML) before expanding into built Gameface or resource data.
  • Treat the absence of a readable .py file cautiously when imports, generated accessors, compiled files, or extension declarations indicate a runtime object exists.

Offline and investigation tools

  • Use focused inspection tools for the artifact you are examining, such as a Python decompiler, SWF/ABC viewer, archive inspector, XML viewer, or structured diff tool.
  • A tool, script, archive, log, generated folder, executable, or packaged mod is not automatically part of the game-client runtime. Treat it as evidence until current runtime code imports or invokes it.
  • Downloaded or decompiled examples can reveal useful design ideas, but timestamps, target realms, client versions, and decompiler output may be stale or incomplete.
  • Prefer inspecting generated or packaged output over editing it directly. Make changes in maintainable source files whenever source is available.
  • Keep only durable conclusions that survive comparison with current client source and observed runtime behavior.