- Status
- Offline
- Joined
- Mar 3, 2026
- Messages
- 805
- Reaction score
- 457
The Real Virtuality engine has always been a quirky beast to reverse, and ARMA 3 is no exception. I’ve been digging into the aim system lately and hit some interesting walls regarding how the game actually handles where you’re looking versus where your body is facing. If you've spent any time in IDA or ReClass with this engine, you know it's rarely as simple as a single viewangle float.
1. ManVisualState (Entity +0xD0)
This is the bread and butter for visual positioning. It uses a 3x4 transform matrix (RTTI: ManVisualState : PersonVisualState : EntityVisualState...).
A function (let's call it ManVisualState_SetTransformMatrix) updates this every frame by copying 12 floats. This handles the physical orientation of the character model in the world.
2. The Mysterious Aim Struct
Follow this pointer chain: Entity +2E0 → +E24 → +1A0. This is where things get annoying.
Current Findings & Testing
I’ve tried a few ways to force a look direction without just writing to the forward vector like a total paster:
The Technical Wall
It seems the pitch path is a straight shot (Mouse → Aim Function → Struct), but the yaw logic is decoupled. The horizontal mouse input appears to update the direction vector directly without intermediate angle storage—unless +0x00 is reserved for something like freelook or weapon sway offsets that I'm missing.
If any of you have experience with the RV engine's look-logic, I'm trying to find the cleanest way to programmatically set the look direction (both body and camera) without leaving traces in the aim struct. Hooking SetTransformMatrix and spoofing the source matrix seems like a candidate, but it might be overkill if there's a simpler input gate.
Anyone else noticed this behavior with the yaw delta leaving residues?
1. ManVisualState (Entity +0xD0)
This is the bread and butter for visual positioning. It uses a 3x4 transform matrix (RTTI: ManVisualState : PersonVisualState : EntityVisualState...).
Code:
+0x00: vtable
+0x08: float[9] - 3x3 rotation matrix (right/up/forward vectors)
+0x20: forward.x — Body horizontal direction
+0x24: forward.y — Always 0 (no tilt)
+0x28: forward.z
+0x2C: float pos.X
+0x30: float pos.Y
+0x34: float pos.ZA function (let's call it ManVisualState_SetTransformMatrix) updates this every frame by copying 12 floats. This handles the physical orientation of the character model in the world.
2. The Mysterious Aim Struct
Follow this pointer chain: Entity +2E0 → +E24 → +1A0. This is where things get annoying.
- Offset +0x04: Pitch angle in radians. Clamped at ±π/2 (±90°). This behaves normally and updates directly with vertical mouse movement.
- Offset +0x00: Usually stays at 0.0 during normal play. It has a ±π clamp, suggesting it’s meant for yaw, but horizontal mouse movement doesn't touch it.
Current Findings & Testing
I’ve tried a few ways to force a look direction without just writing to the forward vector like a total paster:
Writing to +0x00 (Aim Struct): The body turns and you'll shoot where you pointed, but the camera stays static. It doesn't reset, which is odd.
Delta Injection: Hooking the aim function and injecting into the [rdx+00] input actually turns the body and the camera follows. The catch? It leaves a "leftover" value in the aim struct at +0x00 that isn't naturally there during legit gameplay.
Yaw Search: High-level scans for a standalone yaw float specifically for the mouse return nothing. The engine seems to prefer storing the end-result in the direction vector components (forward.x/z) rather than maintaining a persistent yaw angle in memory.
Delta Injection: Hooking the aim function and injecting into the [rdx+00] input actually turns the body and the camera follows. The catch? It leaves a "leftover" value in the aim struct at +0x00 that isn't naturally there during legit gameplay.
Yaw Search: High-level scans for a standalone yaw float specifically for the mouse return nothing. The engine seems to prefer storing the end-result in the direction vector components (forward.x/z) rather than maintaining a persistent yaw angle in memory.
The Technical Wall
It seems the pitch path is a straight shot (Mouse → Aim Function → Struct), but the yaw logic is decoupled. The horizontal mouse input appears to update the direction vector directly without intermediate angle storage—unless +0x00 is reserved for something like freelook or weapon sway offsets that I'm missing.
If any of you have experience with the RV engine's look-logic, I'm trying to find the cleanest way to programmatically set the look direction (both body and camera) without leaving traces in the aim struct. Hooking SetTransformMatrix and spoofing the source matrix seems like a candidate, but it might be overkill if there's a simpler input gate.
Anyone else noticed this behavior with the yaw delta leaving residues?
