FSX Info needed for add-on please

[brandonharwood14]

Hi all

I’ve been trying to find the best possible way to write an add-on for FSX,P3D and in future MSFS whereby I use custom made avionics hardware, I’ve been developing my own hardware in the hopes of one day starting a company but my background in the coding/inner workings of the sim is lacking.

I’d like to write a USB driver and create maybe an INI file to tell the sim which hardware button or key presses relate to which FSX event or variable.

I guess it would be almost identical to the approach Real Sim Gear has made their products work with the sim.

could someone point me in the right direction to get started?
How do the INI files work and how does the addon folder in your ducuments link to the simulator?

Thanks in advance 😊

 

[fsintegral]

Hi.
I don't know much about hardware, and my flightsim background goes only up to FSX (FS9, FS2002... FS4).
But I think there are only three ways to communicate with FS :

1) The most used is called a module. Basically, it's a third party DLL (and eventually an indefinite number of dependency files, text, binary, other dlls, even .exe, etc. all setup in specific directories by design). The DLL is installed in the modules directory of the sim, it's a software piece of code that become a runtime loaded assembly or resource of the sim (don't mind my choice of words, focus on the meaning). It gets loaded by the sim only if it implements the SimConnect concept/scheme explained in the SDK. Most people (developpers) out there goes with this way, much simplier and opens a variety of capabilities offered by design by the sim (read/write variables, commands, visuals, sounds, etc.) Examples are FSUIPC, WideFS, many aircraft and scenery addons that goes deep in communicating with the internals of the sim (the like of PMDG...)

2) Create a peripheral, basically, something emulating a keyboard, mouse, joystick, etc. That hardware would be properly installed on the system with the appropriate driver (that you would auto install via a plug-n-play scheme - that's the expected behavior). The peripheral (controller) would be listed in the system as any other, and, once in the simulator, one has just to select and configure it. However, that's NOT really a two-way communication, as the inputs (control -> sim) is the expected kind of possible actions, and the only output (sim -> control) would be force feedback (or whatever it is called today, like a joystick shaking when the aircraft stalls). There are specific patterns to learn to implement such game hardware features, I don't know much about them, and I believe you want much more than just controls reacting to feedback (in that case, you would go 1) in the first place).

3) A software with exceptional privileges, on an admin computer/session, that bypasses all the windows memory protection, that directly read/write into flightsim. That's overly optimistic, and would only apply to those like me who are a decade or two late, with Windows 7/Windows XP (where you could do a bunch of crazy things with C).

You talked about some .ini files. I don't own any RealSimGear, too poor for that, but on their site, they explain they have two types (probably more) of ini files :
- the system config, located along with the RealSim module in flightsim (or the linked directory path on later sims), it acts mainly as a dictionary that stores upon first activation wich COM port (USB used as COM) the hardware is plugged on.
- the commands mappings, as a general one, and some custom ones you can put in any aircraft directory.
^^ the later rings a bell in relation with your question : if you assumed that was some kind of USB configuration that magically binds the RealSimGear buttons/knobs and screen touch to the simulator, you're probably mistaken. RealSimGear appears to also go the 1) option above mainly, most likely associated with option 2). It's the RealSimGear module (a DLL loaded by the sim) that would read the ini files, not FS, not windows. It would then intercept the inputs from the hardware (would be listed as a peripheral on the system), remap the commands in memory, and send the appropriate-FS-compatible command via the SimConnect scheme. The same the other way around.
I also read the their hardware are on the visual-side extra screens, basically, with control hardware around.

I don't know for sure, but my understanding of hardware "two-way connected" with the sim requires one or several modules, a DLL, a piece of software code one must write, compile and install in FS, to translate whatever computing command/data-transfer (software/hardware) into and back from FS-understandable commands/data transfer. There is no basic simple ini file config, or that would be :
- either implemented by design, explained in the SDK, and probably very limited (like cfg files, you write text, and voila, it works, but, that's about what it can do)
- or implemented by design, not explained in the SDK, and only a few would know about, because that would be so prone to security and exception issues, it would be bad to let anyone play with it.

As an alternal example, one could use cheap hardware components to create an on/off button or lever, let's say, a landing gear lever, then use Arduino to code drivers and connect the thing to the PC via USB. The way to communicate with FS is also a module, that would identify the hardware, it does not have to be on a COM emulated port. It does not even have to be an hardware, you can use a module to communicate between your own made software and the sim, directly, or put your software on a remote computer, or over the internet, and make a module that handles the network communication. You can make a module that send FS data stream over some cloud, create another software for a tablet that downloads streamed data from the cloud and shows the datas, then input commands on the tablet screen that are send to some cloud, and make your module stream download from that cloud to command FS....................... That's the scheme. The SDK only explains SimConnect, you have to write your software/hardware handling logic yourself.

 

[Bert Laverman]

Hey Brandon,
exciting project! Throwing some questions in another direction: are you planning on writing just a driver or an application with a UI showing e.g. device and FS connectivity status? Also, are you going to code in C/C++ or C#?

The thing is: you have three simulator platforms to take into account here: (ignoring X-Plane and other non-FSX derived platforms)

1. "Old school" FSX.
   There is no more active development by Microsoft on it, but loads (and really big loads) of experience by lots of people on how to deal with it. "Plain FSX" vs "FSX on Steam" will work virtually identical, although you have to be careful about where you can find configuration files to hook into.
2. Lockheed Martin Prepar3D.
   Lockheed bought the non-gaming license from Microsoft, but as the only active developer on the platform for a long time, many users either dished out the license costs for "Professional", or declared themselves student pilots and went "Academic". Due to their legitimate interest in training real pilots or providing simulations for the military market, they extended and modernized the API (the interface through which you communicate with the simulator) a lot.
3. Microsoft Flight Simulator 2020.
   After seeing a commercial partner fail with the gaming license on Steam and realizing the potential for promoting Azure-based AI work, Microsoft rejoined the market together with Asobo and Blackshark. The simulator itself is mostly new work, but a lot of reuse was made of aircraft and scenery models, as well as adopting the FSX API as a basis for integration with their new platform. This means many calls valid for Prepar3D won't even compile for MSFS!

Even though there are still a goodly number of people using FSX, you'll find the bulk of the serious flyers on Prepar3D and large numbers of fresh starters (and cautious migrators) on MSFS. The Prepar3D and MSFS APIs are NOT compatible. Both share a common FSX part, which means most of the basic stuff will look the same in code, but if you build with the Prepar3D static SDK, connecting to MSFS will likely throw errors and vice versa. The Dynamic (DLL-based) library is even worse: even though the class names are the same and most methods match, the namespaces are different, using the respective company names. This means you need a layer in between to translate. For this reason, most hardware suppliers have separate builds and provide customers with different installers. For the "Pro Flight Instrument Panel", Logitech inherited a codebase that separates the common (hardware-oriented) code from the simulator part, so if you have both Prepar3D and MSFS, you'll install three parts.

To make things easy, you also have a choice in how to launch your top-level DLL or EXE, either by using Prepar3D's add-on configuration (preferred) or a central DLL.XML or EXE.DLL file (of which two different copies exist). This makes it easier for your code, as it won't get started until the simulator is running and you can get a notification when it shuts down. For MSFS you'll need to create an addon directory in order for it to be picked up, but I haven't read those docs in detail yet. From a Microsoft/Asobo perspective everything isn't set in concrete yet either, so you'll have to watch their forums.

Given what you said, I think the "old" C/C++ API will have everything you need, and the code can stay clean wrt cross-platform considerations, but if you're not an experienced developer you'll have to be careful about C++, as "How to shoot yourself in the foot in C++" was described with:

You accidentally create a dozen instances of yourself and shoot them all in the foot. Providing emergency medical assistance is impossible since you can't tell which are bitwise copies and which are just pointing at others and saying, "That's me, over there."

A joke, but with a painful core of truth. Multi-threading and memory management are subjects to approach with care and lots of (automated) tests.

C# is definitely easier, but less common when interfacing with hardware, and (as noted above) incompatible namespace names between SDKs.

Cheers,
Bert

 

[brandonharwood14]

Hi.
I don't know much about hardware, and my flightsim background goes only up to FSX (FS9, FS2002... FS4).
But I think there are only three ways to communicate with FS :

1) The most used is called a module. Basically, it's a third party DLL (and eventually an indefinite number of dependency files, text, binary, other dlls, even .exe, etc. all setup in specific directories by design). The DLL is installed in the modules directory of the sim, it's a software piece of code that become a runtime loaded assembly or resource of the sim (don't mind my choice of words, focus on the meaning). It gets loaded by the sim only if it implements the SimConnect concept/scheme explained in the SDK. Most people (developpers) out there goes with this way, much simplier and opens a variety of capabilities offered by design by the sim (read/write variables, commands, visuals, sounds, etc.) Examples are FSUIPC, WideFS, many aircraft and scenery addons that goes deep in communicating with the internals of the sim (the like of PMDG...)

2) Create a peripheral, basically, something emulating a keyboard, mouse, joystick, etc. That hardware would be properly installed on the system with the appropriate driver (that you would auto install via a plug-n-play scheme - that's the expected behavior). The peripheral (controller) would be listed in the system as any other, and, once in the simulator, one has just to select and configure it. However, that's NOT really a two-way communication, as the inputs (control -> sim) is the expected kind of possible actions, and the only output (sim -> control) would be force feedback (or whatever it is called today, like a joystick shaking when the aircraft stalls). There are specific patterns to learn to implement such game hardware features, I don't know much about them, and I believe you want much more than just controls reacting to feedback (in that case, you would go 1) in the first place).

3) A software with exceptional privileges, on an admin computer/session, that bypasses all the windows memory protection, that directly read/write into flightsim. That's overly optimistic, and would only apply to those like me who are a decade or two late, with Windows 7/Windows XP (where you could do a bunch of crazy things with C).

You talked about some .ini files. I don't own any RealSimGear, too poor for that, but on their site, they explain they have two types (probably more) of ini files :
- the system config, located along with the RealSim module in flightsim (or the linked directory path on later sims), it acts mainly as a dictionary that stores upon first activation wich COM port (USB used as COM) the hardware is plugged on.
- the commands mappings, as a general one, and some custom ones you can put in any aircraft directory.
^^ the later rings a bell in relation with your question : if you assumed that was some kind of USB configuration that magically binds the RealSimGear buttons/knobs and screen touch to the simulator, you're probably mistaken. RealSimGear appears to also go the 1) option above mainly, most likely associated with option 2). It's the RealSimGear module (a DLL loaded by the sim) that would read the ini files, not FS, not windows. It would then intercept the inputs from the hardware (would be listed as a peripheral on the system), remap the commands in memory, and send the appropriate-FS-compatible command via the SimConnect scheme. The same the other way around.
I also read the their hardware are on the visual-side extra screens, basically, with control hardware around.

I don't know for sure, but my understanding of hardware "two-way connected" with the sim requires one or several modules, a DLL, a piece of software code one must write, compile and install in FS, to translate whatever computing command/data-transfer (software/hardware) into and back from FS-understandable commands/data transfer. There is no basic simple ini file config, or that would be :
- either implemented by design, explained in the SDK, and probably very limited (like cfg files, you write text, and voila, it works, but, that's about what it can do)
- or implemented by design, not explained in the SDK, and only a few would know about, because that would be so prone to security and exception issues, it would be bad to let anyone play with it.

As an alternal example, one could use cheap hardware components to create an on/off button or lever, let's say, a landing gear lever, then use Arduino to code drivers and connect the thing to the PC via USB. The way to communicate with FS is also a module, that would identify the hardware, it does not have to be on a COM emulated port. It does not even have to be an hardware, you can use a module to communicate between your own made software and the sim, directly, or put your software on a remote computer, or over the internet, and make a module that handles the network communication. You can make a module that send FS data stream over some cloud, create another software for a tablet that downloads streamed data from the cloud and shows the datas, then input commands on the tablet screen that are send to some cloud, and make your module stream download from that cloud to command FS....................... That's the scheme. The SDK only explains SimConnect, you have to write your software/hardware handling logic yourself.

Thanks a lot for all the information you have provided I have now found a new love hate relationship with the SDK.... hah

Ive gone the managed simconnect route as it opens as its own seperate EXE and have slowly started writing my code. slowly is definitely the key word there as im finding it quite hard to find information on the managed application side of things as most of the explinations of functions are written in C++ while im using C#.

So far I have been able to get a modest GUI going with a few buttons and reading some information like flap events and also connecting to serial ports on the PC (which is my ultimate goal of this addon) have yet to be able to write any information to the simulator in C# at least as i keep getting syntax erros with my code. The simconnect.MapInputEventToClientEvent being the main culprit.

any pointers are welcome with open arms.......
cheers

 

[brandonharwood14]

Hey Brandon,
exciting project! Throwing some questions in another direction: are you planning on writing just a driver or an application with a UI showing e.g. device and FS connectivity status? Also, are you going to code in C/C++ or C#?

The thing is: you have three simulator platforms to take into account here: (ignoring X-Plane and other non-FSX derived platforms)

1. "Old school" FSX.
   There is no more active development by Microsoft on it, but loads (and really big loads) of experience by lots of people on how to deal with it. "Plain FSX" vs "FSX on Steam" will work virtually identical, although you have to be careful about where you can find configuration files to hook into.
2. Lockheed Martin Prepar3D.
   Lockheed bought the non-gaming license from Microsoft, but as the only active developer on the platform for a long time, many users either dished out the license costs for "Professional", or declared themselves student pilots and went "Academic". Due to their legitimate interest in training real pilots or providing simulations for the military market, they extended and modernized the API (the interface through which you communicate with the simulator) a lot.
3. Microsoft Flight Simulator 2020.
   After seeing a commercial partner fail with the gaming license on Steam and realizing the potential for promoting Azure-based AI work, Microsoft rejoined the market together with Asobo and Blackshark. The simulator itself is mostly new work, but a lot of reuse was made of aircraft and scenery models, as well as adopting the FSX API as a basis for integration with their new platform. This means many calls valid for Prepar3D won't even compile for MSFS!

Even though there are still a goodly number of people using FSX, you'll find the bulk of the serious flyers on Prepar3D and large numbers of fresh starters (and cautious migrators) on MSFS. The Prepar3D and MSFS APIs are NOT compatible. Both share a common FSX part, which means most of the basic stuff will look the same in code, but if you build with the Prepar3D static SDK, connecting to MSFS will likely throw errors and vice versa. The Dynamic (DLL-based) library is even worse: even though the class names are the same and most methods match, the namespaces are different, using the respective company names. This means you need a layer in between to translate. For this reason, most hardware suppliers have separate builds and provide customers with different installers. For the "Pro Flight Instrument Panel", Logitech inherited a codebase that separates the common (hardware-oriented) code from the simulator part, so if you have both Prepar3D and MSFS, you'll install three parts.

To make things easy, you also have a choice in how to launch your top-level DLL or EXE, either by using Prepar3D's add-on configuration (preferred) or a central DLL.XML or EXE.DLL file (of which two different copies exist). This makes it easier for your code, as it won't get started until the simulator is running and you can get a notification when it shuts down. For MSFS you'll need to create an addon directory in order for it to be picked up, but I haven't read those docs in detail yet. From a Microsoft/Asobo perspective everything isn't set in concrete yet either, so you'll have to watch their forums.

Given what you said, I think the "old" C/C++ API will have everything you need, and the code can stay clean wrt cross-platform considerations, but if you're not an experienced developer you'll have to be careful about C++, as "How to shoot yourself in the foot in C++" was described with:

A joke, but with a painful core of truth. Multi-threading and memory management are subjects to approach with care and lots of (automated) tests.

C# is definitely easier, but less common when interfacing with hardware, and (as noted above) incompatible namespace names between SDKs.

Cheers,
Bert

Great stuff Bert, thanks for your information. at this stage im aiming at P3D and FSX and will hopefully... one day get into MSFS.
I gave the C++ route a try and found the worked examples in the SKD relatively easy to get a handle on but ultiamtely decided to go with Managed C# application. Ive got the start of a program working ok but find the C# simconnect code a bit trickier to get my head around as the examples in the SDK are C++ mostly.

cheers

 

[Bert Laverman]

Shameless plug: CsSimConnect! ;-)

 

[brandonharwood14]

Shameless plug: CsSimConnect! ;-)

Bert. Love your work on CsSimConnect... and a great plug
I've been scrounging around your blog and GitHub and will look more closely at it when I get a chance in between work.

My code thus far allows me to connect to the simulator and subscribe to sim events. My ultimate goal is to take the Serial data that the Arduino or similar board spits out and use that code to send events to the simulator. Each Hardware device will have its own events to send to the sim meaning there will be approx. 75 or so events to subscribe to, read the data of and/or send events back to.
I've probably bitten off way too much to chew as all the coding experience I have is high school level...... hah

I've been working diligently on the hardware side of things and have a few working prototypes with custom PCB's, touch screens, Displays, Dual rotary encoders, buttons and LEDs all working. I've also designed my own Be58 Panel that is getting cut and bent as we speak.

Im hoping your Github would be able to help me figure out how to send events to the simulator much more easily. time will tell.
Thanks mate!

 

[fsintegral]

I just came back from a trip (for work), doesn't have decent internet connexion for a week.
Unfortunately, last time I made a module was in 2007 for FS9, and that was based on FS98/FS2000 knowledge, just "to have a look". My knowledge about how to code a module is near zero, let's be honest.
Today, I'm mainly on C# ATM for other purposes outside FS (and attempting to leave VBNet behind). My understanding is, FSX and anything before require C/C++ code. I don't know about P3D, but on GitHub, like a year ago, I spotted some managed C# SimConnect projects. P3D, or at least some versions would likely support SimConnect in managed C#.

BTW, I'm not a professional programmer (well, I'm doing it for work also, though, not really for a living, but because I like to code, it's kind of an addiction, a quite pleasant one, and it allows me to have the software that exactly meets my requirements). Thing is, if someday, I would make a module again, I think it would be easy, but at the moment, I have other priorities, and can't unfortunately invest time. Sorry, I really would like to give hints (for once, someone is willing to come up with FS-compatible hardware, that's great, keep going.. ) but, as someone said "life is a bitch", there are other important matters I must focus my efforts on (we are all aware covid affected everyone - but on my end, I invested X in 2019 for an expected Y result in 2020; the Y result gets postponed for 2022; in the meantime, inflation kicked in, and Y, comparatively, is now below X. I already know the money I'll hopefully get back will be meaningless, yet, I must invest more to get the job done, while I'm already broke)

If I already knew, I would write away. What I can say - mainly outside the SimConnect implementation - is :
- SDK for the basis (communication with the sim)
- Stackoverflow for good reading and resources on how to do what on the software end of programming (I bet you already know)
- MSDN for understanding more what is not explained over StackOverflow
- and lots of tests in sim.
- Google is also your friend : ask direct questions.
Take a few steps at a time and regularly test each piece of code you write (there is always a way, but there is no general rule to write the appropriate code for testing purposes). It's better to understand well what a function really does (SimConnect or dotNet assemblies in general), and what you can then implement, than rushing the use of a given function, being locked in tunnel vision debugging, trying to get a result, while forgetting about the entire picture. Back then, I wasted so many hours/days/weeks trying to use some "magical" function (or I thought) without fully understanding what it does. Don't be afraid of the challenge, just accept learning curve takes time, meaning, just do it the right way because you have a goal, you can't be lost along the way if you care. Also, if there is a built-in way of doing something in the dotNet core (or framework), use it, don't reinvent the wheel. I'm talking about IO (files, memory streams...), interfaces, PInvoke, classes, encodings, etc. Unmanaged code, if you really need it, just do fine with native types (* except arrays and strings), don't add another layer of uncertainties by implementing complex classes. Keep it simple and wisely choose how you name fields/variables/functions/assemblies to understand right away the expected behavior. You will forget what the code you wrote actually does anyway. Use comments as reminders/explanations.

 

[Bert Laverman]

Bert. Love your work on CsSimConnect... and a great plug
I've been scrounging around your blog and GitHub and will look more closely at it when I get a chance in between work.

My code thus far allows me to connect to the simulator and subscribe to sim events. My ultimate goal is to take the Serial data that the Arduino or similar board spits out and use that code to send events to the simulator. Each Hardware device will have its own events to send to the sim meaning there will be approx. 75 or so events to subscribe to, read the data of and/or send events back to.
I've probably bitten off way too much to chew as all the coding experience I have is high school level...... hah

I've been working diligently on the hardware side of things and have a few working prototypes with custom PCB's, touch screens, Displays, Dual rotary encoders, buttons and LEDs all working. I've also designed my own Be58 Panel that is getting cut and bent as we speak.

Im hoping your Github would be able to help me figure out how to send events to the simulator much more easily. time will tell.
Thanks mate!

For an example of how to send events with CsSimConnect, please take a look at the "AutoPilotController" demo app. It uses ClientEventButtons from the CsSimConnectUIComponents package. Each button has a ClientEvent field which is initialized from the name of the event, such as "ap_master" for the Master Autopilot switch. This event requires no parameter values, so triggering it is a simple call to Send().

            <apc:ClientEventButton Grid.Row="3" Grid.Column="0" Grid.ColumnSpan="2"
                                   Width="130" Height="20" Margin="0,5,0,0" Padding="5,0,5,0" HorizontalAlignment="Center" HorizontalContentAlignment="Stretch"
                                   Style="{StaticResource MaterialDesignRaisedAccentButton}"
                                   ClientEvent="ap_master">

The fancy textboxes capture the mouse wheel movements to send INC and DEC events (again no parameter) or the ENTER key. The last one sends an event with value.

            <apc:HeadingTextBox Grid.Row="4" Grid.Column="0"
                               Width="50" Height="14" Margin="0,5,0,0" Padding="0" HorizontalAlignment="Right"
                               x:Name="Heading" WheelUpEvent="heading_bug_inc" WheelDownEvent="heading_bug_dec" SetValueEvent="heading_bug_set"
                               NumDigits="3" Positive="True" AddTicks="False"
                               Style="{StaticResource MaterialDesignTextBox}" materialDesign:HintAssist.Hint="000" />

To create and use an event on itself, you would create a ClientEvent:

private readonly ClientEvent altHoldEvent = EventManager.GetEvent("ap_alt_hold");

And at the appropriate time call Send():

altHoldEvent.Send();

Bert

 

[brandonharwood14]

For an example of how to send events with CsSimConnect, please take a look at the "AutoPilotController" demo app. It uses ClientEventButtons from the CsSimConnectUIComponents package. Each button has a ClientEvent field which is initialized from the name of the event, such as "ap_master" for the Master Autopilot switch. This event requires no parameter values, so triggering it is a simple call to Send().

            <apc:ClientEventButton Grid.Row="3" Grid.Column="0" Grid.ColumnSpan="2"
                                   Width="130" Height="20" Margin="0,5,0,0" Padding="5,0,5,0" HorizontalAlignment="Center" HorizontalContentAlignment="Stretch"
                                   Style="{StaticResource MaterialDesignRaisedAccentButton}"
                                   ClientEvent="ap_master">

The fancy textboxes capture the mouse wheel movements to send INC and DEC events (again no parameter) or the ENTER key. The last one sends an event with value.

            <apc:HeadingTextBox Grid.Row="4" Grid.Column="0"
                               Width="50" Height="14" Margin="0,5,0,0" Padding="0" HorizontalAlignment="Right"
                               x:Name="Heading" WheelUpEvent="heading_bug_inc" WheelDownEvent="heading_bug_dec" SetValueEvent="heading_bug_set"
                               NumDigits="3" Positive="True" AddTicks="False"
                               Style="{StaticResource MaterialDesignTextBox}" materialDesign:HintAssist.Hint="000" />

To create and use an event on itself, you would create a ClientEvent:

private readonly ClientEvent altHoldEvent = EventManager.GetEvent("ap_alt_hold");

And at the appropriate time call Send():

altHoldEvent.Send();

Bert

thanks all seems really great!

forgive me as I may be completely missing something here but i open the AutoPilotController app in VS2019 and it comes up with an error saying the .NET SDK cannot be located and that i should check the GLOBAL.Json version matches the installed version...checked versions and all are good, also ive tried a lot of different solution apps and all come up with errors or they cant run cuz they cant find Simconnect.h which ive tried to manually add the location of but have been unsuccesful.

I believe all my troubles are because I havent worked out how to build the .dll using the commandline that you specify in your documentation.
Any pointers in doing that, which file to open to run and use the commandline of VS like you said?

 

[Bert Laverman]

Have you tried using the UI? I only added the README with the CLI instructions because someone told me he _only_ wanted CLI build instructions and would not accept pre-built ZIPs.

I'll do a refresh of the README and verify it works, and upload a ZIP with a release build of the current state. I may have to create a clean VM to verify what exactly needs to be installed. I also did a first check to see what would be needed to put an executable in the store, but I cannot register for that without a formal registration at the chamber of commerce.