UI Panes and Registries

The client represents screens, dialogs, controls, and many temporary overlays as Pane-derived objects. A pane participates in two independent hierarchies. The Screen composition tree records placement and parent-child drawing relationships. The event-dispatch tree records which panes receive mouse, keyboard, socket-packet, and timer callbacks. A pane may appear in both trees, but the trees have different nodes, payloads, and ownership.

The executable does not expose usable Microsoft C++ class RTTI for these pane types. Enumeration instead starts from the common Pane virtual layout. Every confirmed pane-compatible virtual table contains ui_pane_register_events at slot +0x30 and ui_pane_unregister_events at +0x34. Cross-references to the registration slot identify 173 compatible tables. These include controls and construction-state tables as well as full visible screens, so the count is not a count of 173 independently visible windows. The complete address and handler inventory is in Pane Virtual Table Inventory.

High-level operation

Two pane hierarchies

The Screen composition tree answers where a pane is placed and which panes are below it. ui_screen_registry is a static pointer to its heap registry. The root node holds ui_screen_pane, the persistent 640 by 480 surface pane. Adding a pane supplies a rectangle, an optional pane to place it in front of, and an optional parent pane. Removing a node also removes its child hierarchy.

The event-dispatch tree answers which panes are eligible for input and internal events. It is reached through event_dispatcher + 0x68. Mouse events use virtual slot +0x38, keyboard events use +0x3C, socket-packet events use +0x40, and due pane timers use +0x44. Event traversal visits a node’s children before the node itself. Mouse coordinates are adjusted into pane-relative coordinates during traversal.

The two registrations are deliberately separate. ui_pane_add_to_screen does not register event handling, and ui_pane_register_events does not add anything to the drawing tree. Constructors and transitions normally perform both operations explicitly.

Pane lifecycle

app_initialize first creates the Screen registry, constructs ui_screen_pane, and makes that pane the Screen root. It then creates and starts the event dispatcher and registers the screen pane as the initial event receiver.

The first substantial screen is TerminalPane. Its constructor publishes ui_terminal_pane, adds the pane below ui_screen_pane, registers it in the event hierarchy, and adds its controls. A successful terminal bootstrap packet causes ui_terminal_handle_server_packet to remove the terminal child, unregister and remove the terminal pane, create MainMenuPane, add and register the main menu, send the bootstrap/version traffic, and delete the terminal object. The terminal destructor clears its static pointer.

MainMenuPane publishes ui_main_menu_pane. Its server handler can create ServerSelectDialogPane as a registered child dialog. The dialog destructor explicitly unregisters the pane and removes it from Screen before destroying its dialog state.

The transition into the game reaches ui_main_menu_create_game_panes. It creates the persistent in-game BackgroundPane and MapPane, publishes ui_background_pane and ui_map_pane, and builds the larger child-pane graph below them. The map pane becomes the principal socket-packet receiver for in-game server actions.

Temporary controls follow the same rule. The game-buttons owner stores each allocated skill or spell pane in an indexed heap-pointer array, adds it below the owner in Screen, and registers it below the owner in the event tree. Removal deletes the node from both trees, deletes the object, and clears the pointer slot. TextEdit Escape and Enter paths also remove both registrations before queueing deferred deletion. Enter calls the class-specific virtual slot +0x4C before removal.

Visibility is separate from both hierarchies. Common Pane vslot +0x14 sets the visible flag at +0xB0 and invalidates the pane, while +0x18 clears the flag and invalidates the exposed parent region. Persistent content panes can therefore remain present in both registries while hidden. The exact packet and input transitions for equipment, status, skills, spells, users, paper, messages, and bulletin or mail are in UI, Input, and Packet Flows.

The base ui_pane_dtor only cancels timers and destroys base members. It does not unregister the object from either tree. Every owning path must therefore remove both registrations before immediate or deferred deletion. The observed order varies by owner, but both removals precede destruction.

Named persistent panes and handlers

The following panes have established construction, virtual-table, and handler evidence. M, K, S, and T mean mouse, keyboard, socket packet, and timer.

Friendly class names and concrete event coverage

The executable has no usable Microsoft RTTI for this hierarchy, but it retains many class and method diagnostics. A friendly class name is treated as confirmed only when the same constructor, destructor, or virtual method also installs or is stored in the candidate vtable. This establishes names such as BulletinDialogPane, ArticleListDialog, MailListPane, LegendDialogPane, MonsterPane2, EffectObjectPane, OptionPane, and WeatherPane without relying on nearby text alone. The complete confirmed name-to-vtable map is in Pane Virtual Table Inventory.

A vtable identifies the broad Event families a pane can receive. The handler body supplies the narrower filter. For example, ServerSelectDialogPane has mouse, keyboard, socket, and timer slots, but its mouse override only adds behavior for a left double-click and its socket override only claims server action 0x56. The inherited Dialog handlers still process their ordinary mouse and keyboard cases. This distinction is important for runtime hooks because a non-default slot does not imply that every subtype is consumed.

The client dispatches key-down Events only. Key-up updates EventMan state but does not enter the pane hierarchy. Timer callbacks are also separate from the numbered Event types: the timer worker calls pane slot +0x44 with a class-local callback identifier and two payload values.

The socket handler is not a Winsock callback. Socket bytes are decoded and converted to internal Event type 9 before the dispatcher calls pane slot +0x40. The packet path is documented in Networking, while Win32 WM_* handling remains in Input and Windows Events.

Runtime observation roots

The documented virtual addresses use image base 0x00400000. A runtime tool that resolves a loaded module should use loaded_module_base + RVA rather than assuming the preferred base.

These roots are useful object discriminators as well as pointer chains. A live object begins with its current virtual-table pointer. Comparing that pointer against the vtable inventory identifies compatible panes without relying on absent RTTI.

The Runtime UI Memory Map turns these roots into concrete Screen and Event tree-walking recipes and records confirmed fields for GameButtonsPane, equipment and self-look state, skill and spell slots, BulletinSession, and Users Dialog Pane.

External readers can race Screen changes, event registration, and deferred deletion. The Screen add and remove paths do not acquire a visible lock around the packed list. A practical snapshot should read the list pointer, count, array pointer, and stride, copy the nodes, then re-read those four values and discard the snapshot if they changed. Each pane pointer should also be checked for readability and a known vtable before reading fields. Writes are more hazardous because pane fields, both registries, timers, and ownership must remain consistent.

Code-level flow

Common Pane layout and virtual slots

ui_pane_ctor constructs the common Pane base and installs ui_pane_vtable. The following fields and slots are directly established.

Event values and handler filters

The dispatcher reads the byte at Event offset +0x0C. Mouse subtype values and their Win32 production paths are established in Input and Windows Events.

The following filters are comparisons in the named handler bodies. A handler that delegates to ui_dialog_handle_mouse_event can still inherit the generic Dialog cases after its class-specific work.

Keyboard handlers receive Event type 8 and compare the mapped key byte at Event offset +0x10. Values below are recorded as the handler sees them. They are not assumed to be raw WM_* virtual-key values.

Socket Event handlers filter on the first decoded byte or, where noted, a second subtype byte. The Map action set is kept in the protocol index because each branch has its own parser and side effects.

Timer callback identifiers are local to the receiving class. BackPane uses IDs 0, 1, and 2; MapPane and ScreenPane each dispatch IDs 0 through 4. These values share no global enum with Event types 0 through 9.

Packed hierarchy representation

Both registries use ui_hierarchy_list_ctor, which adds an 11-byte hierarchy header to the requested payload size. The result is a packed, commonly unaligned node array.

Screen requests a 0x34-byte payload, producing stride 0x3F. The pane pointer is at node +0x08, its RECT is at +0x0C, and copied pane flags begin at +0x1C. The root pointer stored at [ui_screen_registry + 0x1C] addresses a node whose child-list pointer is at root +0x04 and whose pane at root +0x08 is ui_screen_pane.

The event dispatcher requests a four-byte payload, producing stride 0x0F. Each event node therefore contains only its hierarchy links and the pane pointer at +0x08.

The exact external pointer chains are:

screen_list = read_process_u32(module_base + 0x000f51cc);
screen_root = read_process_u32(screen_list + 0x1c);
screen_children = read_process_u32(screen_root + 0x04);

dispatcher_object = read_process_u32(module_base + 0x000f51d0);
event_list = read_process_u32(dispatcher_object + 0x68);

Walk screen_children for ordinary Screen descendants. The separately allocated Screen root itself can be observed directly at screen_root. Walk event_list for registered event receivers.

A raw external walk is equivalent to:

static void walk_pane_list(uintptr_t list_address)
{
    uint32_t node_stride;
    uint32_t node_count;
    uintptr_t node_array;
    uint32_t node_index;

    node_stride = read_process_u32(list_address + 0x0c);
    node_count = read_process_u32(list_address + 0x14);
    node_array = read_process_u32(list_address + 0x18);

    for (node_index = 0; node_index < node_count; ++node_index) {
        uintptr_t node_address;
        uintptr_t child_list;
        uintptr_t pane_address;

        node_address = node_array + node_index * node_stride;
        child_list = read_process_u32(node_address + 0x04);
        pane_address = read_process_u32(node_address + 0x08);
        observe_pane(pane_address);

        if (child_list != 0) {
            walk_pane_list(child_list);
        }
    }
}

The helper reads 32-bit values from arbitrary byte addresses because the strides 0x3F and 0x0F do not preserve four-byte alignment.

Creation and removal paths

The common add path is:

1. A constructor installs a concrete pane vtable after ui_pane_ctor initializes the base.
2. The owner calls vslot +0x28, reaching ui_pane_add_to_screen and then ui_screen_add_pane.
3. ui_screen_add_pane validates bounds, resolves optional parent and front panes with ui_screen_find_pane_node, copies the Screen payload, and inserts the packed node.
4. The owner calls vslot +0x30, reaching ui_pane_register_events and event_dispatcher_register_pane.

Removal reverses both memberships before destruction. ui_pane_remove_from_screen releases capture-related state when necessary and calls ui_screen_remove_pane. Event removal reaches event_dispatcher_unregister_pane. Representative dynamic paths are ui_skill_inventory_remove_slot_pane, ui_spell_inventory_remove_slot_pane, the server-select destructor, and ui_text_edit_handle_key_event.

ui_screen_find_pane_node recursively returns the containing list and node index. ui_screen_get_pane_origin walks parent links to accumulate screen coordinates. These functions make the Screen hierarchy useful for both rendering and runtime inspection.

Function table