[UE 5.8] The Sinking City 2

[przemyslawzaworski]

Branch or Release
zDEV-UE4SS_v3.0.1-1028-gd7e7826d

Game and Engine Version
[UE 5.8] The Sinking City 2

Describe the bug
[2026-08-17 13:23:33.3051455] DebugGame Setting Enabled? false
[2026-08-17 13:23:33.3090938] PS Scan attempt 1 (Phase 2)
[2026-08-17 13:23:33.3159746] [PS] Reading image
[2026-08-17 13:23:33.3196729] [PS] Starting scan
[2026-08-17 13:23:34.0659359] [PS] Scan finished in 746.0026ms
[2026-08-17 13:23:34.0661908] [PS] Found EngineVersion: 5.8
[2026-08-17 13:23:34.0668328] [PS] Found GUObjectArray: 0x7ff617c1d128
[2026-08-17 13:23:34.0673517] [PS] Found GMalloc: 0x7ff617b3a2e0
[2026-08-17 13:23:34.0678156] [PS] Found FName::ToString: 0x7ff60dcdcd50
[2026-08-17 13:23:34.0683032] [PS] Failed to find FName::FName(wchar_t*): FNameCtorWchar: expected at least one value
[2026-08-17 13:23:34.0687758] [PS] You can supply your own AOB in 'UE4SS_Signatures/FName_Constructor.lua'
[2026-08-17 13:23:34.0692305] [PS] Found StaticConstructObject_Internal: 0x7ff60ded4cf0
[2026-08-17 13:23:34.0697075] [PS] Failed to find FUObjectHashTables::Get(): FUObjectHashTablesGet: expected at least one value
[2026-08-17 13:23:34.0701684] [PS] You can supply your own AOB in 'UE4SS_Signatures/GUObjectHashTables.lua'
[2026-08-17 13:23:34.0706487] [PS] Failed to find GNatives: GNatives: expected at least one value
[2026-08-17 13:23:34.0710985] [PS] You can supply your own AOB in 'UE4SS_Signatures/GNatives.lua'
[2026-08-17 13:23:34.0715661] [PS] Found ConsoleManagerSingleton: 0x7ff60db53b00
[2026-08-17 13:23:34.0720303] [PS] Found GameEngineTick: 0x7ff60f2ed1f0
[2026-08-17 13:23:34.0724952] [PS] Scan failed

Desktop (please complete the following information):

• OS: Windows 11

[UE4SS]

While we don't officially support UE 5.8 yet, you can get this game somewhat working with a custom config.

Set engine version in UE4SS-settings.ini to 5.7, and use these VTableLayout, MemberVariableLayout and signature files:
TheSinkingCity2.zip

Expect problems, but it may be usable for your purposes.

[przemyslawzaworski]

Thanks for your help. I checked, but unfortunately the mods don’t work, and the in-game console (the tilde key) doesn’t appear either. When launching the game, UE4SS gets stuck on the message “Waiting for object construction...”.

I’m trying to find a way to make the game render graphics at a higher quality. For example, I’d like to be able to execute commands such as "r.Lumen.ScreenProbeGather.DownsampleFactor 4" during gameplay.

In other games, I usually do this either by modifying the Engine.ini file or through UE4SS, but The Sinking City 2 seems to ignore (or overwrite) most of the commands saved in the .ini file.

[botBehavior]

The "Waiting for object construction..." stall after loading the custom config is
probably not a layout problem. I hit the identical symptom on another UE 5.8 shipping
build and the cause was the GUObjectArray address, not the .ini files.

The failure shape

PatternSleuth's built-in scan found a GUObjectArray and reported it in the log
without complaint. Reading that address in the running process gave
Objects=0, NumElements=0, MaxElements=0 — it had locked onto an adjacent global.
The real FUObjectArray was a short distance lower in the same region
(0x68 in my build, but treat that as an artifact of my binary, not a constant).

Construction detection polls NumElements on that array. Pointed at a global that is
permanently zero, it waits forever. Nothing errors, nothing warns, and the layout
files are irrelevant to it — which is why it presents as "the custom config didn't
work."

Confirming it in about a minute

The log line Found GUObjectArray: 0x... gives you the address the scan chose. Read
that address in the running process while you're standing in a level. If
NumElements is 0 there, this is your bug. If it's a large non-zero number, it's
something else and you can stop reading.

The fix

Supply a UE4SS_Signatures/GUObjectArray.lua. UE4SS takes it as a ScanOverride and
drops its own scan result (UE4SS/src/Signatures.cpp,
config.ScanOverrides.guobjectarray -> UObjectArray::SetupGUObjectArrayAddress).
Per the AOB contract, the script returns the address of the GUObjectArray global.

The anchor I used is the one GUObjectArray reference inside
FUObjectArray::AllocateUObjectIndex:

mov rax, [rip+GUObjectArray]   ; 48 8B 05 <disp32>
mov rdx, [rax + rdx*8]         ; 48 8B 14 D0    chunk = Objects[hi]
lea rdi, [rdx + r8*8]          ; 4A 8D 3C C2    &chunk[lo]

"48 8B 05 ?? ?? ?? ?? 48 8B 14 D0 4A 8D 3C C2"

The chunk-index idiom after the load is what makes it unique. The bare
mov rax,[rip]; mov rdx,[rax+rdx*8] on its own matched 17 sites across two different
globals in my image; adding the lea rdi,[rdx+r8*8] narrowed it to exactly one. The
displacement is wildcarded, so the pattern is shape-only and survives a patch that
just relocates the region — worth doing, because I lost an earlier signature to a
same-day rebuild by baking a disp32 into it.

OnMatchFound reads the disp32 at match+3 and returns match + 7 + disp.

That idiom comes from UE's own source rather than from any one build's codegen, so
there's a reasonable chance it matches The Sinking City 2 as well — but I can't check
that, and I'd verify the resolved address reads a sane NumElements before trusting
it. If it doesn't match, the general method is: locate the real array by scanning for
a plausible FUObjectArray live, then anchor on that idiom near it.

Result on my build: with the override in place, Waiting for object construction... clears in about 1.2 seconds and mods start normally. Without it, it
never clears. Everything else — the 5.7 engine version setting and the
MemberVariableLayout/VTableLayout pair from the config above — was already correct;
this was the only remaining piece.

One suggestion for upstream: a wrong GUObjectArray currently costs an unbounded
silent hang. If the construction poll checked whether NumElements is still zero
after some number of iterations and logged something naming the array address as the
likely cause, this class of 5.8 breakage would report itself instead of looking like
a hung load. Happy to open that as a separate issue if it's useful.

[skyheros001]

The "Waiting for object construction..." stall after loading the custom config is probably not a layout problem. I hit the identical symptom on another UE 5.8 shipping build and the cause was the GUObjectArray address, not the .ini files.

The failure shape

PatternSleuth's built-in scan found a GUObjectArray and reported it in the log without complaint. Reading that address in the running process gave Objects=0, NumElements=0, MaxElements=0 — it had locked onto an adjacent global. The real FUObjectArray was a short distance lower in the same region (0x68 in my build, but treat that as an artifact of my binary, not a constant).

Construction detection polls NumElements on that array. Pointed at a global that is permanently zero, it waits forever. Nothing errors, nothing warns, and the layout files are irrelevant to it — which is why it presents as "the custom config didn't work."

Confirming it in about a minute

The log line Found GUObjectArray: 0x... gives you the address the scan chose. Read that address in the running process while you're standing in a level. If NumElements is 0 there, this is your bug. If it's a large non-zero number, it's something else and you can stop reading.

The fix

Supply a UE4SS_Signatures/GUObjectArray.lua. UE4SS takes it as a ScanOverride and drops its own scan result (UE4SS/src/Signatures.cpp, config.ScanOverrides.guobjectarray -> UObjectArray::SetupGUObjectArrayAddress). Per the AOB contract, the script returns the address of the GUObjectArray global.

The anchor I used is the one GUObjectArray reference inside FUObjectArray::AllocateUObjectIndex:

mov rax, [rip+GUObjectArray]   ; 48 8B 05 <disp32>
mov rdx, [rax + rdx*8]         ; 48 8B 14 D0    chunk = Objects[hi]
lea rdi, [rdx + r8*8]          ; 4A 8D 3C C2    &chunk[lo]

"48 8B 05 ?? ?? ?? ?? 48 8B 14 D0 4A 8D 3C C2"

The chunk-index idiom after the load is what makes it unique. The bare mov rax,[rip]; mov rdx,[rax+rdx*8] on its own matched 17 sites across two different globals in my image; adding the lea rdi,[rdx+r8*8] narrowed it to exactly one. The displacement is wildcarded, so the pattern is shape-only and survives a patch that just relocates the region — worth doing, because I lost an earlier signature to a same-day rebuild by baking a disp32 into it.

OnMatchFound reads the disp32 at match+3 and returns match + 7 + disp.

That idiom comes from UE's own source rather than from any one build's codegen, so there's a reasonable chance it matches The Sinking City 2 as well — but I can't check that, and I'd verify the resolved address reads a sane NumElements before trusting it. If it doesn't match, the general method is: locate the real array by scanning for a plausible FUObjectArray live, then anchor on that idiom near it.

Result on my build: with the override in place, Waiting for object construction... clears in about 1.2 seconds and mods start normally. Without it, it never clears. Everything else — the 5.7 engine version setting and the MemberVariableLayout/VTableLayout pair from the config above — was already correct; this was the only remaining piece.

One suggestion for upstream: a wrong GUObjectArray currently costs an unbounded silent hang. If the construction poll checked whether NumElements is still zero after some number of iterations and logged something naming the array address as the likely cause, this class of 5.8 breakage would report itself instead of looking like a hung load. Happy to open that as a separate issue if it's useful.

Thank you very much for your guidance. With your method, I was able to successfully run UE4SS in the game and export both the usmap file and dump objects. However, I'm now facing a serious issue where certain methods in Lua scripts are not working properly. For example, the RegisterConsoleCommandHandler method does not take effect.
For instance, in the following code:
local UEHelpers = require("UEHelpers")
RegisterConsoleCommandHandler("whereme", function(FullCommand, Parameters, Ar)
local Pawn = UEHelpers:GetPlayer()
local location = Pawn:K2_GetActorLocation()
print(string.format("(X=%.5f,Y=%.5f,Z=%.5f)", location.X, location.Y, location.Z))
return true
end)
I'm unable to successfully register the whereme command. Intuitively, it feels like RegisterConsoleCommandHandler is simply not working at all. It seems that RegisterConsoleCommandHandler likely depends on UObject::ProcessConsoleExec internally.