• 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

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.
 
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.
 
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.
 
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:
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
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
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 :)
 
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:
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...
 
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.
 
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.
Metadata_Delta_Updated.png

Section size decompression: First word 00A1 =00A1, next one previous + current = 00A1 + 0000 = 00A1, 00A1 + 0000 = 00A1, 00A1 + 000B = 00AC, 00AC +0005 = 00B1 and so on
When new decompressed word would have value over 0x8000, subtract 0x8000 from it. For example previously decompressed word 00B4 and current delta FD7F = 80B1 over 0x8000 so 80B1 - 8000 = 00B1.
Beginning of metadata section surely has relative position of tiles inside "parent/cgl" quadkey. Precise format unknown.

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.

If one wants to decompress a CGL file following code may (or may not, it's quite terrible) provide some insight. (hardcoded to work with a secondary aerial image container) (python3 and python python lzma required)

Code:
import lzma
import os
# Decompressing all sections from a CGL file
infile=open('sai230.cgl','rb')
inarr=infile.read()
headerstart=inarr[36]
headerlength=inarr[40]
headerarr=inarr[headerstart:headerstart+headerlength]

prop = inarr[49]
pb = math.floor(prop / (9 * 5))
prop = math.floor(prop-(pb * 9 * 5))
lp = math.floor(prop / 9)
lc = math.floor(prop - lp * 9)
my_filters = [{"id": lzma.FILTER_LZMA1, "preset": lzma.PRESET_DEFAULT, "lc":lc, "lp":lp, "pb":pb},]
headerunlzma=lzma.decompress(headerarr,lzma.FORMAT_RAW,None,my_filters)
if(len(headerunlzma)>0):
outfile=open("headerunlzma.bin","bw")
outfile.write(headerunlzma)
outfile.close()

## TODO Meaning of first half of header is unknown, skip for now, needed for compression
compressedsizes=[]
uncompressedsizes=[]
headersize=len(headerunlzma)
compressedsizesdelta=headerunlzma[round(headersize/4*2):round(headersize/4*3)]
uncompresseddeltas=headerunlzma[round(headersize/4*3):round(headersize/4*4)]
compressedsizes[0:2]=compressedsizesdelta[0:2]
uncompressedsizes[0:2]=(int.from_bytes(uncompresseddeltas[0:2], 'little')+int.from_bytes(compressedsizes[0:2], 'little')).to_bytes(2,'little')
i=2
while i<len(compressedsizesdelta):
print(i)
a=int.from_bytes(compressedsizes[i-2:i], 'little')
print(a)
d=int.from_bytes(compressedsizesdelta[i:i+2], 'little')
print(d)
s=a+d
if s > 32768:
  s=s-32768
print(s)
compressedsizes[i:i+2]=s.to_bytes(2, 'little')
print(bytes(compressedsizes))
uncompressedsize=s+int.from_bytes(uncompresseddeltas[i:i+2], 'little')
uncompressedsizes[i:i+2]=uncompressedsize.to_bytes(2,'little')
i=i+2
i=0
while i<len(compressedsizes):
print(str(int.from_bytes(compressedsizes[i:i+2],'little')))
i=i+2
i=0
while i<len(uncompressedsizes):
print(str(int.from_bytes(uncompressedsizes[i:i+2],'little')))
i=i+2
## decompress files from blob
i=0
datastart=headerstart+headerlength
dataend=datastart+int.from_bytes(compressedsizes[i:i+2],'little')
prop = inarr[48]
pb = math.floor(prop / (9 * 5))
prop = math.floor(prop-(pb * 9 * 5))
lp = math.floor(prop / 9)
lc = math.floor(prop - lp * 9)
my_filters = [{"id": lzma.FILTER_LZMA1, "preset": lzma.PRESET_DEFAULT, "lc":lc, "lp":lp, "pb":pb},]
while i<len(compressedsizes):
print(datastart)
print(dataend)
outfile=open("data"+f'{i:03}'+".png","wb")
outfile.write(lzma.decompress(inarr[datastart:dataend],lzma.FORMAT_RAW,None,my_filters))
outfile.close()
i=i+2
datastart=dataend
dataend=dataend+int.from_bytes(compressedsizes[i:i+2],'little')

That's all I have for now, any input would be most welcome.

DEMs seem to have some kind of compression on higher than base zoom levels, only base zoom level renders like expected. Files of higher zoom levels contain byte values of either close to 0 or 255. Some kind of additive to previous layers?
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
 
Last edited:
Top