Suggestion: Provide external access to callbacks, independent of the keyfile
-
+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.