I wrote some of this in a post at fsdeveloper.com and thought to put it here for others to comment on. This line of thought has come about as I develop SDE and watch the efforts of those people trying to update AFCAD2 files to work in FSX.
I am sure there are many ‘de-compilers’ out there for Scenery Files. Just about every scenery design program and flight planner will have some code to extract data from Bgl files. In most cases I would guess they are incomplete. I know of three generalized de-compliers that are available. BglXml, BglAnalyze (in several forms) and now SDE. None of them are perfect and that is more or less impossible because, one we are working with a file format for which there is no published schema, and two the process is not circular. i.e the compilation of XML results in a Bgl file which does not contain everything we put in so we have sometimes to guess at how to reconstruct the original. Of course there is no reason why we should be able to get back the input source from the output file.
AFCAD2 is probably one of the most widely used design tools and, although it was primarily developed to support AI Traffic is is used just about any time someone wants to modify an airport. This program clearly has a good ‘de-compiler’ built in. It also does it’s own compiling and that is where the interesting part comes.
The official compiler for FS XML based scenery is BglComp. There are two versions one which works with FS9 and one with FSX. Each of these represent the model way of doing things. Together with the associated xsd schema file they impose standards and rules on designers. In some cases this seems involve missing access to some parameters and limitations to counts and so on. To understand what happens when things go wrong it is necessary to realize that there are two places that generate errors, compliance with the schema and the internal compiler rules. Unfortunately there are places where these conflict.
AFCAD2 has it’s own compiler which (as far as I can tell) bypasses both the schema and BglComp standards and limitations. Of course it has to create Bgl files which are acceptable to the FS Scenery Engine otherwise it would crash. This provides both strengths and weaknesses – in the first place AFCAD can create things and set parameters that you can’t access via BglComp, in the second place de-compiling AFCAD2 files can generate problems especially if the intention is to update them for FSX. SDE is helping me find quite a few – generally when it dies ungracefully onto the Desktop.
Getting AFCAD2 files for FS9 into FSX appears simple of the face of it and for small airports the process of using a general decompiler and then putting the resulting XML through BGLComp yields good results for some. For more complex airports a number of problems turn up and there is a running thread on some of these on the XML forum at fsdeveloper.com. In many case there is manual (or assisted via SDE) modification of the XML code needed.
I have pretty much decided that SDE should use BGLComp to ensure compliant scenery is generated. However I have thought about direct compilation of Bgls and I am leaning towards the idea of a limited ‘tweaker’ for Scenery Bgl which would allow designers to access some of the parameters which do not seems available through the XML source. This would work a bit like Arno’s excellent Mdl Tweaker allowing users to access and modify certain parameters, those being things that cannot otherwise be worked with.
