Question Apex Legends Kernel RCS — Memory Write Flickering & Offset Analysis

[byte_corvus]

Trying to implement a stable RCS via kernel memory writes in Apex is becoming a massive headache, especially with how EAC monitors viewangle consistency now. If you're digging into the CPlayer structures, you've likely seen the common offsets, but getting a clean compensation without the dreaded flicker is another story.

I've been analyzing the behavior on the latest build using a Vec3 variance scan. Here are the confirmed offsets for reference:

m_vecPunchBase_Angle = 0x2510 (peak 24.5°)
m_vecPunchWeapon_Angle = 0x2520 (peak 73°)
m_vecPunchWeapon_AngleVel = 0x252C (peak 79°)
view_angles = 0x2600 (8 bytes, pitch + yaw)

The Problem: Memory Write Artifacts
When attempting to manipulate these values directly, the engine produces several artifacts that make the "cheat" feel more like a glitch:

1. Zeroing the 12-byte block at m_vecPunchWeapon_Angle while firing (LSTAR/R-301 tests) causes the crosshair to flicker violently while the actual bullet trajectory continue to climb.
2. Nuking the full 40-byte block (Base + Weapon + Vel) locks the crosshair locally, but it's a visual lie. The bullets follow the server-side recoil pattern, and your view will snap to the "true" position the moment you let go of LMB.
3. Delta compensation (view_angles -= punch - prev_punch) results in heavy left-right yaw flickering, suggesting a race condition between your write and the engine's update loop.

Why Bullet Tracing Ignores Your Writes
If you zero-write and the bullets still climb, you're hitting the authoritative state wall. Apex likely uses a separate internal state for projectile calculation that is decoupled from the view_angles at 0x2600 when it comes to the physics of the shot. Writing to 0x2600 only affects where you are looking, not necessarily where the engine thinks the gun is pointing during the fire event frame.

Spoiler: Internal Logic & Component Order

Testing pitch-only compensation often makes vertical recoil 10x worse. This usually points to a mismatch in component order. While Source standard is typically (Pitch, Yaw, Roll), some structures in Apex have been observed to use (Yaw, Pitch, Roll) or even custom packing. If view[0] -= (punch[1] - prev[1]) causes massive vertical movement, your index 1 is definitely mapped to Pitch in that specific buffer.

Preventive Troubleshooting

1. Avoid writing to view_angles directly if you value your account. EAC has been known to flag suspicious delta jumps in view angles that don't match input movement.
2. If you're dead set on memory writes, you need to sync with the game's frame tick or find the authoritative pointer that bullet tracing actually pulls from.
3. Ensure your driver's WPM (WriteProcessMemory) implementation isn't being throttled or intercepted, which often causes the intermittent "nothing happens, then 10x jump" behavior.

Is anyone actually running a smooth RCS purely via memory writes on the current build, or has everyone moved to mouse_event/HID spoofing to stay under the radar? Drop your findings on the component order below.