RE-UE4SS
RE-UE4SS copied to clipboard
UE4SS-RE
Adds KismetDebugger as a C++ mod
Description
It's built alongside all our other targets.
This is based on #296 which has been stuck waiting to be merged for 5 months. I didn't update that particular PR because it's very old and I didn't want to stomp on it just in case. The only alterations I've done is replace all the cmake files with xmake files, and clarify the "GNatives not found" warning. I haven't added KismetDebugger to the packaging step of build.py, and this is just in case that was the problem with the old PR. I just want it to be built for now, so that devs can have easy access to a working version. We can package it for public release whenever those details have been figured out.
Including KismetDebugger with UE4SS will do two things:
- Ensure that we catch breaking changes to the core C++ modding environment immediately because it'll always be built alongside UE4SS.
- Keep KismetDebugger constantly up-to-date for anyone that wants to use it.
It's a very useful tool and well worth including with UE4SS by default. I don't know why the old PR was never merged, but I really want this to be merged so please let me know if there's some kind of problem so that it can get solved and this can get merged.
Worth mentioning is that the byte-code disassembly part of KismetDebugger still works even if the AOB scan for GNatives fails, and it's very useful even without the functionality that GNatives enables (breakpoints). The scan for GNatives only happens when the user hits the "enable" button in the KismetDebugger tab, so it won't slow down the init of UE4SS.
Type of change
Please delete options that are not relevant.
- [x] New feature (non-breaking change which adds functionality)
How Has This Been Tested?
I built UE4SS like normal, then checked the Binaries/KismetDebugger directory for KismetDebugger.dll, then copied it to my game as a C++ mod and checked that it worked.
Checklist
Additional context
Supersedes #296
I installed the UE4SS.dll and KismetDebugger.dll but when clicking on the kismet debugger tab in the GUI it crashes - game is DRG
Your dump isn't sufficient. Building the shipping target locally, neither UE4SS.pdb nor KismetDebugger.pdb is compatible with your crash. I've assumed you've built the shipping target based on the sizes of the dll files.
I've also so far been unable to reproduce the crash myself.
Does the crash happen consistently for you ? The location of the crash suggests that this might be something unrelated to KismetDebugger because it's just an ImGui function that's failing and it's not a Begin/End mismatch error.
I simply switched RE-UE4SS to this branch, ran xmake project -k vsxmake2022 -y to regenerate vs solution with kismet debugger mod, built ue4ss with game__shipping__win64, copied ue4ss.dll/.pdb and kismetdebugger.dll/.pdb into right places with right names.
Yes crash happens consistently, multiple times in a row
I simply switched RE-UE4SS to this branch, ran
xmake project -k vsxmake2022 -yto regenerate vs solution with kismet debugger mod, built ue4ss with game__shipping__win64, copied ue4ss.dll/.pdb and kismetdebugger.dll/.pdb into right places with right names.Yes crash happens consistently, multiple times in a row
Can you provide your PDB files so that I can debug your dump ?
I don't know if I can identify this problem.
Your dump based on the shipping build probably won't be useful.
I'll need a dump with full memory (ini option) from a debug build, and even then, all that will allow me to do is inspect what's going on in ImGui::GetContextRegionMax() as as well as confirm that the memory around the crashing code looks good.
https://drive.google.com/file/d/1hrLDqaqXhNQG7SnA-oNWK2SIeIgo-sKE/view?usp=sharing
It would appear that GImGui is nullptr.
This is an internal imgui variable that keeps track of imgui state.
By default, this is the expected behavior of mods that use imgui.
To allow mods to interact with our UI (via making tabs), we introduced the UE4SS_ENABLE_IMGUI macro which passes the context from UE4SS to the mod by calling ImGui::SetCurrentContext(), and that's supposed to fix this problem.
The KismetDebugger mod does use this macro properly as far as I can tell so I'm not sure why GImGui is nullptr.
According to your dump, the GImGui pointer for UE4SS is non-nullptr so we know that's not what the problem is, not to mention the UI doesn't immediately crash.
I need to think about this a bit more.
I might have found the problem. Can you test this and see if the problem goes away ? KismetDebugger.zip
Seems to work fine
This is definitely unrelated to KismetDebugger then. I will open another PR for this soon, and the fix won't affect the code in this PR so it doesn't need to be held up because of this.
The fix to that crash turned out to be a bit more involved and will likely require this mod to be changed. I'd like to include those changes before this PR is merged so hold of on merging for now. See: https://github.com/UE4SS-RE/RE-UE4SS/pull/481#issuecomment-2068937234
The other PR was pending it being moved to use glaze for json
Considering how long it's been just sitting there, can we get this merged and deal with glaze after ?
The main reason I wanted it done first is because it will be used as an example, so I'd prefer the example not be using something that may get removed. But whatever works easiest.
The main reason I wanted it done first is because it will be used as an example, so I'd prefer the example not be using something that may get removed. But whatever works easiest.
It doesn't have to be made an example of immediately, it can just quietly sit in the repo. We can just merge it and when we eventually change to glaze, we start using it as an example.
It's going to be used as one just by nature of being a c++ mod in the repo. I haven't looked at it in so long I don't recall where all it uses json. The glz swap theoretically should be easy
It's going to be used as one just by nature of being a c++ mod in the repo. I haven't looked at it in so long I don't recall where all it uses json. The glz swap theoretically should be easy
I can look into changing KismetDebugger to glaze after #481 has been merged.
I don't think the format of the existing JSON file is good when using glaze's json-to-cpp-struct functionality. It's an object containing several arrays but the names of these arrays are function names which means they are dynamic and glaze expects static names.
We might need to use a lower level glaze API if we want to keep this format.
The file looks like this:
{
"Function /Game/SomeClass:SomeFunction": [
32,
40
],
"Function /Game/SomeClass:SomeFunction2": [
]
}
What I'm trying to say here is that without changing the current format, we'll probably have to use raw untyped glz::json_t instead of a properly typed API.
This isn't recommended, and as such is not fit to be used if other people are expected to use this code as an example.
Can we change the format to use nested arrays rather than arrays named after the functions?
Can we change the format to use nested arrays rather than arrays named after the functions?
Probably but I think the breakpoints system has to be changed for us to do this. This is really out of the scope of this PR, it's not a super trivial task for someone that doesn't fully know the system.
We use JSON in multiple places in UE4SS so we already have "examples" with the old system that people might use so maybe adding KismetDebugger with the old system won't cause too much damage ?
Closed to preserve original commit authorship of the mod in original PR. That PR is ready for review.