Possible to run 3Dmigoto in Elite Dangerous with OpenXR Toolkit?

[Houndmux]

When I try to run 3Dmigoto with OpenXR Toolkit in Elite Dangerous, I get the error message:

The procedure entry point D3D11On12CreateDevice could not be located in the dynamic link library C:\Program Files\OpenXR-Toolkit\XR_APILAYER_MBUCCHIA_toolkit.dll

and then:

OpenXR Call failed, aborting. C:\projects\openovr\DrvOpenXR\DrvOpenXR.cpp:201 CreateOpenXRBackend. Error code: -32 xrCreateInstance(&creatInfo, &xr_instance)

(note: I don't have a C:\projects folder)

Is there a way to fix this?

[DarkStarSword]

D3D11On12CreateDevice

This indicates that DirectX 12 is in use with a DX11 compatibility layer (11on12) enabled, but 3DMigoto is a DirectX 11 modding tool only, so even with the compatibility layer this isn't a situation that we would necessarily expect to work.

That said, 3DMigoto does work fine with Elite Dangerous (Cockpit Paint Mod and Elite Dangerous Hud Mod both use 3DMigoto, as do several other ED mods, and it is known to work in Steam VR and Oculus VR as well), as it is natively a DX11 title, so I presume the use of DX12 must be coming from OpenXR or some other injected tool which is having some sort of compatibility issue with 3DMigoto.

(note: I don't have a C:\projects folder)

That path is on the developer's computer who compiled OpenXR, not your PC.

Can you please provide more info about your setup, particularly which VR headset you are using, and which OpenXR runtime you are using (if using SteamVR open settings -> enable advanced settings -> Developer -> Current OpenXR Runtime. If using something else google how to find this)?

[DarkStarSword]

This is a bit of a stab in the dark, but you might be able to kludge it into working by forcing 3DMigoto to use hooking rather than wrapping:

• To get around the lack of D3D11On12CreateDevice in 3DMigoto's dll, move 3DMigoto to a different folder from the game and use the external loader (found in the 3Dmigoto-1.3.16.zip file in the loader directory) to inject 3DMigoto into the game. You need to configure the [Loader] section in the d3dx.ini for this to work (it will tell you this if you run it without configuring it). First try with 3DMigoto named d3d11.dll, and if that doesn't work try it named 3dmigoto.dll.

• If 3DMigoto is unable to wrap the D3D11Device and/or D3D11DeviceContext (because they are a D3D11on12Device[Context], not a D3D11Device[Context]), try setting it to hook them instead - edit the d3dx.ini file and find and uncomment the line hook=recommended.

I would try the first suggestion by itself, then if that doesn't work try them both together. Note that all this kludge all hinges on something calling D3D11CreateDevice[AndSwapChain] at some point - if that never happens when 11on12 is in use this may not work.

[Houndmux]

Thanks, option 1 worked! (Pimax 8KX with PimaxXR runtime)

[bo3b]

I"m reopening this bug because a recent version of Unity 2023 has the same problem.

In the game Planet Crafter, 3Dmigoto will block launch because we don't export the D3D11On12CreateDevice call. I can also load 3Dmigoto using the hooking approach.

However, this seems like an oversight for us, and does not match our goal of having a seemless drop in d3d11.dll loader. Times have changed, and Microsoft is exporting more functions in the .def. We should go ahead and update to include all current APIs that are exported with call-throughs for stuff we don't know about, or don't care about.

I'm not quite sure how this should connect to the current D3D11On12CreateDevice handling.

Another open question is that if we crack open this part, we probably should consider adding dxgi exports as well, and use the Reshade approach of exporting everything so that people can simply rename the dll to get different load techniques.