1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Ramblings on Scenery Compilers (and de-compilers)

Discussion in 'Tools programming' started by scruffyduck, 16/2/07.

  1. scruffyduck

    scruffyduck Administrator Staff Member FSDevConf team Resource contributor

    Joined:
    17/9/05
    Messages:
    23,292
    Country:
    wales
    I wrote some of this in a post in the XML forum 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. 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.
  2. Mace

    Mace

    Joined:
    2/12/06
    Messages:
    997
    Country:
    us-missouri
    Nice ramble. I think the tweaker idea is a sound one. Offhand I was not aware of any features that AFCAD2 compiled, that FSX bglcomp did not. On the other hand FSX has some things like BlastFences that are not in FS9/AFCAD. Possibly AFCAD2 is less strict on its processing of distant objects from the Airport Reference Point, whereas fsx bglcomp throws a warning...which may be tangentially related to what you describe.

    I think the idea of using the fsx bglcomp compiler as the standard compiler is a good idea.

    It's a pity we cannot have the full and complete BGL file structure without having to guess or hex edit. Then we would know everything that's in there, and how to adjust it. I guess they don't want to sanction decompilers and modding their copyrighted bgl's, which is quite understandable. Just the fiddler in me would be interested in it.

    In a related vein, at present I think the biggest roadblock for the lower-to-normal-level FSX designer (i.e. a person who is knowledgeable enough to use AFCAD, but does not mess with the minutiae of xml and command-line tools) is the lack of a gui frontend for FSX airport/parking/etc. design. If there were an AFCAD-like front end, it would (I predict) result in a rapid proliferation of FSX afcad-like scenery addons.

    Even faster would be the ability to load FS9 bgl's (a la AFCAD) and then save/output them to FSX bgl's.

    When I made my KSTL scenery for FSX, I did it for proof-of-concept as much as anything else. I found the whole process of decompiling, editing xml, copying, cutting, pasting, head-scratching over various bglcomp error messages, recompiling, loading the sim, and reloading scenery to be quite time-consuming. A person must be detail-oriented and must keep at it.

    And, as you mention, I did have to do considerable manual adjustment and addition to the decompiled xml. There is/was simply no easy way to do it.

    Not having a native FSX gui front end with FSX compiler for some of the design phases probably, (I would estimate) added at least 50% to the development time, at least in my case.
  3. scruffyduck

    scruffyduck Administrator Staff Member FSDevConf team Resource contributor

    Joined:
    17/9/05
    Messages:
    23,292
    Country:
    wales
    .


    Certainly there are things like apron light spacing and intensity. ACES are aware of this and things may change on that front.

    Also AFCAD circumvented some of the limitations imposed by BglComp - not necessarily a good thing

    I think it is the only way to go otherwise we are ignoring standards set by the designers



    The bgl format is quite old and parts of it certainly do not come from Microsoft. It is a copyright format and we can assume that it will not be released to the public domain.

    We are working on it :)

    SDE is pretty good at doing that now

Share This Page