General Category > General Discussion
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:
--- Quote from: ACSoft on March 15, 2009, 08:56:43 pm ---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
--- End quote ---
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.
--- Quote ---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" ?
--- End quote ---
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:
--- Quote from: ACSoft on March 16, 2009, 02:14:26 pm ---I made some more in deep investigations, starting with KORD and sorry, but what you said seem not to be correct.
--- End quote ---
--- Quote ---All navaids defined into the "AF2_KORD.bgl" are defined too in "APPR_KORD.bgl".
--- End quote ---
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.
--- Quote ---But, anyway, I am curious. Why to include this "APPR_KORD.bgl" ?!?
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
Go to full version