Engine core: managers, globals and key objects

The engine's top-level objects and the static slots that reach them: the game manager and its subsystems, the client shell, the main scene and the AI world, the engine interface and its services, the update root and object server, the UI and world-UI owners, time and frame counters, and the tests that say whether a world is loaded.

The engine reaches its subsystems through a small number of pointers stored in the writable globals (the .idata section, 0x25AC000-0x2AA5000). Each is a single slot written once or twice at start-up and read from hundreds or thousands of functions. Heap objects behind them move every run; the slots do not.

The top-level objects

Reads and writes are counted over the whole executable (every instruction that addresses the slot).

Some engine objects are static objects in the image rather than pointers: the render thread at 0x267E338 (its first qword is the thread-class vtable vt_0x1FFD4D0), the file system at 0x2A54600 (reached by 14 lea instructions; see Resource streaming), the console registry at 0x2A58BC0 and the Direct3D block at 0x272D1C0 (see Rendering).

The GameManager

CGameClientShell

Its vf1 0x1A864C is the per-frame client update, half of the main thread's time in play (see Threads and the frame).

MainScene and the AI world

The MainScene's vf10 0x1F6958 is the scene tick and its vf1 0x3365A4 the render submission. Its members are the engine's world-side systems:

The order in which the scene tick runs them is in Threads and the frame.

The engine interface

The engine interface hands out the engine's services; none of them has a global of its own:

The interface also registers world shapes: an atmosphere volume's brushes reach the renderer through its vf15 (see Rendering).

The player

The player list [base+0x2A34C68] is an engine vector {+0x00 begin, +0x08 end, +0x10 u32 capacity, +0x14 u8 owned} of CPlayerObj (vt_0x1F96818). The CPlayerObj set-up pushes the player (push_back 0x19B8064), 0x19B9CBC erases it, and Engine::GetActivePlayer 0x360950 returns begin == end ? 0 : *begin. In single player the list has one entry, the same object as [CGameClientShell]+0x888.

Time and frames

The clocks. The engine keeps a family of scaled clocks, each a holder object with its own vtable (vt_0x22F2E90 to vt_0x22F2F10) whose +0x08 is the clock state (vt_0x22C2570): +0x08 the number of objects that use the clock as their time source, +0x10 the current step in milliseconds (u32) and +0x14 the same step in seconds (f32), +0x18 the time in u32 milliseconds and +0x20 in f64 seconds, +0x28 / +0x2C the rate's numerator and denominator, +0x30 the scale, +0x34 the effective rate of the last step (f32), +0x38 the smallest and +0x3C the largest step in milliseconds, +0x40 a stop byte, +0x44 extra milliseconds added to the next step once, and from +0x60 a list of listeners. The update (vf2 0x59A2F50) computes the step as rate x the real elapsed time plus the pending extra (which it then clears), forces it to 0 and skips the clamp while the stop byte is set or the rate's denominator exceeds 0xFFFF, otherwise clamps it to [+0x38, +0x3C], and passes it to every listener's vf2. Six clocks clamp to 1-100 ms, so a long hitch advances them by at most 100 ms; the unscaled and real-time clocks have no upper bound (+0x3C = 0xFFFFFFFF). With the game paused, the seven pausable clocks read stop byte 1 and step 0, while the real-time clock read stop byte 0, steps of 3-4 ms and a rate of 1.0. The slots are the world [base+0x2702598], the player [base+0x2702548], the combat companion [base+0x2702570], the world UI [base+0x2702558], presentations [base+0x2702578], an unscaled clock [base+0x2702550], the UI [base+0x2702588] and a real-time clock [base+0x2702590]. Three more clocks fill the gaps in that run, 11 slots in all from 0x2702548 to 0x2702598: [base+0x2702560], which one ClientFX manager outside the client shell runs on, [base+0x2702568] and [base+0x2702580]. Every clock but the real-time one stops while the game is paused: with the game paused, the real-time clock advanced 1,015 ms in one second and the other seven not at all. Slow motion scales the first five as channels (see Quests, story and scenes).

The count at +0x08 is a reference count that includes the clock's own holder: the presentations clock reads 1, and its only reference is the holder's +0x08. On each of the 11 live clock states the heap holds exactly two more pointers to the state than +0x08 says, and those two are the state's own +0x58 and +0x80, which point back at it. So the world clock's count, 113,151 in a loaded Lithlad, is 113,150 users and the holder, against 31 on the player clock and 477 on the UI clock in the same scene. A ClientFX manager takes two references to its clock.

A character's time source [char+0x88] is the state of one of these clocks: 114 of 115 characters in the spawn manager use the world clock and the player uses the player clock. The object update scheduler subtracts that clock's step from each object's countdown (see Threads and the frame), so pausing (step 0.0) and slow motion throttle NPC and player updates through the same values. AI services run on the world time instead: each service is due when the world time at +0x20 passes its own due time.

Is a world loaded?

• The spawn manager [base+0x26FFBE8] is null at the main menu and live once a world is loaded. The player object persists across menus, so its presence proves nothing. A world is in play when the spawn manager exists and holds spawned characters.
• Spawn manager layout. +0x190 is the number of characters owned by ambient spawning, not the length of the character array. Entries are 0x40 bytes with the character at +0x20. The manager is reallocated during travel, so a pointer to it must be re-read on every use; the same holds for character controllers, which are replaced on respawn.
• A load starting shows as a new pointer at [CGameClientShell]+0xE50.
• Pause. The simulation pauses while the game window is unfocused: the world time stops and the per-object time steps are 0, while the renderer keeps drawing at full rate.
• Loads rebuild state. Some loading screens deserialise GameDB instance data and faction members again, and a region change resets bundles and animation state, so values written into those objects before a load do not survive it.

Threads and asserts

Anything that allocates engine objects, dispatches to scripts or rebuilds a world object runs on the main thread; the render thread consumes commands the main thread posts (see Threads and the frame). Engine asserts are a write to a null address at 0x819113 with the message in rcx (EngineAssert 0x819104).

Open questions

• Which class vt_0x1DA9640 is ([base+0x26FFB40], constructor 0x108BB0 through 0x1081AC) beyond its shape: a 0x7BC0-byte object with two virtual methods, built by 0x109B44 from a setup object that copies a dozen texture handles into it, each marked by a flag bit; the slot was null in a loaded Lithlad.

Shadow of War (Steam), game version 1.21. An unofficial fan research project, not affiliated with or endorsed by Warner Bros. Games, Monolith Productions or Middle-earth Enterprises. Middle-earth: Shadow of War belongs to its owners.