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.
@doveman:
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.
@blu3wolf:
Well, thats easier said than done. Not to mention it requires support from hardware manufacturers, to implement the new standard. Not gonna happen.
@doveman:
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.
@blu3wolf:
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.
@doveman:
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?
@blu3wolf:
Mouse clicks in the cockpit generate callbacks.
@doveman:
OK, so the callbacks are active even without any keyfile?
@blu3wolf:
Yes.
@doveman:
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?
@blu3wolf:
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.
@Kolbe-49th:
You have exactly three methods to interact with the sim:
Keyboard
DX
Mouse
If 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?
@Agave_Blue:
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.