Yes, but the marketplace is not the only way to get mods into the sim… You can simply copy them in the community folder…
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 never ever 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…
I’m not cherry picking sentences. I am telling you exactly what i’m replying to. A blob of a response aimed at another blob of text is hard to keep track of.
What if i’m making a GPS unit? People working on the widely used GPS units have already said that they have flaky access to the internal FS navdata, and that they cannot use the Navigraph database cause they cannot access files outside of the sandbox. They have also expressed difficulty with flight plans, since you cannot simply save a flight plan to a folder and load it up. Then you have the GPS units based on Garmin trainers which aren’t technically possible because of these limitations.
There are a lot of gauges that need to both display data and access the file system.
True. We can’t blame them for that. It is their platform and we made a choice to buy into it. Fair enough. But we do get to suggest better alternatives. They are not contractually obligated in any way to take advice from us, so i do appreciate it when they do.
This is wildly exaggerated. You are assuming every single dll addon is malicious or incredibly badly written. This has never been a problem historically.
No. I would expect you to install addons from the marketplace. And if you’re currently installing addons from shady sources that don’t verify the validity of files or don’t have a place for users to report problems so you can see if the addon is going to work, i’d be more worried about malicious software in the archives themselves than for badly written code.
- So they should do the same thing they’re doing with everything else on the internet: use trusted sources.
- Like i said, this has not been an issue in the past two decades.
A proven track record is much more valid than bringing up issues that have never existed. The internet is filled with all sorts of malicious software. Yet somehow people manage to steer clear of it just fine, by using trusted sources and antivirus software. This isn’t something particular to flight simulation. In fact, flight simulation makes this harder. Having malicious code run inside FSX or P3D that does bad things is a much harder thing to do than simply packing malicious code straight into the archive.
I could proceed this debate, Cristi… but I’m gonna take a flight, this is my free day. Meanwhile I suggest to Google on FSX and P3D issues with DLL’s, before you state there is a “proven track record” and issues cannot happen. FSX opened up indeed, P3D is a modular system that needs DLL’s, but it has professional customers prepared to pay tenfold the amount we pay now. MSFS is not Windows, or .NET general and documented platform. It is an application program. You will (probably never) be allowed to run threads, that is code running in parallel. The risk of crashes in-flight is simply too big. It may one day become appropriate to open files via WASM, they can switch that on. As well as requiring signed DLL’s… which would exclude many hobby developers to mess up things.
Meanwhile, i suggest you look at my sentence where i said CTD can happen, rather than pretending i said something i never did.
Have fun flying.
The Aerosoft CRJ comes with its own standalone NAV database (the same one used with the P3D version), which exists as a series of text files. Accessing the data on disk is not a problem - the only proviso is that the database must be contained in a sub folder of the main aircraft installation folder. It can also read externally generated simbrief flight plans as long as they are placed into a folder that the aircraft has access to.
Seems like a reasonable compromise— the Nav Datatbase gets processed and put into a specified folder, with a specified name, within the main aircraft (or gauge) folder.
Probably a far better & more reliable process, than relying on a changing MSFS SDK to access that data from the sim itself.
OPEN the way for 3rd party tool (that run on separate pc on the network) connect to XBOX MSFS
Other games and simulator on XBOX platform already have this chance via network. (Ex f12020 and forza motorsport 7)
Hey all, these fruitless discussions will never end unless we find a common voice or the basic requirements we as third party devs need to be fullfilled for a sucessful implementation of our ideas. Pls sit back, relax and bring up pretty clear and reliable requirements like i.e.
Opening the WEATHER up to 3rd party developers.
Opening up ATC to 3rd party developers.
Create a more robust flight model or limited number of flight models
Create a more reliable airport, scenery, helipad and material development toolset
This is not the time for endless discussions, this is a time of basic positioning, defining borders.
So pls write less with more content and be as exact as possible. Nobody is able to read this all. Contribute with quality not quantity!!!
you are right! well, I stick one more line in this thread, I just wrote my point of view without specifics SDK Q&A Stream Feedback - #21 by ImDrako2132, I’m not a developer, just expressed my feeling hoping that others share it to change conduct, but I think it is lost for now.
Indeed it is not a problem in itself, and the reason they include their database IIRC is because they can’t access the FS2020 database using the SDK. In other words, when you’ll have a dozen aircraft each one having its own local database, this will be a dozen set of files to keep in sync and update too.
There remain a problem though: because the WASM sandboxed code is only given the permission to accessing a local sandboxed folder with write access just for this WASM sandboxed code, this further limits one of the strength of any other simulator: mixing add-ons.
Speaking of mixing add-ons:
This is one of the most fundamental architectural principle impairing creativity in my opinion and this is what I’m alluding about with this statement. And there is a reason for this: the SDK inherits the mindset of the past, which is the mindset ACE developers had when they initially build the SDK for internal use which they later opened partially to the public as the official SDK. Here is what I mean by this:
In the Q&A they are saying FS2020 is a platform like Windows, and the add-ons are the applications like Word. This is not true nor representative to me. If I’d keep the same analogy, here is what it would be instead:
FS2020 is Excel
add-ons are Excel documents.
add-ons can only use the limited set of programing functions included in Excel.
the set of programing functions available are those selected for an Excel purpose only.
you can only mix documents if you copy/paste the content of one document into the other, creating a new tab for example.
when you do, you risk formula conflicts and non-working references to the other document.
an Excel document is no more than what the Excel developer thought it could ever be.
as a 3rd party Excel document author, you can never make an Excel document be something else than what it is, a document.
if the Excel programmers are only working with 3rd party document authors doing financial amortization documents, they won’t include statistical functions.
those wanting statistical functions are not listened to nor engaged with because Excel is only sold to financial people.
X-Plane/Prepar3D are Python runtime
add-ons are Python program.
add-ons can only use the limited set of language functions included in Python.
add-ons can extend the set of functions with the use of 3rd party libraries. They can even develop their own libraries to extend the language and use the resources available in the underlying operating system.
a Python program can be many different things the Python language inventor(s) couldn’t ever have imagined their language could or would do.
as a 3rd party Python program author, you can make your program anything you’d like it to be.
P3D Python is offering more functions but at a higher abstraction level (Say DrawCircle() )
XP Python is offering less functions but at a lower level (Say MakeVertexBuffer(), DrawVertexBuffer() ).
the runtime doesn’t need to provide a function for everything, just the minimum necessary for the language to be Turing complete. If it is, they don’t need to custom implement a new function because 3rd party Python program authors can do their own.
This specific Flight Simulator SDK vision consisting in “an aircraft is the container” (the document analogy above) is very strong. In practice I find this is reducing the scope of the gauge and system SDK in my opinion, and I can clearly see this impact already in current FS2020 add-on developments. For example:
It is hard to add a 3rd party gauge in any aircraft, like the G1000 WT gauge. You can’t add the gauge in any of you aircraft easily because this requires changing the aircraft container because the SDK vision is a self-contained entity, the aircraft, rather than a composable set of modules.
If you do find a way to add the G1000 WT gauge, you risk conflicts with the aircraft autopilot system, because both can only assume, in their own right because of how the SDK is imposing this on them, they are the sole entity in the aircraft controlling the autopilot.
yourcontrols add-on requires the other add-on to publish its own list of L:vars so that it can use them for interactions. It would be much easier with introspection APIs and a modern (i.e. non inherited from FSX) event system* (1)
These are just a few examples which are equality applicable to other simulators:
to P3D for similar FSX inherited vision in the SDK (L:vars for events, aircraft container vision), but at least P3D is offering much lower level features and is not sandboxing add-ons so that 3rd party developers can make solutions to addressing this.
X-Plane on the other hand is not suffering any of these, because the SDK is supporting in its very structure and feature set the composable modular concept vision. It is a much richer environment for developing add-ons even if the set of functions is much smaller in number, because they are lower level and therefore they are enabling more.
In my opinion I find the idea to lower the entry barrier to developing add-ons for FS2020 with JS/HTML and the in-sim SDK tools commendable and good for the franchise. I really think this is good this time with the choice of technologies they are using in FS2020, whereas I never thought this was good before with the “XML Scripting Language” which was at the time meant for this.
However, delivering this idea of a lower entry barrier in using higher abstraction constructs, shouldn’t be an excuse to not delivering lower and less abstracted constructs to more experienced developers wanting to do more than what the higher abstraction constructs is provisioning for.
A good example of this to me is the drawing API. At last, Flight Simulator SDK is offering a low level basic but sufficient vector drawing API and a bliter. This is the Asobo Drawing API, very simple, to the point of building vertices and drawing the path and no need for more (2). They also include in the SDK a nanoVG implementation using this low level drawing API. On top of which they are also including in the SDK a GDI+ implementation wrapping the nanoVG implementation in a thin layer. (3)
So if the GDI+ abstraction thin wrapper ontop of NanoVG ontop of Asobo low level graphics API was good enough for the CRJ and for Microsoft/Asobo to allocating development resources just for this, why shouldn’t the same approach be more widespread for the rest and the other type of add-ons or for other add-on vendors? In other words, there is a need for high level abstraction in order to lower the barrier of entry for sure, but there is also a need for lower level API to directly interact with some deeper entry points into the simulator itself, like in other simulators. In my opinion these are really essential to making FS2020 something greater as a platform than a spreadsheet for financial analysts.
But even before going all the way to this route, there are some very basic fundamental constructs which could rapidly and not disruptively be greatly enhanced. We’re detouring the code from FS9 to P3D5 in order to support these few core concepts and to augment the core simulation capabilities (we don’t need to in X-Plane), and I’m not talking millions lines of codes either. These are very light weight very specific augmented capabilities extending their usefulness to any add-on and could help solving some of the inter-gauge and inter-aircraft mixing and communication problems existing in the FS2020 SDK carried over from the FSX area SDK.
(1) In the X-Plane world, an event is a first class citizen, with a name, any other add-on can discover and trigger, and even intercept and transform. This applies both to stock events and runtime created events by add-ons. Furthermore, X-Plane is encouraging the practice to use path delimited names so that it makes it easier to categorize and lookup events. Add-on created events and stock are therefore displaying side-by-side in a coherent tree view in the GUI for example. Any hardware device can also bind to any stock or add-on event created at runtime because they are at the same conceptual level.
In the FS world however, an event is either a number or a stock name. The number type of event is one feature inherited from the past which is perfectly illustrating that the SDK is not designed with multiple add-ons from multiple sources mixed together from the get go. In effect when you mix another 3rd party add-on, you can’t know whether the other add-on is using the same numbers as you. The named type however is limited to the stock SDK event list. The naming convention is also confusing with a some events adopting a noun+verb and others a verb+noun approach. Even in the same category, events can have disparate names and this is due to successive teams adding events with each new FS version. There is no provision for 3rd parties to create their own named events and therefore, there is no way to publish events other add-ons could consume.
This last point is illustrating the founding concept of an aircraft is a sole container, because there is no provision in the SDK to accommodate mixing add-ons. And this has some serious consequences in practice: because there is no event system, gauges are forced to use L:vars as a substitute. The problem is L:vars are meant to store data add-ons can read and write only, and they can read and write the data when it is their turn to do so. In other words, say you have an add-on publishing an L:var to let other add-ons writing 1 or 0 to “trigger” an event. If the other add-on is triggering the event twice during its turn, the publishing add-on will only see 1 event, the last one written in the L:var. A proper event system requires a FIFO queue and an L:var is only a 1 item FIFO.
(2) They are not documenting whether this is CPU rendering (Asobo, SKIA, Blend2D?) or GPU rendering (Asobo, CoherentGT, SKIA?) though.
(3) I understand they spent the time and allocated resources to implementing the GDI+ layer so that it makes it easier for their 1st party partner to release the CRJ quicker with less effort porting the existing FSX drawing code, but I can’t help thinking 3rd party developer doing WASM gauges should have had only 1 choice, which is implementing their own abstracted drawing API on top of the Asobo low level drawing API. We still can hopefuly, but I feel the SDK GDI+/nanoVG now standard has a catch: not only this is creating technical debt with an old graphics API now in the SDK, but because it is now included as standard, many 3rd party developers with legacy GDI+ code might choose to just use this instead of redoing the drawing code. My experience with add-ons is 80% of the CPU resources most gauges are consuming in airliner add-ons are graphics related, and I can’t help thinking both the nature of the GDI+ abstraction in itself (there might be more efficient abstractions than those of GDI+) and their implementation in the SDK (it is WASM code on the CPU running the thin wrapper around NanoVG on the CPU, which is a heavy wrapper around the Asobo drawing API) is not the fastest way, and therefore, add-ons using the “easy porting way” will continue using more resources than necessary and will continue affecting the simulator performance.
Ideally all databases should be the same no matter what the source. As long as the database is based on the current AIRAC cycle, it should not matter whether the database comes from LIDO, Jeppesen or NavBlue. The database is supposed to reflect the real world, based on the latest data from government AIP sources. This would be no problem if the sim’s default NavBlue database was current and accurate, but at the moment it is not. Missing procedures are aggravating, but that can happen even with real-world AIRACs - sometimes due mainly to FMS memory constraints - especially with older hardware.
But the cardinal sin for a real-world navigation database provider is having obsolete information, and NavBlue’s MSFS database has many RNAV named waypoints that were removed from the US National airspace system years ago.
For myself, I use Navigraph both for the core sim nav data (overriding NavBlue), and for the CRJ. It would be great if all aircraft in MSFS could simply use the provided free NavBlue database for all navigation, but unless NavBlue gets its act together, I don’t see that as a viable option.