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

[rhumbaflappy]

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.

 

[Patrick Germain]

I found a bug in the Airport2Project_1_0_0_17 version:

Hi Dick.
Version 1.0.0.18 fixes it.
Since the XML compiler ignores the SnapToxxx value, I output them as FALSE.
But the altitudeIsAgl is now supposed to be set correctly.

 

[rhumbaflappy]

I think we missed the bug. Here's an example:

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.

 

[Patrick Germain]

I think we missed the bug. Here's an example:
It seems BGLViewer and Airport2Project as interpreting the number as a word rather than as a longint.

Good catch ! See version 1.0.0.19.

 

[rhumbaflappy]

That's got it.

 

[rhumbaflappy]

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:

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

 

[rhumbaflappy]

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.

 

[GaryGB]

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.


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.


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 ?

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 ?

GaryGB

GaryGB

 

[Patrick Germain]

A lot of fun ahead.... I'm starting to truly hate these Asobo guys...

 

[scruffyduck]

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

ctVectorPlacement appears to be updated

ctLowResAltitude appears to be a new attribute for scenery objects

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

ctAttribute appears to be a new element inside ctPolygon

 

[Patrick Germain]

I posted a new version of BglViewer to address the polygon issue. Let me know of any issue . Thanks

 

[scruffyduck]

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

 

[rhumbaflappy]

Here's the BglViewer Thread

 

[Patrick Germain]

Version 1.0.0.20 of the Airport2Project is now available. Tries to fix the new Polygons of SU9
See first page of this thread for the zip file or :
Airport2Project_1_0_0_20.zip

 

[Bavarello]

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

 

[rhumbaflappy]

version 1_0_0_20 has an error.

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

<Vertex lat="42.62946367264" lon="-88.60061645508" />

 

[Patrick Germain]

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

 

[rhumbaflappy]

One last minor issue: the search looks for fs-base and fails. Should look for fs-base-genericairports, for the lat-lon area search.

 

[GaryGB]

Hi Dick:

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

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 ?

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

Attribute	Description	Type	Required

applyFlatten

Generate flattening rectangles on the airport based on runways altitude and inclination.

Boolean

No

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


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

 

[rhumbaflappy]

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

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.