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

[instinctualjealousy]

[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

[samuelgr]

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.

[instinctualjealousy]

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?

[samuelgr]

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.

[samuelgr]

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

[instinctualjealousy]

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.