Runtime UI Memory Map

The 4.21 client exposes enough stable process state to build a useful read-only UI inspector. Static module globals lead to the Screen composition tree, the Event receiver tree, and several important persistent panes. Heap pane objects share a common base layout, and their first pointer identifies the concrete implementation through a module-relative virtual-table address.

This page is a runtime lookup reference. It describes addresses and fields confirmed by code paths that construct, read, update, or destroy them. The broader static global catalog is in Data Map, packed programmer-facing declarations are in C Structure Layouts, and the complete pane-class discriminator list is in Pane Virtual Table Inventory. Event Proxy IPC, Rules, and State applies these paths to late-attach snapshots and guarded peek or poke requests.

High-level operation

Address model

Darkages.exe is a 32-bit image with preferred image base 0x00400000. Every pointer and uintptr_t value discussed here is four bytes. The documented virtual addresses identify the analyzed image, but an external reader should resolve the loaded module base and add an RVA:

uintptr_t runtime_address = loaded_module_base + documented_rva;

Do not assume that Darkages.exe loaded at its preferred base. A virtual-table address is also relocated with the module. For example, a live GameButtons pane is identified by:

int is_game_buttons_pane =
    pane_vtable == loaded_module_base + 0x00110300;

Static runtime roots

Each address in the table is storage in the image. Read one 32-bit pointer from loaded_module_base + RVA to obtain the heap object.

These roots are nullable according to lifecycle. A null pointer is ordinarily a phase or ownership result, not an error in the reader.

What the two pane trees reveal

The Screen tree is the primary inventory of composed UI. It contains persistent panes, hidden content panes that remain attached, dialogs, controls, and temporary slot panes. Its parent-child links also describe UI ownership and placement.

The Event tree is an independent inventory of panes registered for mouse, keyboard, socket-packet, or timer delivery. It is useful as a cross-check and can contain an object whose Screen membership is changing. Neither tree is an ownership-safe API for an external process. Both can change while they are read.

A practical read-only inspector can:

1. Snapshot the Screen tree.
2. Validate each pane pointer and vtable.
3. Read the common visibility byte and bounds.
4. Label known classes by vtable RVA.
5. Follow class-specific pointers only after confirming the expected vtable.
6. Optionally snapshot the Event tree and mark which visible or hidden panes currently receive Events.

Useful observation recipes

List current panes

Read ui_screen_registry, then its root at registry + 0x1C. Observe the root pane at root + 0x08, and recursively snapshot the child list at root + 0x04. For every node, read the pane pointer at node +0x08. Read the live pane’s vtable, local bound rectangle at +0x38, relative top/left origin at +0xA8, and visible byte at +0xB0.

The full vtable inventory contains construction and control variants as well as visible screens. A vtable match identifies the object’s current implementation, but does not imply that the pane is visible or top-level.

Find the selected game content

There is no separate static root for GameButtonsPane. Find the pane whose vtable is loaded_module_base + 0x00110300. Its field at +0x124 points to the currently selected content pane. Compare that pointer with fields +0x130 through +0x140 to label the selection as chat, status, equipment, skills, or spells.

This pointer records selection, while the selected pane’s +0xB0 byte records current visibility. Equipment can be the selected object while hidden because selecting equipment twice toggles its visibility.

Read skills and spells

From GameButtonsPane, read the skill inventory at +0x13C and the spell inventory at +0x140. Each parent owns a 36-entry pointer array beginning at +0xF4. Array entry zero represents protocol slot 1:

uint32_t slot_pane =
    read_process_u32(inventory + 0x00f4 + 4 * (slot - 1));

A null entry is an empty slot. A non-null skill entry should use vtable RVA 0x00114820; a spell entry should use 0x00114880. The child objects retain the server-provided display ID and strings, their 1-based slot, pointer interaction state, and cooldown-active state.

Read equipment and self-look state

Read ui_equip_pane directly. The normal equipment range is 1 through 13. For a 1-based slot:

uintptr_t item_id_address = equip_pane + 0x0b22 + 2 * slot;
uintptr_t item_name_address =
    equip_pane + 0x0b3e + 0x80 * (slot - 1);

The identifier is a native little-endian uint16_t in memory, even though the server packet supplied it in big-endian order. The name is a NUL-terminated byte string in a 0x80-byte record. The pane also retains the most recent SSelfLook appearance bytes, strings, a 32-bit value, and two child-pane pointers. Several field meanings remain unknown, so the code-level table uses unknown_XX names.

Read bulletin, mail, and users state

ui_bulletin_session points to a specialized Pane with vtable RVA 0x00101E60. Its current child pointer at +0x120 leads to the active bulletin or mail dialog. Session +0xF5 records its current child-history position and the one-byte field at +0x124 records request-wait state.

ui_users_dialog_pane is a Pane with a direct static root. It owns nine heap row/list objects at +0x550 through +0x570. The dialog remains allocated and is reused by later SShowUsers replies, so +0xB0 is the useful shown/hidden test.

Read movement timing and the lag indicator

Read ui_local_user while the game UI is active. Its latest queued CMove timestamp is a 32-bit timeGetTime value at +0x6F2C, and the latest SMove response sample is at +0x6F34. The persistent lag pane has its own direct root, ui_lag_indicator_pane, and stores the displayed smoothed value at pane +0xF4.

The raw sample and displayed sample are intentionally different. On every accepted SMove, the pane replaces its value with (old_value + latest_sample) / 2. A reader that wants to reproduce the visible band should use the pane field. A reader that wants the latest unsmoothed movement response should use the local-user field.

Peek versus poke

Read-only observation is practical with the layouts on this page. Raw writes are not equivalent to client UI operations.

Changing Pane + 0xB0 does not perform invalidation, capture release, focus changes, or parent redraw. Replacing a child pointer does not update either packed hierarchy and can create a use-after-free during Event traversal. Editing a vtable or packed node can redirect a virtual call. Editing a fixed string without preserving its limit and NUL termination can overwrite adjacent state.

If controlled UI mutation is investigated later, the safer design is to invoke the established pane method on the client UI path and let it update both registries and rendering state. This page intentionally documents a read-only snapshot model.

Code-level memory map

Packed hierarchy list

Both Screen and Event registries use the same packed hierarchy list. Multi-byte fields in a node may be unaligned, so an external reader should copy bytes or use an unaligned-safe read helper instead of casting a local aligned structure over remote memory.

Screen requests a 0x34-byte payload, so its node stride is 0x3F. Event requests a four-byte payload, so its stride is 0x0F.

The runtime entry chains are:

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

uintptr_t dispatcher =
    read_process_u32(module_base + 0x000f51d0);
uintptr_t event_list = read_process_u32(dispatcher + 0x68);

Common Pane fields

ui_pane_set_bound_rect retains the input rectangle’s top and left at +0xA8/+0xAC, translates the rectangle to a local origin, and applies it to the graphic bound rectangle at +0x38. ui_pane_get_bound_rect reverses that translation. The in-parent rectangle can therefore be reconstructed without a client call:

int32_t relative_top = pane_bound_top + pane_origin_top;
int32_t relative_left = pane_bound_left + pane_origin_left;
int32_t relative_bottom = pane_bound_bottom + pane_origin_top;
int32_t relative_right = pane_bound_right + pane_origin_left;

These client rectangles use top, left, bottom, right field order, not the Win32 RECT memory order. ui_screen_get_pane_origin then finds the Screen node and accumulates parent placement. An external tree walker can preserve the parent chain and perform the same accumulation when absolute screen coordinates are needed.

Runtime class discriminators

The following vtables are especially useful for state walking. The address to compare at runtime is loaded_module_base + RVA.

Lag indicator and movement timing

The lag indicator is a 0xF8-byte Pane created with the rest of the in-game pane graph. Its constructor publishes ui_lag_indicator_pane, initializes +0xF4 to 300 milliseconds, sets a 32 by 32 local bound, and adds and registers the pane below BackgroundPane. The attach method passes left = 537, top = 314, right = 549, and bottom = 328 to ui_rect_init. The helper stores the client-order words (top = 314, left = 537, bottom = 328, right = 549), placing the visible indicator at x = 537..549, y = 314..328.

The value is not based on socket throughput, receive queue depth, or a periodic ping packet. net_c_send_move builds CMove action 0x06, increments the one-byte movement sequence at local user +0x6F28, and stores timeGetTime at +0x6F2C. When the local user receives SMove action 0x0B, ui_local_user_handle_smove stores the unsigned difference between the new clock sample and +0x6F2C at +0x6F34. It then calls ui_lag_indicator_update_from_local_user, which averages the new sample with pane +0xF4 and invalidates the pane rectangle.

uint32_t latest_sample = current_tick - last_move_send_tick;
uint32_t displayed_sample =
    (previous_displayed_sample + latest_sample) / 2;

The sender keeps only one timestamp. If another CMove is queued before an earlier SMove arrives, the newer send overwrites +0x6F2C. The packet byte read at decoded-packet offset +0x0A is also discarded rather than compared against the client movement sequence. The indicator is therefore a smoothed response time relative to the most recent move timestamp, not a rigorous per-sequence network RTT measurement.

ui_lag_indicator_pane_draw selects statcon.epf frames with unsigned comparisons:

The frame numbers and thresholds come directly from the 4.21 draw code. The color labels were checked by decoding the same-named statcon.epf against legend.pal from an available 4.51 data set: frame 3 is blue, frame 2 green, frame 1 orange, and frame 0 red. Exact 4.21 asset identity was not available in this workspace, so tools that require byte-identical 4.21 colors should verify those four asset frames while retaining the code-established frame mapping.

See Pane Virtual Table Inventory for dialogs, bulletin and mail panes, controls, MapPane, options, books, effects, and the remaining compatible tables.

GameButtonsPane fields

GameButtonsPane is constructed by ui_game_buttons_pane_ctor and found dynamically by its vtable. Its direct links make it the most useful bridge from generic pane enumeration to persistent in-game UI state.

The five selection methods hide the previous +0x124 pane, show the chosen field, and replace +0x124. The button-state bytes are also updated so exactly one ordinary content button is selected.

Skill inventory and slot panes

The skill inventory parent has vtable ui_skill_inventory_pane_vtable. It owns exactly 36 heap pointers.

SAddSkill replaces the selected entry with a 0x294-byte pane. SRemoveSkill unregisters, removes, deletes, and clears the entry. SCooldown marks the selected child and later clears it through a parent timer.

Spell inventory and slot panes

The spell inventory parent mirrors the skill parent and also owns 36 heap pointers at +0xF4.

Equipment and self-look fields

The User Equip pane uses vtable ui_equip_pane_vtable and has a direct static root. The item fields use a 1-based protocol slot directly in the identifier expression, while names use a zero-based record index.

The five strings are updated as one SSelfLook transaction. A snapshot reader should copy each bounded buffer and accept it only if the pane pointer and vtable remain unchanged after the copy.

BulletinSession fields

The session is a Pane and can be validated against vtable RVA 0x00101E60. Its active child at +0x120 is another Pane with its own bulletin or mail class vtable.

Users Dialog Pane fields

Row record internals are not yet mapped to the documentation threshold. The direct pane root, visibility, common bounds, and nine owned objects are established.

Stable external snapshot procedure

The client does not expose a lock for external readers. Screen insertion and removal can relocate a list’s packed node array, and deferred deletion can free a pane after it disappears from a registry. Use retryable snapshots:

1. Read list stride, count, array pointer, and root pointer.
2. Reject an unexpected stride, an implausible count, integer overflow in count * stride, a null array with nonzero count, or an unreadable byte range.
3. Copy count * stride bytes with one ReadProcessMemory operation.
4. Re-read the four metadata fields and discard the copy if any changed.
5. Parse nodes from the local byte copy with unaligned-safe reads.
6. Snapshot each non-null child list recursively.
7. Before reading a pane, confirm that its first four bytes are readable and that its vtable is a known module address.
8. After copying class-specific state, re-read the pane’s vtable and the owner pointer that led to it. Discard the object snapshot if either changed.

The core packed-node calculation is:

static uintptr_t packed_node_address(
    uintptr_t node_array,
    uint32_t node_stride,
    uint32_t node_index)
{
    return node_array + (uintptr_t)node_stride * node_index;
}

Do not cast the remote 0x3F- or 0x0F-byte nodes to an ordinary local C structure. Their second and later records are not four-byte aligned.

Function table