- Status
- Offline
- Joined
- Mar 3, 2026
- Messages
- 750
- Reaction score
- 457
Anyone currently digging into ARC Raiders? I've been trying to nail down the WorldToScreen scaling for an external, but the FOV logic is being a massive pain on the latest patch. If you've looked at the PlayerCameraManager (PCM) lately, you'll know that the default values are easy to find, but the live camera data is playing hide and seek.
Current Verified Layout:
Testing on the current build confirms these offsets are still valid for the base classes:
Inside FMinimalViewInfo, the location and rotation (using doubles) represent the camera position perfectly, but the FOV field is static:
The ADS Scaling Problem
The issue is that the FOV at PCM + 0xCF0 (which is the combined offset for ViewTarget.POV.FOV) stays locked at 100.0. It doesn't update when you aim down sights or use a scope. This results in the ESP boxes drifting and lagging behind the 3D model during any zoom transition because the projection matrix is using the hipfire FOV while the screen is actually zoomed in.
I've run a heap-pointer sweep looking for candidate floats between PC + 0x300 and PC + 0x600. I found a couple of potentials:
TeamID Logic on Embark Classes
Building on that, TeamID identification seems broken on AEmbarkCharacterBase + 0x812. It returns 0 for everyone including the local pawn, which makes squad filtering impossible. Given how Embark usually structures things, they might have moved the replicated team index to APlayerState or a dedicated component. If you're seeing everyone as Team 0, your filtering logic is probably hitting the wrong offset or a non-replicated field.
Where are you guys pulling the live camera FOV from for the matrix? Is it tucked away in the CameraComponent on the Pawn, or are you grabbing it from the ViewportClient?
Drop your findings if you've mapped out the latest camera class changes.
Current Verified Layout:
Testing on the current build confirms these offsets are still valid for the base classes:
Code:
PCM + 0x3D8 = PCOwner (AController*)
PCM + 0x3E8 = DefaultFOV (float, constant)
PCM + 0xC90 = FTViewTarget base
ViewTarget.Target @ +0x00
ViewTarget.POV @ +0x10 (FMinimalViewInfo)
ViewTarget.PlayerState @ +0x810Inside FMinimalViewInfo, the location and rotation (using doubles) represent the camera position perfectly, but the FOV field is static:
Code:
Location @ +0x10 (Vector3 doubles, 24 bytes) — OK
Rotation @ +0x30 (Vector3 doubles) — OK
FOV @ +0x50 (float) — Static 100.0The ADS Scaling Problem
The issue is that the FOV at PCM + 0xCF0 (which is the combined offset for ViewTarget.POV.FOV) stays locked at 100.0. It doesn't update when you aim down sights or use a scope. This results in the ESP boxes drifting and lagging behind the 3D model during any zoom transition because the projection matrix is using the hipfire FOV while the screen is actually zoomed in.
I've run a heap-pointer sweep looking for candidate floats between PC + 0x300 and PC + 0x600. I found a couple of potentials:
- PC + 0x338 -> points to a float of 100.0 (likely another DefaultFOV ref).
- PC + 0x3A8 -> points to a float of 54.8 (potentially an ADS multiplier, but doesn't transition).
TeamID Logic on Embark Classes
Building on that, TeamID identification seems broken on AEmbarkCharacterBase + 0x812. It returns 0 for everyone including the local pawn, which makes squad filtering impossible. Given how Embark usually structures things, they might have moved the replicated team index to APlayerState or a dedicated component. If you're seeing everyone as Team 0, your filtering logic is probably hitting the wrong offset or a non-replicated field.
Where are you guys pulling the live camera FOV from for the matrix? Is it tucked away in the CameraComponent on the Pawn, or are you grabbing it from the ViewportClient?
Drop your findings if you've mapped out the latest camera class changes.
