MSFS C++ Flight Model Override

[MikeNolan]

Hey Guys,

I wish to override the MSFS Flight Model with my own FM written in C++, ideally by simply supplying my own forces & moments & leaving the sim to calculate resulting velocity/accel/position. Can this be done?

I see no Force/Moment/Aero Simvars, only velocity/accel simvars that are writeable. Is overriding these via Simconnect the 'correct' way to implement a custom FM?

Thanks

 

[tml]

My guess is that yes, and that this is how the 3rd-party helicopters work. But that is just a guess, anybody is free to correct me.

 

[tml]

Would be lovely if somebody would implement a fully open-source sample aircraft to exhibit how to create an aircraft from scratch, using Blender for the 3D modelling, and also using C++ code for various interesting additional functionality. (Not much time needs to be spent on making the 3D model look like any existing aircraft, that is irrelevant in this context. It could be the proverbial flying brick. As long as it demonstrates how to use the MSFS materials properly, some interesting animations, etc.)

The project would have .cfg and .flt files that would not have been allowed to be re-written by the Aircraft Editor, and they would not be just slightly edited copies of files from some existing Asobo sample aircraft either. No, they would be beautifully formatted with long comments. I mean like this:

;         0: None, 1: wheel, 2: scrape, 3: skid, 4: float, 5: water rudder)
;          !    Long, lat, vert w.r.t reference datum (FT)
;          !    !                Impact damage threshold (FT/MIN)
;          !    !                !  Brake map (wheels) (0: none, 1: left, 2: right)
;          !    !                !  !  Wheel radius (wheels) (FT)
;          !    !                !  !  !    Steer angle (wheels) (DEG, -90..90)
;          !    !                !  !  !    !  Static compression constant (FT) (0 if rigid)
;          !    !                !  !  !    !  !    Max static compression ratio (FLOAT)
;          !    !                !  !  !    !  !    !    Damping ratio / water rudder effectiveness (0: undamped, 1: critically damped),
;          !    !                !  !  !    !  !    !    1 = normal)
;          !    !                !  !  !    !  !    !    !    Extension time (S)
;          !    !                !  !  !    !  !    !    !    !  Retraction time (S)
;          !    !                !  !  !    !  !    !    !    !  !  Sound type (0: center gear, 1: auxiliary gear, 2: left gear, 3: right gear,
;          !    !                !  !  !    !  !    !    !    !  !  4: fuselage scrape, 5: left wing scrape, 6: right wing scrape,
;          !    !                !  !  !    !  !    !    !    !  !  7: aux1 scrape, 8: aux2 scrape, 9: tail scrape)
;          !    !                !  !  !    !  !    !    !    !  !  !  Airspeed limit for retraction (KIAS)
;          !    !                !  !  !    !  !    !    !    !  !  !  !  Airspeed that gear gets damage at (KIAS)
;          !    !                !  !  !    !  !    !    !    !  !  !  !  !  Exponential coefficient, whatever that is
;          !    !                !  !  !    !  !    !    !    !  !  !  !  !  !
; Floats   !    !                !  !  !    !  !    !    !    !  !  !  !  !  !
point.0  = 4,  25,   4, -2,  15000, 0, 0,   0, 0.3, 2.5, 0.4, 0, 0, 4, 0, 0, 1
point.1  = 4,  25,  -4, -2,  15000, 0, 0,   0, 0.3, 2.5, 0.4, 0, 0, 4, 0, 0, 1
point.2  = 4, -25,   4, -2,  15000, 0, 0,   0, 0.3, 2.5, 0.4, 0, 0, 4, 0, 0, 1
point.3  = 4, -25,  -4, -2,  15000, 0, 0,   0, 0.3, 2.5, 0.4, 0, 0, 4, 0, 0, 1

; Water rudder
point.4  = 5, -42,   0, -2,  15000, 0, 0,   0, 0,   1,   1,   0, 0, 0, 0, 0, 1

; Wheels (for testing)
point.5  = 1,  34,   0, -10, 15000, 0, 1,  45, 0,   1,   1,   5, 5, 0, 0, 0, 1
point.6  = 1, -11, -18, -10, 15000, 1, 1,   0, 0,   1,   1,   5, 5, 2, 0, 0, 1
point.7  = 1,  11,  18, -10, 15000, 2, 1,   0, 0,   1,   1,   5, 5, 3, 0, 0, 1

; Scrape points
point.8  = 2, -80,   0, 15,   1000, 0, 0,   0, 0,   0,   0,   0, 0, 4, 0, 0, 1
point.9  = 2,  -1, -83, 15,   1000, 0, 0,   0, 0,   0,   0,   0, 0, 5, 0, 0, 1
point.10 = 2,  -1,  83, 15,   1000, 0, 0,   0, 0,   0,   0,   0, 0, 6, 0, 0, 1

(That is an excerpt from a flight_model.cfg I am working on.)

I might even do it myself.

No, the kind of pseudo open source that just throws the end result package into GitHub without for instance including the original .blend file or the top-level project .xml file just doesn't cut it. I want a full buildable project, with PackageDefinitions and PackageSources directory trees.

(Needless to say, "freeware" "mods" that just modify existing Asobo aircraft are not that exciting to me.)

 

[tml]

Would be lovely if somebody would implement a fully open-source sample aircraft to exhibit how to create an aircraft from scratch, using Blender for the 3D modelling, and also using C++ code for various interesting additional functionality.

I might even do it myself.

And I did. After a few days of enjoyable hacking, https://github.com/tml1024/flying-brick . As the saying goes, patches welcome.

 

[KAI31]

 

[tml]

Have you managed to build the Wasm modules in the MSFS SDK Samples? Are you possibly trying to build it as Win32 code, not as a Wasm module?

 

[MikeNolan]

And I did. After a few days of enjoyable hacking, https://github.com/tml1024/flying-brick . As the saying goes, patches welcome.

Wow, astounding work. Thanks for sharing!!

I also had some build errors

Build started...
1>------ Build started: Project: FlyingBrick, Configuration: Debug MSFS ------
1>FlyingBrick.cpp
1>FlyingBrick.vcxproj -> B:\Libraries\Downloads\flying-brick-main\Project\Packages\tangomikelima-aircraft-flying-brick\Modules\FlyingBrick.wasm
1>'MSFSLayoutGenerator' is not recognized as an internal or external command,
1>operable program or batch file.
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(155,5): error MSB3073: The command "@echo on
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(155,5): error MSB3073: MSFSLayoutGenerator B:\Libraries\Downloads\flying-brick-main\Project\Packages\tangomikelima-aircraft-flying-brick\Modules\..\layout.json
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(155,5): error MSB3073: :VCEnd" exited with code 9009.
1>Done building project "FlyingBrick.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

I've successfully built WASM modules before; I note that the layout.json referenced in the error isn't present in my files & neither is the command recognized? Any thoughts would I could be missing here?

From your testing, do you know if it's possible to set Accel/Velocity & let MSFS do it's own calculations for position?

 

[tml]

Wow, astounding work. Thanks for sharing!!

I also had some build errors

Yeah, I need to add a mention to the README.md that it needs the MSFSLayoutGenerator executable, from https://github.com/HughesMDflyer4/MSFSLayoutGenerator

Possibly there is some more correct way to get the standalone Wasm module to be included in the package, but I haven't figured out how yet. For now the VS project just plops it into the modules directory and uses MSFSLayoutGenerator to update the layout.json.

I also experimented with having this as a panel Wasm module, but then my SimConnect callback function wasn't called. But maybe I did something wrong.

From your testing, do you know if it's possible to set Accel/Velocity & let MSFS do it's own calculations for position?

Nope. Even if you set the VELOCITY WORLD X, Y, Z variables the PLANE LATITUDE and PLANE LONGITUDE stay the same.

Sadly none of this seems to be documented really, you just have to experiment.

--tml

 

[MikeNolan]

Yeah, I need to add a mention to the README.md that it needs the MSFSLayoutGenerator executable, from https://github.com/HughesMDflyer4/MSFSLayoutGenerator

That'd be the trick - thanks.

Nope. Even if you set the VELOCITY WORLD X, Y, Z variables the PLANE LATITUDE and PLANE LONGITUDE stay the same.

Sadly none of this seems to be documented really, you just have to experiment.

That's a shame; increases the workload a decent amount - thanks for the info. Agreed that it is very frustrating the lack of documentation but projects like these are really helpful.

I'm not too sure about the panel WASM module useage in this case but from my experiments I used the SimConnect API inside the gauge callback cases (ie Pre_install, Pre_update etc) rather than a Simconnect Callback Func which seemed to work

Perhaps moving forward you could annotate areas where force calculations etc should be done (although it's already pretty clear already tbh) & continue the template setup you've got going. Perhaps even a simple function/model to convert global forces/moments to position, velocity & acceleration (ie a basic 6DOF EOM model) would make it even more accessible? I'd be happy to contribute where possible; although I fear my minimal experience with SimConnect might be more of a nuisance than helpful

Fantastic stuff & again thanks for sharing

 

[ronh]

Possibly there is some more correct way to get the standalone Wasm module to be included in the package, but I haven't figured out how yet. For now the VS project just plops it into the modules directory and uses MSFSLayoutGenerator to update the layout.json.

I think you can just a a "Copy" asset group into package definitions - similar to the way Working Title adds their stuff

<AssetGroup Name="HtmlGauges">
<Type>Copy</Type>
<Flags>
<FSXCompatibility>false</FSXCompatibility>
</Flags>
<AssetDir>PackageSources\html_ui\Pages\VCockpit\</AssetDir>
<OutputDir>html_ui\Pages\VCockpit\</OutputDir>
</AssetGroup>


so do this?

<AssetGroup Name="FDModule">
<Type>Copy</Type>
<Flags>
<FSXCompatibility>false</FSXCompatibility>
</Flags>
<AssetDir>PackageSources\Modules\FlyingBrick\FlyingBrick\x64\Release</AssetDir>
<OutputDir>Modules\FlyingBrick\</OutputDir>
</AssetGroup>

But I don't see how you have referenced the module in your git example. Is it a hidden/fake panel gauge?

 

[tml]

I don't see how you have referenced the module in your git example. Is it a hidden/fake panel gauge?

It isn't referenced by any .cfg or other file as it is a "standalone" Wasm module, not a panel one. Just having the .wasm file in a top-level "modules" folder in the package is enough for MSFS to load it and call the module_init() function in it. But it is a bit unclear to me whether that actually is the right way to add code that is after all specific to the one aircraft. Possibly (will check tomorrow) the code is now run for *all* aircrafts you fly, not just the FlyingBrick one. Which obviously is not what I intended. I did try to make it a panel module instead (see https://github.com/tml1024/flying-brick/commit/e4016edc530bd15ec39ae1c4c32f9a6b9afd9155 ), but as the comment says, then I couldn't get the SimConnect event pump to run. But I might have missed something trivial.

 

[KAI31]

Have you managed to build the Wasm modules in the MSFS SDK Samples? Are you possibly trying to build it as Win32 code, not as a Wasm module?

Yes, modules, gauges and applications are assembled and work. This assembly does not compile, errors.

 

[tml]

Yes, modules, gauges and applications are assembled and work. This assembly does not compile, errors.

Well the errors in your screenshots are quite mysterious to me. It seems as if you are using the wrong VS version or an old SDK version or something.

 

[KAI31]

SDK 0.12.0.0

 

[ronh]

I get errors also - used both VS 2017 and 2019, I see you have some properties that are not the same as the ones in the sample wasm code. but will review later - probably me. I can compile the latest wasm sample code.

 

[tml]

Possibly (will check tomorrow) the code is now run for *all* aircrafts you fly, not just the FlyingBrick one. Which obviously is not what I intended

Yep, that is what happens. So I really need to turn this into a panel Wasm module instead. Working on that. I know it must be possible, but I don't know how yet.

 

[tml]

I really need to turn this into a panel Wasm module instead

Done now.

 

[ronh]

Had to create my own wasm MSFS project in VS 2019, then copied the .h and .cpp text into my project, now compiles fine.

 

[tml]

Had to create my own wasm MSFS project in VS 2019, then copied the .h and .cpp text into my project, now compiles fine

OK. It would be great if you could suggest a patch to the VS project files, in case it is something I can fix.

 

[ronh]

ok just noticed you have a new version - panel. I downloaded it and it compiles fine in VS 2019 and places the wasm in the panel folder. So I did not need to create my own.