Help Listing Comms Callbacks
-
I’m in the process of changing all the comms menu outputs for FoxVox from the old T-T-T-1 style keypresses to utilize callbacks as defined in the BMS key file. I have built a new plugin utility that reads the key file which maps the callbacks accordingly to support this, changing this:
into this:
I Have found that several of the callbacks, however, seem not to be defined in the key file (such as newer Wingman set Bingo, Lineup Single Ship, Lineup Element), and also some extend beyond my familiarity with the terms (i.e. WingmanChainsaw - my guess is this is Grinder?).
The technical manual says that all defined callbacks are found in the bms_full.key file. Is this actually true, or are some new ones possibly missing? Any pointers in getting a full list along with linking it to the comms menu equivalent would be greatly appreciated.
Thanks!
-
@foxster In 4.37.2 I would estimate that about 1 out of 10 commands were available as callbacks. That figure has increased quite a bit in U3 with Wingman/Element/Flight commands having much better coverage. But still there are 71 commands in total to issue to your wingman and only 46 of those are callbacks in the Full keyfile.
On top of that it seems that the entries in the keyfile does not run ordered or sequentially through the menu structure, so you can’t even rely on that for mapping between the TTT-1 style and callback name.
Many ATC commands are not available as callbacks either so it’s probably a work in progress to get full coverage (for U4?)
-
@foxster – I can help you with this. The general population probably can’t answer completely without being able to look into the code to know both what the callback names should be and what is and isn’t implemented yet.
Once upon a time there was very little comms menu direct equivalent callbacks…a few got added over time but more of them really because some of us on the code team wanted direct access mappings via DX instead of as key bindings…certainly for what I’ve added in that way over the years it’s about cherry picking the ones to add that I actually use…many of these aren’t necessarily documented or picked up in the .key file support docs/content because we didn’t necessarily expect people to want that direct access.
What you are doing now motivates a complete set of discrete binding callbacks for comms menu functions. But that only partially exists for now. When I reached out to you, the idea in my head was to complete that mapping so you can pick them all up in the way you are showing. In other words, your work gives us a reason to complete the discrete callback set and I’m I guess signed up to make that happen. But it’s not all there yet…
-
-
@Boxer Thanks…Great info. I’ll proceed with mapping the ones we have for now.
-
@airtex2019 With 128 buttons each on 16 devices with vJoy, we don’t actually need keyboard mappings defined, just the callbacks to be available for dx mapping…if that’s possible within the code.
There could be a possible limit with the way the dx shift modifier works also as I’ve found that the button values just increase past 128 for each virtual device which would mess things up past 256 or whatever the current default dx shift value is at.
-
@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.