If there’s reason to believe it works better than an EDTracker I could try it. Maybe I want some sort of hypothetical industrial strength tracker.
You can use the EDTracker hardware with FTNoIR or OpenTrack. I use mine with latter and only use the EDTracker software to rest the gyro bias, which has to be done each time I plug it in (actually I have a button on my USB hub that disables the port, so I rarely need to physically unplug it).
Hi,
I’m interested in purchasing one of these.
Can anyone in the UK tell me what happens when it gets to the UK customs? Does it get held until I pay the bill?
And what would be the amount of tax on that around £20?
You have to pay 20% VAT on the total price, including shipping, for any purchases from outside the EU and an £8 (Royal Mail) or £10 (DHL) fee for them to pay the VAT in advance and do the customs paperwork for you. They won’t hand over the goods until you’ve paid. Not sure about RM but DHL can take payment at the door if you haven’t already paid when they turn up.
Only purchases under £15 don’t incur any VAT (and thus no fee either).
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.
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.
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?
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.
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.
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?
Mouse clicks in the cockpit generate callbacks.
OK, so the callbacks are active even without any keyfile?
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?