My take here is, if MSFS team is fully committed to provide out of the box good interface to implement things, it is a good thing. It is win win situation for both, users and third party where by it reduces the amount of work needed which as result will benefit the users to get add-ones in faster rate and I think that is what MSFS wants to achieve. I do agree with you, it is kinda of bumpy ride for them but I am still sure, they will get right at some point. X-Plane got it right after some iterations and the same will be for MSFS.
I have to stress this, and this is the last time i’m doing it cause i think i’ve been pretty clear in all my posts: If a developer needs more than what the current system provides, this is not making things easier for them in any way. This is making it impossible for them. And there are developers who right now are struggling with the way Asobo chose to go about doing things, who would have had a much easier time if the system was more open for developers. And there are some developers who find it impossible to bring addons to FS2020 who have been possible in FSX, P3D, and X-Plane. This system is not any more beneficial for developers than what FSX could provide: those that want to focus on other aspects of the simulation can use the default flight model (like Carenado have been doing successfully for years and years). But those that need more no longer have the means of achieving more.
I am having a very hard time understanding how everyone thinks that allowing third party developers to use their own custom flight model in conjunction with Asobo developing the default flight model for those that want to use it is a worse state of affairs than denying third party developers the option.
Because those third parties leave their knowledge with them and don’t contribute upstream. If instead everyone works together on one flight model that makes everything possible and has everyone with a vested interest in its accuracy, everyone wins.
The alternative is the current FSX and P3D situation: the core components stagnate, folks just hack together proprietary solutions, and development expertise stays completely isolated in pockets that don’t speak with each other. And that doesn’t help the sim community at all.
Surely allowing or denying third party developers the option to use their own flight model, is a MICROSOFT decision, not an Asobo one ?
ie Whatever Microsoft decides in the BIG PICTURE of things, it up to their sub-contractors to do as directed.
Same goes for:
Opening the WEATHER up to 3rd party developers.
Opening up ATC to 3rd party developers.
Its really a case of if MSFS 2020 is going to be a simulation environment, with the basics put in place by Microsoft, and the finer details left to 3rd party developers, or if for some yet to be explained reason, they want to keep parts of that environment locked up for their own sole development and marketing.
And what’s in it for those developers? Will they be getting a share of the revenue because their knowhow makes it into the game? Or are they expected to give up their decades long knowledge for free? And besides, there are plenty of developers lining up to give Asobo their help who are not getting any response. How are they supposed to proceed, when their advice is not received and they are also not allowed to create work-arounds?
That last bit is demonstrably false. FSX and P3D have a working weather system built by third party developers. They have study level aircraft built by third party developers. They have all sorts of features like working caster tail wheels, working leading edge flaps, all built by third party developers. And they have a working internet multiplayer environment, through VATSIM and IVAO, built by third party developers. If anything, FSX and P3D show the true power of developers when allowed to express their creativity freely. Not only flight simulation history, but real world economics have shown us, free competition and unrestricted creativity will always lead to a better market for the consumer. If FSX and P3D adopted the same model that FS2020 is adopting, and would have closed developer access to the weather system and the flight model, the core codebase would have still stagnated, and now those sims would not be used by anyone.
I will not discuss here any further Asobo’s (or Microsoft’s) decision to close off the flight model or any other part of the sim to third party developers. I feel like i have said all i had to say on the subject and I feel like this is not the place to have such a discussion. If anyone wishes to continue discussing this with me, or with anyone else, please create an appropriate topic somewhere on the forum, or contact me privately. Thank you.
It seems like some developers have managed to override the flight model. The latest statement from Indiafoxtecho on their Facebook page indicates that it is totally possible to do so.
Indiafoxtecho: "Unknown to many users, it is possible in MSFS to write your own custom flight model (using C++) and override the MSFS flight model partially or completely (…and btw it is also possible to do that in most modern flight simulators).
We have starting experimenting with this in late December, and it was soon clear to us that we could try and build a proper helicopter. We have also involved experts in helicopter simulation in the development to create a “by-the-book” dynamic model.
We chose the Mini-500 (even if it is not a very popular model) for a number of reasons, but the main one was that we wanted to start with a very simple machine.
Also, we have decided not to share details on this project so far mostly because -a the moment- it is a research project."
“we will not allow you to override the flight model” is exactly what they said, which I assume means even if you find a way to override it (like what @Techy111 , Dan @BragTester70312 et al and Indiefoxecho are doing), Asobo under the command of Jorg could close the loophole anytime they feel like doing so.
Which creates this interesting situation:
If you buy a plane because of its realistic flight model and Asobo deliberately break that model and the developer tells you that it is not possible for them to fix it and they need to revert to the default, inferior, flight model… Are you entitled to a refund? Who’s going to pay it? The third party developer who is blocked from delivering a product? Or Asobo who are simply fixing what they consider to be a bug? Is it acceptable to tell someone that they now have to wait for an indefinite period of time until Asobo improve the default flight model to be as good as the custom one?
All very interesting questions, i think.
Very easy, Asobo sees that the flight model is being altered before the product hits the marketplace and is thus not allowed on there. That’s probably one of the reasons it all takes so long to get a product on there.
The multiple discussions about the flight model (code) of MSFS or any other Entertainment PC sim are beyond me, since many years now…
Especially that I work as software design lead in an aircraft manufacturer. No need to tell you that the software we develop and release for real aviation is not sold at 80$ (the average price of a PC Sim?).
As you know, professional, certified, high fidelity flight simulators can be summarized as follows:
1 software = 1 flight model
The sim comes with Software + Hardware + Control systems all calibrated to work together as intended
Obviously the price can be from thousands to million Dollars or Euros…
It’s obviously strange and far fetched to expect the accuracy I hear people complain about in PC entertainment flight sims.
A PC entertainment sim features a wide range of aircraft types, from the ultra light to the most sophisticated jet etc, that people install on a wild and wide range of PC systems + OS setups and use with a wide range of controller types and technology, coupled with a subjective or default calibration.
What I mention is obvious common sense, but does not seem to convince many out there.
So even the generic and broad PC Sims that have versions licensed for real world training, do no offer the high fidelity people dream or complain about here.
Keeping the flight model in house and improving and updating it constantly is the way to go and I agree with this approach. It will be hugely beneficial to developers who have a relatively small team or who don’t have the resources to completely hack the system to create their own flight systems and flight model. They want to give everyone an even and a very solid ground to stand on.
As i’m sure everyone knows, all flight sims to date (FS2020 included) have featured a default flight model. You have a cfg file that describes all the parameters needed to simulate the aircraft, you load it up in the sim, and it just works. But it has been possible to also use the sim as an environment into which you could plug in a flight model. So you can have “the generic and broad PC Sims” that you mentioned, but also “1 software = 1 flight model”. This is why we can have study level simulations of airplanes, down to the extreme ends of the flight envelope.
To be clear: We are not “dreaming” about this. We do not “complain” that we do not have this fidelity. We already have this fidelity in FSX and P3D. All we’re saying is that it would be nice to be able to have the same fidelity in FS2020.
MSFS, XP, P3D etc, are not and can not be a 1 software for 1 flight model. It’s everything in the engine that is coded exclusively for a specific type of aircraft.
These sims have a broad flight model system with obvious compromises and limitations. It can’t be specialized.
And still, even Level-D sims are not 100% accurate in terms of detailed and subtle flight modeling / envelope as far as those who know told me.
FSX or P3D fidelity? Well, I heard the same complaints I read here, for every sim I played with.
All sophisticated addons, people like to call “study level”, even if they are not, sometimes use custom code to override the main engine’s flight models. But they do not have a custom flight model architecture to override the main one. They were always done as workarounds.
When I discovered MSFS for the first time and I saw that we can toggle between the modern, legacy etc flight models, I thought it was made to host future custom flight models or even specific ones like those we could need for detailed Helicopter behaviors etc.
Yet, I think we have most probably the business factor that is involved. Asobo would need to deliver an SDK that let programmers code their flight dynamics engine with access to the core engine architecture? Programmers can tell…
Also, and as mentioned in this thread, the maintenance factor from Asobo’s side when it comes to the core engine interaction with these custom flight model systems would be on the wild side.
This is why, I take MSFS as is, for the price I paid for it, to have so much fun in such an immersive environment. I got a many addons that I am happy with, including the facny Aerosoft CRJ and I think I don’t need more than this for the purpose of this super fun sim published by the XBox Studio not CAE or similar companies…
To be honest, comparing professional simulators and MSFS makes absolutely no sense at all.
However, one does not need to dig very deep to find problems with the MSFS flight model in its current state:
Incorrect simulation of wing sweep: changing the wing sweep will change MAC position as follows: a positive sweep will move the MAC forward and conversely, completely changing the balance of the aircraft. There is no way to set a distinct and fixed MAC position and dimension for weight and balance purposes.
Incorrect simulation of leading edge flaps: they currently act as trailing edge flaps.
Absence of propeller drag when engine is failed, absence of propeller feathering simulation.
And the list goes on…:
It would be unreasonable to expect a 100% exact flight model for all the various planes that MSFS has to offer. But it doesn’t mean that there are not problems to be solved.
I’m currently investigating the default 747-8 and here is what I’ve discovered so far:
the drag problem associated with flaps beyond 5 is due to a wrong animation of the LE flaps. If you want to remember, when MSFS was released, the LE flaps were deployed incorrectly, following this sequence: UP, 1°, 5°, 10°, 20°, 25°, 30° when IRL they fully extend when flaps 1 are selected. In order to fix this problem, the devs have changed the values in the flight_model config file to 21° for all LE flaps settings. Unfortunately, this “fix” for the animation of the 3D model introduced the drag bug which sees full lift and drag applied from flaps 5 and beyond. At the moment, there is no difference in the flight model between flaps 5 and flaps 30 in the default 747-8. To fix the drag problem, just return the values back to 0, 1, 5, 10, 20, 25, 30 in the config file, with the animation returning to wrong as a drawback.
the fuselage length of the 3D model is the one of the 747-400, not of a 747-8. It is missing 6 meters in length. I discovered that while trying to solve the mass and balance problems. I went to change the Datum reference to the one of the TCDS, trying to position the MAC correctly when I noticed that the fuselage orange box was longer than the 3D model. In the config file, the length was correct, 250 ft. By intuition, I changed it to the 747-400 fuselage length of 232 ft, and it now matches the 3D model.
to be continued?
I understand if the devs want to keep the control over the flight model. But they need to improve it and fix it so that developers don’t feel the need to use an external one.
I can only speak as a customer. I take the flght model for granted (I ask questions here, I’m not a pilot) and I am quite satisfied with the scenery side of the SDK after update 1.15.8. But I also acknowledge there are issues. Why do I have to build my scenery 2x before it works ? Why are there no error messages ? But that is Zendesk-level complaint, not questions for a session like this… I have the impression Asobo/MS regard these question sessions as a pony parade, mainly presenting good news to partners, clients and SDK hobbyists. Very familiar… I completely missed out on these feedback sessions for that reason, because I regard MSFS as hobby, not work. In RL I am often on the other side of the table, hoping to convince the customer of the quality and value of my work. I don’;t need to be convinced about MSFS, because I think Asobo/MS has done a fabulous job.
WASM is sandbox and very fast. The only thing that cannot be done wiith WASM is DirectX. I wonder if it is really needed for third party developers to work at the shader level…
Sofar I spent quite some money on aircraft and scenery. I rather would not buy or download extensions that include DLL files. I even hesitate when I find an executable for installation in a third party package. Especially when it is freeware. It is not that I distrust the developer… But I know what bugs in DLLs can do. Any developer can leave a bug somewhere. When I run MSFS, I’d like to have some guarantee things are not messed up or unsafe to run. For the game we have a 10 year support contract. Are third party developers going to adhere to the same standards ?
… or multithreading… or accessing external files like navdata databases, flight plans, etc… or communicating with external applications like the Garmin Trainer in order to deliver a 1:1 GPS unit simulation…
So don’t. No one says you have to.
The over two decade history of this approach indicates that this is a non-issue. What’s more, we have companies presently that have been providing support for their addons for well over a decade.
You’re cherry-picking sentences, please don’t do that…
Use Simconnect and an external executable. You can do what the API/protocol allows you to do. The CPP/WASM gauge is currently only for display in the game. WASM is perfect for that. Apparently Asobo/MS wants to keep the low level access for themselves in this stage. Can’t blame them for that. Suppose they want to update some part… incompatible WASM will raise an exception (a single exception) and the simulator will just show a back gauge in your cockpit. Unmanaged code in a DLL could cause CTD’s or seriously impact your installation or harddisk content, when something goes wrong. Especially when you give it file access.
Ok so you expect me to rar the archive, use flat files list and sort it on file extension to check for DLL’s and executables ? For me that may work fine (and I do that !) but I think 90% of the MSFS customers don’t have any idea what rar files and flat files lists are. Let alone they are aware of the difference between sandboxing and unmanaged code.
Sure. There will neverever be something wrong with unmanaged external machine level 64-bit code, because some vendors have allowed it for 20 years… I don’t buy your argument, Cristineagu…