Better Support for SimConnect_FlightPlanLoad

Official Microsoft Flight Simulator Wishlist
,
1

Several third party applications encourage users to play multiple legs in a single session, preferably without returning to main menu. Programming the flight computer in game is a chore. It would be nice if third party tools could load a flight plan directly into the FMS. SimConnect provides an API for this, but it does not work as expected.

I have been trying some naive stuff using Python-SimConnect with MSFS2020 1.9.5.0

sm = SimConnect()
print(sm.load_flight_plan("path to .pln"))
sleep(5)
sm.exit()
quit()

I’m testing with the MSFS2020 1.9.5.0 Cessna 172 G1000.

I have found a few interesting things.

  1. If I load up a plane with no flight plan, and run this code, everything populates into the G1000 and everything is happy.
  2. If I load a flight plan, and then attempt to load a new flight plan over the top, the CDI/PFD updates accordingly, but not the FPL in the G1000. The old waypoints remain, but none are shown as active.

In situation (2) if I delete the flight plan, I can load up a new one but the same issue persists - no waypoints displayed, no active leg.

Now, if I reload the aircraft (using developer mode), whatever the last plan I called with sm.load_flight_plan appears correctly.

2

I’d like to also offer the following suggestion:

Please pair any SDK function which is expecting to be loading a file on the drive, with the equivalent function loading the same data from memory.

In effect, any file loading function in the SDK is in turn loading the content of the file into memory first (I doubt there is any such function loading the file line by line). And only when in memory, which can be either explicit (alloc memory, load content) or implicit (let the underlying file handle buffering the file content), there is a parser code interpreting the content and calling other functions depending on the content accordingly.

As such, any file loading function could easily be paired with the same function loading the same kind of data as raw bytes from memory.

There are multiple advantages:

  • You don’t break the existing file loading SDK function.
  • You open creativity to add-ons which can use these functions in an ‘update’ loop without resorting to using any file in the process.

As a matter of fact, there is no low level flight planning SDK functions but there is a macro level load-it-all function. This function, SimConnect LoadFlightPlan, if also being made available with the following arguments: (address, size) would be loading the same raw bytes as the ones which would be found in a file otherwise. This could be used by add-ons to regularly update the flight plan programmatically as a whole, as-if add-ons would have access to lower level flight planning functions.

In turn, I’d suggest any single SDK function loading anything from file should also be paired with the same function loading the same raw data but from raw memory bytes (address, size). This concerns flight plans, weather, and any other one loading files.

PS: to some extent, there is no need for any file loading SDK function because any program calling these functions should be capable of loading the file bytes in memory themselves as well and in turn, only functions loading from memory buffer are necessary. I understand this opens up a point of failure should the buffer size passed to the function is not correct, and this leads to buffer overrun exploits. However, this is not SDK fault but 3rd party add-on fault only, pretty much the same way wrongly formatted file content could lead to other faults in the simulator internal parsers. In the end, 3rd party add-ons developers know what they are doing and any crashed induced by such wrongly set buffer size when calling the function is blaming the 3rd party only.

2 Likes