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