How to call a callback from an external application
-
Greetings,
I was just wondering how you would call a callback from an external app. So if I was creating an application in Visual Studio 2013 how would I get to the shared memory for the callbacks?
Thanks,
-Matt
-
Greetings,
I was just wondering how you would call a callback from an external app. So if I was creating an application in Visual Studio 2013 how would I get to the shared memory for the callbacks?
Thanks,
-Matt
An example would be how would I find what the switch state would be for something like the lights.
-
As far as I know, switch states etc are not in shared memory.
In the BMS folder you have a subfolder tools, where you can find shared memory viewer. There you can see what is in sharedmem available.
Callbacks are dependant on your used & configured keyfile, so not to be found in sharedmem anyway. Best way would be to have the user of your program point to the active .key file and then you assigning BMS callbacks in your program, and when triggered check the assigned keyfile what keystroke is linked to it and then fire that keyboard input. -
Currently it is not possible that BMS could “tell” you which switch is in what position.
This will for sure work if the input system is revised someday in the future.
To see what information is provided by BMS just take a look at …/Tools/Shared MemVice vera BMS can recognize on simulation start, what state your physical controller switches are in.
This obviously does only work with DX.Edit: FD was faster…;)
-
You can always monitor keystrokes and use key file at the same time to know the states of the user switches. Not efficient but the only way as I see it.
Sent from TapaTalk
-
You can always monitor keystrokes and use key file at the same time to know the states of the user switches. Not efficient but the only way as I see it.
Sent from TapaTalk
not necessarily true.
If one uses a keystroke to send a toggle callback instead of separate up/down callbacks you only know the switch changes position, but not exactly what position. -
I believe the initial state can be saved… so you have a starting point. Your problem will be if you loose some keystrokes capture.
else a programmer must record all cockpit variants or some he likes at their stock state and also there you have a starting point. -
I believe the initial state is saved… so you have a starting point. Your problem will be if you loose some keystrokes capture.
saved where? Switch states in 3D pit are nowhere to be found in shared memory.
-
there is not only shared memory in falcon world.
-
there is not only shared memory in falcon world.
That’s not an answer to my question nor useful information for the Guy starting this thread…
-
Well that’s all I can give, in the sense that the cockpit state is saved by the user. Can’t recall where it’s saved but this is useful info and one interested can search to find, in case he doesn’t know this functionality exists at all. Right?
So please don’t judge that quickly and easily what is useful or not.
The pita will be if this save state doesn’t include what’s needed but also my reference might trigger a more knowledgeable member on the subject and contribute on the quest.Also searching how the 3d state gets the initial state of the switches might help to have a start instead of only asking someone to provide u ready a modification in the shared memory.
Right?Sent from TapaTalk
-
Well that’s all I can give, in the sense that the cockpit state is saved by the user. Can’t recall where it’s saved but this is useful info and one interested can search to find, in case he doesn’t know this functionality exists at all. Right?
So please don’t judge that quickly and easily what is useful or not.You can save a cockpit state, but that requires an action from the pilot first IIRC, and then you need to reload the saved state once back in pit too IIRC. So hardly a default BMS way solution for what the OP is asking.
I’m not judging anything. I was honestly asking where the switch state could be found as that would interest me too.
Also, my original issue that I mentioned still exists. If you know an initial state, and the user clicks in 3D pit, the state has changed, but not the saved original cockpit state, so same issue, you don’t know.instead of only asking someone to provide u ready a modification in the shared memory.
Right?Don’t put words in my mouth Arty, I never asked for that. Unless you can point towards a post on this entire forum where I did…?!
I only said it can’t be found in shared memory, nothing more, nothing less. -
One of the great things about BMS is that you can write an external app and tell BMS what to do - take your idea, and turn it inside out.
I’m working on doing this sort of thing for my own pit project - as I’m going to have switches, etc. that will be in a known state when I get in my pit, what I envision is a way to send that state to BMS on command; i.e. - read all of the actual switch states and then send that information to BMS. Of course, I’ll be doing this through Arduino or Pokeys scripting outside of BMS itself…and I’m thinking I’ll use the FCLS RESET switch or some combination of paddle and some switch to invoke the command to my interface controllers.
But in principle, I can’t see any reason why you couldn’t do this sort of thing with a standalone scrip that just saves your callback “defaults” and runs when invoked to send those callback states to BMS. You’d have to use the entire callback list in this case for the sake of completeness, I’d think.
-
some of the initial switch states are saved in the callsign.ini file but very basic iirc and does require that they were set previously