Glover (original PC port, not Steam): Xidi thinks XInput controller is not XInput

Question

Glover (original PC port, not Steam): Xidi thinks XInput controller is not XInput

Closed this issue 20 days ago · 7 comments

instinctualjealousy commented a year ago

[10/15/2023 13:35:04] [D] Attempting to import DirectInput functions from C:\WINDOWS\system32\dinput.dll.
[10/15/2023 13:35:04] [I] Successfully initialized imported DirectInput functions.
[10/15/2023 13:35:04] [I] Successfully created a DirectInput interface object.
[10/15/2023 13:35:04] [I] Binding to non-XInput device "Controller (XBOX 360 For Windows)". Xidi will not handle communication with it.

This is very, very strange. XInputPlus successfully intercepts this game's calls- but something about Xidi's XInput check is being fooled by Glover, making it think an XInput controller is not one and treating it as a DirectInput pad (no interception). This isn't high importance to me, but it might be an interesting implementation issue that could potentially affect other games.

Curiously, the config utility hooks correctly and respects my remaps:
Xidi_DInput_config.exe_7816.log

Answer 1 · 2023-10-15T23:39:03.000Z

Are you using any other patch or mod that intercepts DirectInput that only applies to the main game and not the configuration file?

Also, could you please provide the full log for the main game? I'm wondering if there is some additional context that might help.

Answer 2 · 2023-10-20T16:47:47.000Z

I'm not using any other wrappers that should be interfacing with DirectInput- I did try dxwrapper's dinputto8/dinput8 Xidi just to see if behavior was different, it wasn't. I think the log result was even the same- of course, I'm not reporting this based on the results of that, but on the direct usage of Xidi dinput.dll.

I have modified Glover with a redirect manifest:

"<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
  version="6.0.0.0"
  processorArchitecture="x86"
  name="redirector"
  type="win32"
/>
<description>DLL Redirection</description>
<dependency>
  <dependentAssembly>
    <assemblyIdentity
      type="win32"
      name="Microsoft.Windows.Common-Controls"
      version="6.0.0.0"
      processorArchitecture="X86"
      publicKeyToken="6595b64144ccf1df"
      language="*"
    />
  </dependentAssembly>
</dependency>
<file
      name="dinput.dll"
/>
</assembly>

...as by default the game insists on loading dinput.dll from its system location (something Hookshot also solves). Xidi is hooking and logging, so I have little reason to doubt this method is causing the issue. I did try Hookshot a week ago, with no better result. As for concurrent wrappers- dgVoodoo and ogg-winmm. I got rid of ogg-winmm as it's possible being an older dinput7-and-under game, that it's doing some weird winmm.dll stuff. That said, XInputPlus being able to modify button mapping and deadzone in-game without issue through the same entrypoint and game configuration leads me to think otherwise.

Glover does do some relatively verbose logging for a commercial title without arguments, but I don't think it'll be that much help:
glover.log

I guess the bigger question is: How does Xidi actually determine if a controller is XInput-capable, and how would a game's handling of DirectInput (or a user's misconfiguration) lead it to think it isn't capable?

Answer 3 · 2023-12-01T19:13:23.000Z

Just to clarify, what I was hoping to see is a Xidi log from Glover itself, rather than from the configuration utility. The log would show which devices Xidi sees and also produces output about how they are enumerated to the game,

The way Xidi determines if a DirectInput device supports XInput is to use the device ID string and check for a special identifier that identifies it as an XInput device. The implementation itself is located here. If there are any problems getting that property, or if the "IG_" string is missing, then Xidi assumes that the controller does not support XInput.

Answer 4 · 2023-12-01T20:41:03.000Z

Actually, could you please capture Xidi logs from both the configuration utility and the game itself using this development build? I augmented the log messages related to identifying devices being enumerated, including how Xidi detects if they support XInput or not.

Xidi-v4.2.1-dev.15.0+7c1632be.zip

Answer 5 · 2024-04-29T18:23:08.000Z

Xidi_DInput_config.exe_16612.log
Xidi_DInput_glover.exe_4100.log
Here you go, against your test build. Sorry for getting back so late.

Answer 6 · 2024-12-13T20:42:46.000Z

What I can see in the logs:

The config utility looks like it's working correctly. It queries the system and asks it to enumerate DirectInput devices, then binds to a virtual controller.
The game does not enumerate and directly requests the GUID of the Xbox controller, bypassing Xidi. My guess is the game looks in a config file for the configured controller GUID and just asks for it directly.
The log message Xidi produces is misleading. When it says that the device doesn't support XInput, it actually didn't check. The game asks for the GUID of the XBox controller, Xidi says "not a virtual controller GUID" and assumes it doesn't support XInput. If the game actually did do an enumeration, it wouldn't see the XBox controller at all, just the virtual controllers.

I added a test to catch this. Because Xidi is supposed to hide all XInput controllers, the correct behavior is to reject the application's request to bind to the XBox controller directly and bypass Xidi.

Please run the configuration utility, make sure it works with the Xidi virtual controller, then make sure it saves the controller configuration (change a few settings and then change them back, if needed), and then try launching the game again. Xidi has its own virtual controller GUIDs that it uses, so if you do that, then the configuration file should tell the game to ask for one of those instead of the Xbox controller's GUID. You can also try this development build; at very least, you should see in the log file that Xidi knows the XBox controller supports XInput and is preventing the game from binding directly to it.

EDIT: There's a bug in the development build, so I removed the link from this comment.

Answer 7 · 2024-12-23T02:10:02.000Z

Xidi_DInput_glover.exe_11960.log

Decided to have another look at this:
[12/22/2024 19:52:51] [I] Attempting to bind directly to XInput device "Controller (Xbox One For Windows)" with instance GUID {de715520-0260-11ef-8001-444553540000}. Xidi hides XInput devices and therefore is rejecting this request.

Your cloaking is working as expected. However, the game is not actually taking on Xidi's virtual controller still, so now the controller 100% doesn't work due to the combination of direct-access blocking and the virtual controller not being used. I re-ran the config utility, remapped a single button and hit save. It didn't change anything; it did rewrite the file.

This is the configuration file (renamed from *.cfg) if you're curious. I found no other notable files or registry entries.
Glover.txt (it's binary)

I went ahead and got the newer version off Steam considering this game is kind of jank and I don't feel like working on my all-in-one fix for it anymore. Still, I can keep it installed to see if we can figure out what the heck's going on.