Is there a way to "monitor" the state of switches/knobs/buttons in this game?
I suspect this is possible, as Helios is able to “extract” information for things such as gauges and indicator lights, but I have no idea how this “witchcraft” is done
What I am hoping to do is to be able to query the sim to find out the position/state of certain switches, knobs, and buttons in the game and so as to be able to display the proper image or icon in an external application. This is to ensure that the switch state as shown in the sim and in the application are “in sync.”
you’ll have to do it the same way cockpit builder do it with their real physical switches
Use the all switch position callbacks and not the toggle
that way, when you set a switch down, you are certain that Falcon does not toggle the function, but indeed place the switch down.As for switch sync, you only have one option: do the cockpit checks at each ramp. When you have output switches, they are never in sync, depending on how you exit the previous game
Yes sir, I am not using the proper callbacks rather than toggle. One example is mapping Gear Down and Gear Up separately and not using the Gear Toggle function.
One problem I have is that for instance, if your physical gear lever is down and you start on the ground, that is fine as both switches are “in sync.” However, if your lever was down but you start a mission in the air, then the two are not “in sync.” Granting that you can simply put the physical gear lever up…
However, as you said in the other thread, there are very many callbacks… will I have to assign a key combo for each callback I want to use? In the landing gear example above, I had to map a different key combo for Gear Up and another different combo for Gear Down. Is it possible to simply map a control so that if I put the gear lever up, it sends the callback and not the key combo, therefore having to skip finding an “available” key combo fore each callback I want to use?
Another problem is that I am using a program and not a physical cockpit. I want the program to interrogate the sim on startup and maybe even every minute or so just to make sure everything is in sync. Thus if the program shows your Master Arm switch as Arm (where you left it the last time you played) and the sim starts with the MA switch on SAFE, the program changes the position of the switch IN THE PROGRAM to sync it with the switch in the game. Again — the switch in the PROGRAM syncs with the position of the switch in the sim. In our landing gear example above, for example, if you left your gear lever on the down position and started a mission in the air, the program will interrogate the sim, find out that the gear is actually up, and will automatically change the image in the program to the “gear up” image to sync with the sim.
Nope, currently that is not possible. And in fact, this is why cockpitbuilders have come up with software solutions that sync the other way round: reading the state of the external app/physical switch, and send the corresponding expected state to BMS via normal keyboard callbacks, analogue inputs etc… oh well, maybe at some time in the future, together with an input system rewrite. Don’t hold your breath.
Edit: geez, RedDog was much faster and much more accurate… hence I quit this thread now
Dunc, I understand the concept of cockpit builders but like I said, I am not building a physical cockpit and therefore I can have my IN-PROGRAM switches magically sync with the IN-SIM switch No need to manually have to move a physical toggle to sync with the pit.
There is no difference between physical switches and software switches. The physical stuff always uses software to do the communication. So from a BMS point of view, there is no difference, and all which has been said above is applicable for “non-pyhsical” switches as well.
I’m sorry, one of us is confused. Probably me.
As RD stated, one way to ensure switches are in sync is to check them at ramp start. But what if you start a quick mission with the jet already in the air? Another point made was to use proper position callbacks and not the toggle ones, so if I start with the gear lever down but the sim starts the aircraft in the air, I could put the gear lever up and it would command the “gear up” callback (instead of the “gear” toggle) and I would be safe.
However, this is where the physical and software switches are different, and this is why I ask on this thread. In the gear example above, you could fly the entire mission and only realize the “out of sync” as you come in to land, but no big deal as you can simply bring your physical gear lever up, and now you are “in sync” with the actual gear lever state as shown in the sim. Then simply put the physical gear lever down, and the gears come down. PHYSICAL switches. Now what I want to do is “automate” this system a bit. Same scenario but with a “software” switch this time. The “software” switch starts off in the lever down position, but the mission starts the aircraft in the air. Again we have the “out of sync” problem as before. At this point, I want the program to query the sim, realize that the gear in the sim is actually up, so I want the program to realize this “out of sync” scenario and change the “software” switch to show a lever up position, bringing the two “in sync.” The pilot never realized he was “out of sync”, he does the mission, brings the gear down (sync step skipped because the program did this already!), lands, mission complete.
So the question is –- how do I query the sim to make this “automation” possible?
You’re complicating what’s really simple.
Don’t bother with syncroniztion… if your using “switch position-callbacks”, then next time you use a switch (physical) you’ll be synced with that switch.
Think by logic… If you start mission flying, gear is obviously up. So when it comes the need to lower it and you find your gear switch (physical) already down, then simply pull it up then down again. see?
as Dunc said, you can’t do that
Switch states are not externalized, so you can’t ask a software to do it as the information is not available from BMS shared memThe only way to do it, is to consider the user that clever software that put all switches in sync
And that’s done with the preflight cockpit checks
The only way to do it, is to consider the user that clever software that put all switches in sync
And that’s done with the preflight cockpit checksLol… some of us are too impatient we start the flight in the air… so no “preflight checks”…
You still have to place the switch in sync yourself, using the all position relevant callback
Hmmm… okay, thank you, I think I got that part correct.
Now I know Falcon does make information available that allows cockpit builders to replicate the cockpit state — is this the “shared memory” you are talking about? So what exactly is in this shared memory? Is it just gauges and cockpit lights? Is that how MFDE and other cockpit extractors work, by reading this shared memory? So the cockpit switch states are not included in this?
yes, cockpit stuff is possible thanks to the information available in the sharedmemory
You can see what is in there by opening the flightdata.h in your doc folderit’s indeed gauge & lights stuff, but many other things - but no switch state
Yep, took a look, nothing about switches, mostly just lights and gauges.
Here’s my keyfile.
903 (different) callbacks without cougar (SSC/TQS) ones. These are included at end of file.
Hmmm… okay, how do I make use of Flight Data.h information? How does it work? I was just hoping to be able to “watch for” the Master Arm switch coming on and would be able to reflect the On/Off state of the light in my project.
you need a sharedmemory reader, I’d check Viperpit for those, but they are in maintenance
I am curious how programs like Helios or MFDE reads the information. For example, how does MFDE know when to put on the caution light? If I can find out how it “reads” this info, I’ll try incorporating that to my program.
… I was just hoping to be able to “watch for” the Master Arm switch coming on and would be able to reflect the On/Off state of the light in my project.
WTH are you talking about?
Master Arm switch comming on…??? ON/OFF light…??? (What light ?)
Anyway, sharedmemory reflects all light states. Any sharedmemory reader will indicate lights states.
here’s a SM reader; https://www.assembla.com/code/lightningstools/subversion/nodes/releases/Programming%20Tools%20and%20Source%20Code/Falcon%204%20Shared%20Memory%20Reader%20for%20dotNet%20and%20COM?rev=95 (Work of “Mr.” Lightning)MFDE (and other) tools combine SM readers and video memory readings, coz MFDs and other Displays cannot be read from SM.
Also, follow this thread about SM structure and WIPs; https://www.benchmarksims.org/forum/showthread.php?5914-Shared-memory-documentation
I LOL at myself… I meant “Master Caution” light… sorry. Thanks for the links!