What is the process for adding games?

[Bateman34]

I want to try and add more games but I don't know what you are supposed to do. This project has insane potential and yet it seems to be dying.

[isJuhn]

You add more games by reverse engineering the games camera related code and figure out how to manipulate it in memory to move the camera and also how to find it in memory. It's not an easy process.

[Bateman34]

Is there documentation on this process? I want to help by adding some games but I can't figure out how to.

[isJuhn]

It's a complicated process, just start out with learning how to use cheat engine and how to find the camera direction address. Also general programming skills is very much a plus. I won't write a full tutorial because it's not possible, the process is different for every game.

[slidenerd]

so you are getting these hex code values by running the PC version of the game with cheat engine in the background?

[isJuhn]

No, I run the games in rpcs3 and use CE attached to that

[Coinhexa]

I take it that you have single handedly written many implementations from your Games folder. I have a few questions if you dont mind answering.

• How did you find out if a certain game is using the HAVACamera or HvecCamera or HvecVACamera
• Lets take your implementation for KillZone3 for example. Your implementation has this line into it.

  
  "01.14" => DerefChain.CreateDerefChain(ipc, 0x15fcf80 + 0x770, 0x40, 0x68),

- What is 0x15fcf80? Is that the base pointer that you deduced from several scans inside cheat engine by performing different actions to narrow it down? I am guessing this pointer doesnt change no matter how many times you reload the game or whichever player reloads the game?
- This math implementation here looks different for each game. For KillZone3 again
- Some games have a third person view and then you aim down your sights, what have you observed with respect to the camera in such type of games? Does the address change or is it just a change in values?
- Why is SensModifier 0.003f everywhere?

m_camera.HorY = IPCUtils.ReadFloat(m_ipc, (uint)m_hor.Value); m_camera.HorX = IPCUtils.ReadFloat(m_ipc, (uint)(m_hor.Value + 4)); m_camera.Vert = IPCUtils.ReadFloat(m_ipc, (uint)m_vert.Value); m_camera.Update(diffX SensModifier, -diffY SensModifier); IPCUtils.WriteFloat(m_ipc, (uint)m_hor.Value, m_camera.HorY); IPCUtils.WriteFloat(m_ipc, (uint)(m_hor.Value + 4), m_camera.HorX); IPCUtils.WriteFloat(m_ipc, (uint)m_vert.Value, m_camera.Vert);

How did you arrive at this equation under updateCamera. It looks like it is different for each game? I would super appreciate if you can atleast add some comments on how this equation is deduced. I am trying to add my own game with your implementation on it and it would be super useful as a reference point.

[slidenerd]

It's a complicated process, just start out with learning how to use cheat engine and how to find the camera direction address. Also general programming skills is very much a plus. I won't write a full tutorial because it's not possible, the process is different for every game.

If it isn't too much to ask, perhaps you could document the process for the current game that you are trying to add. You dont need to write a 1000 paragraphs. A few screenshots of your cheat engine scans and the game while doing what you do would be super helpful

[isJuhn]

Since I'm on phone right now I'll answer some of the shorter stuff now and come back to this when I'm at my pc

• You can tell from the values what kind of camera it is. Is the camera 3 values which all range from -1 to 1? It's a 3D vector thus HVVec. Just observe the values and their ranges when you move the camera ingame.
• 0x15fcf80 in killzone 3 is some kind of base address for a large and complicated structure which contains loads of the game state, by traversing this structure through offsets and dereferences we can arrive at the camera values. Those offsets are what's sent as arguments after the base address to DerefChain.
• Third person view and aim down sight tends to be different. The most complete and complicated hook which takes this into account is ratchet acit, where it uses different logic for the different cameras in addition to a horrific memory structure which I hope never to have to figure out. Right now I use heuristics to find the correct camera, very ugly.
• Sensmodifier being that value was just a reasonable default for my setup, the idea is that every single game should scale in the same was such that that moving your mouse enough to spin 360 degrees in one game should work in all other games without adjusting sensitivity, even if one game uses vectors and the other angles.
• as for writing more, I have written some in the half finished KAMI discord, I can post the link later if you are interested.

[Coinhexa]

@isJuhn thank you for taking your time to answer these queries, please do link to the discord or documentation that covers the explanation for some of the rationale in your implementations.

[isJuhn]

@Coinhexa here's the discord, feel free to ask there for faster responses https://discord.gg/88eSsFwKC4

As for the 7 lines of code you posted, it's just the natural process of reading the camera values from the game, modifying them and then writing them back. In this case the horizontal and vertical addresses are different, thus there are 2 different dereference chains. But the idea is you just read out the 2 values representing the horizontal vector, and then the value representing the vertical angle and assign them to the corresponding values of the camera object. Then calling update with the newest mouse movements, and the camera will manipulate the values as needed and you can just write them back to where you read them from.

@slidenerd The current game I'm working on is Battlefield bad company, but there's no way to convey the process in a few screenshots of scans. It has been hours of scanning combined with meticulous debugging and reversing. For some games the process is very simple, you just find the camera values by using the unknown initial scan then doing "value changed"/"value unchanged" until you arrive at number of candidates. After that you can add them to the list and perform a binary search by selecting half the values and pressing space bar to freeze all selected values, depending on if the camera ingame is frozen or not you'll know if the camera address is in the selected half or not.

Only after finding the address will you know how hard the game will be to actually add to KAMI. If you are lucky, this address is the same on every boot and every level. If you are unlucky you will need to trace how the game accesses this value, which can be a very long process of tracing backwards where the value comes from and how it is calculated. To do this I use a combination of ghidra, cheat engine memory breakpoints and the rpcs3 debugger. There is also some experimental code I've written for a custom rpcs3 one can use, but this requires knowledge of how to build rpcs3 and generally how PowerPC64 works.