Free Roaming (using Yaw and Pitch)

[Paul44]

A.k.a Fly hack.
(in a nutshell: you move/fly around using for-/backward keys while steering with the mouse)

I have been (re)searching this feature (on and off) for quite some time now, reading and trying out plenty of stuff on the subject. My main challenge was to come up with something "simple" to integrate, without the need of some extensive 3D transformation knowledge.
The result of my research can be found here: [ [Link] ].

I've made sure that the basics behind the script got properly documented. And I hope it will be helpful to my colleague tablemakers.

ps: technical terms might/will not always be in par, but you'll get the gist for sure.


Note:
Table below basically contains the (complete) FreeRoam/Flyhack in just 1 script. Obviously, you still need to "integrate" the asm part in your own table; and "feed" the proper structure addresses. If you need some clarifications/ assistance, do give a shout.

-EDIT- : updated pdf and table...

[amorrow28]

Very cool, thanks for doing this! There is not enough discussion on manipulating the player or camera coordinates here. In reading through your writeup, I noticed a small error with significant implications:

When working in radians:
Pitch is -1/2*pi to +1/2*pi (-1.57 to +1.57)
Yaw is zero to 2*pi or -pi to +pi (usually 0-6.28, again could be -3.14 to +3.14)

Two thoughts come to mind if the number you perceive as pitch is strictly between -1 and 1:

1. A bunch of games prevent extreme angles in viewing, which you may need to disable. I've seen locks as strict as 0 degrees to 40 degrees (+0 to +0.7), which made my free camera almost useless until I found and disabled that pitch lock. Seriously, I could not look up. AT ALL. (BUT if you're going to disable the pitch lock, be sure to implement a reasonable lock, e.g. -89.5 to +89.5 degrees, or you may end up flipping / locking your camera.)

2. A bunch of games I've looked at instead represent rotations using quaternions, which would be 4 numbers between -1 and +1 (x, y, z, w). So if rotation numbers you find don't ever exit those bounds, you might be dealing with quaternions. You can calculate your Euler angles as needed: [Link].

Finally, another approach to consider is to move the camera without moving the player. Often there is a second set of coordinates of where the camera is looking, which is tied to the player via continuously running write commands. You can disjoin the two coordinates (usually via NOP), then move the camera or the camera target without moving the player. This way you do not have to hide the player, and your movements should not be subject to all the physics of the player. You can still teleport the player on demand with a hotkey, by writing the new camera target coordinates to the player coordinates. (You can find the coordinates looking for the same XY, but Z is often the center of the player instead of the feet.)

[Paul44]

^ yep, i've came across those details plenty of times, but the endresult expected some serious research & coding; which i was not really willing to do (let alone diving into that 'quaternions theorem' ). I'm not going through all them vids again, but - surely the ones i've referenced - brought my attention to this particular approach.
Basically yaw (and pitch) angles are 'converted' to a "180 degrees = [0 ~1] range (or [0~-1] range, depending going CCW vs CW)". Iow if you turn 180 degrees CCW, you'll find a value that will go from '1' to '0' to '-1' (along the x-axis) and '0' to '1' to '0' (along the y-axis). and these values will be in proximity of each other.
(ps: for pitch you'll find a "representative" range between '1' and '-1'. AND btw: this is the best value to scan for !)

By now, i have updated (almost) all my tables to this new routine; and my routine has been updated to cover all "exceptions" (y/z values inverted, "negative" height, positive/negative yaw values). But most importantly, I've found these numbers - pretty quickly - in all them games !

ps: in the past, i simply updated x,y,z coordinates using appropriate (num)keys. it worked well - all things considering - but "steering" is/was obviously a pain...


As for your camera suggestion: i've been thinking about that as well, but then figured: "what if one can change the distance to the player - primarily for 3rd Person games - in such a way that s/he winds up 'behind the player's camera view' ?"
(not at all on my research plate atm)
=> also keep in mind that you'll find plenty of these "similar" values in your game; i would not be surprised if some of them cover particular camera positions... ?!

[amorrow28]

It's very interesting that you are able to make that work! I do still suspect you might be dealing with tilt locks, and here is my reasoning... but of course please take with a grain of salt because I don't own this specific game and cannot test your table directly!

You definitely are using standard trigonometry to calculate vectors, as far as I can see. So if for example you are looking up 45 degrees from the horizon, that would be 0.8 radians, but if scaled to a -1 to +1 scale, it would be 0.5 (exactly half way to 90 degrees). If you move forward, your code would raise your height by distance * sin(0.5 or 28 degrees) and forward by cos(0.5 or 28 degrees). So instead of moving forward, you would feel like you're moving forward and down. Is this something you are experiencing? If not, I would have to think the numbers are truly in radians and there is code preventing you from tilting more than -1 radian (-57 degrees) to +1 radian (+57 degrees). Of course, if you are finding that the numbers have been scaled, you could unscale them back into radians by multiplying by 2/pi, that would restore correct trajectories in all dimensions.

In regards to quaternions, I'll admit I haven't bothered to manipulate them. My favored approach to dealing with quaternions is to ignore them entirely. I find the XYZ of the target, and the XYZ of the camera. And then I move those two coordinates and let the game engine do the rotations for me!

Putting the player behind you is an interesting idea, but might make positioning the player tricky if you want to teleport. Perhaps just make the player invisible by activating clipping or culling?

[Paul44]

^ perhaps a "showcase" might put some light on the matter ?
a. google "paul44 site:fearlessrevolution.com": gives you some/most of my tables (and most of these have the latest Free Roam feature already ~ check features/updates list)
b. give me some/a list of your own tables (for games i can download/repacked preferably) AND for which you've - preferably - already made a flyhack/freeroam feature

as for: i have not yet found a good way in researching/detecting 'clipping'; and 'culling' is a new word to me (and a quick wiki did not help either ) ?

ps: like i mentioned before, my wording is not (always) top notch on this matter; rereading my last post just made things more confusing frankly

[amorrow28]

First, BTW, thanks for discussing and chatting (and for making the initial tutorial) - I feel like no one ever responds to replies on this forum for some reason, especially if someone actually offers some feedback. This has been interesting!

Ok, I went WAY down the rabbit hole, much further than I probably should have haha.

The only game I own that you developed a fly hack for was Assassin's Creed 2, which I must say is a terrible game for finding cheats since there is no window mode and the game minimizes every time you alt-tab out. How on earth did you do any searching for this game??

Using your cheat table as a base, I found the base pointer for the camera module, which is at AssassinsCreedIIGame.exe+01E111B4 using the current version of the game.

[AssassinsCreedIIGame.exe+01E111B4]+30 = Camera X
[AssassinsCreedIIGame.exe+01E111B4]+34 = Camera Y
[AssassinsCreedIIGame.exe+01E111B4]+38 = Camera Z
[AssassinsCreedIIGame.exe+01E111B4]+10 = The base value for what your script calls Yaw 1, is sin(yaw)
[AssassinsCreedIIGame.exe+01E111B4]+14 = The base value for what your script calls Yaw 2, is cos(yaw)
[AssassinsCreedIIGame.exe+01E111B4]+18 = The base value for what your script calls Pitch, is -sin(pitch)
[AssassinsCreedIIGame.exe+01E111B4]+1C = ??
[AssassinsCreedIIGame.exe+01E111B4]+20 = Rotation around the Y axis (some mathematical combination of +10/+18)
[AssassinsCreedIIGame.exe+01E111B4]+24 = Rotation around the X axis (some mathematical combination of +14/+18)
[AssassinsCreedIIGame.exe+01E111B4]+28 = cos(pitch)
[AssassinsCreedIIGame.exe+01E111B4]+2C = ??

If you NOP this instruction:
AssassinsCreedIIGame.exe+11883F3 - 0F29 41 30 - movaps [ecx+30],xmm0

Then you can put the camera anywhere you want, as that single instruction writes to +30/+34/+38/+3C.

Similarly, knocking out these instructions:
AssassinsCreedIIGame.exe+11883E3 - 0F29 41 10 - movaps [ecx+10],xmm0
AssassinsCreedIIGame.exe+11883EB - 0F 29 41 20 - movaps [ecx+20],xmm0
will allow you to directly manipulate camera rotation, but not correctly if you only edit +10/+14/+18, because they are not truly yaw and pitch. Your script works just fine despite thinking of +10/+14/+18 as an XYZ vector (combo of yaw and pitch) because you're not trying to move the camera at all, you're just letting the game engine do it for you. After all, you can get yaw from sin(yaw) and cos(yaw) using arctangent2, and you can get pitch from -sin(pitch) by using arcsine, which you referenced in a link listed in your pdf.* Treating +10/+14/+18 as an XYZ vector doesn't let you directly manipulate the camera angles, unfortunately, only the location of the camera and/or player, because the matrix does not fix itself (+20/+24/+28/+2C remain unchanged as you manually change +10/+14/+18/+1C, even if you knock out only the first instruction).

That's fine for this particular game engine because once you block writes to camera XYZ, you essentially have free-look because the engine doesn't enforce the view to the player; most games I've worked on force the camera to stare at the player however. What to do if the camera forces view? Breaking writes to +10/+14/+18/+1C/+20/+24/+28/+2C would allow you to edit the rotation numbers directly, but we'd have to figure out all the numbers of the matrix, which is kind of beyond me. Or we backtrace until we find the true tilt and pan, because usually these numbers do exist in memory somewhere. If you can take control of those, you can free rotation, which will allow you to look away from the player. In this game you don't need to do it for that reason, but it still may be worthwhile to find/free the true tilt and pan so that manipulate them even during times when the player doesn't have tilt/pan control (for example during cutscenes), and you can bypass the tilt locks (AC2 only lets you look down to 70 degrees, and up to 45 degrees).

EDIT: Since the mouse can look freely when the camera XYZ is detached, I realized that I had all I needed to implement a basic free camera, so I went ahead and did so, just so you can compare your approach to mine!

AC2_FreeCamera.CT

(8.03 KiB) Downloaded 1242 times

Code: Select all

Free Camera Controls:

Hotkey : Num 0 (Toggle On/Off)

Num 8 : Forward
Num 5 : Backward
Num 4 : Left
Num 6 : Right
Num - : Up
Num + : Down

Mouse control for tilt/pan. (Make sure to use keyboard/mouse controls.)

F1 : Decrease Camera Speed (Press and Hold)
F2 : Double Camera Speed (Press and Hold)
F3 : Quadruple Camera Speed (Press and Hold)

Note: My approach is to move the camera instead of the character, in which I discovered something very strange about this engine - it doesn't really properly render objects not in view of the player (and things get... weird). Also, if you code inject instead of NOP, you could copy ecx into a memory address and that would point to the coordinates as well, but I used a static pointer, because why not.

Anyway, here are all the camera scripts I've done: Trails of Cold Steel 1, Trails of Cold Steel 2, Trails of Cold Steel 3, Hajimari no Kiseki CLE, Kuro no Kiseki CLE, Tokyo Xanadu eX+, Atelier Ryza, Atelier Ryza 2. Clearly we have pretty different tastes in games haha.

Oh, and culling is when the game engine removes an object from the render pipeline because it is not visible, which improves frame rates by reducing the number of calculations. I've never actually tried to force culling a visible object using CE though, but I suppose it should be possible. I've found the clipping variable a few times, usually by standing next to a wall and moving the camera so that the player keeps appearing and disappearing.

[Paul44]

^ Swell that you have AC2 at hand, so i/we can use that one as example. As for the "intake": my goal was to achieve a roaming feature for the player him/herself, nothing about 'influencing' the camera; your vision is pretty much the opposite.

In the mean time, I did some thinking myself:
1. when you activate the free roam script, you can no longer move your player... since the script continuously feeds him his latest coordinates (which basically is another way of "locking" your player)
2. interesting enough, i'm using the camera's yaw/pitch values here found in a structure named 'AC2FreeRoamingCamera'. (guess how i came up with my "own" naming convention )
3. what i've seen sofar in most games - and surely AC2 also applies - is that these structs also contain their own coordinates (not really surprising). So what would happen if one feeds those coordinates (instead of the player's) ?
(set aside the possibility - as you stated - that the camera is "linked" to the player ~ although i'm pretty confident that one of them many structs actually use another camera struct...)

what i'll do in coming days/week:
a. update 2 of my tables, as their games got updated
b. definitely try out your table feature
c. feed them camera coordinates instead of player's
d. see if i can get my hands on one of them games of yours

to be continued...

ps: get windowed, see here [ viewtopic.php?f=23&t=11869 ].
note that: a. AC2 comes with a batchfile allowing you to patch the exe b. i prefer using Dxwnd in most cases c. aforementioned topic has some other suggestions as well...

[amorrow28]

I think that's a fair assessment, that our goals are different! Honestly I didn't understand that at all until I actually downloaded and tried one of your scripts, and took it apart to see how it worked.

I thought you were defining pitch and yaw as numbers that went from -1 to +1, but really you were transforming numbers than went from -1 to +1 into pitch and yaw. It kind of all made sense once I actually dug into the code. Also, once I realized that you really weren't manipulating the camera at all, your approach made sense to me (hunting for the rotation matrix itself). Honestly, the only faults I can see are that there are other rotation numbers that are between -1 to +1 such as limited pitch (true pitch in AC2 is actually restricted from -1 to +0.7 radians for example) and quaternions. So it helps for me to know that what you are looking for are numbers that go from -1 to +1 when traversing the XYZ axes. (although for folks reading the thread hoping to actually manipulate camera rotation, know that this approach isn't going to work - find the real pitch and yaw!)

Anyways, please do try out my table! I actually don't think our goals are actually opposite, since you could adapt my approach for teleportation (see my Atelier Ryza / Ryza 2 tables). I have a hotkey defined that moves the player to right in front of the camera at the touch of a button. I see a few advantages to this approach.

1. Unobstructed view - you don't have the player in front of you as you roam the level. Bonus that the player isn't stuck in a weird falling animation the whole time (at least Ryza seems to look like she's constantly falling if I drag her around a level).

2. No detection - you don't really need to worry about "god mode" other than fall damage. I could see how it would be annoying to bring the character along as you roam in a stealth game, for example, especially if the mechanics cause instant death / restart if you're detected. Or you drag the character to the end and all the enemies follow you so that you have a whole mob behind you by the time you get to where you're going. With a camera-centered approach, you can leave the character in a safe place while roaming the level, then teleport to the goal once you've located it with the camera.

3. Player choice - some folks (like me) just want to look around. Others might want to "preview" a level but still want to play roughly as intended. So they could browse the level, plan a route, turn off the free camera and then play the level.

4. Smoother experience (??) - I'm at a loss to explain this one, but I've noticed that game engines somehow resists more when dragging the character. Even comparing AC2 scripts, the game seems to jerk / lag when I use your script. Granted my computer is really underpowered. But this isn't the only game where I've run into this.

To be fair, I see advantages to your approach too!

1. Simpler. Freeing the camera was really easy in AC2 for some reason, easier than any other game I've ever done. Most of the time, you have to disable all sorts of things to get the camera to look away from the player and to restore a smooth parabolic arc to the camera tilt (if you're moving the camera target instead of the camera itself).

2. Fun - Admittedly it's kind of hilarious to drag your character around while he's stuck in a free-falling animation.

Anyway, if you like my idea, I think my only tip is to use a temporary memory buffer for teleportation because Lua is kind of slow, which isn't a problem for free roam but *is* a problem for teleportation. If you writeFloat three times (X1Y1Z1->X2Y2Z2) the game engine may read XYZ in between the three writes, and the player may end up at X2Y1Z1 or X2Y2Z1, which might trigger instant death, a cutscene, enemy detection, etc etc. So usually I'll write X2Y2Z2 to a 128-bit space I've allocated, then use the copyMemory command to move all the bytes at once.

Oh, and as to you knowing the name of 'AC2FreeRoamingCamera' - I assume you're referring to this? I was very excited to read your post and have tried that in a few games, but sadly I haven't had any luck. I've also tried the script that Dark Byte posted over on the CE forums without any success. I can find the structure names, but have never been able to find instances of structures based on names - even when I know the names are there (because CE can "guess" the name when I use the dissect structure feature). My guess is that a lot of the techniques are based on how Visual Studio compiles code, and all the games I play are console ports written on Sony software. I haven't given up though, I suspect the principles are probably the same and I just need to find the correct pointer path.

[Paul44]

^ "what you are looking for are numbers that go from -1 to +1 when traversing the XYZ axes": see, that wasn't too hard . Just kidding, but yes, that is exactly what I try to explain in that doc. Iow I do not do anything spectacular, i just collect these values and do some minimal trigonometry to get both angles, and from there the corresponding x,y,z "additions" (steps, if you will). Which made this routine pretty simple. and indeed - apart from 1 game - most games will return value ranges somewhere between -1 and +1.
Tip: since pitch can only be between -1 and +1 (up and down), that is therefore the easiest to find. (it's a bit similar to finding coordinates using height changes ~ walking up/down the stairs). Another thing i might look at: use a modifier/multiplier "to stretch" them values to actual +1 ~ -1 (especially with pitch angles being rather small-ish)

a. using the camera to go about and create some teleport spot elsewhere, is what got my attention. not to mention all them +'s you've mentioned here in that respective.
b. "game engines somehow resists more when dragging the character": pretty much most/all do; i'm guessing because of constant coordinate read/writes. which is when using a read-opcode, your character will be "jerkier".
c. "usually I'll write X2Y2Z2 to a 128-bit space": interesting approach; will keep that in mind...
d. "AC2FreeRoamingCamera": yep, that is the link, credits to #Sunbeam. It'll take some practice at first, but you'll get there eventually. Best approach would be to exercise first with an existing structure, and follow its path to the structname...

[amorrow28]

Yes, give it a try! You could just bind a hotkey to write the camera coordinates to the player's coordinates, although it would be more elegant to deposit a little in front of the camera. In my tables I calculate the dropoff, but since you already have the values for your camera aim vector, you could use them.

In AC2, for example, you could do something like this: (note - untested, math might need some tweaking)

Code: Select all

--Teleport to where the camera is looking
if isKeyPressed(VK_DIVIDE) then
  writeFloat("memorybuffer+0", [[camerabase]+30] - 5 * [[camerabase]+10] * [[camerabase]+28]) -- X coordinate
  writeFloat("memorybuffer+4", [[camerabase]+34] - 5 * [[camerabase]+14] * [[camerabase]+28]) -- Y coordinate
  writeFloat("memorybuffer+8", [[camerabase]+38] + 5 * [[camerabase]+18]) -- Z coordinate
  copyMemory("[playercoordinates]",12,"memorybuffer+0")
end

Thank you for the insights on hunting down structure instances.

[Paul44]

^ I have tested your table, this afternoon. Kudos, man ! Really excellent stuff; I would never go that far for sure...

And obviously, i wanted to see what i could do with my routine, as it - logically - would be able to do the same thing. and you find the result attached: a) enable 'Free Cam...' b) enable 'Free Roam... ' (and ignore the main script altogether)

Things I'll be working on in coming weeks/months:
1. get this as "smooth" as your routine (see your suggestions earlier - perhaps doing some nop-ing here as well)
2. "generalize" the routine, so that I can easily integrate it in my framework
3. do some (serious) thinking about how to include 'Left - Right' movement (for player roaming, not really an issue; but i do dig it from a camera perspective ~ logically that struct should also have that info, in relation to horizontal plane orientation)
4. add the 'teleport' functionality here as well

As for your table:
1. if you do not mind, I'd like to post it in my topic. will first do some testing with my other exes (in that respect, i'll be removing the exe reference and use $process instead for starters)
(if you want to do that yourself, give a shout and I'll upload all my exes pronto)

2. main Q: what is your approach to finding the proper camera structure ?
for AC titles, that will not be a big issue, but other game titles might/surely take more research time...

3. some suggestions re your routine:
=> keep in mind that i did NOT take your quick build of this table into account; iow it might just work like this normally... !
a. use 7-9 to de/increase (easier to manipulate ~ reach those keys)
(if not, use + = increase & - = decrease <= well, in my case they do the opposite ~ could also be a keyboard issue)
b. speed multitpliers: not really sure how they're integrated atm, apart from continuously holding the F-key to see its effect
(and i am assuming that this is not the idea; but rather pressing "a" speed_key results in you in/decreasing accordingly ?!)
~> if not, i would use the F-keys to set a particular speedmultiplier, which is then applied while roaming
(definitely not happening now)


ps1: you'll find my actual routine following [Tools ~ Settings ~ Maintenance scripts ~ Initialize Special Scripts]
ps2: you have to admit that my routine is a lot less complicated then yours (snoring with a captal S here )

and thx for sharing all this knowledge.

[amorrow28]

First, you are definitely welcome to post my script in your post, copy all or parts of it, reuse it, change it, whatever you like! As I put in the table credits, I got the original routine from Cyber's CS4 table, although I've altered it a fair amount at this point.

I tried your script, works pretty well! I think my script is smoother only because my timer interval is set to 10ms and yours is to 100ms (1/10th the FPS); you could set your timer interval and default XYStep to both be lower.

Left and right strafing is a math thing, you shouldn't need more numbers than you already have. The easiest way is to swap x and y, for example left should be XValue = xVal - y and YValue = yVal + x, I *think* that should work. But if it doesn't, do your calculations on an angle 90 degrees less than your current yaw. For example, if forward yaw is 120 degrees, left yaw is 30 degrees. So if your current script has x = cos(yaw) and y = sin(yaw) for forward and backward movements, then x = cos(yaw-90) = 1-sin(yaw) and y = sin(yaw-90) = cos(yaw) for left and right movements. Diagonal movements are the same, just use 45 degrees (e.g. xVal + x - y, yVal + y + x should work, although for the best experience you could either calculate on yaw +/-45, or use Pythagorean theorem, xVal + sqrt(x^2-y^2) which will probably feel more natural but is probably overkill).

In regards to how I found the camera structure - in this game I cheated and used your table as a base:

1. I used your player coordinates to start.
2. I added your camera directional vector on to the cheat table so I could see the values (They're the -1 to +1 numbers, I'm going to call them xdiff, ydiff, zdiff although as established above, they're technically sin(yaw), cos(yaw) and -sin(pitch)).
3. When xdiff is 0, camera X should match player X, so I searched memory for player X value when xdiff was as close to 0 as possible. I knew the number would be close but not the same as player X, which helped. Then I moved the camera without moving the player, and searched for increased/decreased value (since I already know the direction of the axis, no need to use changed/unchanged).
4. Once I knew the value, I added all the memory addresses that held the correct value all of the time to the table. I then froze them a few at a time until the camera started to stutter with movements, then whittled down until I found the only value that made the camera stutter.
5. I confirmed that there was only one instruction writing to this address, and that instruction wasn't shared. NOPing the instruction locked the camera in place, and I could move the camera by typing in manual values, confirming the memory address as the true camera coordinates.

Of course, when I'm actually finding it in a game where I don't already have your table, I do it the old-fashioned way, by walking up and down stairs and looking for changed/unchanged and increased/decreased values. (See Stephen Chapman's amazing video [Link].) I like that you can find the structure by name though, it'll make it much easier (I think) for you to find it in other games based on this engine! Even when I'm "porting" a table from one game to another on the same engine, I end up using AOB scanning for analogous code.

In regards to the control scheme, this was indeed a quick and dirty table. I've kept Cyber's scheme for many of my tables for familiarity reasons, and it probably could be improved. I like that - is up and + is down because on my keyboard, - is above + on the number pad (I use an old PS2 keyboard that I'm pretty sure I bought in 1998 or so). The table I posted here has about half the function removed, because I didn't hunt down true yaw and pitch. Next to the true yaw and pitch is often roll, and the 7 and 9 keys are used to control roll (screen rotation), with 3 as a reset key, and the arrow keys would control yaw and pitch manually. As you said, our goals are different - I usually want full control of the camera. I'll find and disable the tilt locks, Z limiter, camera distance, HUD drawing, camera collision sphere, cutscene camera lock, and implement some form of universal game pause / freeze frame so you can take epic screenshots. Some games I end up having to disable in-game mouse control, so I've had to re-implement mouse control in some of my tables as well (esp if I'm dealing with quaternions). You're absolutely right with the speed control though; I've never touched that part of the script which is inherited from Cyber, but I've never liked how you have to hold down those keys (esp since they're so far away from the keypad).

And likewise, thank you for sharing your knowledge!

[Paul44]

a. "smoother only because my timer interval is set to 10ms": damn, did not even think about thàt, but that did it effectively
b. "Left and right strafing is a math thing": for sure, but atm i have no idea how it will behave in them respective 4 quadrants; especially with those "exceptions" (~not all games will give the same matrix values; some give "inversed" x-values, others y-values). But surely doable, just need to 'trial & error' in practice as usual... After all, i already have the yaw angle, so...
c. "because on my keyboard": funny that you say that, as i bumped into that myself with gamers either having no NumKeys at all (read 'laptop') or some special gaming keyboards. Which is why i made it configurable in my tables.
=> in that respect, check out Nirsoft's [KeyboardStateView] tool; it returns the (hex)code of any pressed key !

[amorrow28]

Oof, trying to make code foolproof for any table creator to use without fully understanding is quite a challenge!

I have two thoughts / approaches that you could consider:

1. You could base your script instead on finding two coordinates (camera XYZ, camera target XYZ). The vector from cXYZ to ctXYZ will ALWAYS point forward, regardless of what direction the axes point. Then you only need to worry about direction of the yaw angle, clockwise or counter clockwise, which only affects left and right movement. (Interestingly, the games I've worked on, using Sony's phyreEngine, Gust's LTGL engine, Falcom's new engine, have all had counter-clockwise yaw, whereas AC2 has clockwise yaw [inverted Y] which baffled me at first.) You could base your calculations on yaw for forward, yaw+90 for left, yaw-90 for right and yaw-180 for backwards, and then have a global variable for CW/CCW and flip the signs depending on how the user sets the variable.

2. You could keep your method, and have 2-3 variables to set (inverted Y and inverted Z at a minimum, probably inverted X as well). Then your calculations flip the x,y,z signs before applying to xVal,yVal,zVal. (e.g. if inverted_Y == true then y = -y end) The user doesn't need to worry about transformations (xVal + x - y etc etc), only the direction of the axes.

The advantage to #1 - very intuitive to set. As stated, cXYZ -> ctXYZ always points forward, no matter the direction of the axes. If the table creator finds those, forward direction works right away. Then if left key goes right instead of left, change global variable yaw_is_clockwise from false to true.

The advantage of #2 - as you have found xdiff/ydiff/zdiff may be easier to hunt for. The disadvantage is that it might take some experimentation to get the directions right since there are three variables to set (inverted X/Y/Z). Having said that, rotation matrices don't really change since they are fed directly into the DirectX libraries, so likely X and Z will not be inverted 99% of the time (I would instruct the table creator to tackle the axes in the order of Z->Y->X). Also, I'm pretty sure the camera rotation matrix will always exist *somewhere* in memory; the same cannot be said for ctXYZ, true pitch, true yaw. So this method is probably the most reliable.

Of course, this is mainly for your goal of making it more plug and play. For me, I adapt my approach to every game, much easier than trying to make one master code that works for all games... I think it's great that you're doing this though, and ultimately a lot of table creators will benefit!

I'll have to check out KeyboardStateView, thanks!

[Paul44]

^ I've finally uploaded my AC2 table, with Camera roaming added (+ additional finetuning). Also noticed that AC2 only updates environment within a (short) range of the player... iow when using Camera and move some distance away, streets are no longer populated and environment gets only "basic" graphics. (bummer)
ps: i only referred to this topic as far as your table is concerned; as i realized that the hardcoded address_refs were pointing to the Camera struct. And since i got it running in my table, i decided not to touch it (for the time being).

I have also been working on Kena (UE 4.x), implementing a similar free roaming. and it took me awhile to get Kena not dying all the time when descending much... (as far as I know, no godmode flag in this game ~ luckily #Cake-san's UE4 Base Table comes with a flyhack feature, which helped me to find a solution)
Btw: this game (UE by default ?) has a 'PlayerCameraManager' struct, which holds info related to that camera (incl actual yaw, pitch and roll). I'm not using those values though as I followed my standard routine; plus i noticed that updates of these values seem to "lag" a bit (could be CE though)...