Question Deadlock — Magic Bullet Bullet Origin in CUserCmdPB (Source 2)

[byte_corvus]

Been digging into the Deadlock internals recently and hit a wall with bullet synchronization and position manipulation. While silent aim is trivial enough by hooking the prediction path camera setup and swapping pitch/yaw during the prediction tick, getting a proper magic bullet (position offset) for hitting over cover is proving to be a pain in the ass even in Source 2.

Current Progress & Implementation
So far, silent aim is stable. I'm hitting the prediction path and restoring camera state post-tick. However, writing to the camera position at

cam + 0x38 / 0x3C / 0x40

or messing with the pawn scene_node m_vecAbsOrigin during prediction does absolutely nothing to move the actual bullet spawn point. The server seemingly ignores these local client-side position writes for the projectile trace origin.

Technical Roadblocks
I'm suspecting the shoot origin is being packed into the CUserCmd protobuf sub-messages, likely within the camera info section, but finding the exact field is a scavenger hunt.

1. Input Handling: CreateMove isn't sitting in its usual place in client.dll. It looks like it's been moved into engine2.dll's CInputService dispatch chain.
2. Trace Manipulation: Tried using TraceShape to verify points, but my calls return a fraction of 1.0 even through solid brushes. The filter at

   +0x08

   clearly expects a specific vtable/callback structure that I haven't reconstructed yet.
3. Network Path: The call stack from engine2 goes through networkgameclientbase, but tracking exactly where the shoot origin gets populated in the CBaseUserCmdPB is still unclear.

Spoiler: Technical Notes on Prediction

If you're testing this, remember that Valve's prediction on the Source 2 engine is much more sensitive to pitch/yaw desyncs than CS:GO was. If you mess with the origin too aggressively without correctly populating the protobuf sub-messages, you're going to get snapped back or simply face no-regs as the server-side lag compensation rejects the trace origin.

Has anyone mapped out the CBaseUserCmdPB sub-messages for Deadlock specifically? Is the shoot position actually controlled via the camera info sub-message, or is there a separate field in the input buffer we need to override to force an origin offset?

Drop your findings on the engine2 dispatch chain below.