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

Bgl2Xml beta

The program is just extracting whatever is in the bgl file. Are you asking that it change things or something else?
It seems so yes, it is not occurring with every afcad file but with certain ones the surface= value is not getting decoded properly, leaving a 3 digit code in quotes in some of the instances instead of the surface name. This does not happen when opening the afcad file with ADE.
 
Hmm the same decompiler is used with ADE. Can you please attach some of the problem bgl files to a post in this thread.
 
Hmm the same decompiler is used with ADE. Can you please attach some of the problem bgl files to a post in this thread.
For eg I was trying to decompile my tweaked afcad of AS EGLL which gave some instances of surface="132" and error compiling with bglcomp.
Edit: It seems the problem might be limited to AFX created afcads only, those created with ADE appear to decompile normally.
 
Last edited:
As far as I can see, it seems there is a problem with extraction of taxiwaysign records. Each record contains 2 duplicate lists of existing taxi signs that is [A, B, C, A ,B , C]
This is an example from extracting stock APX16160.bgl for 5J0 airport..but it seems all extractions are affected. Seems the problem also existed in v1.70. Of course, visually it doesn't change anything but after recompiling, BGL file size increases significantly ;-)
Could you check?

Hervé

<TaxiwaySign
lat="44.4094432890415"
lon="-118.962775021791"
heading="196"
label="m17"
size="SIZE3"
justification="RIGHT"/>
<TaxiwaySign
lat="44.397435209059"
lon="-118.963930273205"
heading="183"
label="m35"
size="SIZE3"
justification="RIGHT"/>
<TaxiwaySign
lat="44.403335399182"
lon="-118.963351171722"
heading="185"
label="m35-17"
size="SIZE3"
justification="RIGHT"/>
<TaxiwaySign
lat="44.3995885194856"
lon="-118.963760988707"
heading="200"
label="m35-17"
size="SIZE3"
justification="RIGHT"/>
<TaxiwaySign
lat="44.3999439089526"
lon="-118.964288508918"
heading="17"
label="m17-35"
size="SIZE3"
justification="RIGHT"/>
<TaxiwaySign
lat="44.4094432890415"
lon="-118.962775021791"
heading="196"
label="m17"
size="SIZE3"
justification="RIGHT"/>
<TaxiwaySign
lat="44.397435209059"
lon="-118.963930273205"
heading="183"
label="m35"
size="SIZE3"
justification="RIGHT"/>
<TaxiwaySign
lat="44.403335399182"
lon="-118.963351171722"
heading="185"
label="m35-17"
size="SIZE3"
justification="RIGHT"/>
<TaxiwaySign
lat="44.3995885194856"
lon="-118.963760988707"
heading="200"
label="m35-17"
size="SIZE3"
justification="RIGHT"/>
<TaxiwaySign
lat="44.3999439089526"
lon="-118.964288508918"
heading="17"
label="m17-35"
size="SIZE3"
justification="RIGHT"/>
 
Hi Jon,
in this version, the <noautogensuppession> tag is ignored if the BGL comes out from instant scenery (fsx).
In previous version, the tag appeared on the xml, even from IS files.
 
Thanks for letting me know. Can you please provide me with an example of the IS bgl files which are giving this result?
 
FSX SP2 Windows 7 The GUI works fine for me.

By fine, I mean that the few details that I have usually looked at in the past with this, I would not have noticed the situation mentioned by Herve in reply #24.
 
I have fixed the duplication of taxisigns in the output. I have not figured out why it was happening but I have foud a way to stop it
 
For eg I was trying to decompile my tweaked afcad of AS EGLL which gave some instances of surface="132" and error compiling with bglcomp.
Edit: It seems the problem might be limited to AFX created afcads only, those created with ADE appear to decompile normally.


I would like to see one or two bgl files that you have showing this error. The decompiler looks for surface types greater that 127 for P3D and versions of FSX which support the transparent flag. This is because the transparent flag sets the surface type in the surface number. It seems that AFX is generating such a number but not in relation to the transparent flag and thus the bad value is getting through.

Please either post a bgl file showing the problem as an attachment here or send an example to me via email - jon AT scruffyduck DOT co DOT uk. I will then try and fix it.
 
I have fixed the duplication of taxisigns in the output. I have not figured out why it was happening but I have foud a way to stop it
Thanks Jon. Will you provide a new beta or should we just wait for the final 1.80 ?

Hervé
 
I will try and provide an update once I have fixed another bug which is outstanding
 
I will try and provide an update once I have fixed another bug which is outstanding
Jon, did you progress on that, despite a well-deserved summer holidays rest if any

Hervé
 
I am sorry but I have been on another no ADE related project for most of the summer. I am hoping that it will wrap up in the next week or so. Then I will try and get back to things Flight Sim
 
Hi all,

Has anybody noticed that the new version seems a lot slower (v1.7 from the download link at the top of this Topic)? It's probably something I'm doing wrong (it usually is!) but I extracted about 1600 BGL files the other night and it took over 8 hours to complete (I run it in a harness that lets me batch process multiple files). The BGL2XML bit (in the command window) is taking tens of seconds per file. I'm probably wrong but I though it used to complete in a about a second?

Sorry in advance if I'm being a Doofus!

Regards

Ian
 
Last edited:
Didn't notice that but I never managed so many files in a single process. Jon will probably be able to reply, according to code changes he performed
Also hope he will be able to publish an update if he now have enough time for that.

Hervé
 
I can't really say. Performance is affected by a lot of different factors
 
Back
Top