MattNischan

We're the folks at WT. The GPS simulation that exists presently in the WT avionics is one of the most advanced (if not the most advanced) GPS simulations available for a consumer flight simulator. It uses NASA orbital ephemeris data along with actual orbital mechanics solutions to place all of the real GPS satellites currently in orbit into their real 3D positions in space at the current time, and correlates those locations into an actual sight picture for the GPS receiver of the currently viewable satellite constellation. GPS signal strength based on angular horizon distance is simulated and each satellite is tracked separately by the receiver up to the number of available receiver channels. In addition, the system is loaded with the geostationary positions of the regional SBAS satellites (WAAS, EGNOS, GAGAN, and MSAS) as well as the coverage areas of the ground portions of those systems. As such, it also computes your SBAS availability based on the geostationary SBAS constellation that may be visible from your ground location and your ground service coverage area. All of these satellites are represented within the system and on any relevant displays with their real world satellite IDs. Additional simulated features include individually tracked satellite solution time, system solution figures of merit (vertical and horizontal), almanac downloads, and system solution status. As can happen in systems of this complexity, occasionally a bug or two can arise. In SU14, there is a bug where satellites are not re-acquired over long time ranges and can be forgotten or failed to be rediscovered by the receiver. This only affects longer flights, generally, and is fixed in SU15. -Matt

If you are on SU14, this bug with the WT avionics satellite simulation (it's part of the avionics and not part of the sim) gradually losing satellites is fixed in SU15.

I don't believe this is a limitation, no. I have lots of axis and button bindings but mostly still use the VC, especially in testing. There is nothing in the sim code that knows the difference between a button being pressed in the VC versus being pressed in hardware, they both trigger the same binding event. Have you tried with an empty Community folder? This is an additional wrinkle that wasn't mentioned in the original post. It's possible that there is a conflict with some third party software here or that the binding being used is not correct. We only can only say how it should work when using the official sim spoiler axis bindings, which are supported.

They certainly should be. As per the real aircraft, spoilers will deploy for RTO or in case or forgetting to be armed on landing when two of the engines enter the reverse range. Spoilers are driven up when those two engines enter reverse, and likewise should be driven down when throttles are advanced towards the takeoff range (to prevent accidentally taking off with spoilers up). As for the spoiler axis, both the 787 and 747 in the sim use the same underlying spoiler system, and are not hardcoded to reverse thrust. I just tried the spoiler axis (with an empty community folder and the default livery) and am unable to reproduce the issue; the spoiler lever moves throughout the range and can be clicked into the arm position via the axis. I would suspect some kind of mod or livery conflict.

The reason, in actuality, is just due to how GPUs work. GPUs don't actually support anything other than rectangular projections. A rectangular projection will always have distortion near the edges, which becomes greater and greater the wider the horizontal FOV. From a mathematical perspective, rasterizing triangles requires straight lines for any level of acceptable performance. Any other kind of projection makes lines of a triangle not straight on the projection. All the other types of projections you might see, for example, in racing sims, are post-processing shader fakery, where the rectangular projection is set a good deal wider than the screen itself, then a post-processing step pulls in the edges, or where the scene is rendered multiple times from a few rectangular projection camera angles, and then stitched together in a post-process step. Either of these techniques is reasonably performance heavy, but in a racing sim with a lot more limited geometry, much more limited draw distances, no stuff like volumetric clouds etc, is more easily within the performance budget.

There are actually scenarios on the Garmins where this is the correct behavior. Generally, the units will do this if loading the approach would change your current flight guidance. In other words, if the leg you're currently on would be replaced by a different leg, the unit will instead keep the destination in the enroute segment and put the approach after that. This is to avoid having the autopilot swing in an unexpected direction while following GPS guidance, which could potentially be dangerous if the pilot isn't expecting that. If the units are doing that outside of this case, then I'm not totally sure. It's hard for me to tell from the descriptions what the order of operations are here. But just wanted to bring up that FYI in case folks were thinking the units should never do that under any circumstances, which is not the case.

Not necessarily here. The performance data for the airframe and the flight model itself must be properly filled in by the airframe developer. If the various Cd values are not correct in the performance data, or they are indeed matching the FM but the FM is too slippery or the idle thrust is too high, the computer will think it needs to start slowing to the next speed restriction far too far in advance, because technically it does need to. There's a lot to it, as the computer is running an integral simulation of the whole flight using the real aerodynamic and engine model data to produce a speed trend and path solution.

Updating the SDK will have no effect on the sim. Any positive results being seen are just CTD luck of the draw. No sim files, code referenced by the sim, or code referenced by installed third party products are changed. Downloading the SDK simply downloads the documentation, samples, and reference code headers and libraries used by developers at development time. Once the products are packaged, they are shipped with their version of these references. I believe both are affected (most planes with reverse are).

I'm going to have to defer to the experts, I'm afraid. I may be mistaken, so best to wait for an answer on the official forums.

You need to also configure the G3X in panel.xml. Docs here: https://microsoft.github.io/msfs-avionics-mirror/docs/g3xtouch/panel-xml-tag-documentation#autopilot

By aircraft configuration, I was referring to the total set of CFG files that make up the aircraft. I'm not sure which one these are in, specifically.

Well, we do, and that was part of the problem. The satellite simulation, which uses orbital mechanics to place satellites in real positions in space, was slowly forgetting about satellites over very very long time frames. So eventually you would not have enough satellites to get a position, and thus the LOI message. Now the system is no longer forgetting about satellites, and the position solution is resolved just fine. 🙂

They definitely are included and working. I would try with an empty community folder, it's possible something is overwriting some wiring.

The new ground handling model is opt-in for developers and must be enabled and tuned in the aircraft CFG files, in order to keep backwards compatibility. Out of those aircraft, only the 172 has received these changes. The other aircraft are still using the previous model.

Generally, a link to the docs for the beta SDK are posted within a few days on https://devsupport.flightsimulator.com/

This system is optional for developers, not for end users. If this system is enabled in the aircraft CFG files (as it is for the 172), then it will be used in-sim and no further user action is required.

The item you're referring to is this one in the changelog and is in the beta: We were not involved in any other AI traffic changes so I can't really comment.

I wasn't involved there, so unfortunately I don't have any information about any of those features. Probably a better question for the official forums.

The G3X Touch, on its own, is a VFR only device (as in real life). Only if the plane includes a compatible external navigator (something like a GNS or GTN) can the unit then display the IFR guidance from the external navigators. On release, the WT GNS430W and GNS530W are compatible, which means aircraft that include both a G3X and a GNS can have IFR capabilities, if the aircraft developer has used the new panel.xml options to correctly point the units at each other to communicate. Third party navigators can also be made compatible by using the MSFS Avionics Framework to synchronize the numerous data points required between the units. We will be releasing documentation and framework packages that third party developers can use to do this during the SU15 beta. Also as in real life, though, a great deal is shared between the units, so there is definitely some developer work required for the third party navigators.

The Comanche uses an external flight model coded in AccuSim and thus the sim ground modeling is bypassed.

Autothrottle, logic, and control loops are implemented entirely aircraft-side with all G3000/5000 aircraft. As a result, sim updates would not affect any change in these systems.

I can't vouch for the Horizon, but I'm unable to reproduce the wrong trim values in the 787-10, at least. Those loads and CGs produce 4.75 and 7.25, respectively, which match the FCOM.

This is how the real PC-12 is, as well. The aircraft automatically has a bit of rudder cross-control with ailerons, to make turns more coordinated without extra pilot input. I don't think this has anything to do with the realism on either platform (although the MSFS flight model is light years ahead of the FSX one). Rudder and aileron cross connect is a developer choice: it requires custom code to drive the sim to do that on any of the platforms. So it's possible no previous developer decided to implement that feature of the real plane (or perhaps were unaware of it).

This is not really the case. FSR3 comes with a bunch of different requirements than FSR2, including a totally different async swapchain implementation, the necessity to integrate the frame generation (not even present in FSR2), and a whole new requirement to split UI into a different rendering path entirely. Definitely will probably take a good amount of doing, if I had to guess, based on the FSR upgrade docs and presentation. Keep in mind that in software development land big features like this can easily take even an experienced engine programmer a few weeks to a month+ (especially to ensure the render path changes haven't broken anything unrelated), the SU15 beta starts in a few weeks, and code for big features should be well out of dev and in internal testing a good amount of time before beta.

No possibility, no. The way the system upon which these instruments is built in MSFS (CoherentGT made by a company called Coherent), this is not technologically possible.