MSFS High Level Overview of MSFS2020 Tech

[theisomizer]

Hi everybody! The time is finally upon us that we can talk about MS2020, and specifically developing for it.

I had a version of this post drafted that did not include SDK details, however it would appear from the other post that they have indeed released the SDK with the sim.

Some of us have been working with the tech already so I'd like to give an overview of where it is at and what has changed, and what we know so far. Keep in mind that many things are TBD or WIP, both from our understanding and from an SDK / platform perspective. These can be further expanded in detail in subsequent posts.

1. Is it based on FSX Tech?

Yes. More or less the entirety of the FSX codebase was compiled in, with obviously some systems being supplemented or totally replaced. This means some things "just work" out of the box:
* XML gauges
* SPB files
* Various aircraft systems
* Basic simobject container structure
* Pieces of airports (more later)

Other systems have changed entirely or substantially:
* Terrain
* Aircraft programming
* Atmospherics / weather
* Aerodynamics

Essentially the sim is composed of an FSX base (not MS Flight) with many improvements, combined with Asobo's graphics engine on DX11 (although it is cross-platform and being ported), plus a Bing maps engine, and the bongfish / blackshark procedural engine.

2. State of the SDK

Version 0.5.0 is out, you can download it from in the sim (see other thread for instructions).

You'll note that it is a work in progress, and still under heavy active development. That's all I'll say for now, we can look forward to continued updates and you should go explore what is in there now.

One thing that will take some getting used to is the tooling is all in-sim using the "dev mode". There are no longer standalone command line tools to compile various file formats, everything is a "package" and is either built in the sim using the GUI or from the command line sim package tool launcher tool in the SDK.

Packages are a simple XML format that the dev mode parses and then uses to generate the actual addon files or signatures if need be. Unfortunately we don't have the full schema for this (yet) and different package types are heavily under development so robust out-of-sim tools may not be practical yet. That being said, go explore the in-engine dev mode, it is very powerful and there may not be a big need for external authoring.


3. What's the deal with these "packages"?

MSFS uses a fully virtualized file system, similar to Flight if anybody ever worked with any of Steve's tools, with a major difference being the zips are extracted to your local file system. Be sure to pick a custom path for the addon content when installing the sim, else this will be way up in your appdata folders.

There is the onestore (no public details / still under NDA) and then a community folder where you can test and distribute packages. All of the default content is installed under "onestore" but you can browse some of it.

A significant departure from previous sims, although similar to many modern game engines, is the requirement that many file changes within your package as you are working on it will require you to "rebuild" the package before the sim will load it, as a form of security and validation. You'll get used to this process pretty quickly, but remember to do it.

A built package can be distributed to users to put in their community folder.


4. What about programming?

Although a source of consternation for some, I want to just stick to the facts on this one.

XML gauges are fully supported, some have reported very minor differences in parsing and systems but it is mostly drop-in.

C++/native gauges have been replaced with a new C++ LLVM / WebAssembly based system. The idea is that upon installation of the SDK you get a new project type (MSFS Project), and you can use this build config to target this platform, in addition to any other platforms like an x64 config for P3D V5. There's no need to really learn about Wasm/Clang/LLVM yourself as this is all fused and distributed with the SDK and integrates directly into VS.

Webassembly modules are distributed as LLVM bytecode (much closer to native assembly than something like .NET IL). They are then JIT compiled on your clients machine on first run by Innative, which the Asobo engine hooks to then add function pointers to native code for things like the gauges.h functions.

So you still compile your C++ through Visual Studio (2019), you just target a different platform. Note that this is currently a single threaded (threads are coming soon) 32-bit environment. You can still use SimConnect.h and Gauges.h which have been ported to work under Wasm, as well as the new MSFS*.h files. There is no concept of "Windows" or Windows.h here, which will probably catch many C++ programmers who are not used to doing cross-platform work by surprise. Atomics are now also working, so most things without explicit threading will build with few changes.

Static libs are now supported and you can pretty easily build things from source for them, such as Boost. Remember - no dlls, no .libs, you need to rebuild from source any 3rd-party dependencies to .a libraries. The debugger is not as good as you are probably used to due to the Wasm linear memory model but is being worked on now.

Note that this is all sandboxed (go read up on WASI for the motivations), meaning if MSFS doesn't give you an API, you can't do it. You can't access arbitrary file locations on the host (you do get access to a folder local to your package for saving / reading data), you can't do things like Windows Registry, and can't do web requests yet. This is a restrictive environment but intentionally designed to make it very easy to repackage and publish your app on many different platforms, and MSFS has many cross-platform ambitions.

There is much to still be worked out in this system, but it is certainly an app platform for the future. For a taste of how powerful Webassembly can be, check out https://lightroom.adobe.com. Yes, we run a massive C++ codebase in your browser.

There is also a new javascript based gauge system that I will describe in further detail below.

5. What APIs do we get?

The sim comes from FSX, so SimConnect is still the standard API. In fact it's the same on-the-wire protocol version. Do note that the TCP implementation on localhost is deprecated for named pipes. For out of process you can either use the new native DLL (like FSUIPC has been doing) or there may be a static lib coming soon. There is also an out of proc .Net client dll that ships with the SDK. For in-process you are required to use Wasm modules and the native SimConnect client.

Also note that it's roughly the same API footprint as FSX. There are some Key Events and Simvars that have changed and are not documented or hooked up through SimConnect yet, this will evolve. Things that were added over the years to SimConnect in P3D are not there and may catch you by surprise, and obviously there is no PDK-style interface. There are also some SimConnect functions (like some around weather and AI) that are either not yet hooked up or have behavioral changes or regressions. Asobo is working heavily on stabilizing the SimConnect API, and then will be expanding it as well.

There is a new gauges system as well that I will describe in the html post.

Ok that's the start, more to come.

 

[OzWookiee]

Awesome, this really helps come to grips with this new system for newbies like me and vets alike I'm sure!

 

[theisomizer]

Ok, round 2

6. APIs continued

HTML / JavaScript powers the new gauge system. It is important to understand that this is not yet properly documented in the SDK, and that this is also how all of the default aircraft are built. This doesn't mean that C++ is a 2nd-class citizen. rather that C++ / Wasm tech was a later addition to the MSFS tech stack that will ultimately become more powerful over time.

The entire UI of the sim is written using the Coherent GT toolkit which is a local web / html framework based on webkit that blits directly onto the GPU. It's very cool tech for UIs, as I'm sure anyone in UI/UX would be much happier implementing directly in familiar HTML/css/js constructs rather than having to use XAML designers or even requiring someone to translate the design to C++ UI toolkit code. It is even more cool to see it applied to the gauges and the avionics. Given the power of of the js engine (JavaScriptCore), it is very impressive to see what they have been able to do in terms of aircraft systems and avionics programming in terms of what is essentially an embedded web app.

You can include these html gauges now in your panel.cfg, but it is not easy to author them as you're missing the entire framework Asobo has developed for all of their default instruments. They have mentioned opening this up over time, but I imagine as of now I imagine they are prioritizing the C++work. Much of the JavaScript / HTML / CSS code ships with the sim, if you are curious to inspect it. There is also some TypeScript that reduces down to JavaScript if that's something you are interested in. Unfortunately the Coherent debugger doesn't ship with the sim, but you can still see the effects by editing and building a package.

7. Graphics libraries

So, without windows.h, you don't have GDI+. Furthermore, many developers have used other techniques by overwriting the gauge header bitmap or in P3D using render to texture techniques. Here you don't have any access to Direct2D or a D3D Device/Context, so out of the box there is not a straightforward port for graphics and this is where I imagine many developers will spend a lot of their time.

MSFS ships a version of the NanoVG vector graphics library(https://github.com/memononen/nanovg) that is now contained directly into the Wasm layer. It provides a Canvas-style API, and if you are writing new code this would be a great place to start (see the GaugeDemo sample aircraft from the SDK).

However, a GDI+ wrapper is in the works, either based off of nanovg or a yet-to-be-announced system. Developers who rely heavily on GDI+ may be best served by waiting or doing what they can with either nanovg or the html / css system.

Anybody with a custom rendering system should looks at the "fsRender" native rendering API in the SDK docs. This is in the backend for NanoVG that is used to composite into their engine straight to the GPU and it is very high performance. If you are familiar with D2D or D3D it should be fairly self explanatory - it is just like a fixed function pipeline and vertices in 2D only.

Remember that the point of all of this is to build a truly cross-platform realtime vector graphics library, which is no small feat.

8. Airports and scenery

I don't do much in this area myself so others who are more knowledgeable may be better to speak up on this. Many people are working on airports currently and it has good tooling support in the SDK, although the docs are still being expanded.

The basics of airport BGL files are the same. There are some changes so it is not drop-in replacements, but the structure of the records should be familiar.

Many areas of airports now heavily use vector data for polys. You can use the dev mode to draw all kinds of polys for the airport, and these are actually stored as CVX-style (adaptive delta compressed) records in the bgl. Interestingly enough this format is only used here and not actually used for geo vector data anymore.

Sloped runways are supported, as the airport textures are projected / draped onto the underlying mesh. As you are not able yet to customize elevation data, the only way to adjust slopes and airport elevations is with local "terraforming" polys, which take some getting used to but are very powerful.

The same bgl layer system is in place (now based on Content.xml), and I expect to see more functionality around the scenery library as addons become more prevalent.

9. Terrain System

This is typically my area of focus and probably warrants a post of its own.

The FSX terrain system is officially dead, and there are now more QMIDs nor 6 root cells, everything is now based off of a standard quadtree (with the exception of things such as airports objects that are placed on a QMID grid which are then transformed to raw lat / lon). It is all Mercator projection using the Bing maps tile system (https://docs.microsoft.com/en-us/bingmaps/articles/bing-maps-tile-system). This means the base (CGL) scenery directories are different with 3 numbers 0-4 (representing 3 quadtree levels) instead of 4 (with the x/y regional divisions) from FSX.

There is unfortunately no backwards-compatible way to load FSX / P3D style terrain data. It will have to be rebuilt in the new format, and terrain addons are not yet supported by the sdk tools, although they are coming soon.

Everything is based on CGL files now that are new and replace everything resample did. These are a very simple container format that is LZW compressed and contains all of the tiles for an area and can be easily worked with.

Unfortunately once decompressed the contained data is in many different formats and most of it is not yet decipherable. Also most of this cannot be authored through the SDK yet, only aerial imagery can and it has some quirks / differences from the FSX system related to progressive loading of tiles.

bldn/bldo files - bf building footprint data, format is further compressed and not known
dem files - raw elevation heights, uncompressed, or windows hd photo
lcg - land class data? .webp format
vec / vecn - vector roads, etc
vgm - Vegetation models?

Also to note is that now many urban areas now contain photogrammetry from Bing Maps. These are essentially 3D models of the city, and I have the format worked out, they are easy to render. Unfortunately since they are solely hosted in the cloud, you probably will never see them offline. They also don't integrate in with the other scenery types, it is all or nothing and you can easily see where the photogrammetry ends and the generated world begins. They can be excluded by a poly in addons. Nevertheless they look extremely impressive when flying in a downtown.

10. Models

FSX MDL files can still be loaded just fine, although they are legacy and are not to be used for store content. Everything has been replaced with .gltf, and Asobo uses a lot of gltf extensions, most of which they ship with the SDK.

It's important to realize that there is a "baking" process that occurs when you build a package that changes the gltf files, optimizing them. It currently doesn't change the .bin data but this could change in the future, and could hamper the ability to create ready-made or rapid prototyped models from other tools. Of course, you could always just export sdk-format gltf and run this step as a part of your pipleline.

Otherwise these are pretty standard gltf files and easily viewed in a text viewer. I applaud Asobo on choosing such an open format and I hope as the sim evolves this openness stays true.

I have an MSFS gltf viewer almost working.

11. Autogen

As an honorable mention we will talk about the new replacement system for FSX-style autogen. FSX autogen and annotations are dead.

Go watch the partnership video from blackshark.ai from last week and this will give you an overview of what is being done here inside MS2020. Note that the vast majority of this generation process happens offline, you just consume the data.

Essentially aerial imagery is analyzed for building footprints and building heights. This geometry information is combined with landclass data at runtime to synthesize very realistic looking autogenerated buildings. These are complete with details such as facades, roofs, solar panels, etc. Most of the this data is preprocessed and shipped in CGL files with the sim so you can fly offline. Trees are also generated to cover artifacts of the photogrammetry as well as, well, anywhere a tree is detected by the ML models. There is also online updating of the vegetation masks that are downloaded from Azure.

If you have heard of ESRI CityEngine, the blackshark.ai PGG is a similar runtime generation system to ESRI's PRT (without the AI component, assuming you start from footprints from OSM or similar).

Unfortunately PGG mods are not supported through the SDK yet, although it looks like they will be in the future. This is an incredibly powerful system and I can't wait to see what we are able to do with it.

Ok, that's all for now.

 

[theisomizer]

Posts Part 1 and 2 have been updated with feedback from the community and Asobo. Here goes Part 3:

Part 3: Other areas and FAQ

I have received many messages about some of these areas so I would like to add some clarification. I will warn you that my understanding of these areas may not be complete as some are not things I typically work with.

12. More info on modelling and animations

To clarify from earlier, the intent of an open standard is not for you to take the meshes as-is and drop them in another program. The idea is that they are 1) really easy to inspect, 2) relatively easy to author outside of the official tools, and 3) able to evolve with the community that is driving the standard over time. MSFS meshes are (depending on your interpretation of some parts of the standard) either fully gltf or almost fully gltf compliant, so although there is no free lunch they are relatively easy to work with.

There is another thread here from Vitus who got a Blender exporter for MSFS working, which is really cool. I think Gibbage also got substance painter hooked up which is incredible.

Regarding modelling, I didn't mention it before but as one would expect officially it is all through 3ds Max (2016-2020 are supported). The exporter from max is open source (https://github.com/AsoboStudio/FlightSim-glTF-exporter) and you can also explore all of the scripts that ship with the SDK for Max, including the PBR preview shader. The material system is fully PBR and different than what you are used to, but concepts like modeldef.xml animations still exist and it seems to be a relatively painless transition for those who have done PBR for V5 to learn this new toolset.

I am not a 3d modeller myself, but there is the DA62 full sample aircraft (minus the gauges) that you can download from the SDK help menu - it is super helpful.

13. Sound

The legacy sound format using waves / .cfgs are still supported, although the new system based on WWISE is much more flexible.

The WWISE system is highly extensible and robust and you can use standard tools and XML to edit these. The docs in the SDK are very good and there are tutorials in the dev mode help menu as well.

It has been stated that a sound API will be made available under Wasm at some point for addons, as this is core functionality in many gauges.

14. Aerodynamics / Physics

The FSX physics model is still supported and mostly works the same. You can include legacy .air and .cfg files and they will load, and there is even a "legacy mode" aerodynamics in the settings. The ability to maintain backwards compatibility here was one of the main design criteria of this title. You are probably seeing a common theme here that there is backwards compatibility in many areas, although there are new methods going forward.

The FSX aerodynamics are documented in painstaking detail in the SDK, including all of the derivations. If you have a strong calculus / physics background it is an interesting read. The new aerodynamics model has a very high-level overview but is not explained in much depth, although there is a tutorial that goes much more into detail about designing new aircraft.

I will attempt to summarize, but know that despite my engineering background I am by no means an FDE guru. The FSX model essentially treats your plane like a box with wings and stabilizers that are also boxes. The forces are largely table driven, summed at those large boxes only, and they are geometrically integrated at a relatively low delta T with minimal interaction from the environment, so although mathematically correct, they give that feeling of the plane being on "rails", or perhaps too stable.

The new model replaces the integrator and runs at a much higher rate, and splits up the aerodynamic into thousands of smaller surfaces across the airplane geometry (from the aero model, not the visual model like x-plane) and sums the forces individually. It's not really blade element theory, more just rigid body dynamics at a high scale. Since the environmental force model is also in 3D, this allows much more accurate calculations and responses to control inputs and winds. With this approach, it is claimed tables for a lot of areas are largely not needed or legacy. What I don't understand is the claim that all of the forces distributed across the body sections still sum to the same as the FSX model - they clearly don't. Maybe somebody can elaborate.

As you fly you will have to be the judge of the aero models, I don't think one is inherently better than the other, they are different. I do think the legacy model is more stable at this point but the new model is much more advanced and has much more potential for the future. I watched them iterate on the new model positively over the course of the Alpha and expect that to continue, and as always with aerodynamics the model is only as good as the data you throw at it.

Anecdotally, other than some obviously wrong P-factor and ground interference behavior, I believe the new model in the 172 greatly matches my experience flying one in the "real" world incredibly accurately and much more faithfully than the legacy model. On the converse, I have spent time working on and flying in Level D sims for airliners, and I believe these flew much more like the legacy model. Of course, these are massively table driven and airliners are generally incredibly stable, so this makes sense.

There is a debug mode in the aircraft editor and it is really cool to see and debug the forces.

15. Living World

The Living World system (AI for boat traffic, freeways, and airport life) is largely the same as in FSX with some additions to the XML for the new airport functionalities. These are documented in the SDK.

It has been observed to extend to things like the AI boat traffic - custom data produced by Lamont Clark's AI boat traffic compiler looks to work out of the box.

This extends to other legacy areas as well - for example, AI air traffic format (the antiquated BGLC bgls) still appears to be largely the same!

16. Lighting model / rendering / world

Asobo's advanced graphics engine is multithreaded, instanced, and deferred, so this will be a structural change for most people who are coming over from FSX/P3D. The results are obviously very visually stunning. It efficiently works with the GPU (on a modern mid-high end system I am almost always GPU bound) so the performance profile will be different from what you are used to with less emphasis on the main thread. Of course, addon developers will, as always, have to be careful not to starve main thread resources, as remember that is where many of the functions you are used to using will be dispatched.

How you build meshes will most likely evolve. There is no (strong need for) drawcall batching, so you will see moves towards larger texture sheets and less materials where it makes sense. With today's GPU architectures, triangles are fairly cheap and VRAM is at more of a premium. Be efficient in how you lay out your maps and consider adding details to meshes directly.

There are numerous areas on the rendering side that saw 3rd-party modification in P3D/FSX, including base textures, weather and sky visuals, and even shader modifications. All of these will be very difficult to mod in MSFS, for many reasons. For one, other than render to texture techniques in P3D none of this was ever officially supported. Asobo has made it clear that the core of the game is to remain consistent and not be messed with, with security being a concern. The shaders, for example, ship compiled as uber-shaders already in a packaged / archived format. Textures ship in several packages including the compressed .dpc compressed containers as well as various other MSFS core-managed packages such as the bongfish texturesynth and fs base material libs.

With a deferred lighting model things such as dynamic lighting and lighting shadows can be computed much more cheaply than in forward. You see this reflected in the cockpits which come out of the box with dynamic night lighting and shadows and full PBR, which look fantastic, which are areas that have seen a lot of techniques and workarounds from 3rd-party devs in clever but hard to maintain ways. Areas such as the sky, for example, are mostly procedurally generated using precomputed atmospheric scattering and volumetric clouds for truly global illumination (see the paper from Eric Bruneton and Fabrice Neyret from INRIA for the basics), so there is little you would be able to modify there.

In terms of textures, perhaps long-term a technique for overriding these for the curious without destroying the base sim install will be devised.

17. Effects

This one has caught some people off guard, so it deserves a quick mention. The FSX particle system is present (and included in the SDK docs) but much of it is not currently hooked up. If you don't see your effects working this is why.

The state of this has changed over the course of development and it would appear that it is being replaced with a different effects system. Keep in mind that the FSX system was designed back in the days of fixed-function GPU pipelines, so expect a newer system to be much more performant and in line with modern engine tech.

Stay tuned for more details as we learn more.


Ok, that's all for now. I will either add a part 4 if needed or dive more into other topics in other more directed threads, and I would encourage everyone to start adding info to the fsdeveloper wiki.

For questions about packages, I highly suggest you study the SDK on this, the documentation is good and there are tutorials for the dev mode tools in several areas already. Remember, the SDK is still being worked on. Also, try all of the sdk samples, they're tasty!

 

[thetford569]

Awesome stuff. Thank you! Looks like it won't matter too much that I forgot half the stuff I learned in FSX Airport Design. LOL! I'm going to be learning almost from scratch anyway!

 

[WarpD]

I wonder if it's possible to use TCP/UDP communications and/or named pipes from within a gauge?

 

[DagelijksGamer]

I wonder how to make liveries with this

 

[Delta_Who]

Fantastic stuff.
Was wondering if GLTF can be converted ala modelconverterx style to fbx or obj. Not sure on the clauses to this, but would be great to get those models in a 3d painting software. (If a mod dissaproves, feel free to remove)

 

[Vitus]

You can import glTF files to almost any 3d program. The only problem is that you'd probably need to re-build all the materials, because some aspects of those materials are defined by the Asobo extensions to the glTF format. But you'd get the geometry, the uv map, animations and scene hierarchy.

 

[OzWookiee]

You can import glTF files to almost any 3d program. The only problem is that you'd probably need to re-build all the materials, because some aspects of those materials are defined by the Asobo extensions to the glTF format. But you'd get the geometry, the uv map, animations and scene hierarchy.

Unfortunately MSFS glTFs cannot (currently) be imported to other programs, I went through the process earlier with someone else who wanted to try import into substance painter.

 

[theisomizer]

I wonder if it's possible to use TCP/UDP communications and/or named pipes from within a gauge?

I don't think this is hooked up as it is now through WASI (as there doesn't seem to be a network interface), but I do think this is something that is being investigated / on the roadmap. This would open up all sorts of use cases.

I wonder how to make liveries with this

In general liveries work the same as in FSX, you just create a new texture set to be added to the aircraft.cfg.

Redistribution is another matter as you need a new package that supplements the original package to add it. I believe documenting / supporting this is a high priority and on the short-term roadmap.

Unfortunately MSFS glTFs cannot (currently) be imported to other programs, I went through the process earlier with someone else who wanted to try import into substance painter.

Correct, not as of now. The main roadblock is the `textures` section which is based solely on the microsoft dds gltf extension schema. However with a little bit of code this become possible, albeit for academic purposes only, of course.

 

[OzWookiee]

Correct, not as of now. The main roadblock is the `textures` section which is based solely on the microsoft dds gltf extension schema. However with a little bit of code this become possible, albeit for academic purposes only, of course.

Yup, especially since Asobo have provided the schema for these. It'll be neat to have the ability to import the model into your favourite paint shop and just go to town.

 

[Devinci]

I just got the SDK today. It seems like you can only add new airports and not edit already existing ones.
I also cannot find how to compile an airport. The documentations is lacking a lot in this.

 

[Delta_Who]

Correct, not as of now. The main roadblock is the `textures` section which is based solely on the microsoft dds gltf extension schema. However with a little bit of code this become possible, albeit for academic purposes only, of course.

Yh, I have a feeling it's more to do with legal ramifications, with the mention of airline licensing. But no matter, tomorrow I will have a tinker at trying to install the 3ds max exporters instead.

 

[mendiola_loyola]

I just got the SDK today. It seems like you can only add new airports and not edit already existing ones.
I also cannot find how to compile an airport. The documentations is lacking a lot in this.

You can compile the airport xml files using the program "C:\MSFS SDK\Tools\bin\fspackagetool"
There is an example on the sdk folder to create an airport.
You can create airports just using xml.

Regards
Alfredo Mendiola Loyola

 

[Jay Bloomfield]

Unfortunately MSFS glTFs cannot (currently) be imported to other programs, I went through the process earlier with someone else who wanted to try import into substance painter.

There’s a rumor on the Autodesk forums that an official import-export glTF plugin will soon be released. Whether this will help is unknown. The Win 10 3D apps and those from the MS store do read the format. 3D Builder is used for creating objects with a 3D printer and by default in Win 10 opens .gltf files. It prompts for the correct texture files and displays animations.

 

[OzWookiee]

There’s a rumor on the Autodesk forums that an official import-export glTF plugin will soon be released. Whether this will help is unknown. The Win 10 3D apps and those from the MS store do read the format. 3D Builder is used for creating objects with a 3D printer and by default in Win 10 opens .gltf files. It prompts for the correct texture files and displays animations.

The problem is that most importers/viewers are not handling the extras Asobo has added gracefully and have to be updated to understand those extentions (which are valid per the glTF format).

Correct, not as of now. The main roadblock is the `textures` section which is based solely on the microsoft dds gltf extension schema. However with a little bit of code this become possible, albeit for academic purposes only, of course.

@Jay Bloomfield see theisomizers response a couple entries above

 

[scruffyduck]

I just got the SDK today. It seems like you can only add new airports and not edit already existing ones.
I also cannot find how to compile an airport. The documentations is lacking a lot in this.

If you build or edit airports inside the sim then you use the project editor. In the Inspector window there is an option to Build the Project which is the same as compile. There are exclusion rectangle types and airport delete types that allow you to exclude the existing stock airport and replace it with your own. You are right that at the moment there is no easy way to edit an existing airport or start with a stock airport but rather need to start from scratch. However if you can get the XML for an existing airport (via ADE for example) then that could be used as a base. However there are a number of changes to the XML that need to be addressed before the internal compilers or schema. A new version of ADE is currently being developed which will address these issues. It uses the external Package Tool to compile the XML into the sim. There is no XML reference at the moment for bglcomp but I posted a document created from the schema here: https://www.fsdeveloper.com/forum/threads/sdk-reference-scenery-design.448407/#post-851117

Can I suggest that threads about airport design for the new sim are placed in the Airport Design General forum so we can keep them in one place?

 

[delta_foxtrot]

Thank you so much for putting this in. This is a gold information. Very good overview on the new platform architecture. Looking forward for part 3!

 

[Devinci]

If you build or edit airports inside the sim then you use the project editor. In the Inspector window there is an option to Build the Project which is the same as compile. There are exclusion rectangle types and airport delete types that allow you to exclude the existing stock airport and replace it with your own. You are right that at the moment there is no easy way to edit an existing airport or start with a stock airport but rather need to start from scratch. However if you can get the XML for an existing airport (via ADE for example) then that could be used as a base. However there are a number of changes to the XML that need to be addressed before the internal compilers or schema. A new version of ADE is currently being developed which will address these issues. It uses the external Package Tool to compile the XML into the sim. There is no XML reference at the moment for bglcomp but I posted a document created from the schema here: https://www.fsdeveloper.com/forum/threads/sdk-reference-scenery-design.448407/#post-851117

Can I suggest that threads about airport design for the new sim are placed in the Airport Design General forum so we can keep them in one place?

Thanks very much,
You would think that they thought about editing existing airports though! I'm very much looking forward to a new version of ADE, it will be amazing!