Help Listing Comms Callbacks
-
@foxster yeah vJoy is the only approach I know of to synthesize joystick HID input.
let’s discuss … what is your plan exactly? not sure how this will interface with Alt Launcher usage.
is the plan for FoxVox to emit an alt-launcher XML file for the vJoy device, mapping its 128 button slots to the radio-menu callbacks?
I suppose that could work.
AL is using an ancient 32-bit-only DLL for the DirectInput wrapper … the name of the aforementioned XML file contains the “device instance guid” obtained from DirectInput – note, this is not the pid/vid guid listed in DeviceSorting.txt
It’s on my backlog to replace this ancient 32-bit dependency with a more modern interop layer for DirectInput… even if I have to write one myself.
But aligning it to the way BMS enumerates devices, based on pid/vid guids … and maintaining back-compat for current AL users, is going to be tricky.
-
@airtex2019 Going for a more simple approach. I’ve got a dll plugin built for FoxVox that reads the key file at startup and maps the output from that. All I’m doing to get them into the key file is building the bindings manually and pasting them in.
-
@foxster for proof-of-concept / prototyping purposes, sure ok…
but as a plan for general usage… consider, how it will work in conjunction with AL – which writes the .key files a few milliseconds before launching BMS
-
@airtex2019 AL already sees the buttons just fine like it does any other joystick. I already tested this by binding a few commands manually. To bind one manually you need to have vJoy installed with at least 1 virtual controller active and enabled in FoxVox. Then with AL open for dx binding click one of the vJoy buttons in FV. AL picks up the button and registers it in the key file. As long as the vJoy driver is running at launch AL won’t delete the bindings once they are present…unless I’m missing something.
The question is how does AL store the bindings before writing the Key file…I thought it used the key file itself but if it uses an xml file cache then the virtual bindings will have to be added there.
-
@foxster I believe the DX mappings are held in the XML files and upon launching BMS the AL merges the XML into the key file with the respective DX inputs.
-
@Wheelchock @airtex2019 Well then maybe just creating a new stock file for vJoy device that has the comms mapped in it? Like what’s available for other joysticks? How do these stock templates get applied, and can there be more than one used? I’d rather let the experts tell me the best way to go about doing this…
-
@foxster scroll back up to 12 hrs ago…
<< is the plan for FoxVox to emit an alt-launcher XML file for the vJoy device, mapping its 128 button slots to the radio-menu callbacks?
I suppose that could work. >>
These XML files are pretty simple… just an array of 128 callback names. (well now 2x arrays for the 2 jet profiles … and ignoring the axes stuff, and pov-hats, and dx-shift layer…)
The only hard part will be naming the “vJoy.xml” file in the idiosyncratic way AL will look for it.
Currently the filename pattern is
$"Setup.v100.{hidProductDescription} {dxDeviceInstanceGuid}.xml"
I predict it will be awkward and difficult for you to obtain that {dxDeviceInstanceGuid}. Maybe not? idk
I’m open to amending AL to also probe for
$"Setup.v100.{hidProductDescription} {hidIdAsSeenInDeviceSortingList}.xml"
… thus allowing the filename for your vJoy device to be wellknown ahead of time.The final complication is … whatabout people who are already using vJoy for other purposes?
They will have duplicate-looking entries in DeviceSorting.txt … 2 or more lines with same pidvid ID for vJoy.
My understanding: the order in which DirectInput enumerates HID devices is relatively stable… at least, from moment to moment as we transition from AL to BMS – so this will probably “just work” but it needs to be tested.
-
@airtex2019 said in Help Listing Comms Callbacks:
@foxster scroll back up to 12 hrs ago…
<< is the plan for FoxVox to emit an alt-launcher XML file for the vJoy device, mapping its 128 button slots to the radio-menu callbacks?
I suppose that could work. >>
Ok, ok I’m catching up (thanks for being patient)…but if it needs an xml file rather than just copy/paste lines into the key file then I’m for just doing it once as a template rather than having code spit it out. As it stands right now, everything is in place to work, but every user would have to map each and every callback manually through the launcher…major PITA.
I’ve got a different idea…Rather than go through the whole process of trying to create an XML with the right name and GUID and schema, etc. what if you simply had a designated list of callbacks for vJoy listed in a plain text file named “vJoy_Callbacks.txt” (or whatever) from which you could append each binding to the end of the key file, starting at a specific button value and incrementing each one to the next button? This could also allow the user to specify which device/button to start at to avoid conflicts with other vJoy apps they may already be using. This would be done in a separate routine just at the end of the Key file creation. I’d be happy to write the routine to do it for you to save time, but it’s really simple and I don’t think you’d need/want my help.
Here’s what would be in the text file (along with possibly a button start value - or that could be kept inside AL and shown to the user on the UI):
FlightFluid
FlightSpread
FlightStackAnd here’s what gets added to the key file
#======== vJoy Device ========
FlightFluid 0 -1 -2 0 0x0 -1
FlightSpread 1 -1 -2 0 0x0 -1
FlightStack 2 -1 -2 0 0x0 -1I know it bypasses the xml schema that’s already in place, but it seems like it would be much simpler to do. What’s your thoughts?
-
Just for reference, here’s the parsing spec for FV variable inputs/outputs (as it stands now):
Keyboard:
InputType | KeyCode | ScanCode | Modifiers | Position- InputType [int]: 1 for keyboard.
- KeyCode [int]: A virtual key code value.
- ScanCode [int]: A scan code value.
Note: Either a key code or scan code is required. If both are specified, the scan code is used and the key code is ignored.
-
Modifiers [int]: A bitwise enum value from the following:
None = 0,
Shift = 1,
Control = 2,
Alt = 4,ex: Alt+Shift would be a value of 5, Ctl+Shift would be a value of 3
-
Position [int]: 0 means press & release (down then up); Greater than 0 (i.e. 1) means key down; Less than 0 (i.e. -1) means key up;
Ex: “1|0|1E|1|0” - sends Shift+A keypress down then release
Joystick/HID:
InputType | Device/Report# | ButtonType | Id (Button#/Hat#/Axis#) | Position | Product-
InputType [int]: 2 for Joystick/HID.
-
Device/Report# [int]: Device number (0 based index).
-
ButtonType [int]: 0 for button, 1 for POV/Hat, 2 for Analog value.
-
Id [int]:
ButtonType=0: Button ID (0 to 127)
ButtonType=1: Pov/Hat ID (0 to 3)
ButtonType=2: Axis Id where X=48, Y=49, Z=50, xR=51, yR=52, zR=53, Slider1=54, Slider2=55, Slider3=56 -
Position [int]:
ButtonType=0: <0 up, 0 full press, >0 down
ButtonType=1: POV position in degrees: 0, 45, 90, 135, 180, 225, 270, 315
ButtonType=2: 0 to 100 percent -
Product: the HID device product name used to identify it (must include ‘vJoy’ if specifying a vJoy virtual device output)
ex: “2|0|0|0|0|vJoy Controller 1” - sends button #1 press and release on vJoy device #1
-
@airtex2019 said in Help Listing Comms Callbacks:
we may need a named-pipe, or open a local network socket or some similar sort of IPC interface, for companion apps like FoxVox to invoke callbacks.
That would be great and simplify a lot of 3rd party utilities.
-
@airtex2019 I’ve gone ahead and added functionality to the parser plugin to auto-populate the key file with the vJoy bindings that will ship with FoxVox v2.3 so you don’t have to mess with that and can focus on the bigger picture going forward. The plugin is easily configured to run after BMS starts by detecting the BMS version in shared mem, so it will update the key file after AL has already reset everything. I’ve tested that it works great and makes mapping callbacks to vJoy easy by placing them in a text file named vJoyBinds.ini located in the same config folder as the key file.
I’ll distribute the new FoxVoxParser.dll and default vJoyBinds.ini file as assets for a new library with the next FoxVox update.