It looks like you're new here. If you want to get involved, click one of these buttons!

Hitman 2016

Anyone know if there is a CE table available for this game?


  • edited November 2016
    An outdated one: https://www.reddit.com/r/HiTMAN/comments/4gkmbi/i_need_a_photo_mode_so_hard/d37kdfh/ (AOB scanning though). It doesn't seem to work anymore, but I'll check today and if not will try to fix it. Game looks too good to pass up ;)

    (edit) Found player and camera coords by using stairs+walk/updown+scan trick, now to convert that into a CT... Looking at Jim's table, it *should* be rather easy, but the thing is overwriting the coords with a value doesn't work (is reset immediately), so I have to circumvent that by telling it to read them from somewhere else. Problem is of course: the coords are read in a lot of places, and as the original table doesn't do that, I miss something. I see they left the labels in the exe, perhaps I can use that...

    (edit)... and it crashed. back to square one! :/
  • Thanks! Having a look at the table as well.
  • edited November 2016
    For ref: cam z is written at:
    hitman.CAkRegisteredObj::~CAkRegisteredObj+10AB39 - 0F29 43 70 - movaps [rbx+70],xmm0
    which is: hitman.exe+4193949

    I now understand what Jim did: he nopped the write (the above instruction) and grabbed the coord address in rbx (and add 70).

    (edit) x & y are also written by this same instruction. Hmm... nopping it will swap the vector direction so mouse look is OK but camera doesn't move. Looking further.

    (edit) lol, moving x&y moves player around, but not camera. close!

    (edit) other write:
    hitman.exe+4190268 - F3 0F11 83 98000000 - movss [rbx+00000098],xmm0
    hitman.exe+4190138 - F3 0F11 83 98000000 - movss [rbx+00000098],xmm0

    These write Z for cam + player. Nopping one doesn't work, nopping both moves player and cam up in the air, nice for a good laugh but, also not what we want! gah... Maybe yet another address... :/

    (edit) FOV written at:
    hitman.Scaleform::Render::Matrix4x4::SetIdentity+104DEF - F3 0F11 83 00070000 - movss [rbx+00000700],xmm0

    At least there's SOME progress ;). Still can't believe I can't fix the damn camera.

  • edited November 2016
    To leave this sadness on a semi-high note, here's the FOV script. Fov is at [fovAddress+700].

    Code is an eyesore, but it does the trick. Will re-work it into a threaded lookvector driven flyby camera like I did for darksiders 2 later.


    mov [fovAddress], rbx
    jmp exit

    movss [rbx+00000700],xmm0

    jmp returnhere

    dq 0

    jmp newmem

    movss [rbx+00000700],xmm0


    Still looking into that camera mess. If anyone has ideas, jump in! :)

    (edit) game hotsamples nicely btw, all aspect ratios.
  • edited November 2016
    hitman.CAkRegisteredObj::~CAkRegisteredObj+10AB39 - 0F29 43 70 - movaps [rbx+70],xmm0
    is the right instruction, apparently something went wrong when I first tested it. In the first mission now, nopping this and changing the coords on rbx+70 manually works: camera moves, 47 stays put :)

    Not a lot of time now so I hope to hack something together quickly :) That code is called for x, y and z, so to grab the address some tests have to be done, which I of course don't know, but will try.
  • Ok, got it.

    fovAddress + 70 is coordX, fovAddress+74 is coordY, fovAddress+78 is coordZ. :) Camera now works in a hacked together table. Will clean it up and release rudimentary version which uses camera movement over xyz. Not ideal but it's better than nothing! ;) Look vector is near fovAddress too so it's not hard to work it into a proper 'hatti-style' camera. Stay tuned :)
  • Here it is:
    Just click 'download zip' or copy/paste the file.

    Press F2 to enable camera tools, you can then change fov to your liking using num+/-. Reset with num*. After camera tools are enabled, you can enable freecam with Num0. move with num8/2-/num4/6-num9/3. Use alt to speed that up. Still rudimentary, not sure if timestop plays nice, had a crash while typing hotkey definitions. The nopping of the current statement is perhaps a bit rigid, as it's used by more functions than just the camera. So it should do a compare on the fovAddress found and do the original code if the passed in pointer isn't equal to that, but that's for later.

  • Didn't realize you guys were working on it. I already updated the freecam today. No idea how it works outside of the intro level though.

    Natty seems to have noticed some issues so there's probably some filtering required. Boo hiss...
  • Didn't realize you guys were working on it. I already updated the freecam today. No idea how it works outside of the intro level though.
    Natty seems to have noticed some issues so there's probably some filtering required. Boo hiss...

    Heh ;) Yeah flying boats seems... off ;)

    Once I had the fov I watched the memory around it while moving the camera and found the addresses rather quickly that way: even rotating the camera updates these addresses which suggests it's the right one ;) Tried it in intro and paris level, and seems to work OK. Though as the code which is altered now is also used for other pieces of data, I think indeed some filtering is still needed, as often e.g. cubemaps are created with cameras too so it could hurt reflections too but haven't noticed anything so far.

    Updated the table at the gist at github to give you credit too, as the timestop is still yours. Will see if I can migrate your mouse stuff to my table too and make it a proper moving camera tomorrow.
  • I even checked to see if there were any other addresses being written to by those camera opcodes.

    I grabbed all the DLC levels now so I'll be doing some checks on those as well. Filtering out values you don't want in scripts isn't all that hard, but when you have to do it for 3 opcodes in a single script, it gets annoying.
  • Flying boats SHOULD be fixed now:


    Still checking the other levels for any other anomalies.
  • Oh wow! Lots of updates while I was sleeping! Thanks guys, I really appreciate all your hard work. I'll definitely be trying these tables out.

    Flying boats? What if I wanted flying boats!?!
  • edited November 2016
    Jim, your coordinates are definitely different but both work. Same scene, same instance, I loaded first your table, grabbed the addresses below and then loaded mine and did the same.

    Jim's table:
    cam x: 1AD863590
    fov: 1AD86367C

    cam x: 1AD863570
    fov: 1AD863C00

    So that figures why you have different code addresses to overwrite. They're almost next to each other, and are updated in sync. It's odd that manipulating either one will give the desired effect, so both seem to be used for the end result. Oh the mysteries in life ;).

    Differences are also in the fov value: mine is '40.0', yours is '0.70'. The '40.0' in your structure is there though, it's a couple of rows up. As I haven't played any of the higher levels I don't know if my table works there, but we'll see. Will try to make it a threaded table with smooth movement aligned with the lookvector today, should be 'easy' as I can simply re-use code from darksiders II

    (edit). Mine is buggy too sometimes. It failed on me the first time I tested it in the prologue video with the chopper. If I timestop first, then enable camera, it's out the window, however repeating these steps don't make it fail again. Bizarre shit. Anyway, failing stuff is not usable, so I'll ditch it, and will update yours with the movement thread code :)

    (edit) for reference: see the Guide topic for the updated smooth camera: http://www.deadendthrills.com/forum/discussion/comment/10565/#Comment_10565
Sign In or Register to comment.