IcemanFBW

This is currently a planned feature, not yet completed, and would be done with the aid of an external process (like our external MCDU). There is no way to accomplish this completely in-sim, as Matt mentioned.

Can't wait to get this bird in the air - congrats to the folks over at Fenix! It's great to see the hard work from all these developers finally come to fruition - it's going to help MSFS grow even more as a platform and we can't wait to see what the future holds.

Can you give this a shot and let us know if it resolves the issue? https://docs.flybywiresim.com/fbw-a32nx/support/reported-issues/#autopilot-fadec-electrical-systems-not-working-as-intended-utf8-issue

From what I can gather, it seems like a binding contract with Meteoblue is the reason for not allowing weather customization - quite a shame in my opinion to lock out customization while at the same time not offering something of a similar caliber. The lack of ability for third party developers to customize the flight model is also a long-standing issue we've brought up time after time. In my opinion, it seems as though management at MS/Asobo is mainly focused on prioritizing functionality for paid DLC/expansions rather than missing core sim features.

This is not how much the servers cost to operate - the budget is how much money OpenCollective projects us to receive in a year based on current balance and recurring donations. I would say the figure is closer to $15,000 USD at the moment, the main expense being CDN costs.

There is no VNAV or custom FMS v2.0 in the experimental version as of right now, only other various improvements including constraint logic and LNAV improvements.

We plan to add an option for a PF/PM callouts - e.g. "positive rate, gear up", etc in the future. But I would say an automated copilot is out of the scope of our development, especially given how automated much of the workload is in an Airbus, compared to three crew older aircraft such as the DC-6.

We're in the process of integrating it with the flight model and fly-by-wire system. No ETA, but our initial tests with it are looking spectactular.

See if this helps:https://docs.flybywiresim.com/fbw-a32nx/support/reported-issues/#autopilot-fadec-electrical-systems-not-working-as-intended-utf8-issue If it's a problem with the default A320, it may be something else altogether. Can you post a screenshot or video of the issue?

Keep in mind that the T16000 has an unreliable twist axis after a couple months of use - I've had it happen to me personally with both the base T16000 and TCA sidestick, ended up getting a Gladiator NXT instead.

I never claimed I knew everything PMDG was trying to do. I did not state the problem did not exist - I simply said I was certain that an SDK limitation was not at fault (which is true, as confirmed in the Q&A stream). FBW is developing a complex airliner that makes use of WASM and C++ (you can take a look yourself), and had thoroughly investigated the possibility of bringing the aircraft to XBOX but realized it would not work, mainly due to licensing and workload concerns. I hope this clears up any misunderstandings - have a wonderful day!

Out of curiosity, is your internal graphics library built on top of the existing low-level graphics API provided by MSFS? I was looking into the possibility of experimenting with NanoVG in some displays (currently using HTML gauges) to improve performance, but from what you're saying it doesn't look too promising and it might be worth making our own, like you guys are doing.

I'm going to preface this with a disclaimer: whatever opinions I have expressed in this thread are those of my own, not necessarily the FBW team. The SDK is synonymous with the platform in the context of MSFS - the SDK is the developer-side interface to the platform. If the sim (platform) is lacking functionality or implements functionality incorrectly, then the API's available through the SDK will also lack that correct functionality. IBM defines this relationship as follows: "SDK stands for software development kit. Also known as a devkit, the SDK is a set of software-building tools for a specific platform." [1]. If something isn't available on the platform, then it won't be available in the SDK. I see no reason to comment on this issue any further - I simply stated the truth, but Randazzo felt the need to resort to straw man [2] and ad hominem [3] fallacies in his frankly unprofessional response. I wish the PMDG team the best of luck in their development, and look forward to flying their aircraft. [1]: https://www.ibm.com/cloud/blog/sdk-vs-api [2]: https://en.wikipedia.org/wiki/Straw_man [3]: https://en.wikipedia.org/wiki/Ad_hominem

They already are using WASM. That's the only way to compile a C++ gauge in MSFS (the alternative being an HTML gauge, which doesn't obscure the source code - not ideal for payware). It replaced the old way of compiling into a .DLL in P3D/FSX, which was also unsafer. However, this doesn't affect how the code is written at all, only how it's built/compiled into an executable format once it's ready to be put in the sim. It's as simple as specifying some different command line options, as you can see in our code: https://github.com/flybywiresim/a32nx/blob/master/src/fbw/build.sh#L26 https://github.com/flybywiresim/a32nx/blob/master/src/fbw/build.sh#L61 https://github.com/flybywiresim/a32nx/blob/master/src/fbw/build.sh#L114

I can comment because I know the SDK inside and out, specific to aircraft systems and avionics development. There are simply no showstoppers from the SDK side aside from a weather API (which we have already requested from Asobo and is expected to come out this year). Displays: there are already TWO functioning API's available for drawing displays from WASM: GDI+ and low-level. This is the same technology that Aerosoft used to draw their CRJ displays. There are no limitations here whatsoever - anything you imagine can be drawn, animated, updated, etc. https://docs.flightsimulator.com/html/index.htm#t=Programming_Tools%2FWASM%2FGDI%2B.htm https://docs.flightsimulator.com/html/index.htm#t=Programming_Tools%2FWASM%2FLow_Level_API%2FLow_Level_API.htm Simulation/environment data: As I said, everything is available via the SimConnect API for both reading and writing data from the sim, with the exception of granular weather data for drawing custom weather radars. The same way it was in P3D and FSX. For that, you can either choose to use the default, uncustomizable weather radar (what WT is using for NEXRAD in the NXi), or wait for a proper API which should be coming shortly (like the CRJ). https://docs.flightsimulator.com/html/index.htm#t=Programming_Tools%2FSimVars%2FSimulation_Variables.htm https://docs.flightsimulator.com/html/index.htm#t=Programming_Tools%2FWASM%2FGauge_API%2FGauge_API.htm Flight model: allows for full customization based on aircraft geometry and aerodynamic coefficients using the blade element model that X-Plane uses. Fully documented here and works perfectly fine for anyone with a proper understanding of 6DOF flight model physics. There are a couple improvements that could be made (such as further customization of speedbrake/spoilers and ground friction coefficients), but no showstoppers. Worst case scenario, you can make an external flight model like Fenix and just communicate aircraft position back to the sim via the SimConnect API mentioned above. https://docs.flightsimulator.com/html/index.htm#t=Content_Configuration%2FSimObjects%2FAircraft_SimO%2FFlight_Model_Definition.htm https://docs.flightsimulator.com/html/index.htm#t=Additional_Information%2FFlight_Model_Physics.htm Engine model: very similar to the engine model parameters that were used in P3D and FSX. However, this is a non-issue as any decent-fidelity aircraft is just overwriting the basic built-in engine model with a custom one using SimConnect. This is what we are doing at FBW: https://github.com/flybywiresim/a32nx/tree/master/src/fadec/src https://docs.flightsimulator.com/html/index.htm#t=Content_Configuration%2FSimObjects%2FAircraft_SimO%2FEngine_Config_Definition.htm Any other systems (hydraulic, electric, pneumatic, air conditioning, etc.) have zero reliance on sim API's aside from fetching environmental/simulation data via SimConnect. I can describe this in further detail in another comment if you wish but I'm sure you get the point now. I have no ulterior motives or anything to gain from speaking my mind here - I contribute to FBW in my free time, not for a paycheck. I just want the community to know the truth and read another perspective here. Anyone who sells a payware aircraft on the other hand, has an obligation to sell as many copies as possible to recoup investments and increase profits, so they naturally have a motive to maintain a good public image of themselves, even if it means deflecting blame onto others in some cases.