• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

MSFS High Level Overview of MSFS2020 Tech

Messages
27
Country
canada
The game, at least the graphics side, is heavily related to A Plague Tale. There are references to materials used in that game inside the executable. I wonder if its possible to get some of those materials working in game - something like fur would be useful for passengers in older open-pit aircraft.

There are also some variables for lightning that might be fun to get access to. Stuff like how branching lightning is and what color. I don't think the game is taking current atmospheric conditions into account for lightning color but I haven't looked at those shaders yet.

Also the codename was kittyhawk and some of the folders reference 11.0. I guess even microsoft doesn't consider Flight to be the 11th installment.
 
Messages
277
Country
us-newyork
Is there a way of improving the size of the shadow maps in the cockpits ?

Not from what I can tell. Terrain shadows are already separate, as are screenspace. It's possible what you are seeing is artifacts from the shadowing algorithm that has been chosen, which an increased shadow-map resolution won't help.

Does anyone know if AirlineICAOCodes.spb and PlaneTypeICAO.spb in installdrive\MicrosoftFlightSimulator\Packages\Official\Steam\fs-base-aircraft-icao actually do anything?

They could be edited without too much difficulty. The only issue is both may need to be the same number of characters for replacement names. Some script would need to be made to pull out the names and compare them to real world airports and aircraft.

Yes, they can be edited via Steve's FlightToolkit.Simprop code (after some slight modifications to the propdefs in MSFS for some syntax errors) and take effect. I would recommend you make a new community package to override and not edit the base.

SimObjects installed by every package show up in the Scenery Editor and hence this poses questions as to what objects are legal to use

Not a lawyer but it has been stated from Asobo that the standard modellibs that ship with the sim can be composed and reused, as you could with library objects in FSX.

So WebAssembly targetting from MS/Asobo shows that they are on board the future wagon and also that more is happening under the hood that is web based ?
Yes, very much. The UI toolkit is running a full web browser. Webassembly is embeded via an html host gauge, and the beauty of webassembly is that (given proper dom support through WASI) there can eventually be a high degree of interoperability between the JS and C++ code.

The game, at least the graphics side, is heavily related to A Plague Tale. There are references to materials used in that game inside the executable. I wonder if its possible to get some of those materials working in game - something like fur would be useful for passengers in older open-pit aircraft.

There are also some variables for lightning that might be fun to get access to. Stuff like how branching lightning is and what color. I don't think the game is taking current atmospheric conditions into account for lightning color but I haven't looked at those shaders yet.

Also the codename was kittyhawk and some of the folders reference 11.0. I guess even microsoft doesn't consider Flight to be the 11th installment.
This is all very true. Over time I would like to see the ability to bind a shader to a material (as in Flight) given to 3rd-party devs. I don't know how the API footprint would look but opening up atmospherics via API would be a big win for 3PDs as well, so none of the tricks that were previously necessary in FSX/P3D will have to continue.

Flight came more from the TS2 codebase than anything else, with a lot of the previous FSX system functionality removed. Nevertheless there were some really interesting concepts in the engine that have yet to make it into another product.
 
Messages
414
Country
us-newyork
Not a lawyer but it has been stated from Asobo that the standard modellibs that ship with the sim can be composed and reused, as you could with library objects in FSX.
Thanks. They problem stems from payware third-party objects where the developer does not name the object with a prefix (like KDEN_Building 6) which clearly shows it's from a payware package.
 
Messages
16
Country
greece
Is there anywhere an introduction on how all these community packages are assembled to be used by everyone?

Is there any documentation of some kind of what steps need to be completed? For example there is an FPS fix around that includes adding a menu to the MSFS Aircraft menu. Manifest.json indicates that this is core enhancement of some sort..

Are all these different ways to create packages, documented somewhere as a starting point?

P.S. I suppose that this part of the original post here answers my question?
"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. "
 
Last edited:

JAB

Messages
19
Country
switzerland
MSFS2020
Hello,
Sorry if this not the conveniant place to ask a question.
As utilities creator, I need to find the MSFS 20202 folder.in order to reach Community folder and Officiel one.
How can I find this information (for example in the registry) ?

Thanks a lot for your answer.
Jacky
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
33,887
Country
unitedkingdom
C:\Users[user name]\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache

In there is a file called UserCfg.opt

The last entry is InstalledPackagesPath <PathToContent>

This points to the location of the Community and Official content
 

WebSimConnect

Resource contributor
Messages
154
Thanks for the post. I have not started SDK analysis yet, however it is nice to see MS/Asobo went the same way as I did pioneering with html-based gauges, already back in 2013. Their SVS also looks familiar, so I need to see what lies behind :)
 
Messages
15
Country
finland
The container format is simple - it is an LZMA compressed header with pointers to tiles within the file, and then LZMA compressed sections following.

Hi, I'm trying to figure this out, but am having a hard time.

If I've understood correctly, decompressing lzma requires either lzma header from which the decompressor can read parameters (dictionary size, lc, lp and pb ( lclppb usually combined to single byte)) or that they are provided to it (raw mode).
Looking and comparing some dem cgl's i've found that there is a "file header" at start of the cgl, that contains uncompressed fields for for example section count (0x20 D(?)WORD) uncompressed header length ( 0x24 WORD) and what I think is the length of compressed header(0x28 (WORD)).
BUT I've not found parameters that would decompress the header...
Any pointers for figuring it out would be greatly appreciated
 
Last edited:
Messages
435
Country
france
I wonder if it's possible to use TCP/UDP communications and/or named pipes from within a gauge?
I come back to this "old" question from WarpD, I think it is an interesting one. I have some CockpitSonic devices (Airbus MCDU and RMP) for which I developed drivers for the Wilco Airbus Series to make them plug-and-play. These devices use sockets through the EHID software provided by CockpitSonic. If the MSFS SDK does not let us access Windows features and libs, I'm afraid I will never be able to use these devices with MSFS...
A possible solution might be to use a Windows external application that communicates with the devices through sockets on one side, and communicate with the sim using SimConnect on the other side. This would be a complex and not very elegant solution, I'd rather have everything integrated in the sim, is possible.

By the way, the same question appears for the use of an external Navigraph database. If the SDK does not let us read any file on the file system, how can we read the navigation database?
Does it mean we will have to rely on the sim internal database? I hope not...
Does it mean the database will have to be duplicated in each aircraft file system? If so, can you imagine the nightmare when it has to be updated?
So many questions...
 
Messages
2
Country
unitedstates
I come back to this "old" question from WarpD, I think it is an interesting one. I have some CockpitSonic devices (Airbus MCDU and RMP) for which I developed drivers for the Wilco Airbus Series to make them plug-and-play. These devices use sockets through the EHID software provided by CockpitSonic. If the MSFS SDK does not let us access Windows features and libs, I'm afraid I will never be able to use these devices with MSFS...
A possible solution might be to use a Windows external application that communicates with the devices through sockets on one side, and communicate with the sim using SimConnect on the other side. This would be a complex and not very elegant solution, I'd rather have everything integrated in the sim, is possible.

By the way, the same question appears for the use of an external Navigraph database. If the SDK does not let us read any file on the file system, how can we read the navigation database?
Does it mean we will have to rely on the sim internal database? I hope not...
Does it mean the database will have to be duplicated in each aircraft file system? If so, can you imagine the nightmare when it has to be updated?
So many questions...

From .js gauges one seems able to use the fetch API quite easily to make get/post requests. It's not ideal in some cases, but an external program could open a local web server and listen for requests from the sim via http.
 
Messages
15
Country
finland
Hi, I'm trying to figure this out, but am having a hard time.

If I've understood correctly, decompressing lzma requires either lzma header from which the decompressor can read parameters (dictionary size, lc, lp and pb ( lclppb usually combined to single byte)) or that they are provided to it (raw mode).
Looking and comparing some dem cgl's i've found that there is a "file header" at start of the cgl, that contains uncompressed fields for for example section count (0x20 D(?)WORD) uncompressed header length ( 0x24 WORD) and what I think is the length of compressed header(0x28 (WORD)).
BUT I've not found parameters that would decompress the header...
Any pointers for figuring it out would be greatly appreciated
Some progress (I am not certain this fits best in this topic, but...)

This information comes mostly from observing fsPackageBuilder creating CGL for SimpleAerial project.
After creating higher tile level images (PNG) builder compresses them with lzma1 using parameter byte 5D (lzma parameters lc=3, lp=0, pb=2) and writes them to single file "tmp_blob".

It also creates a "tmp_metadata" file, example in image below, which contains start offset and length for every section in "tmp_blob".
1603831497232.png

At this point tmp_metadata is very readable, but in CGL it is compressed and I believe it is compressed with two layer compression. First one is some kind of "delta" type of compression and then second lzma1 (parameter byte 00 :O).
Image of "DELTA" compressed metadata below. Section size interpretation is wrong!!!
Metadata_Delta_Updated.png

Beginning of metadata section surely is relative position of tiles inside "parent/cgl" quadkey.

When fsPackageBuilder has compressed "metadata" and "blob" it will write a CGL file with uncompressed header and concat "metadata" and "blob" to it.
1603837636824.png

One of the non marked bytes in the uncompressed header surely has tile layer identification in it, what's left is a mystery.

DEMs contain a Laplacian(?) Pyramid (Refer to Pyramid (image processing) - Wikipedia)
1604024425883.png

E: Updated metadata decompression, added a more complete example.
E2: Removed load of wrong information regarding DEM compression, update lzma properties decoding code, add about DEMs
E3: Removed false information, will reply with up to date information later and nuke this post afterwards
 
Last edited:
Messages
15
Country
finland
Messages
4
Country
norway
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.

Hi! Could you please elaborate this part? Does it mean that named pipes will be the recommended way for out of process communication, and that the TCP server will eventually be removed? There are clients that use raw TCP sockets (without using the SDK dll/lib) - will those no longer be able to connect in the future? 🤔
 
Last edited:
Messages
277
Country
us-newyork
From a later discussion with Asobo on the topic:

The current implementation of SimConnect includes support for IPv4 and IPv6, with Pipes being the recommend method. At the time, only static ports supported, with dynamic ports being deprecated and planned for removal (see below).

As with other applications using SimConnect, the ports are pipes are configured on the SimConnect.xml file, present if am not wrong at C:\Users\<your user>\AppData\Local\Packages\Microsoft.FlightSimulator_<your developer id>\LocalCache". Starting from the last version, this file should be generated automatically, and it uses the same syntax of previous FS versions.

We do not plan to write the ports in the registry, as it is our understanding that pipes are better suited for local communication.

So as long as these clients use a fixed port as specified in the user SimConnect.xml and not autodiscovery with the dynamic port, they should be in good shape assuming the actual on the wire packet structure has not changed.
 
Messages
4
Country
norway
So as long as these clients use a fixed port as specified in the user SimConnect.xml and not autodiscovery with the dynamic port, they should be in good shape assuming the actual on the wire packet structure has not changed.

Thanks for your reply! JSimconnect (java client lib) uses the registry for autodiscovery, so those clients will break then (when running locally).
 
Messages
277
Country
us-newyork
Thanks for your reply! JSimconnect (java client lib) uses the registry for autodiscovery, so those clients will break then (when running locally).

As does BeatlesBlog.SimConnect by default, which I know a lot of the .Net folks still use. It seems like an initial focus was to prioritize in-process / named pipes, but if there is a rise in demand for out of proc functionality perhaps they may reconsider. Personally I'd love to see the OTW protocol opened up. In the abscence of a decision from Asobo perhaps the community should standardize on a default port and just write it to the simconnect.cfg in installers.
 
Top