Questions about your AFCAD's

[ACSoft]

Hello,

Personnaly, I do not use AFCAD's using tick's like dummy runway array, or set of AFCAD's, each defined for a particular wind direction or approach. As it is the style of AFCAD you use, I have the following questions on this matter:

Before I start to tune myself, to my own tastes & needs, the AFCAD's included with your addon for LSZH, KJFK and KORD, do you have a "generic" AFCAD for these airports, not using the mentionned tricks, but which simply comply with FS2004 standard and conform to your design (I mean don't tell me to look on Internet for other AFCAD's, I ask for official FSDreamTeam generic AFCAD's) ?

I have also remarked that you may use two different AFCAD bgl files in the same time. One is the classical "AF2_xxxx.bgl" file, the other one is "Appr_xxxx.bgl" (first time I see this design). Such duplicate AFCAD files have the reputation to potentially provoke Memory leak. Of course, this will most probably occur, with duplicate complete AFCAD's. In your case, I have remarked that "Appr_xxxx.bgl" only contain some Navaids. But, anyway, can-you certify this design is "memory leak safe" ?

Many thanks in forward for your informations,

Best Regards,

Alain Capt
ACSoft Productions

[virtuali]

Before I start to tune myself, to my own tastes & needs, the AFCAD's included with your addon for LSZH, KJFK and KORD, do you have a "generic" AFCAD for these airports, not using the mentionned tricks, but which simply comply with FS2004 standard and conform to your design

If you just delete the dummy runways, you will have a file which doesn't do anything strange. Perhaps, you might just want to check which runways are open or close, but that's it.

Such duplicate AFCAD files have the reputation to potentially provoke Memory leak. Of course, this will most probably occur, with duplicate complete AFCAD's. In your case, I have remarked that "Appr_xxxx.bgl" only contain some Navaids. But, anyway, can-you certify this design is "memory leak safe" ?

There's no duplication of data between the two AFCAD. The "APPR_xxxx.bgl" file contains JUST Approaches and fixes/navaids needed for the IFR Approach procedures and nothing else. The main AFCAD contains everything else EXCEPT Approaches, so there's absolutely no problem using them together ( If there were, we would't do it like that )

The reason why we supply two separate files, is because user can freely play and tweak the main AFCAD file, without fear of losing the changed Approaches procedures, that very few AFCAD editing tools preserve when saving so, regardless of which editor you use, you can be sure you'll never risk touching the Approaches, because they are in a separate file.

[ACSoft]

Many thanks Umberto,

All clear !!!

Alain

[ACSoft]

Hello Umberto,

I made some more in deep investigations, starting with KORD and sorry, but what you said seem not to be correct.

All navaids defined into the "AF2_KORD.bgl" are defined too in "APPR_KORD.bgl". So, I don't know what you mean by "no duplication of data", but, to my view, this is obviously a duplication of data. Now, does it induce memory leak, that's the question.

But for now, this is not my problem. As these datas are duplicated, to build my "generic" version of AFCAD, I see no reason to include "APPR_KORD.bgl". So, this will exclude the memory leak potential danger in my case. I suppose, no problem with that, do you agree ?

But, anyway, I am curious. Why to include this "APPR_KORD.bgl" ?!? I have remarked that the rank order of ILS definitions in the navaid list is different in both lists. Marker are identical, except "OM22R" is only defined in "AF2_KORD.bgl" and VOR/DME "JOLIET" is only defined into "APPR_KORD.bgl". Can-you ellaborate a bit more, or is it a secret ?

EDIT:
One more question: Still for KORD, the AFCAD has a configuration with some runways defined for landing only and other's defined for takeoff only. Is this configuration the permanent configuration, or does it depend on wind direction, or seasons, or something else (in other words it may change for some reasons) ?

Many thanks in forward.

Best Regards,

Alain Capt

[virtuali]

I made some more in deep investigations, starting with KORD and sorry, but what you said seem not to be correct.

All navaids defined into the "AF2_KORD.bgl" are defined too in "APPR_KORD.bgl".

That's not the case, obviously.

You falled into the trap of believing the APPR_xxxx.bgl file contains navaids, because the AFCAD program, when you open an airport, scans in the DEFAULT scenery files for navaids in proximity of the airport you are editing, allowing to move them if you need, and saving back in the file your are editing ONLY the stock navaids you moved. This is clearly explained on the AFCAD Read Me file, at the "Navaids" section.

What you are seeing, are the default navaids that are loaded together with the APPR_xxx.bgl, because that's how AFCAD works, but our BGL doesn't contain any navaids, it only has the waypoints used by the Approaches.

But, anyway, I am curious. Why to include this "APPR_KORD.bgl" ?!?

As I've explained already, the APPR_xxxx.BGL is mostly needed for Approaches. Since the runways CHANGED numbers compared to KORD default scenery ( 27L became 28 and 27R became 27L ) all the associated Approaches changed accordingly so, it was necessary to supply an updated Approach file that contains the updated procedures, otherwise the runway that changed would appear as Visual only in the ATC.

[ACSoft]

You falled into the trap of believing the APPR_xxxx.bgl file contains navaids, ...

I am afraid so !!! LOL

(not the first time I was catched by this, but I didn't tweaked AFCAD since a while).

As I've explained already, the APPR_xxxx.BGL is mostly needed for Approaches. Since the runways CHANGED numbers compared to KORD default scenery ( 27L became 28 and 27R became 27L ) all the associated Approaches changed accordingly so, it was necessary to supply an updated Approach file that contains the updated procedures, otherwise the runway that changed would appear as Visual only in the ATC.

OK I see.

But these "APPR" files are apparently special. I mean, they are identified as AFCAD, but in program AFCAD 2.21, nothing can be found, except those navaids, which as you said, don't even belong to the file. Anyway, I don't need to understand all your technology. My target is to have what I call a "generic" AFCAD and to be sure it will work correctly.

Airport KORD:
Actually, I have simply removed the dummy runways array. I have also seen that runways have landing & takeoff restrictions defined. I shall probably remove them to, because, in any cases, they don't work anymore without the dummy array. What do-you think ?

From your explanations, I suppose it is better not to remove "APPR_KORD.bgl" ?

Do-you confirm it will be OK that way ?

Airport KJFK:
Here also, I simply removed the dummy runways array. In this case, runways don't have any landing & takeoff restrictions defined, so no problem.

But what shall I do with both "APPR_KJFK.bgl" ?


Many thanks in forward for you precious help.

Best Regards,

Alain Capt
ACSoft Productions

PS:
I am not a masochist ! I mean, if it would be possible to fool FS2004 for the bug of crossing airways, WITHOUT to totally destroy the ATIS ATC. I would naturally be happy with this trick. I would also accept a solution to solve the problem of different wind conditions, if it would'nt require to switch manually between different AFCAD files. To my view, these kind of tunings are like blocking a hole by digging a larger one.  Between two troubles, I chose the one who is, for me, the most less bad.

[virtuali]

But these "APPR" files are apparently special. I mean, they are identified as AFCAD, but in program AFCAD 2.21, nothing can be found, except those navaids, which as you said, don't even belong to the file. Anyway, I don't need to understand all your technology.

They are AFCAD. Or, if we really want to use the correct term, they are standard SDK Airport BGL, that contains only the Approach section and the waypoint section. It's not "our" technology, it's  100% standard MS SDK compliant BGL, just in a separate file, and Flight Sim supports this.

You are confusing what FS9/X can do with the BGL file format, with what the AFCAD utility allows you to do and how it presents the data. Since the AFCAD utility doesn't support Approaches display and/or editing, it's perfectly normal you don't see anything when opening that file with the AFCAD utility, because that section is entirely ignored.

Since the APPR_xxx.bgl file contains ONLY Approaches, the AFCAD utility will show it as if it was an empty file. However, since the AFCAD utility recognizes it IS related to Chicago, it will also show all the navaids in that area taken from the default scenery, so you might have the wrong impression that file contains just navaids.

Also, if you edit that file and save it back, you will also LOSE the Approaches, because the AFCAD utility do not save them back if you edit the file.

THAT'S why we have a separate file for Approaches. Since users like to tweak the *Airport* AFCAD, if we put the Approaches together with the Airport BGL ( the AF2*.BGL file ), they would lose the ability to edit it without losing the approaches, because the AFCAD utility (which is the most widely used), don't support them. The new ADE, for example, can be safely used to edit AFCAD with Approaches inside, but it's for FSX only.

My target is to have what I call a "generic" AFCAD and to be sure it will work correctly.

Just follow my initial advice: ignore the Approach file, and edit the main AFCAD file for the Airport, remove the dummy runways and, eventually, remove any take-off/landing restrictions on the runways, this will obtain a file which is as standard as possible.

But what shall I do with both "APPR_KJFK.bgl" ?

Just pretend they don't exist...unless you want also to renumber the runways.

To my view, these kind of tunings are like blocking a hole by digging a larger one.  Between two troubles, I chose the one who is, for me, the most less bad.

I perfectly agree. In fact, since we develop under FSX, we do the FSX AFCADs in the regular way without those tricks. However, FS9 users seems to be generally more of the "tweaker" type and they asked for these kind of customizations, so we just let them have it: the AFCADs that comes with FS9 is the result of some help by forum users.

[ACSoft]

Hello Umberto,

Now all is perfectly clear and I know exactly what to do. Many thanks and congratulations for your very professional assistance. It is really nice to see a firm which is so responsive for the technical support. Obviously, your technical support is at the same quality level of your 4 marvellous airport sceneries !!!

No I wasn't confusing, when I said "But these "APPR" files are apparently special", I was simply thinking relatively to AFCAD definition and its associated program, as these files are identified to be BGL of this type. This is what I was meaning by "special". A "special" AFCAD file if you prefer.

I have no difficulty to believe they are 100% standard MS SDK compilant BGL and when I said "your" technology, I was simply thinking you do not use AFCAD 2.21 to create them. Like you told me, it is now also fully understandable, why you do separate files. A very good idea, so tweaker's like me can still act on the "AF2_xxxx.bgl", without to loose the approach data not recognized by AFCAD program.

Again many thanks for your precious collaboration.

Best Regards,

Alain Capt
ACSoft Productions