droncode / rehitman Goto Github PK

We should make our custom placeholder and logo.
All discussions of this issue in Discord

I guess, that have trouble in design by IO-Interactive developers.
But we can fix that by creating patch for that. And here we have 2 ways:

1. Patch the loader and load custom loader sequence script (unpack that from PRM and use as external file)
2. Fix ZLoader_Sequence_Wintel_D3D class and calculate new timings in runtime.

Realistically the Launcher should close once it has launched our Dev Console.

It can be closed manually without any issue, so it should close after a period of time, or once execution of the launcher has completed.

This issue looks at the possibility of re-organizing our folder structure for the CoreKill SDK which we are reversing from IOI's original.
This would put us inline with IOI's original file structure for the game.

SDK STINGS.txt

Thanks @Notexe for strings usage since I couldn't be bothered.

We have a few notes in the folder
HM3CoreKill/HM3CoreKill/docs/
and I guess it's better been in wiki pages.

Intro

Hitman uses native C/C++ scripts for in-game behavior.
It conflicts with the multiplayer concept.
We must disable all scripting and take control of all entities before start multiplayer development.

Tasks

• Detect ZScript::update(float dt) method
• Hook ZScript::update(float dt) and implement our logic
• Add AngelScript or LUA as scripting engine

Extra tasks

• Implement serialization/deserialization of entities into binary packages or JSON

So, we have already reversed some components of the rendering subsystem (like ZDirect3DDevice) and we should continue our work here.

We need to decomposite this issue by subtasks.

Executable of Russian location for Hitman Blood Money looks reversible.
I need to check that. If it's not supported need to make the task for the support it in ReHitman.

Introduction

We have a debug menu with some information about the current session, but we have not any information about systems and players (except their addresses, but this we can see in debug terminal 😸 ).

Player region

• Show player position and edit box
• Show player health amount
• Move noise level into the player region (also add progress bar if it available)
• Show camera position (X,Y,Z, angle and zoom) and add edit boxes for it
• Show current weapon information (weapon id, name, ammo amount)

Systems region

• Show system members addresses and values (if it possible)
• Add controls for systems (add "complete task" button with a combo box for the select target as an example)

If somebody wants to help me with it - write a comment and we will discuss it.

If you have any problems with ZIP Free File System create issues for it and link it to this issue.

Documentation: ZIP Free File System

For now all dependencies placed in project as raw sources.
It's bad idea, better to use git submodules for it.

We should continue our reverse process for ZHM3Actor.

Method kill was reversed in #27.

I guess we should reverse other state-changers methods. Also, we should check the 'pathfinder' controller and 'M13PosController`.

And the last thing: we should look for ZHM3Movement things.

We need to create a class for the ZGui structure to communicating with UI objects.

Documentation: ZGUI-Structure

I wanted to compile this to test it out but you haven't included the x86 directory for HM3CoreKill, just thought I would let you know.

Not really high priority but I figured an issue for it wouldn't hurt.

We need to implement free resource loading, not from ZIP archives.

This is top task for missions reverse engineering

I guess we should start from M13 (Requiem) because it's the easiest mission in-game (except HideOut).

What we should reverse:

• Communication between Game & DLL
• DLL segments (SF, ISF, Scripts and ScriptImports)
• Game API for providing interfaces (most of that functions not explained by disassembler and we should do that manually 😞 )
• Create complete examples & docs of usage

Good practice to use the gamepad as an external tool for easy debug.
We can use xinput2 API for the support this.

It's very difficult to use the debug menu when keyboard & mouse input enabled.
Too many conflicts in work.
As a solution, we can hook the update method on the keyboard and stop mouse events emitting when the in-game debugger opened.

Since I can't be bothered to compile things with Visual Studio,
This issue is focusing on setting up & using AppVeyor for this project.

Requirements

• Log into a AppVeyor Account associated with the Project.
• Sign up with the associated github account via OAuth
• Authorize GitHub or BitBucket to list this repo.
• Setup the AppVeyor Project for this Project.
  • Outlined: #17 (comment)
• Start the Build Process

Benefits

• Users who don't have access to a compiler can test and use the latest project master, or PR's.
• We don't have to supply binaries to users.
• Widened test Audience.

Blockers for this Issue

• Current Visual Studio Project Output
• We need to change this from Z: etc etc etc, to something current directory.
• Will submit PR for.

Potential Future Issue for Review

• Review where we are currently exporting the projects binaries too:
• PR Artifacts & Continuous Build Delivery

That debug interface is useless for us.
Also namespace 'glacier' not acceptable for us (we are using ioi::hm3 for Hitman things and ck:: for CoreKill things).

When HM3_DEBUG_ENABLED launcher option disabled CoreKill.dll can fail the initialization of some internal components. It's a very bad case because all the hooks are very important for us.
"Sleep mode" could be applied as a temporary solution but "true-way" is wait for internal hooks works and free main CoreKill thread only after all internal components are ready to work.

We have an opportunity to lock/unlock doors via event bus but it's not enough for us.

What's required:

• CDoor::open
• CDoor::close
• CDoor::getOpeningProgress() - (in float degreese or other value cathegory)

Introduction

So, in PR #25 we have an issue about loading custom animations. It's prohibited by a level resource management system. For now, we know that all animations, available on the level, declared in ANM file. This file located in ZIP archive. So, it's can be a better opportunity to fix issue #22. If it will be possible we should research ANM format for future in-code usage.

Tasks

• Research how level loading works (find all requests to resources)
• Fix issue #22
• (optional) Research how ANM format works if it is possible add external animations sources for future SDK works.

Howdy :)

I think I should be able to do a few pull requests and commit to this project, do you happen to have any social media or contact details? I'd really like to help with this project since it's a HUGE dream of mine.

Discord / Slack / Email?

We have bad timings in gameplay when we are using hooked input. This brokes the M13 mission. Need to fix that.

ZKeyboardInput component could be used for that.

It's no secret that Blood Money suffers issues with it's GUI.
Scaling GUI elements is broken when the aspect ratio is beyond 4:3 or the resolution is increased beyond 720p.

Following Screenshots are in 3840x2160, highlighting these issues

2D GUI

• Thing do not scale with resolution increase and stay at a set scale

3D GUI

• Things are scaled via a hard-coded value, which increases "zoom" when resolution increases.

We need to look at a replacement for GUI, or a patch for incorrectly scaling GUI.

As experimental debug feature we could add wireframe rendering option in debug menu.
It could be enabled by this code
g_d3d_device->SetRenderState(D3DRS_FILLMODE,D3DFILL_WIREFRAME);
And disabled by this code
g_d3d_device->SetRenderState(D3DRS_FILLMODE,D3DFILL_SOLID);

Reference https://www.drunkenhyena.com/cgi-bin/view_cpp_article.pl?chapter=2;article=22

Also we must think about how to apply this mode for specific model (instance). Glacier presents this feature (they are using instancing concept) and the idea could be implemented through vftable proxy hook (find method "draw" and insert logic in it).

As perfect solution we can implement ray tracing from player camera by the angle to find object to draw in wireframe mode but it's impossible (looks like a challenge).

Tasks

• Reverse ZSTDOBJ
• Reverse ZGEOM
• Reverse ZLIST
• Reverse ZREGTAB

Implement API for ZLIST

• Implement ZLIST factory (like ZLISTFactory<T>::create(size_t count))
• Implement ZLIST::add
• Implement ZLIST::remove
• Implement ZLIST::at
• Implement ZLIST::next
• Implement ZLIST::prev
• Implement ZLIST::size

ZLIST API could be used through wrapper or similar data structure. I guess we shouldn't simulate original API. Main goal of this is get easier access to Glacier's members without any __asm blocks in logic code.

Implement API for ZSysMem allocator

• Implement ZSysMem::allocate<T>()
• Implement ZSysMem::deallocate(void* pMem) or ZSysMem::deallocate<T>(T* ptr)

Introduction

That interface is very buggy, also some functions, like Give all, Beam works awful.
In PR #5 we are working under custom debug menu and these functions could be implemented there.

Subtasks:

• Disable ZCheatMenu & Shift+C shortcut
• Reverse player inventory
• Implement method "give item"
• Implement method "give available items list"
• Fix bug with model loading (if we starts the game from custom scene part of models will not be loaded)
• Implement hooks on ZOSD class for full anxiety control on level
• Reverse animation system for custom animations viewer
• Implement teleport for player
• Implement assets preview
• Implement load level not from ZIP package