New UE4SS working directory location

[Buckminsterfullerene02]

Description

As according to the discussions in #476. Install location of all files will be in /ue4ss except proxy. Legacy locations all supported, but if files are in new locations, those take priority.

Proxy tries to load UE4SS.dll from new location, but the location of the UE4SS.dll (and thus the root directory) can be overriden by placing a file called override.txt next to the proxy and can contain either an absolute or relative path to the UE4SS.dll. Still supports legacy UE4SS.dll location.

Also changes the build script as all files need to be zipped inside of a ue4ss/ folder that will still be unzipped inside of the game exe directory due to the proxy also being there.

Type of change

• New feature (non-breaking change which adds functionality)
• Requires documentation update

How Has This Been Tested?

Tested files in legacy, new, and overriden file locations, seperately and in a mix of two or three at once.

Checklist

• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation.
• I have added the necessary description of this PR to the changelog, and I have followed the same format as other entries.
• Fix issue with console/dll not initialising game correctly
• Fix release assets not going into the right places

[Buckminsterfullerene02]

If running the game directly from the shipping exe, there is an issue where DRG doesn't load properly as shown:

If running the game from steam, it doesn't load up at all.

I'm sure both of these issues are related to the proxy dll, but I wouldn't even know where to begin with debugging as there is nothing obvious when breakingpoint debugging the proxy code.

[UE4SS]

If running the game directly from the shipping exe, there is an issue where DRG doesn't load properly as shown:

If running the game from steam, it doesn't load up at all.

I'm sure both of these issues are related to the proxy dll, but I wouldn't even know where to begin with debugging as there is nothing obvious when breakingpoint debugging the proxy code.

As far as Steam not working, that's because you're using std::filesystem::current_path() which gives you the working directory.
Steam actually uses the location of the non-shipping exe as the working directory.
I've implemented the solution to this by using GetModuleFileNameW instead.

As far as DRG not loading properly when using the shipping exe, what do you mean ?
I don't see anything odd other than the regular Windows console not rendering properly for whatever reason.
I was unable to reproduce that problem.

[UE4SS]

I'm sure both of these issues are related to the proxy dll, but I wouldn't even know where to begin with debugging as there is nothing obvious when breakingpoint debugging the proxy code.

To debug the proxy, open Intermediates/.gens/proxy_files/windows/x64/Game__Debug__Win64/dllmain.cpp in your IDE, put a breakpoint, and then set your IDE up to launch the game and attach when you hit the debug button, and then your breakpoint should be hit immediately.
Replace Game__Debug__Win64 in the path with whatever target you built.
I figured this problem out by putting a breakpoint in that file in the load_ue4ss_dll function and inspecting the value of ue4ssPath.

[UE4SS]

Packaging is failing: https://github.com/UE4SS-RE/RE-UE4SS/actions/runs/9106272884/job/25033211418

[Buckminsterfullerene02]

I'm sure both of these issues are related to the proxy dll, but I wouldn't even know where to begin with debugging as there is nothing obvious when breakingpoint debugging the proxy code.

To debug the proxy, open Intermediates/.gens/proxy_files/windows/x64/Game__Debug__Win64/dllmain.cpp in your IDE, put a breakpoint, and then set your IDE up to launch the game and attach when you hit the debug button, and then your breakpoint should be hit immediately. Replace Game__Debug__Win64 in the path with whatever target you built. I figured this problem out by putting a breakpoint in that file in the load_ue4ss_dll function and inspecting the value of ue4ssPath.

That's what I was doing, I just didn't see anything wrong, so I thought it was some weird thing I didn't understand.

[Buckminsterfullerene02]

If running the game directly from the shipping exe, there is an issue where DRG doesn't load properly as shown:
If running the game from steam, it doesn't load up at all.
I'm sure both of these issues are related to the proxy dll, but I wouldn't even know where to begin with debugging as there is nothing obvious when breakingpoint debugging the proxy code.

As far as Steam not working, that's because you're using std::filesystem::current_path() which gives you the working directory. Steam actually uses the location of the non-shipping exe as the working directory. I've implemented the solution to this by using GetModuleFileNameW instead.

As far as DRG not loading properly when using the shipping exe, what do you mean ? I don't see anything odd other than the regular Windows console not rendering properly for whatever reason. I was unable to reproduce that problem.

Your fix works, thanks.

For debugging my exe path is the shipping exe. When it loads, it:

1. Loads steamVR for some reason, despite DRG not using it
2. Gets this error: ←[0mFSDLog_Gameflow: Error: UFSDGameInstance:: Init - Steam not initialized!
3. Ends up on that screen about steam not initialising correctly

Actually, without ue4ss installed, the exact same thing happens when loading directly from shipping exe. So steam must be initialised from the bootstrapper one. But if I load from the bootstrapper one by debugger isn't attached to the right process...

[narknon]

There shouldn't be a message box when ue4ss loads should there? That's just kinda annoying if you have to close out of it

[UE4SS]

There shouldn't be a message box when ue4ss loads should there? That's just kinda annoying if you have to close out of it

It's only if it fails to load.
Otherwise the game just immediately shuts down without an error, which means the user has no idea what happened.

[narknon]

"I put in two; one for when proxy fails to load for whatever reason, and one for when UE4SS.dll loads."

[UE4SS]

"I put in two; one for when proxy fails to load for whatever reason, and one for when UE4SS.dll loads."

That's a typo, they meant if UE4SS.dll fails to load.

[narknon]

The second half of the sentence

[UE4SS]

The second half of the sentence

Yes, and one for when UE4SS.dll loads is a typo.
I literally checked the code as well.

[Buckminsterfullerene02]

Just realised deleting API.txt broke build script. Will get on that shortly.

[Buckminsterfullerene02]

Releases build as expected now.

[UE4SS]

Does this PR also affect the location of imgui.ini ? Not sure if the creation of that file is based on the location of UE4SS.dll or the exe.

[Buckminsterfullerene02]

Does this PR also affect the location of imgui.ini ? Not sure if the creation of that file is based on the location of UE4SS.dll or the exe.

Forgot about that. It seems to still be put into the exe dir. Should it be kept that way?

[UE4SS]

Does this PR also affect the location of imgui.ini ? Not sure if the creation of that file is based on the location of UE4SS.dll or the exe.

Forgot about that. It seems to still be put into the exe dir. Should it be kept that way?

If possible, it should go in the ue4ss directory, but I don't know if imgui provides a way to do that and I don't think we should bend over backwards to get that to work.

[UE4SS]

Revert moving imgui.ini location
Don't ask me why, I have literally no idea.

What ? Was there something that didn't work properly ?

[UE4SS]

The object dumper directory doesn't use the new path:

[15:19:47] mods directory: Y:\test_games\5.4\UE4SS_Main54\Windows\UE4SS_Main54\Binaries\Win64\ue4ss\Mods
[15:19:47] log directory: Y:\test_games\5.4\UE4SS_Main54\Windows\UE4SS_Main54\Binaries\Win64\ue4ss
[15:19:47] object dumper directory: Y:\test_games\5.4\UE4SS_Main54\Windows\UE4SS_Main54\Binaries\Win64

[UE4SS]

Looks good to me.
Tested and it's working.