• 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.

Official Airport to SDK project: here is a small app to help you (draft)

I found a bug in the Airport2Project_1_0_0_17 version:

<SceneryObject lat="60.414034947753" lon="-0.789023637771606" alt="-27.238" pitch="7.877" bank="358.2971" heading="85.28137" imageComplexity="VERY_SPARSE" altitudeIsAgl="TRUE" snapToGround="TRUE" snapToNormal="FALSE">
<LibraryObject name="{A0816D88-A51A-4730-9993-87603822684B}" scale="0.964387" />

It should be:

<SceneryObject lat="60.414034947753" lon="-0.789023637771606" alt="-27.238" pitch="7.877" bank="358.2971" heading="85.28137" imageComplexity="VERY_SPARSE" altitudeIsAgl="TRUE" snapToGround="FALSE" snapToNormal="FALSE">
<LibraryObject name="{A0816D88-A51A-4730-9993-87603822684B}" scale="0.964387" />

The alt="-27.238" is correct, but the snapToGround overrides the altitude. This example is from the asobo-airport-eg78-outskerries detailed airport.
 
I think we missed the bug. Here's an example:

error.png


a) is Airport2Project output. It's altitude is wrong.
c) is what BGLViewer sees in the Airport2Project BGL.
b) is MSFSBGLXML output. It's right.
d) is what BGLViewer sees in the default BGL.
e) is what BGLViewer sees in the MSFSBGLXML BGL.
f) is a machine lang view of the MSFSBGLXML BGL. It shows AE 6C FF FF and shows -37714 as a longint... the posssible solution.

It seems BGLViewer and Airport2Project as interpreting the number as a word rather than as a longint.
 
With SU9 we have a change in the way polygons are formed. They are now coded in an XML format. It seems the old shapefile method still can be compiled, but going forward, I'm sure this will change. The default airports now reside in the fs-base-genericairports folder (D:\MSFS\Official\Steam\fs-base-genericairports in my computer).

Attached is a stub-airport, with the new polygon code. A couple of polygons:

XML:
    <Polygon altitude="300.01978064235300">
        <Attribute name="UniqueGUID" guid="{359C73E8-06BE-4FB2-ABCB-EC942F7761D0}" type="GUID" value="{82E1FD14-CA23-44CB-A38F-23D76FC80EF0}"/>
        <Attribute name="FlattenFalloff" guid="{5548FDB5-2267-4328-8E6F-FD0A45ADEC8F}" type="FLOAT32" value="10.000000"/>
        <Attribute name="FlattenMode" guid="{065E9D4D-6984-4D2A-91FD-3C33C4F53B22}" type="UINT8" value="1"/>
        <Attribute name="ExcludeDetectedBuildings" guid="{5C1A2387-1F07-47DF-A569-962CF6258E55}" type="UINT8" value="1"/>
        <Attribute name="ExcludeOSMBuildings" guid="{F3C2635D-9F2F-458F-8663-90B3837BED09}" type="UINT8" value="1"/>
        <Attribute name="ExcludeMSBuildings" guid="{F78A3074-8AD5-4B8B-92C4-C1C948BB7AA5}" type="UINT8" value="1"/>
        <Attribute name="VegetationScale" guid="{6A043F59-E6F2-4117-A2E4-D510E7317C29}" type="UINT32" value="127"/>
        <Attribute name="MaterialFalloff" guid="{C17EBBDE-627D-4585-94F0-7C329CD69C4E}" type="FLOAT32" value="3.000000"/>
        <Attribute name="MaterialColoration" guid="{B140B3CC-5887-449C-95CE-98D9E900CB58}" type="UINT32" value="-14328269"/>
        <Attribute name="ExcludeTIN" guid="{18B58CBF-AE02-4A19-8AA9-3809E8E73400}" type="UINT8" value="1"/>
        <Attribute name="VegetationDensity" guid="{41EFF715-C392-4B31-A457-50A504353A90}" type="UINT32" value="31"/>
        <Attribute name="Layer" guid="{9E2B4C3E-7D84-453F-9DCC-B6498FF46703}" type="UINT32" value="1"/>
        <Attribute name="BiomeName" guid="{E5FA1B20-BB2F-40D5-913B-480C547CC9B8}" type="STRING" value="Date_Tree"/>
        <Attribute name="ExclusionFlags" guid="{4CACC252-E6DC-419A-B20C-16EC601DF70E}" type="UINT32" value="15"/>
        <Vertex lat="42.62946893231210" lon="-88.60061064161160"/>
        <Vertex lat="42.62947659399846" lon="-88.60025031375179"/>
        <Vertex lat="42.62976554233875" lon="-88.60025562198497"/>
        <Vertex lat="42.62976553739847" lon="-88.60062085006744"/>
    </Polygon>
    <Polygon groupIndex="1" altitude="294.22157698911542">
        <Attribute name="UniqueGUID" guid="{359C73E8-06BE-4FB2-ABCB-EC942F7761D0}" type="GUID" value="{A5A84E4A-F819-4A2A-BF20-308CB429823F}"/>
        <Attribute name="MaterialGUID" guid="{CD28EFD0-D3F0-43B6-9F88-4E4707344A04}" type="GUID" value="{2B809652-F4C3-4622-A698-9DEBD0B8A0A7}"/>
        <Attribute name="MaterialTiling" guid="{58D2D4FF-1657-4AB0-BDB2-09B2D8A77688}" type="FLOAT32" value="12.000000"/>
        <Attribute name="MaterialFalloff" guid="{C17EBBDE-627D-4585-94F0-7C329CD69C4E}" type="FLOAT32" value="3.000000"/>
        <Attribute name="MaterialRotation" guid="{A27E9C0F-D3F5-4FB2-B020-82179BDB622D}" type="FLOAT32" value="0.680678"/>
        <Attribute name="MaterialOpacity" guid="{591218A9-7B17-40CC-B38C-57A201A20C1D}" type="UINT8" value="246"/>
        <Attribute name="MaterialColoration" guid="{B140B3CC-5887-449C-95CE-98D9E900CB58}" type="UINT32" value="-14192585"/>
        <Attribute name="Layer" guid="{9E2B4C3E-7D84-453F-9DCC-B6498FF46703}" type="UINT32" value="-1"/>
        <Vertex lat="42.63057123681902" lon="-88.60064051860233"/>
        <Vertex lat="42.63018255097286" lon="-88.60067834447477"/>
        <Vertex lat="42.63014394887865" lon="-88.60031860099645"/>
        <Vertex lat="42.63055878170507" lon="-88.60034160380218"/>
    </Polygon>

Untitled.png
 

Attachments

  • Basic-LakeLawn.zip
    32.5 KB · Views: 163
Here are the same polys without the airport stub (attached).

The polys cannot be read by CVXExtractor, and the BGLViewer doesn't work right either. Also, these polys cannot be viewed by tmfviewer, which tells me they are a different animal then the original polygons. There is a need to find a means of decompilation.
 

Attachments

  • LakeLawnPolys.zip
    26.9 KB · Views: 151
Hi Dick:

Considering the results I had using Airport2Project cited here:

https://www.fsdeveloper.com/forum/threads/changes-for-su9.455227/post-901849

...it seems that this utility will also require another innovative and generous update by Patrick Germain. :wizard:


AFAIK, ARP2Proj v1_0_0_19:

https://www.fsdeveloper.com/forum/attachments/airport2project_1_0_0_19-zip.81475/

...detected / output no "new" MSFS SU9-version Polygon type code for the example ICAO's I tested in the thread linked to above from this same post. :oops:


PS: Please see the edits in my post linked above... apparently 'some' CVX terrain-type vector 'Polygons' are still "Alive and Well", and can be viewed in TMFViewer, and can also be de-compiled via CvxExtractor. ;)

But for vector types intended to be- / not yet- ported from CVX format into "airport" XML code, how long will MSFS maintain retro-compatibility ? :rolleyes:

Perhaps we might benefit from a new output type in CvxExtractor that internally converts CVX vector code to the new MSFS SU9 SDK XML "Polygon" code ? :idea:

GaryGB


GaryGB
 
Last edited:
In addition to the above there are a few other changes from bglcomp.xsd from SDK 17

ctVectorPlacement appears to be updated

1651658824156.png


ctLowResAltitude appears to be a new attribute for scenery objects

1651658906702.png


ctVisualEffectObject appears to be a new scenery object type for scenery objects

1651659001985.png


ctAttribute appears to be a new element inside ctPolygon

1651659117602.png
 
Last edited:
I posted a new version of BglViewer to address the polygon issue. Let me know of any issue . Thanks
I must be having a very dim day but I am not able to find a download for the currrent BglViewer :(
 
Airport2Project prevede di leggere i file dalla cartella ufficiale (fs-base). Quindi se selezioni un file aeroporto (APX*.bgl), il codice A2P cerca il file NAV corrispondente nella cartella fs-base-nav
It seems that I still have some problems seeing the <COMs>.
I'm at FNMQ (H: \ MSFS_2020 \ Official \ OneStore \ fs-base-genericairports \ scenery \ 0604 \ APX52340.bgl) I went to see the correspondent:
H: \ MSFS_2020 \ Official \ OneStore \ fs-base-nav \ scenery \ 0604 \ NAX52340.bgl but there is no <COM> at this airport

I redid the same procedure with FNUG because in NAX52340
there are only two airports with <COM>.
But even on this (FNUG), Airport2Project does not display <COMs>

Regards

Immagine 2022-05-12 193930.jpg


Immagine 2022-05-12 195317.jpg
 
version 1_0_0_20 has an error.

<Vertex lat="42.62946367264" long="-88.60061645508" /> should be...

<Vertex lat="42.62946367264" lon="-88.60061645508" />
 
Version 1.0.0.21 fixes 2 issues :
- Vertex longitude ("lon" and not "long" : thanks Dick)
- Due to change from fs-base to fs-base-genericairports (again a great thank you to Asobo for supporting developers worldwide by shuffling names and ids with each release), COM and NAV objects were not added to the XML file
 
One last minor issue: the search looks for fs-base and fails. Should look for fs-base-genericairports, for the lat-lon area search.
Untitled.png
 
Hi Dick:

AFAIK, the MSFS' default "Generic Airports" are supposed to have Boundary Fences in the "Airport XML" code. :coffee:

If that is no longer the case, where else can we find these objects (...or should I say: where / how do we 'derive' them) ?


https://docs.flightsimulator.com/ht...cilities/Airport_Definition_Properties.htm#h2

https://docs.flightsimulator.com/ht...port_Definition_Properties.htm?rhhlterm=Fence

https://docs.flightsimulator.com/ht...ts/VectorPlacement_Objects.htm?rhhlterm=Fence


Airport2Project_1_0_0_21 does not interpret and generate XML for Boundary Fence objects in my current tests at KMKJ.

https://www.fsdeveloper.com/forum/threads/terrain-mesh-issue.455340/


ARP2PROJ does, however, interpret appropriate attributes for (deleteAllBlastFences and deleteAllBoundaryFences) in the <DeleteAirport> element


BTW: Do we have any further info on what is changed in MSFS airport infrastructure when ApplyFlatten is set to "TRUE" in ARP2PROJ XML ? :scratchch

https://docs.flightsimulator.com/ht...finition_Properties.htm?rhhlterm=ApplyFlatten


AttributeDescriptionTypeRequired

applyFlattenGenerate flattening rectangles on the airport based on runways altitude and inclination.BooleanNo


FYI: Airport2Project_1_0_0_21 does interpret and generate XML for ApplyFlatten with a parameter value of either "TRUE" or "False".


However, it is still not clear (to me at least), what results with any aspect of rendering within Kilometers of a ARP test radius when set to "TRUE". o_O


IIUC, this seems as though it may be an On / Off toggle to enable / disable implementing changes defined by RunwayDeformation:

https://docs.flightsimulator.com/ht...y_Definition_Properties.htm#runwaydeformation

https://docs.flightsimulator.com/ht...ct_Definitions.htm?rhhlterm=RunwayDeformation

https://docs.flightsimulator.com/ht...nery_Objects/Scenery_Object_Definitions.htm#h


FYI: Airport2Project_1_0_0_21 does interpret and generate XML for RunwayDeformation with parameter values at KMKJ.


GaryGB
 
Last edited:
AFAIK, the MSFS' default "Generic Airports" are supposed to have Boundary Fences in the "Airport XML" code. :coffee:

If that is no longer the case, where else can we find these objects (...or should I say: where / how do we 'derive' them) ?
The code for the generic airports is old code. Nothing has been redone for them in a while. I think they simply don't have boundary fences.
 
Back
Top