BGLCOMP Compilation problem

[hjwalter]

Hi All,

 

In my FS9 addon version of the rather complex OMAA (Abu Dhabi) airport I've made quite some changes via the old Afcad program, especially concerning the ugly black taxiways, aprons, etc. and have changed them all, either into asphalt or concrete. Maybe not like it actually is in real life but just to make it look better for my own personal FS9 taste.

 

The way I've done this is by de-compiling the AF2_OMAA.bgl file into an XML file and then making all my changes and some minor error corrections in it.

 

However, when trying to compile the resulting XML (837Kb) file I get a message saying: FATAL ERROR: Airport Output Buffer OVERFLOWERROR C2470: Unrecoverable error parsing XML!

No other error messages before this one because I had previously corrected them all.

 

This "output buffer overflow" error sometimes also happens when compiling old SCASM based SCA texture files but that has the simple solution for increasing it's output buffer by adding a few (buffer extension) lines in the input SCA file.

 

Does anyone know of something (preferrably) simple to increase the output buffer size for the XML compilation process ?

 

Regards and thanks in advance for any reactions/solutions.

 

Regards

 

Hans

 

 

 

[chris_eve]

Can't help directly, but a quick "Google" for "OVERFLOWERROR C2470" came up with a short thread on FSDeveloper.com (which the software here won't allow me to include!)

Possibly too many vertices in a polygon?

It may be worthwhile trying to re-compile the original disassembled code, just to make sure it's good to begin with.

If so then you may have to isolate the changes you've just made individually to see where the problem lies.

Some older compilers, AFCAD2 and SCASM for example, and the compiler used by UK2000, (which may be an in-house specific piece of software), can/will assemble code into apparently working scenery which, when decompiled, won't recompile using BGLCOMP, as I've found through experience.

Whether the issues are caused by the original compilation or by the de-compiler I don't know, but I've had to redraw a few polygons over the years to suit my tastes ;)

Good luck :)

[hgschnell]

Hi Hans,

 

did you try "extended compile" complx split in ADE9?

 

 

[Tom Gibson]

Yeah, the file is probably too large, or has too many aprons, vertices, or other objects.  AFCAD did not have such limitations (it used its own compiler).  Putting into ADE and using split compile as suggested above might work, though.

[hgschnell]

21 hours ago, hjwalter said:

The way I've done this is by de-compiling the AF2_OMAA.bgl file into an XML file and then making all my changes and some minor error corrections in it.

If the complex split is not successful, divide the XML code more.

You are able to work with XML, so you can divide the XML in several APRON, objects parts if necessary.

[hjwalter]

Hi Guys,

 

Opening the original AF2_OMAA.bgl airport in ADE9 and then immediately re-compiling it, causes ADE9 to crash, also when done via the "extended compile" procedure. So in this case no joy with ADE9 in which I had also noticed that it uses the same BGLCOMP program as the one from which I got the original "overflow" error message. Strange though that ADE9 just crashes without any such "overflow" error messages.

 

However, I did split the de-compiled XML up into part1 containing everything EXCEPT the aprons and into part2, which contained ONLY the aprons ...... and ...... to my great surprise, both were compiled via the BGLCOMP program without any error messages. Even the visible results of these two new files seemed to be as I had hoped for. WOW !!

 

The only (possibly technical) problem left is that a duplicate airport has now been created because of the two exact same airport header data sections in each active part.

 

But anyway Guys, thanks for your suggestions and help. I've learned a lot from them amd all I now need to do is to make the decision, between having a duplicate airport with better looking taxiways etc. or a single one with the ugly black taxiways. I think I will just flip a coin !!

 

Thanks again and regards.

 

Hans

 

 

 

 

[hgschnell]

Hi Hans,

you are on a fine way.

 

Just edit your "Apron part" xml and delete all besides Aprons and recompile.

[hjwalter]

hgschnell,

 

I tried what you suggested by removing the airport header data from the "Apron part" and then compiling the resulting XML via BGLCOMP but that only produced an error list of about a meter long. After correcting a few things, which I hoped would make BGLCOMP feel a little more happy, I noted that the errors were mainly about missing geographical and elevation elements, which these very specific types of (apron-)polygons evidently need for positioning relative to those elements.

 

The only thing I could now do is to make all the necessary apron polygons myself and to compile them into a "normal" scenery BGL to be placed amongst the other scenery BGLs. However, I'll need a Monk to do that because it entails a tremendous amount of work.

 

Conclusion: I will just flip the coin as I've said before.

 

Hans

 

P.S. This whole issue was definately not a matter of life or death but just one of keen interest on my part but which also brought up the question about how the original author(s) had managed to compile their very large Afcad file without "overflows" and/or ADE9 crashes.

 

 

Quote

 

 

[hjwalter]

Please disregard my final question because the original Afcad file was set up via the Afcad program, which has no size limitations like BGLCOMP has.

 

Hans

[Tom Gibson]

It's no problem to have two airport files, so just leave things alone and you will be fine.  The only way you would get into trouble is if the files had different airport ref points, which they do not.

[hgschnell]

14 hours ago, hjwalter said:

I tried what you suggested by removing the airport header data from the "Apron part" and then compiling the resulting XML via BGLCOMP but that only produced an error list of about a meter long.

Sorry about misleading you.

Aprons are different from objects, where "divide and rule" works.

[hjwalter]

hgschnell,

 

No problem about "misleading you", This whole, for me very interesting "issue", has only added to my knowledge and ......... has kept me off the streets and out of sleasy bars for many hours !! LOL.

 

Yes Tom, I agree with you but only when it concernes FS9 itself. In my mind however, third party programs such as e.g. FSNav, ATC and possibly a few others, could and I repeat "COULD", cause potential problems and especially when the same processing priority of the two duplicate airport files, cannot always be guaranteed, predominantly because of their different sizes and different further contents.

 

Regards.

 

Hans

 

 

 

 

 

 

 

[Tom Gibson]

That is true Hans.

[SCM0616]

Why not try from the other direction and simply replace the taxi_bitu texture to something more to your liking?  It has its limitations, but at least you can get rid of the pitch black surface.
Of course, make a backup of the original in case you want to restore it. 

[hjwalter]

SCM0616,

 

I had already begun doing as you propose with the original Afcad file but I immediately ran up against a multitude of direct errors, overlapping ground textures of different colours, different taxiway widths and same apron routes. In fact so much so that I wanted to try converting the file to XML which seemed far simpler and less work to edit. In fact, that's what this thread is all about and additionally because I found the combination of XML, ADE9 and BGLCOMP very interesting, as I had practically no experience with any of them.

 

Anyway, since a few days I'm back at the original Afcad file again and have made many changes, which in fact only BEGAN with the ugly black taxiways. After that I will begin enhancing the airport itself by adding EZ library objects. Maybe not like the real airport should look but it will most certainly then look a lot less deserted.

 

Hans