I've posited a similar question over on the Game Development StackExchange, but I'm going to refine it, elaborate, and piecemeal a more R.E.-specific context with the hope that someone out there has experience with this!
To start, I'm looking to create a free-fly cam hack where I can move anywhere with forward orientation always being where my mouse is pointing.
The game I'm hacking (single-player-only) auto-moves the player after tasks are completed; there are no instructions bound to player movement with anything but rotation via mouse. This means I'm building in WASD functionality myself, in a sense. I've found an instruction to inject on which allows me to obtain the XYZ coordinates (which change when the game auto-moves the player) of the camera, as well as its rotation data. Thus, I have the following:
- camX (Plane) -- Value is a float ranging from negative to positive
- camY (Plane) -- Value is a float ranging from negative to positive
- camZ (Up/Down) -- Value is a float ranging from negative to positive
- camH (Horizontal/Yaw) -- Value is a float in degrees from +180 to -180
- camV (Vertical/Pitch) -- Value is a float in degrees clamped to +89 to -89
With that information, I've written a script in Lua (for use in Cheat Engine) which allows me to bind directions (forward, backward, left, right, up, and down) to keys (W, A, S, D, Q, and E); however, those simply add/subtract to/from XYZ values along with a speed modifier, meaning if I'm facing forward and moving forward, everything is fine. Turning 180 degress with the mouse, though, effectively means back is forward, left is right, etc.
What I'm looking to achieve is having those directional keys apply to wherever I'm aiming the mouse pointer. So, forward is always where I'm facing, etc.
What I've done so far is some combination of the following:
- Download flycam/freecam scripts from other games and replace relevant instructions/data/etc. with my own.
- Attempt to create my own based on various information I've gathered (example here) and general research of trigonometry and vector calculus as related to game development.
It seems that no matter how much I think I understand what's going on, I've yet to make this work.
Something I've gathered is that it would really behoove me to find where the game stores/references sin and cos information, such that I don't have to calculate those values on my own via something like math.cos()/math.sin() and possibly converting degrees/radians, etc. And even those manual calculations I've tried haven't worked out, so I'm not sure I fully grasp what I need to there.
Bearing all of the aforementioned in mind, here are my questions:
Question 1: What do sin/cos values tend to look like, and at what point through a camera/coord-related subroutine might I expect to see them (whether on the stack, in FPU/XMM registers, etc.)? I've gathered that these should be close to where I'm dabbling either in memory or within a subroutine, but I'm just not quite sure what I'm looking for.
Question 2: Are there general approaches through reversing to identify the coordinate system of a game? In the case of the game I'm hacking, it's developed in Unreal Engine 4, so I can simply look up the engine's coordinate system; however, if I wanted to validate such findings (possibly fleshing out if a game is using a custom coordinate system instead of the in-built one) or discover anew when dealing with a custom engine, how I might I do that? Are they values that tend to reside in nearby memory addresses of avatar/camera data, or possibly in registers/on the stack in camera-related subroutines?
Question 3: If I know the coordinate system used in the game, as well as the XYZ and Pitch/Yaw camera values, is there a formulaic way I can calculate sin/cos therewith to then use with a speed modifier to successfully implement a freecam? This, in the event that I cannot find sin/cos within the game to use within my script.
Question 4: I only have a cursory understanding of the trig/calc I've looked up in trying to understand calculations as related to sin/cos. Given a left-hand and right-hand coordinate system with Z being up, along with XYZ, Pitch/Yaw data, and a speed modifier, could someone possibly walk me through the necessary calculations for making forward work in both coordinate systems no matter where the user points the mouse? For example, what exactly the sin/cos values are comprised of at any given time, how/why they matter, and why you would add/sub/mul to appropriately modify XYZ, etc?
Apologies for the verbosity and if I'm unknowingly asking questions that require FAR more understanding to adequately answer, but I just wanted to be thorough in explaining my research and efforts up to this point.
Thank you for any guidance you can provide!