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

BGLViewer for FSX BGL files.

Thanks Dick; it's interesting to see how this is getting "unpacked". :)


BTW: Some FSDevelopers here may find that their (virtual) reality constructs are being much too exuberantly 'reshuffled' by SU9.

Don't be surprised if someone considers a MSFS "GiraffeFence" as an 'offense' ...in and of itself. :laughing:


...Reminds me of the old SciFi classic movie "The Day of The Triffids". ;)

"...Bill creates a makeshift flame thrower to kill the triffids. It doesn’t work"

https://www.retrozap.com/wp-content/uploads/2019/06/SFS02-Triffids-06.jpg

https://www.retrozap.com/the-day-of-the-triffids-1962-sci-fi-saturdays/



PS: I could not find HLGH, but I did find this with the help of "Polygon" vertices in BGLViewer2020_2_16 and Google Earth:

https://www.google.com/maps/place/A...07a19f18ef!8m2!3d30.1257433!4d7.6587159?hl=en

https://www.africabizinfo.com/DZ/aéroport-menzel-ledjmet-est-mle

...which reminds me of: :rolleyes:

https://en.wikipedia.org/wiki/The_Flight_of_the_Phoenix_(1965_film)

GaryGB
 
Last edited:
Dick,
The altitude is read as a float and is indeed coded in meters, You may see it as feet because of the settings of the software (View -> Settings -> Imperial vs. Metric)
 
rhumbaflappy said:
Hi Patrick.

The only issue I have is the altitude expressed as feet (and as an integer). I also note the compiler changes the location of points and altitudes slightly... probably to fit into the QMID scheme.
Click to expand...

Hi Dick:

Can you refer us to an example of code that shows the change of location for points and altitude you alluded to above ?

[EDITED]

Might this be different for Polygons associated with airports which IIUC may be viewed as the MSFS equivalent of 'land class' types available for use as Aprons, that are GIS projected for "BGLComp equivalent" content purposes as EPSG:4326 EPSG:3857 ?

And AFAIK, that type of MSFS "Airport" content GIS projection would be distinct from how source data may be GIS projected for FS legacy format Terrain vector objects as EPSG:3857 EPSG:4326 ?

[END_EDIT]

GaryGB
 
Last edited:
Attached example of polygons.
 

Attachments

  • hlgh.zip
    49.5 KB · Views: 116
Hi Patrick:

Assuming further modifications to a decompilation engine for MSFS may see their way into Airport2Project and an updated CvxExtractor, as well as DLLs utilized by ADE or MSFSBGLXML, AFAIK, it might prove pertinent to mention my recent inquiry here:

https://www.fsdeveloper.com/forum/threads/project-saving.454364/post-902261


Thanks again for all your innovative and generous work to help us sort out the esoteric code of more recent FS versions. 🙂

GaryGB
 
Last edited:
rhumbaflappy said:
Attached example of polygons.
Click to expand...

Thanks again, Dick.

IIUC, Airport2Project_1_0_0_20 does not interpret an Airport Boundary / Background Polygon in your HGLH project attached above.

Can you create an 'airport flatten' at HGLH ...so we can use BGLViewer to see where / how SU9 codes Airport Boundary "Flatten" Polygons ? :scratchch


Thanks in advance for sharing any additional insights you may have regarding this aspect of the SU9 et seq. updated coding. 🙂

GaryGB
 
Last edited:
I think the airport flatten is in the airport definition... not as a polygon.

applyFlatten="TRUE"

BGLViewer shows this:
Untitled.png

And that is the flatten, as far as I can tell.
 
SU10 has added a couple of things. Projected mesh as an element of airports, and Light Supports as an element of airports.
XML: 
<?xml version="1.0"?>
<FSData version="9.0">
    <ProjectedMesh groupIndex="1" priority="15" drawOrder="APRON" surface="WATER" groundMerging="FALSE">
        <!--SceneryObject name: Isafjordur_Building05-->
        <SceneryObject lat="42.62883133116827" lon="-88.60115590187289" alt="0.00000000000000" pitch="0.000000" bank="0.000000" heading="-179.999995" imageComplexity="VERY_SPARSE" altitudeIsAgl="TRUE" snapToGround="TRUE" snapToNormal="FALSE">
            <LibraryObject name="{6EFB2218-A82E-4F3A-8C8F-7140D4E29925}" scale="1.000000"/>
        </SceneryObject>
    </ProjectedMesh>
    <Airport groupID="1" groupGenerated="FALSE" state="Wisconsin" city="Delavan" name="Lake Lawn" ident="C59" lat="42.63412501662970" lon="-88.60113054513930" alt="296.56999999999999" magvar="2.000000" trafficScalar="1.000000" airportTestRadius="10000.00000000000000" applyFlatten="FALSE" isOnTIN="FALSE">
        <LightSupport parentGroupID="1" groupIndex="1" latitude="42.63119138838181" longitude="-88.60165787172916" altitude="295.94641113281250" altitude2="305.94601440429688" heading="4.059667" width="24.054300" length="246.619217" excludeLights="FALSE" excludeLightObjects="FALSE"/>
        <LightSupport parentGroupID="1" latitude="42.63123057481369" longitude="-88.60112007318031" altitude="299.47775268554688" altitude2="299.47775268554688" heading="2.187848" width="50.000000" length="463.685852" excludeLights="TRUE" excludeLightObjects="TRUE"/>
        <ProjectedMesh parentGroupID="1" groupIndex="3" priority="1" drawOrder="TAXIWAY" surface="ASPHALT" groundMerging="TRUE">
            <!--SceneryObject name: Isafjordur_Building01-->
            <SceneryObject lat="42.62906114613339" lon="-88.60106764877104" alt="0.00000000000000" pitch="0.000410" bank="-0.000410" heading="148.437728" imageComplexity="VERY_SPARSE" altitudeIsAgl="TRUE" snapToGround="TRUE" snapToNormal="FALSE">
                <LibraryObject name="{77949C20-3875-42B1-9EF3-4292C5FD25E1}" scale="1.430000"/>
            </SceneryObject>
        </ProjectedMesh>
        <Aprons>
            <Apron parentGroupID="1" groupIndex="2" surface="{85D02B2B-08A1-452E-AB07-6D5AE7F52884}" drawSurface="TRUE" drawDetail="TRUE" localUV="FALSE" stretchUV="FALSE" flipUV="FALSE" priority="0" tiling="25.000000" heading="0.000000" falloff="0.000000" opacity="255" groundMerging="TRUE" excludeVegetationAround="TRUE" excludeVegetationInside="TRUE" isRectangle="FALSE">
                <Vertex lat="42.62875861741434" lon="-88.60132218324514"/>
                <Vertex lat="42.62855867144692" lon="-88.60131548518653"/>
                <Vertex lat="42.62854098796360" lon="-88.60144433083185"/>
                <Vertex lat="42.62868425978001" lon="-88.60153854539101"/>
                <Vertex lat="42.62877623110299" lon="-88.60144713618654"/>
            </Apron>
        </Aprons>
        <PaintedElements/>
        <ApronEdgeLights/>
    </Airport>
</FSData>

One LightSupport is acting as an exclusion here (taking out runway and taxiway lights and their objects within the rectangle). The other Light support raises one end of the selected light row area (runway lights), and displays as lights and their objects raised in the air on a slope.

The projected mesh is part of the Airport by default, although it can be ticked as "Individual" making it outside the airport. If the ProjectedMesh is outside the airport, then DevMode disallows the drawOrder, but it does display in the XML. If you change that from "APRON" by editing the xml, it makes no difference in the sim... it will still draw under the apron level.

I added an apron just for fun. BGLViewer shows none of this.

ProjectedMesh drawOrder: APRON, TAXIWAY, RUNWAY, MARKING, RUNWAY_MARKING, MARKING_TEXT

Edited--- correction to include ASPHALT...
ProjectedMesh surface: CEMENT, GRASS, WATER, ASPHALT, SHORT_GRASS, CLAY, SNOW, ICE, DIRT, CORAL, GRAVEL, OIL_TREATED, STEEL_MATS, BITUMINOUS, BRICK, MACADAM, PLANKS, SAND, SHALE, TARMAC, PAINT, ERASE_GRASS, UNKNOWN
 

Attachments

  • Basic-LakeLawn.zip
    26.6 KB · Views: 93
Last edited:
Hi Patrick:

Thanks so much for your help with this and your other FS utilities; IMHO, the FS Development Community would be lost without them. :)


FYI: I am doing a few tests of your new Bgl2020.dll, and this looks to be another brilliant and successful release, as cited here:

www.fsdeveloper.com

MSFS - Airport fixed elevation plz help!

ZIP the layout.json and manifest.json files into backup, then delete the originals in: [MSFS-2020_Packages install path]\Official\OneStore\asobo-airport-heca-cairo\ ...sub-folder Now if I start a flight at HECA, the A/C is at the altitude assigned by a custom airport BGL (in a Project or in a...
www.fsdeveloper.com www.fsdeveloper.com

Regards,

GaryGB
 
rhumbaflappy said:
ProjectedMesh drawOrder: APRON, TAXIWAY, RUNWAY, MARKING, RUNWAY_MARKING, MARKING_TEXT

ProjectedMesh surface: CEMENT, GRASS, WATER, SHORT_GRASS, CLAY, SNOW, ICE, DIRT, CORAL, GRAVEL, OIL_TREATED, STEEL_MATS, BITUMINOUS, BRICK, MACADAM, PLANKS, SAND, SHALE, TARMAC, PAINT, ERASE_GRASS, UNKNOWN
Click to expand...
Thanks for the heads-up Dick!
 
Patrick Germain said:
New version of BglViewer available : 2.0.0.18 (See 1st message of this forum)
- Light Support
- Projected Mesh
Click to expand...
The LightSupport isn't quite right. You have ID, Size, Latitude, Longitude.... But it should be ID, Size, ExclusionMask, Latitude, Longitude...
XML: 
        <LightSupport parentGroupID="1" groupIndex="1" latitude="42.63119138838181" longitude="-88.60165787172916" altitude="295.94641113281250" altitude2="305.94601440429688" heading="4.059667" width="24.054300" length="246.619217" excludeLights="FALSE" excludeLightObjects="FALSE"/>
The mask includes excludeLights and excludeLightObjects as a binary 00000000 with the lowest bit as a flag for excludeLightObjects and the second lowest bit as a flag for excludeLights.

That throws everything off a word.

I have this:
ID as word
Size as long
ExcludeMask as word (but used as a binary mask)
Latitude as 64-bit float
Longitude as 64-bit float
Altitude as 64-bit float
Altitude2 as 64-bit float
Heading as 32-bit float
Width as 32-bit float
Length as 32-bit float
 
rhumbaflappy said:
The LightSupport isn't quite right. You have ID, Size, Latitude, Longitude.... But it should be ID, Size, ExclusionMask, Latitude, Longitude...
XML: 
        <LightSupport parentGroupID="1" groupIndex="1" latitude="42.63119138838181" longitude="-88.60165787172916" altitude="295.94641113281250" altitude2="305.94601440429688" heading="4.059667" width="24.054300" length="246.619217" excludeLights="FALSE" excludeLightObjects="FALSE"/>
The mask includes excludeLights and excludeLightObjects as a binary 00000000 with the lowest bit as a flag for excludeLightObjects and the second lowest bit as a flag for excludeLights.

That throws everything off a word.

I have this:
ID as word
Size as long
ExcludeMask as word (but used as a binary mask)
Latitude as 64-bit float
Longitude as 64-bit float
Altitude as 64-bit float
Altitude2 as 64-bit float
Heading as 32-bit float
Width as 32-bit float
Length as 32-bit float
Click to expand...
Indeed : Data is correct but FileOffset was wrong
Version 2.0.0.18 has been fixed
 
Patrick Germain said:
Indeed : Data is correct but FileOffset was wrong
Version 2.0.0.18 has been fixed
Click to expand...
The raw Altitude2 is OK, but the interpreted is not.
Untitled.png

<LightSupport parentGroupID="1" groupIndex="1" latitude="42.63119138838181" longitude="-88.60165787172916" altitude="295.94641113281250" altitude2="305.94601440429688" heading="4.059667" width="24.054300" length="246.619217" excludeLights="FALSE" excludeLightObjects="FALSE"/>

...and both altitude values are a bit rounded off.
 
rhumbaflappy said:
The raw Altitude2 is OK, but the interpreted is not.
View attachment 84301
<LightSupport parentGroupID="1" groupIndex="1" latitude="42.63119138838181" longitude="-88.60165787172916" altitude="295.94641113281250" altitude2="305.94601440429688" heading="4.059667" width="24.054300" length="246.619217" excludeLights="FALSE" excludeLightObjects="FALSE"/>

...and both altitude values are a bit rounded off.
Click to expand...
Version 2.0.018 re-re-fixed :)

I need vacations!
 
We have a new entry for terrain polygons.
XML: 
<?xml version="1.0"?>
<FSData version="9.0">
    <Polygon altitude="285.76941021066159">
        <Attribute name="UniqueGUID" guid="{359C73E8-06BE-4FB2-ABCB-EC942F7761D0}" type="GUID" value="{F6AAE3CD-7AB1-485F-9AC0-C0F3D850F406}"/>
        <Attribute name="FlattenFalloff" guid="{5548FDB5-2267-4328-8E6F-FD0A45ADEC8F}" type="FLOAT32" value="5.000000"/>
        <Attribute name="FlattenMode" guid="{065E9D4D-6984-4D2A-91FD-3C33C4F53B22}" type="UINT8" value="1"/>
        <Attribute name="Layer" guid="{9E2B4C3E-7D84-453F-9DCC-B6498FF46703}" type="UINT32" value="2"/>
        <Attribute name="PreciseTerraforming" guid="{4D2A51D4-91AC-412F-833E-212CC10E5FBC}" type="UINT8" value="1"/>
        <Vertex lat="42.65035299568797" lon="-88.74516749936167"/>
        <Vertex lat="42.65087967508948" lon="-88.74615717334680"/>
        <Vertex lat="42.64992697114068" lon="-88.74605592594480"/>
    </Polygon>
</FSData>
It seems the value might not make a difference for PreciseTerraforming. Just the presence of the attribute forces the new terraforming. The absence of that line makes the old-style terrain polygons. The entry isn't in bglcomp.xsd, which probably isn't used for anything anymore.
The DevMode will always add this Attribute, and it will always have a value of 1. You can add any value in the XML by hand, and it will compile with that value, but it will show the same as 1.
 
Last edited:
Patrick Germain said:
Hi folks !

This is an application (.NET) I wrote to dump the content of a BGL file (and interpret the data), based on the wiki page http://fsdeveloper.com/wiki/index.php?title=BGL_File_Format that I'm trying to update a s much as I can.
Attached is the zip file (exe + dlls + config file) and a snapshot of the screen.

Enjoy!

PS : See also https://www.fsdeveloper.com/forum/threads/bglviewer-for-fsx-bgl-files.432840/post-885474 for FS2020
Click to expand...
Hello Patrick

Thank you very much for sharing your fabulous bgl2020 DLL. A real work of monk as we use to say in french to salute an exceptional work.
I started trying to write my own "bgl2020" reading https://www.fsdeveloper.com/forum/threads/bglviewer-for-fsx-bgl-files.432840/post-885474 and googling I discovered your post. It saved my life ;-)

I am using your dll inside a personal Visual Studio C# app to scan my Community and OneStore folders to collect Airports, Runways, Gates and Parkings. Until now I've found no "database" that suits my needs (MakeRunways, Little Navmap, VmsAcars, ProSim).

I got some trouble with some 3r party sceneries, for example LPMA from AmSim. Tracing the execution, I found that their AirportRecord seems to end with "0x00" records, length 0, in that case "fileReader.BaseStream.Position += bglNode.NodeSize - 6" makes the program looping and looping creating "all 0" bglNodes.

There are some undecoded 0x58 and 0x59, for example in SimAddons canadian sceneries (CYEG is one I remember).

Best regards,

Didier
 
You must log in or register to reply here.
Back
Top