-
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.
ADE v1.20: co-mingling obx and apx data
- Thread starter Mace
- Start date
- Messages
- 34,854
- Country
-
Rhett
Perhaps you could expand a bit on your concern.
OBX files contain a lot of information including the placement of generic building and library objects at an airport. The only objects from an OBX file that are currently read only are the autogenerated buildings. The reason for this is that we are still looking at the best way to handle them ADE knows what they are and where they are located. We find that they are all st to a heading of 0.0 and the orientation of the object itself is locked into the model. We expect to be able to handle these better in a later version
Jon,
my concerns are related to Scott's in this thread:
http://www.fsdeveloper.com/forum/showthread.php?t=9326
I have had to decompile, cut and paste, recompile, etc. many times, mostly related to object data, but also related to approach data too.
As you know, Microsoft segregated obx and apx (and of course other files such as cvx shp2vec files).
But I do share the view that "Airport Scenery" should be the goal of ADE and to that end, I suppose co-mingling is necessary and desirable.
my concerns are related to Scott's in this thread:
http://www.fsdeveloper.com/forum/showthread.php?t=9326
I have had to decompile, cut and paste, recompile, etc. many times, mostly related to object data, but also related to approach data too.
As you know, Microsoft segregated obx and apx (and of course other files such as cvx shp2vec files).
But I do share the view that "Airport Scenery" should be the goal of ADE and to that end, I suppose co-mingling is necessary and desirable.
- Messages
- 8,893
Mace
MS also segregated obx and obx1's for the same airport.
In many cases the same NDB's (Terminal vs non-Terminal) are listed twice in 2 different files then stack on top each other based on lat/lon.
Many airports have 6 pieces of scenery called towers that are in different bgl files and then also a Tower in the APX that does not work correctly.
We have to work with what FSX does which requires looking for all areas that make up one airport.
The 8 x 8 rectangles that reference scenery /vector data that is present within a area (Terrain and Scenery SDK) does not mean the entire airport is only in one of those areas.
Facility files are geographically divided with each file covering a grid square and the name of the file (e.g. APXnnnn.bgl) which contains the grid address. A airport may be on the cusp of one or more grid squares and we must search all files (possibly up to 4) that intersect the largest search square. There is also the Base, Country, Region, City and Global folders that have many parts of the airport that are not in a APX, OBX or a CVX.
Factor the multiplier of 4 x multiple bgl's that can make up a airport and ADE makes it look simple. The reconstruction of a stock airport is very very complex. Jon and the development team has spent months on working through the maze of bgl's so the ADE grid puts it all together from code behind the scenes.
Example would be trying to find airport runway records and then looking for a copy of the ILSs (up to 4 or more per runway) that associate with a runway. That is what some FSX utilities do which is not very reliable. You end up with what is called a User ILS stacked on top of the Stock ILS which may or may not be the correct ILS in a compiled (User) bgl.
In one of our previous conversation you ask for a white paper from MS. MS never designed FSX or a SDK that says we can 'reconstruct' an airport based on their bgl's. If you carefully study the thought process of the SDK we are allowed to 'construct' a duplicate airport using hand written XML and then add to, or block certain portions of the it.
We have to go all the way back to FS2002 and thank the late John Stottlemire (Add a Gate) and Lee Swordy (AFCAD 1.0) for setting a precedence that unlocks airport data regardless of where it is co-mingling and then put it all together on a Grid so it appears as one single User bgl.
hope this helps
MS also segregated obx and obx1's for the same airport.
In many cases the same NDB's (Terminal vs non-Terminal) are listed twice in 2 different files then stack on top each other based on lat/lon.
Many airports have 6 pieces of scenery called towers that are in different bgl files and then also a Tower in the APX that does not work correctly.
We have to work with what FSX does which requires looking for all areas that make up one airport.
The 8 x 8 rectangles that reference scenery /vector data that is present within a area (Terrain and Scenery SDK) does not mean the entire airport is only in one of those areas.
Facility files are geographically divided with each file covering a grid square and the name of the file (e.g. APXnnnn.bgl) which contains the grid address. A airport may be on the cusp of one or more grid squares and we must search all files (possibly up to 4) that intersect the largest search square. There is also the Base, Country, Region, City and Global folders that have many parts of the airport that are not in a APX, OBX or a CVX.
Factor the multiplier of 4 x multiple bgl's that can make up a airport and ADE makes it look simple. The reconstruction of a stock airport is very very complex. Jon and the development team has spent months on working through the maze of bgl's so the ADE grid puts it all together from code behind the scenes.
Example would be trying to find airport runway records and then looking for a copy of the ILSs (up to 4 or more per runway) that associate with a runway. That is what some FSX utilities do which is not very reliable. You end up with what is called a User ILS stacked on top of the Stock ILS which may or may not be the correct ILS in a compiled (User) bgl.
In one of our previous conversation you ask for a white paper from MS. MS never designed FSX or a SDK that says we can 'reconstruct' an airport based on their bgl's. If you carefully study the thought process of the SDK we are allowed to 'construct' a duplicate airport using hand written XML and then add to, or block certain portions of the it.
We have to go all the way back to FS2002 and thank the late John Stottlemire (Add a Gate) and Lee Swordy (AFCAD 1.0) for setting a precedence that unlocks airport data regardless of where it is co-mingling and then put it all together on a Grid so it appears as one single User bgl.
hope this helps
Last edited:
- Messages
- 34,854
- Country
-
There is no technical reason why airport and scenery data should not be in the same bgl file. The philosophy of ADE is to create on file for BglComp elements and one for Shp2Vec elements. Whist we could sub divide the BglComp elements there does not seem to be any practical benefit as far as FSX is concerned in doing so.
We have a patch release almost ready for ADE that will unlock the stock objects that are currently Display only and make them accessible to move, edit or delete.
We have a patch release almost ready for ADE that will unlock the stock objects that are currently Display only and make them accessible to move, edit or delete.
Actually Microsoft doesn't segregate OB and AP "data" into different types of files. AP files include airport data which includes many scenery objects. OB files do include objects, but you can run a simple quick test - move / rename the OB file for a complex, but not custom, stock airport - see how much of the scenery objects are part of the AP file.
BTW - the X is the version # of FS, not part of type of file.
There are many scenery library objects in AP files - including many localizer antennas, many VOR antennas, many NDB transmitters, glidepath transmitters, windsocks, fuel station objects, and many, many more.
The AP file is limited as far as I can tell to airport objects - and Microsoft deals with two separate sections of the airport in the default files.
The first which we are most familiar with is the data included under the airport header. Lee Swordy only worked with those elements in his program.
The second is actually above the airport headers at the top of the AP file - and includes most of the library objects for airports in that file.
Before we were always working with just a part of the airport. This version of ADE gives us a properly structured file per the BGLComp SDK for a single airport.
Much data and information for the airport is placed correctly above the airport header.
This is a capability we've never had before - and comes much closer to putting an airport correctly in the minimum number of files.
Yes, we could not do things that way in FS2004 - because the tool we used would scrub out all the parts of the airport, both above the header and under the header, which that tool did not understand.