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

FS2004 ADE9 does not compile any more

Then it seems your airport is too big for the compiler to handle
 
Thanks Jon,

in such cases a complex split was a solution... :(

If I get split xmls I could try to modify and compile them part by part.

Did you test my AD4?
 
I did a complex split for your project and got bgl files

1632149667469.png
 
The LTFM_ADE9_HGS.Bgl is very small and unusable for AFLT4 as Reference file.
But I will see what I can do, thanks Jon.
 
And I could find a solution.

I edited the LTFM_ADE9_HGS.xml and copied TXN and APR into it.
XML2BGL compiled it without error.
So I had a LTFM_ADE9_HGS.BGL at a descent size of 56kB and APN, OBJ and SGN.

These 4 BGLs work fine and my LTFM_ADE9_HGS.BGL has all infos to be used as reference file for AFLT4.

Background:

LTFM (Istanbul new Airport) got a 5th runway in 2019.
My freeware LTFM FS9 v1 had only 4 runways and so I added the new rwy 18/36 with taxiways, taxisigns and lights.

I will try to contact the creators of LTFM_FS9_v1 and offer them my changes.

Thanks for your help and perhaps is there anybody who can help me with my "Dusk/Dawn" problem.




LTFM1.jpg
 
Jon, perhaps you could think about your extended split.
The "AFCAD Split" does not work at all the way you split it.

My kind of split is necessary for AFLT4.
 
hgschnell said:
Jon, perhaps you could think about your extended split.
The "AFCAD Split" does not work at all the way you split it.

My kind of split is necessary for AFLT4.
Click to expand...
What split do you need? Bearing in mind that it may, in any case, fail due to the compiler failing
 
I think there should be OBJ, SGN, APN and the main with all other (like I edited it manually in LTFM above).

The AFCAD split should contain in the main bgl: TXN (runways, taxiways, parkings), comms, starts, and APN (Aprons).
OBJ, SGN, and APR cannot be changed by AFCAD2, so they should be separated.

(all for FS2004, I can nothing say about the other )

TER and ALT like now.

It is up to you of course, maybe Tom or Don could jump in and tell their opinium?

I know, there is always a limit, but in my monster LTFM the main bgl is only 57kB and the biggest is the SGN with 212kB.
 
Guenther, if I could perhaps attempt a simplification of what you seem to be suggesting, you are proposing that Jon keep runways, taxiways and aprons in one file rather than separating them. Of course, others who need a complex split may find such a consolidated file still too big to compile.

AFLT does not use apron data; it simply displays it. I can think of no reason why AFLT couldn't use standalone apron data as a separate project, allowing you to place apron edge lights. Similarly, I see no reason why AFLT wouldn't handle runway data normally in the absence of taxiway and apron data. There may be a minor issue with standalone taxiway data in that taxiway/runway intersections would not be apparent unless the file contained the runway links as well. But, if not, the worst result I can image is that filleting of taxiway lights at runway intersections may not happen. Since, for you, on;ly a single airport is of concern, maybe you could give it a try.

In the meantime, I will investigate whether AFLT could consolidate those three .xml files if they exist in the folder where AFLT is told to look for the airport .bgl/.xml.
 
No Don, not the aprons...
I think there should be OBJ, SGN, APN and the main with all other.

Let me know if there is another monster airport which does not work with this "balanced" SPLIT:
The AFCAD Split is another thing.

I think, if the "Main" Bgl contains runways and taxi lines, AFLT can easily transform their lights and approach lights to nicer AFLT lights.

I dont know many extreme large airports which go over the BGLComp limits of FS2004, so I can only ask for help, if I ran in these limits.

The AD4 file in my opening post was one of these airports.

The way the "complex split" works till now in fs9 creates a main bgl with Starts, Comms and not much more and it cannot be used for the AFLT4 reference file.
 
To be honest the Extended Compile function was created many years ago when there was still a decent community of FS9 users. I have looked for the code and it is what I would call closed. The compiled library still exists but the code, if I can find it, will be locked in an archive.

So I am sorry but updates to it are not going to happen.
 
Guenther, as promised, I have taken a look at having AFLT recognize when a complex split had been done and to create a consolidated .xml file that would enable AFLTs airport analysis capabilities. While not technically difficult, (as you know from having done the process manually), there are lots of opportunities for error, including user errors.

Given: this is a FS9 unique feature of ADE, the shrinking FS9 user base, that only a single airport to date has been reported to require this additional and a manual workaround is available, I'm not sure the effort involved and the risk of once again destabilizing AFLT is worthwhile.

I will, however, attempt to implement the capability, but may later decide arbitrarily to abandon the project, in which case you'll be left with the manual workaround.
 
Cheer-up Guenther. I just realized AFLT doesn't have to reconstruct the xml. All it has to do is decompile the base file (.bgl or .xml) and then, if it doesn't contain any runways or aprons, then decompile the _TXN and/or _APN files - adding to the base data.

Look for an updated AFLT tomorrow.

EDIT: New development release posted
 
Last edited:
You must log in or register to reply here.
Back
Top