Suggestion: Provide external access to callbacks, independent of the keyfile
-
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. -
Encoders. Not all encoder interface boards are created equal though (from my experience anyway). There’s a lot of useful information and help available for this sort of thing over at viperpits.org – you may want to take this question over there. I’m not familiar with Opencockpits hardware but someone over at viperpits might be…needing a separate application, even a simple one seems…unusual…but perhaps I don’t grok how that hardware works.
One thing to keep in mind from the game code side of it though: the callback commands for things like the HSI knobs understand closely-space (in time) input pulses as a request to accelerate (so inc by 5 rather than by one degree). Once that was added the issue of encoder rate and missed clicks reduced significantly. You can tune the interval for this from the cfg file (g_nKnobAccelerationDelta, default is 60ms).
-
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).
That’s an even better idea…I’d just like to be able to send in my TACAN channel changes real time, and not have to worry about synching my switches to 106X (or whatever) every startup. But I think they did something about this in 4.33, right? Haven’t had a good look…
-
One thing to keep in mind from the game code side of it though: the callback commands for things like the HSI knobs understand closely-space (in time) input pulses as a request to accelerate (so inc by 5 rather than by one degree). Once that was added the issue of encoder rate and missed clicks reduced significantly. You can tune the interval for this from the cfg file (g_nKnobAccelerationDelta, default is 60ms).
Many thanks for the advise Boxer! Basically I solved the problem of the shared memory. I get altimeter pressure reading/writing like a charm with 4 byte integer by the address 000004E9829C of the Falcon process memory. Not sure if this lifehack of the the memory addresses for the read/write is breaking any rules. May I post here the progress of the experiments?
-
From your EULA that you agreed to when you installed Falcon BMS:
You may not decompile or reverse engineer the software.
You should be reading the Kollsman window value from AltCalReading in the FlightData2 shared memory area. There is no safe way to write that quantity, and no plans to add one.