Controller sort order

[russdirks]

The controller order issue has still not really been solved. Advanced users and cockpit builders sometimes have many controllers, some of which might have the same name. That means the new SimConnect_RequestJoystickDeviceInfo function you added in v3.2 is of no use, since it only returns the "friendly name" of each controller.

One possible work-around would be if we enumerate controllers using DirectX, and then re-sort in the same order that P3D sorts. In some other thread it was mentioned that P3D sorts by "vendor", then "product". Could you provide more details, even code snippets, as to what exact piece of information you are obtaining about these two items, and how you obtain them? Otherwise we would have no confidence that our sorting would yield the same results as P3D. Unfortunately, when enumerating devices with DirectX, no information is available about vendor, at least not that I know of.

[russdirks]

DirectX only provides the following information, via the DIDEVICEINSTANCE structure:

Code: Select all

typedef struct DIDEVICEINSTANCE {
    DWORD dwSize;
    GUID guidInstance;
    GUID guidProduct;
    DWORD dwDevType;
    TCHAR tszInstanceName[MAX_PATH];
    TCHAR tszProductName[MAX_PATH];
    GUID guidFFDriver;
    WORD wUsagePage;
    WORD wUsage;
} DIDEVICEINSTANCE, *LPDIDEVICEINSTANCE;

As you can see, there is no vendor information provided.

[russdirks]

If P3D is only using vender and product information to sort, would that not yield ambiguous results if someone has two similar controller plugged in?

[Clifton Crane]

Hi Russel,

This article provides an example that shows extracting the VID and PID information from a DirectInput device's product guid:

https://msdn.microsoft.com/en-us/librar ... 17014.aspx

In Prepar3D, the devices are sorted in increasing order first by VID and then by PID. Any devices with same VID and PID will then be added in the order they are enumerated.

[adiemus]

Sorry to butt in here, but we're facing a similar issue. SimConnect_RequestJoystickDeviceInfo is helpful, but is only a half-solution, as it doesn't provide enough info to reliably disambiguate between two identical controllers.

Is there any way an analog for DIDEVICEINSTANCE's guidInstance member could be exposed or synthesized by P3D? Under DirectInput, that was a reliable way to address a specific controller, even if multiple identical controllers were connected. A similar instance GUID returned by a future SimConnect_RequestJoystickDeviceInfoEx would resolve the issue of controller disambiguation.

(My understanding is that P3D v3 switched from DirectInput to RawInput [rather than XInput]. If so, could an instance GUID perhaps be synthesized from the instance section if the RIDI_DEVICENAME value string? Or even just expose the raw string itself via a SimConnect call so that third-party devs can then match the instance-specific value. Though, I'm not sure if that would follow a controller around even when plugged into a different port, the way a DirectInput guidInstance does)

[russdirks]

Thanks Clifton, that looks like it will be helpful.

Any devices with same VID and PID will then be added in the order they are enumerated.

I just want to clarify how you are enumerating devices, since the example code you referenced looked like it was enumerating via DirectInput. Are you enumerating via DirectInput, RawInput, XInput, or some other method?

[Clifton Crane]

Russel,

It is the RawInput enumeration.

adiemus,

You are correct, the device instance path is unique for each device but does not persist between plugging and unplugging devices into different ports. So, even if this was used to create a key or guid, it would not be consistent.

I agree that utilizing an instance guid or the device path is better way to look up and manipulate devices via SimConnect. The absence of the instance guid has been an issue in other areas as well. We will continue to consider our options when it comes to consistently identifying and differentiating between devices of the same type.