Suggestion: Provide external access to callbacks, independent of the keyfile
-
The previous thread in which I posted was quite rightly closed as the OP was out of order. I should have really started my own thread in the first place instead of tagging onto his but I was using Tapatalk on my phone at the time and I’m not sure how to start new threads using that, so I posted whilst my thoughts were fresh. Anyway, I’d like to continue the discussion of my suggestion without the baggage of that thread. I’ll quote the previous posts to recap.
I wonder if it would be possible and not require too much work to change the way callbacks work, so instead of having to be mapped to keys, the callbacks directly trigger the associated function in the sim. Then keys are mapped (if using a keyboard rather than pit hardware) to trigger the callbacks.
This would have the advantage for pitbuilders that they wouldn’t even need a keyfile and would just setup their hardware (or intermediary software) to send the appropriate callbacks. It would make it easier for third-party software that sits between the hardware and BMS as well, as that would just need to map the appropriate callback (using user-friendly names perhaps) to each hardware control and not have to worry about the keyfile.
Then the keyfile would only be needed for keyboard users, with only the appropriate toggle/cycle callbacks in it. We have this already and it wouldn’t need to be altered, just the background code which dictates how callbacks and keys are connected.
Well, thats easier said than done. Not to mention it requires support from hardware manufacturers, to implement the new standard. Not gonna happen.
Of course even the smallest change requires more work than suggesting it. Why would it require support from hardware manufacturer s though? Using Arduinos and the like, it’s easy enough to configure them to send the callbacks over UDP. At the moment I think they have to be configured as HID devices and send DX keys which are then mapped in the keyfile don’t they? That seems more complex to me.
I know a chap who’s developing some software for another sim in where you say switch/encoder/LED, etc is attached to pin x on the Arduino and it should be mapped to sim command x and it then creates the firmware and pushes it to the Arduinos. It has profiles to let you easily switch between planes and if BMS had set callbacks (they could be set in a file listing them, rather than hard-coded, to make it easy to add new ones whilst keeping the old ones for backwards compatibility) then I think he could be persuaded to add BMS compatibility, which would make it very easy switching between sims.
If you are using an arduino, you are effectively the manufacturer of your hardware. If you are using something like say PoKeys, X-Keys, or anything else, you would not be able to use such a system.
DX frankly seems easier than what you are suggesting.
Fair point but it would seem a fairly simple project (for someone who can program that is) to create a utility that maps the DX input from such hardware to callbacks that are sent on to BMS (or indeed whatever other sims use instead of callbacks). Whilst Arduinos can be setup to send DX signals, in all sims this then requires the extra step of mapping those to functions, which is unnecessary if the hardware is mapped directly to callbacks/UDP commands and then you never have to worry about your mappings getting messed up by an update or something.
Does Helios interface with BMS by sending callbacks over UDP? If so, it seems most of what would be required is already there, it just (and I in no way use that word to suggest it would be 5 minutes work) needs the callbacks to be made independent of key mappings.
I’m not sure how it works currently, as obviously mapping a callback to a key doesn’t make the callback when triggered send the key, as the keys mean nothing to BMS, so I presume that when the key is pressed it triggers the callback but any callbacks not mapped to keys are inactive and can’t be triggered by any method?
Mouse clicks in the cockpit generate callbacks.
OK, so the callbacks are active even without any keyfile?
Yes.
So why isn’t it possible to trigger them externally without mapping them to keys in the keyfile? I’m presuming that Helios only works if there’s a properly configured keyfile?
I have no idea how Helios works. Havent used, not likely to.
The whole point of a system like directX is that it makes the interface between software and hardware, both software and hardware agnostic. Im not seeing the benefit to removing the existing keyfile just to make another one that exists at the hardware developers end instead of the user.
You have exactly three methods to interact with the sim:
Keyboard
DX
MouseIf you don’t tell BMS with which method you’d like to interact, obviously nothing will happen.
You have two choices to define it by yourself: Keyboard & DX. Mouse is just 3d pit stuff supported by default.I’m sorry, I don’t get the point.
What exactly would you like to achieve other than what is “there” already?
Because when I plug in my HOTAS, BMS doesn’t have anything built in to know that “Button1=Pickle button, Button2=Trimhat right, Button3=x”, etc. And even if it did, there would need to be a table of ‘what button does what’ for each kind of HOTAS …. and for each new HOTAS … and for each combination of Stick/Throttle … and for other peripherals (MFD’s, for example) … etc., etc., etc. And then those button-to-callback tables would be fixed; not user editable. Otherwise you’re just back to making personal keyfiles.
I assume that making these built-in HOTAS to callback tables may not be easy in Falcon code, would be forever incomplete with the myriad combinations of devices people use and would not keep up with any new HOTAS/devices developed. Not too mention all the people who would say, 'But I want my Button1 to do such-and-such, not what BMS programmed."
An ‘external’ keyfile is easier, imho.
I’ll respond to Agave_Blue’s post first. My suggestion has nothing to do with HOTAS, which will always output DX. All sims that I’m aware of use a similar UI method of mapping HOTAS DX commands to sim functions (in BMS’ case there is the alternative option of editing the keyfile but I think that’s an option rather than necessary). With PoKeys and HOTAS that are hardcoded to output DX, nothing would change and users would continue to use the UI or edit the keyfile, although if someone was to create a separate program that sits between the hardware and BMS and allows the user to map DX buttons to callbacks (using user-friendly names) that would probably make life easier for them, as well as the devs as they wouldn’t have to maintain a pitbuilders keyfile in future. DX hardware is not what my suggestion is about though, it’s purely about enabling hardware panels (and touchscreen apps, whether running on the PC or on tablets) to output callbacks and for those to work independent of the keyfile.
In response to the last two posts from blu3wolf and Kolbe-49th, firstly there’d be no need to remove the keyfile. If the callbacks are active and listened for on a UDP interface, regardless of the the keyfile, then it doesn’t matter if there’s also a keyfile that maps keyboard (or DX) commands to callbacks.
I had a quick look at one of the Helios profiles for BMS and as far as I can tell, it does seem to have callbacks mapped to the on-screen switches. I don’t know my way around Helios well enough to work out what sort of interface it’s using though, so I don’t know if it’s UDP or something else. Looking at the download page for the profile http://ihpff4bms.blogspot.co.uk/ it does require a keyfile, so it seems that even if it’s outputting callbacks they won’t do anything unless they’re mapped to keys. I don’t think Helios could be outputting keys rather than callbacks, as when the Helios screen is tapped it would put Helios in focus and thus BMS wouldn’t receive the key output.
The big advantage of using callbacks rather than DX, IMHO, is that it’s much simpler when setting up hardware/touchscreen controls. For example, if I’ve got a two-way switch that I want to operate the gear, assigning up to the callback for GearUp and down to the callback for GearDown I can instantly see what function it’s assigned to, both at the time and later when checking the assignments. If it’s instead mapped to Joy3 DX9 and DX10 for example, I have to then cross-reference with the keyfile to find out what Joy3 DX9 and DX10 are assigned to, which is much more complicated. In addition, if the keyfile gets corrupted or an update changes something, the DX mappings may no longer work properly and I’ll have to debug the files to find out what’s happened. If the callbacks are independent of the keyfile, then the hardware will always work. The list of callbacks defined in the BMS code can be added to if necessary, whilst maintaining the existing ones for backwards compatibility, with a list of them exported with each update for developers of third-party utilities to reference.
Just because it’s done in other sims doesn’t mean they’re right and BMS is wrong but the fact is that several other sims I’m aware of do provide direct UDP access to callbacks/functions and it’s much easier to just change what commands the hardware outputs depending on what sim is being flown than to switch between firmware that outputs UDP over the LAN and DX over USB, so if BMS could provide the same access it would make life a lot simpler for people building their own panels. Providing the same interface as other sims (as an option) also increases the chances that someone will develop (or adapt for BMS) programs that make it easy for users to configure their hardware for BMS, as even if the author doesn’t fly BMS it’s very simple for them to add a BMS profile with all it’s callbacks.
-
….
I’ll respond to Agave_Blue’s post first. My suggestion has nothing to do with HOTAS, which will always output DX. All sims that I’m aware of use a similar UI method of mapping HOTAS DX commands to sim functions (in BMS’ case there is the alternative option of editing the keyfile but I think that’s an option rather than necessary). With PoKeys and HOTAS that are hardcoded to output DX, nothing would change and users would continue to use the UI or edit the keyfile, although if someone was to create a separate program that sits between the hardware and BMS and allows the user to map DX buttons to callbacks (using user-friendly names) that would probably make life easier for them, as well as the devs as they wouldn’t have to maintain a pitbuilders keyfile in future. DX hardware is not what my suggestion is about though, it’s purely about enabling hardware panels (and touchscreen apps, whether running on the PC or on tablets) to output callbacks and for those to work independent of the keyfile.…
Well, this is obviously well beyond my expertise since I fail to understand how ANY input method can initiate a callback if there is no ‘translator’ to say ‘input x = command y’, i.e. a keyfile. I don’t see how that changes whether you’re working with a keyboard, a HOTAS, a touchscreen panel, a clickable cockpit, voice activation or a physical panel.
-
From how I understand Helios works, it needs both the callbacks and the key bindings, but Helios sends out the key bindings to the sim, not the callback, hence the need for key bindings.
As an example, for instance you have the AFGearUp and AFGearDown callbacks. Gear up is mapped to (for example) SHIFT+G and down is mapped to ALT+G. You assign the AFGearUp callback to the up position of the gear lever in Helios and you assign the AFGearDown callback to the down position of the gear lever. What Helios does is recognize what position the switch is in, look at what callback that is tied to, then throw out what key bindings are connected to that callback. Because of this, Helios CANNOT work if the callback is not assigned to a key binding.
On the other hand, callbacks assigned to DirectX functions do not need a key binding to work.
Hope that helps!
-
Well, this is obviously well beyond my expertise since I fail to understand how ANY input method can initiate a callback if there is no ‘translator’ to say ‘input x = command y’, i.e. a keyfile. I don’t see how that changes whether you’re working with a keyboard, a HOTAS, a touchscreen panel, a clickable cockpit, voice activation or a physical panel.
It’s just cutting out the middleman so to speak. With the keyfile setup to map e.g. G to the AFGearUp callback, when G is pressed it triggers that callback, which in turn runs the code associated with that callback. With a UDP interface listening for the callbacks, when the AFGearUp callback is received then the sim runs the code associated with that callback.
-
From how I understand Helios works, it needs both the callbacks and the key bindings, but Helios sends out the key bindings to the sim, not the callback, hence the need for key bindings.
As an example, for instance you have the AFGearUp and AFGearDown callbacks. Gear up is mapped to (for example) SHIFT+G and down is mapped to ALT+G. You assign the AFGearUp callback to the up position of the gear lever in Helios and you assign the AFGearDown callback to the down position of the gear lever. What Helios does is recognize what position the switch is in, look at what callback that is tied to, then throw out what key bindings are connected to that callback. Because of this, Helios CANNOT work if the callback is not assigned to a key binding.
On the other hand, callbacks assigned to DirectX functions do not need a key binding to work.
Hope that helps!
Thanks Ice. You obviously have a much better understanding of Helios than I do, having created a BMS profile in it.
I’m curious how it works if it’s sending keypresses though, considering that touching the Helios interface would surely put Helios in focus, thus putting BMS in the background and unable to see the keypresses?
This obviously isn’t an issue for DX output, as if BMS is the only program that’s listening for DX input it will receive it whether it has focus or not but I presume that the keyfile still needs to have the DX commands mapped to callbacks?
-
I actually have no idea how Helios does that part. I have BMS in “windowed” mode due to extracting gauges/MFDs and interacting with Helios via my touchscreen does NOT remove the focus from the BMS window.
-
I actually have no idea how Helios does that part. I have BMS in “windowed” mode due to extracting gauges/MFDs and interacting with Helios via my touchscreen does NOT remove the focus from the BMS window.
OK thanks, it must be doing something clever I guess! I’ll have to test it sometime to see if it works with BMS fullscreen.
-
It’s just cutting out the middleman so to speak. With the keyfile setup to map e.g. G to the AFGearUp callback, when G is pressed it triggers that callback, which in turn runs the code associated with that callback. With a UDP interface listening for the callbacks, when the AFGearUp callback is received then the sim runs the code associated with that callback.
There is no ‘middle man’ in the BMS keyfile. It’s direct from the input device to the game command. If Helios (or anything else) forces a middle-man (input device –> keyboard press --> game command), that seems to me to be a front-end device interface ‘problem’, not a BMS Keyfile ‘problem’.
However, I now think I see what you’re getting at. Having Helios (or otherwise) acting like any other direct input device, where touching position x,y on a touchscreen calls some game command directly. ???
-
However, I now think I see what you’re getting at. Having Helios (or otherwise) acting like any other direct input device, where touching position x,y on a touchscreen calls some game command directly. ???
That’s correct.
It appears from what Ice said that Helios is only using the callbacks as labels to make it easier to create the profile and it then looks at the keyfile to find what key is mapped to that callback and sends that key, with BMS then referring to the keyfile to find which callback that key should trigger.
Whilst Helios could presumably just map the on-screen buttons to the keys instead of callbacks, then you have the problem of having to check the keyfile to see which callback key x is mapped to, so it’s understandable why it uses the callbacks as labels instead. If it could just send the callbacks however, it simplifies things and eliminates any issues with BMS not having focus to receive the keys Helios outputs, or the need to find clever workarounds for said issue.
Obviously tablet apps can’t send keypresses without some PC utility to listen for them and forward them onto BMS but sending callbacks eliminates the need for that.
-
That is correct. You can change the key binding for AFGearUp and AFGearDown and Helios will not care. When you throw the gear lever up, Helios will look at the .key file it has loaded, see what is mapped to AFGearUp, and send that key binding. This means less “maintenance” when you change .key files or key bindings.
-
The code contains some direct support for input devices. TrackIR for example. This is done with the use of an SDK provided free for general use by developers – it requires more or less no configuration that rises to the level of “coding” in the sense that whacking on key file content does. I guess support for other such devices that have the same sort of SDK approach might be possible in theory; should such a thing be available at some point and only if it would equally not force more complex programming tasks on players.
The idea of adding RPC or equivalent (which is likely what “UDP” support would imply) isn’t going to happen. If the point was “to simplify” (as measured by not requiring one to understand and edit the syntax of the key file) then this whole thread is headed in the WRONG direction thinking about things like that. Not trying to be rude and it’s not like minds are closed to ideas for improving the programmability aspects of the game but I’d say this feels like a dead end.
The key file is complicated because it provides a LOT of flexibility. Most of that one doesn’t need to use on the average unless you are pit building (or the like) in which case you signed up for complex work by definition for most people using the default key files should work nicely. Programmable controllers (TM, CH, XKeys, etc.) that can either emulate DirectX game controller devices or HID keyboards or mice will work with the defaults really quite well in most cases. Better now that Kolbe-49th went to the trouble of reorganizing the default callback to key mapping sets. If your controller is too complicated to program to map to the defaults, then there’s not much that can (or will) be done in the game code to mitigate that.
Which really comes back to Kolbe-49th’s point anyway: what you need is there so unless there’s an unmet need that we’re not aware of (some input type that can’t be expressed via the existing input paradigms; and none seems apparent from the discussion above) then it’s not clear what could change that would in fact help. Again, adding programmable interfaces like RPC over UDP is not simpler…likely it’s harder to grok and use than the key file.
-
The idea of adding RPC or equivalent (which is likely what “UDP” support would imply) isn’t going to happen. If the point was “to simplify” (as measured by not requiring one to understand and edit the syntax of the key file) then this whole thread is headed in the WRONG direction thinking about things like that. Not trying to be rude and it’s not like minds are closed to ideas for improving the programmability aspects of the game but I’d say this feels like a dead end.
No need to put this topic for more complicated matter than it is actually is. Giving ability to write data to the shared memory would make a huge step forward for the sim for the cockpit builders. I am currently experimenting with emulating imputs via DX vitrual joystick to work with those callbacks - it just works very bad, my application is not matching DX polling rate so Falcon misses a very frequent key presses.
I would recommend to add shared memory writing feature to the roadmap (pressure setting, heading, course, volumes, tacan, manual radio panel channels, etc.), even though I understand you have a lot of other things to do. -
+1…I really wish I could write to SM as well as read it. Would solve some problems.
-
+1…I really wish I could write to SM as well as read it. Would solve some problems.
I would really love to be able to externally send in Datalink data to the game. That would be a shit ton of fun for someone playing AWAC’s coordinator (and there is an an entirely [weird] subset of people who enjoy doing this).
-
The IDM isnt really open to that kind of thing, though. L16 is, but as its not implemented its not really useful to have a feature for making it more accessible.
-
The IDM isnt really open to that kind of thing, though. L16 is, but as its not implemented its not really useful to have a feature for making it more accessible.
I know this is a philosophical difference between me and the BMS team, but in the absence of full L16, I would rather be able to do something then nothing.
-
I’m a cockpit builder myself. Trust me, I understand the intricacies of getting hardware interfaced to the game…up to and including actual MILSPEC flight hardware, some of which I have in my set up. I’ve been working on this since 2003 and I have yet to encounter a problem that even suggested a need to write to shared memory. I’m not saying assertions that such a capability are wrong, but my experience suggests otherwise. Since I’m not going to claim that my experience is exhaustive, however, what is it that you think I may have missed??
The IDM/L16 thing is kind of an aside but to address that: there’s no work planned for IDM even, much less L16 at this point and if there were, opening up to arbitrary input from 3rd party tools would likely not be near the top of the list.
-
I’m a cockpit builder myself. Trust me, I understand the intricacies of getting hardware interfaced to the game…up to and including actual MILSPEC flight hardware, some of which I have in my set up. I’ve been working on this since 2003 and I have yet to encounter a problem that even suggested a need to write to shared memory. I’m not saying assertions that such a capability are wrong, but my experience suggests otherwise. Since I’m not going to claim that my experience is exhaustive, however, what is it that you think I may have missed??
The IDM/L16 thing is kind of an aside but to address that: there’s no work planned for IDM even, much less L16 at this point and if there were, opening up to arbitrary input from 3rd party tools would likely not be near the top of the list.
I would like to be able to pass ground-based Laser Designation into Falcon from ARMA 3 so that Falcon pilots can provide Laser Guided air support to ground troops in ARMA 3, and there is not a good way to pass that information into Falcon.
In the absence of being able to do that - it would be nice to be able to pass steerpoints to pilots from the ground, but again, I suspect I am asking for things that most people here just won’t care about.
-
I would like to be able to pass ground-based Laser Designation into Falcon from ARMA 3 so that Falcon pilots can provide Laser Guided air support to ground troops in ARMA 3, and there is not a good way to pass that information into Falcon.
In the absence of being able to do that - it would be nice to be able to pass steerpoints to pilots from the ground, but again, I suspect I am asking for things that most people here just won’t care about.
This use case doesn’t look realistic to me since terrain is not matching (Arma3 vs Falcon theaters).
-
I’m a cockpit builder myself. Trust me, I understand the intricacies of getting hardware interfaced to the game…up to and including actual MILSPEC flight hardware, some of which I have in my set up. I’ve been working on this since 2003 and I have yet to encounter a problem that even suggested a need to write to shared memory. I’m not saying assertions that such a capability are wrong, but my experience suggests otherwise. Since I’m not going to claim that my experience is exhaustive, however, what is it that you think I may have missed??
Can you please tell me how did you build the entries for altimeter pressure, course and heading inputs? I have Opencockpits hardware in my pit that is serving an encoders. It provides all necessary functions like acceleration, anti jitter, so I can easily build a logic in the opencockpits to calculate course as integer value (0-359) from the encoder input. Now the problem comes when I want to enter this data in the Sim. I made a simple application that can be driven by open cockpits SIOC and simulate inputs to the virtual HID device (simple joystick with buttons and axes). When I am sending key press/release events to the virtual joystick, sim is reading only part of the multiple inputs from HID device. I had to put a delay, so there would be around 20ms between the key presses. Then it started to work somewhat usable (at least half of the DX events being accepted by falcon. But this instrument response is lagging a lot so this solution is not good.
Of course I can replace encoder with just two buttons (increase course/decrease course), but it is not close to the way the pilot provides the input in the cabin.
So the ideal way would be if I would write a course value directly to the shared memory and update the instrument. Sim response rate will be much faster since there Will be no need of so many iterations to change the variable.