Conversation
…stants and addresses
…her dll builds or exe builds
| # We could reinstate this later: | ||
| ## set(OPEN_SHC_DLL_DEST "${CRUSADER_DIR}/ucp/modules/${OPEN_SHC_NAME}-${OPEN_SHC_VERSION}" CACHE PATH "Path for OpenSHC.dll and OpenSHC.pdb") | ||
| # For now it is easier to put it in a dll subfolder | ||
| set(OPEN_SHC_DLL_DEST "${CMAKE_BINARY_DIR}/dll" CACHE PATH "Path for OpenSHC.dll and OpenSHC.pdb") |
There was a problem hiding this comment.
What is the issue that is solved here? Does reccmp not follow Symlinks?
I would contest that a bit, since it breaks the "debugging with game" flow.
The main reason for the DLL is the partial replacement and being able to run the game with it.
The flow "reimplement and check reimplementation state" could be done exe only.
There was a problem hiding this comment.
There is no big issue. What it solved was that I couldn't find the dll file, as the path to the _original/ucp/modules/OpenSHC-1.41.0 folder makes the location of the dll file in an unexpected place for reccmp. I can also adapt reccmp of course. It is kind of the question of what should work "out of the box" and what is an advanced usage users need to configure. I had the thought that the reccmp flow on the dll should work out of the box (as building the exe doesn't work without all reimplementations for known functions). But I can see clearly the argument for "debugging with game" flow to be optimal.
What about adding a cmake statement to also copy the dll and pdb to the build-RelWithDebInfo/dll/ subdirectory that reccmp expects? Then the "debugging with game" is default but the other situation also works.
README.md
Outdated
|
|
||
| 2. Create a softlink to the original game executable with the name `_original` by running [softlink.bat](softlink.bat). It will request the full path to the game folder. | ||
| 3. Setup the needed Python environment to run `reccmp` for binary comparison by running [setup.bat](reccmp/setup.bat) in the reccmp folder. | ||
| 3. Setup the needed Python environment to run `reccmp` for binary comparison by running [setup.bat](reccmp/dll/setup.bat) in the reccmp folder. |
There was a problem hiding this comment.
The fact that a version for the exe also exists could be mentioned here.
There was a problem hiding this comment.
- Setup the needed Python environment to run
reccmpfor binary comparison by running setup.bat in the reccmp/dll folder (or thesetup.batin the reccmp/exe folder if binary comparison on the reimplemented .exe file is preferred)
There was a problem hiding this comment.
Is this the hash of the game in the file name and every enum?
Also, I remember the discussion from here: #10
Did you conclude that a difference in naming between struct and func would not be helpful?
There was a problem hiding this comment.
Yes, it is the file version independent way of getting a source of truth. Currently the steam exe is the source of truth, so this hash is in the enum. Future versions we support (if we ever go there, currently we decided against it), get their own file with their hash in the file name. The enum will consist of mostly the same enum names as the steam exe, but of course different enum values as addresess are different.
Regarding data versus code, the first .data section of the .exe starts at 0x59e000, so anything lower is func, and everything higher is struct. The usage context of the enum names is obvious enough to know the distinction, so I think it is fine without F and D
There was a problem hiding this comment.
Comment regarding the exe-reccmp files:
Are these just copies from their DLL using versions, mostly unchanged?
There was a problem hiding this comment.
Yes is the same files as in the dll/ subfolder
| #define static_assert_cpp98(condition) typedef int _static_assert_cpp98_obj[(condition) ? 1 : -1]; | ||
| #define static_assert_cpp98_obj(condition, obj) typedef int _static_assert_cpp98##_##obj[(condition) ? 1 : -1]; |
There was a problem hiding this comment.
Does this properly complain in case of issues? Do you have a (shortened) example for the compiler error?
There was a problem hiding this comment.
Yes, the error will be error C2118: negative subscript with a stack trace pointing to the location of the static_assert_cpp98_obj statement that caused the issue.
There was a problem hiding this comment.
Did you manage to make it fully compatible with the full Windows.h? (see #14)
There was a problem hiding this comment.
I haven't run into that issue yet, but we can do the solution I suggested just now on that issue page.
There was a problem hiding this comment.
What is this enum for?
Are these really completely general, or should they rather be part of or be themselves a normal game enum?
I also feel the precomp is not be good place, since unlike the addresses or the Ghidra data types, these are not really "unchangeable" meta structures.
There was a problem hiding this comment.
Why are they not "unchangeable"? Because we could expand the list in the future triggering a rebuild of all files? Or because we need to change it when we go 800x800 on maps?
I considered this file for constant integer values that are systematically used across the code but never used as an enum (e.g. in a switch-case statement). Constants we deduce from what they must have used as a macro or constant at some point in the source code but which has been completely inlined. What could be added is the amount of preallocated space for the unit array, etcetera.
| tmp/ | ||
| /*.7z | ||
| /*.sarif | ||
| /*.bin | ||
| /reccmp/**/*.json |
There was a problem hiding this comment.
For what are these? (Maybe we need to comment the project specific more anyway.)
.gitignore
Outdated
| /reccmp/**/*.json | ||
|
|
||
| # Users should use git add --force for these: | ||
| /cmake/openshc-sources.txt |
There was a problem hiding this comment.
I would prefer if we can create a flow that does not involve such git tricks.
What is the issue and intention behind this?
There was a problem hiding this comment.
It is laziness. I usually do git add . and commit. However, the cmake/openshc-sources.txt that is upstream should reflect the required state for the latest buildable binary. Locally, it can have fewer, or additional lines, depending on what is being worked on (to reduce rebuild times). Auto adding the local developing state of that file when doing git add . would be annoying.
I can remove this feature on the upstream .gitignore and only use this trick locally. Fine by me!
| Tuple of (success, diff, stdout, stderr) | ||
| """ | ||
| cmd = [str(Path("reccmp") / "run.bat"), "reccmp-reccmp", "--target", "STRONGHOLDCRUSADER", "--json", "diff.json"] | ||
| cmd = [str(Path("reccmp") / "dll" / "run.bat"), "reccmp-reccmp", "--target", "STRONGHOLDCRUSADER", "--json", "diff.json"] |
There was a problem hiding this comment.
Could the MCP be actually changed to also receive if it should work with the "exe" or the "dll"?
Although I assume the "exe"-Version can not build unless every known function is implemented, so maybe this would not be helpful.
There was a problem hiding this comment.
Indeed, as the exe can not build unless every known function is implemented, the mcp server only uses the dll. This does mean the mcp server doesn't have access to some optimizations that only apply to exe files, but I find that acceptable (unless it becomes a problem in the future).
undefined3in ghidra typedefs