Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
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 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.
For scenery:
The new vector placement tool is broken. It will be fixed for SU10. Don't use it.
Polygons are now saved as XML code, and can be found right in the airport xml code. Polygons can also be used without airport code. They can no longer be seen in the TMFViewer.
...\asobo-airport-knfl-nas-fallon\scenery\Nas_Fallon\KNFL.bgl contains the newly created polys within the airport file. I'm pretty sure it also used the vector placement tool.
...\asobo-airport-kcof-patrickafb\scenery may have the old Shapefile method in the shapes.bgl, and new polygons (or fences) in the airport bgl.
IIRC, legacy FS versions were able to place 3D objects such as Airport Boundary fences and lines of library objects via BGLComp XML code, provided the coding was generated correctly using ex: a 3rd party utility such as ADE, SBuilderX, IS3 etc..
Legacy CVX vector code compiled by FSX / P3D SDK SHP2VEC was also able to auto-place default and/or custom "Meta-Objects" consisting of 3D models attached to vector objects at assigned intervals (pre-defined in Terrain.Cfg) as a type of 'Vector Autogen'.
IIUC, apparently you refer to how MSFS Airport-related XML code has now inherited some vector placement features for "Meta-Objects" that are not specifically Terrain object-related, thus you refer to the object type cited in this MSFS SDK Doc ?
Polygons are now saved as XML code, and can be found right in the airport xml code. Polygons can also be used without airport code. They can no longer be seen in the TMFViewer.
IIUC, when you use the term "Polygon" in the context of this thread (thus far), you refer to textured / painted ground markings and/or Ground Polygons (aka "G-Polys"), and not 'Terrain' vector objects such as Flat / Level and/or Sloped Airport Flattens (Airport Boundary / Background vector type) ...as previously implemented in FS legacy versions via Terrain.Cfg ?
I shall 'transplant' my prior comments and inquiry regarding "Terrain" vectors previously posted in this thread ...into a separate (and future) thread.
However, IIUC, technically we can see SU9 MSFS SDK may be intent on changing future methods for how "Terrain" type vector objects are implemented.
Furthermore, one might wonder if Rectangle Grids configured within SDK Terra-Forming Profile mode may replace other local terrain mesh tile methods.
Yet for many airports, as of SU9, Polygon-based "Terrain" flattens (aka legacy 'CVX vector Airport Boundary / Background') objects are still present inside CVX*.BGLs alongside the APX*.BGLs, and are able to be viewed in TMFViewer, as well as de-compiled by Patrick Germain's CvxExtractor:
[ MSFS-2020_Packages path ]\Official\OneStore\fs-base-genericairports\scenery\[ Area # ]\CVX*.bgl
I believe we may benefit from a new output type in CvxExtractor that internally converts CVX vector code to the new MSFS SU9 XML "Polygon" code.
But I also believe many of us would still want to retain the ESRI Shape *.SHP output option in CvxExtractor for use with other non-SDK GIS applications.
Personally, I plan to continue use of Global Mapper and Sketchup for certain "Terrain" development activities, and would welcome the ability to import that GIS source data via the ESRI Shape *.SHP file format ...into MSFS DevMode (and ADE).
Perhaps we may also benefit from having an ability within CvxExtractor to de-compile ESRI Shape *.SHP files output by other non-SDK GIS applications, then internally convert that vector code into MSFS' SU9 XML "Polygon" code for DevMode / ADE use ?
UPDATE: (July 2022)...
FYI: There is still a way via MSFS SDK DevMode GUI, to save ESRI SHP files of ones vector data for Polygons, without all such object code ending up saved within the "airport" AFD XML file used for a project:
For scenery:
The new vector placement tool is broken. It will be fixed for SU10. Don't use it.
Polygons are now saved as XML code, and can be found right in the airport xml code. Polygons can also be used without airport code. They can no longer be seen in the TMFViewer.
Could you elaborate on what's broken with the vector placement tool? I've just replaced a whole heap of fences and hedge rows in my airport using the new tool and now I'm worried by your comment that its incompatible with something.
It is very unstable. SimObjects that compile without error with fspackagetool.exe crash the sim without warning, once selected through the Scenery Editor.
Polygons are pretty challenging. Trying to outline an area in water, so the photo derived underwater features show through, results in a kind of depressed Sargasso Sea. Looks fine from a plane however!
I suppose I could retrace the area and set a second polygon for "terraform," because a water override polygon will do only that - they also add grass, for whatever reason, however dragging a terraform polygon to numeric sea level zero with six decimal places of precision is itself a joy, because just being able to type "0" would be too easy.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.