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

ADE and AFCAD in FS2004

Messages
16
Country
southafrica
I very recently downloaded ADE with a view to using more up-to-date software for airport design, having created South Africa's new airport FALE using AFCAD. I used ADE to open my previous afcad work on FALE and made some enhancements to taxiway signs and jetways and saved the work. After compiling the airport in ADE, I found that my PMDG aircraft were not 'responding' to the magnetic variance and the runway heading and magnetic headings didn't correspond in the ND.

My investigations revealed that ADE and AFCAD2.1 seem to process the magnetic variance differently. If the MV in ADE airport properties shows minus24.00 (which it should be), this figure translates into plus 24.00 when viewed in AFCAD and the discrepancy throws out PMDG's IRU's and the planes' ability to track correctly. I removed all afcad files and this didn't help. It wasn't a feature in AFCAD previously.

Can someone please throw some light on what is causing the discrepancy between ADE and AFCAD2.1 and tell me if there is a solution. I shall be most grateful. Thank you. Quentin Moore
 
I very recently downloaded ADE with a view to using more up-to-date software for airport design, having created South Africa's new airport FALE using AFCAD. I used ADE to open my previous afcad work on FALE and made some enhancements to taxiway signs and jetways and saved the work. After compiling the airport in ADE, I found that my PMDG aircraft were not 'responding' to the magnetic variance and the runway heading and magnetic headings didn't correspond in the ND.

My investigations revealed that ADE and AFCAD2.1 seem to process the magnetic variance differently. If the MV in ADE airport properties shows minus24.00 (which it should be), this figure translates into plus 24.00 when viewed in AFCAD and the discrepancy throws out PMDG's IRU's and the planes' ability to track correctly. I removed all afcad files and this didn't help. It wasn't a feature in AFCAD previously.

Can someone please throw some light on what is causing the discrepancy between ADE and AFCAD2.1 and tell me if there is a solution. I shall be most grateful. Thank you. Quentin Moore


I think you posted this in another forum or maybe by email. Apologies but I do not think we replied :o It does seem that ADE reports the magvar opposite to AFCAD. ADE has always handled magvar the same way. I need to confirm which is correct - if necessary we will need to fix ADE.
 
Last edited:
Thanks for your response Jon. I was beginning to think something serious had gone wrong with FS2004 in my machine. How will I know when ADE has been corrected, if indeed this is necessary, so that my version can be updated?
Quentin
 
ADE has an automated updater. At the moment we are working on the next major version but if we have issues with the current one then we will issue a patch for it.

We also generally announce updates and fixes on www.airportdesigneditor.co.uk


To deal with the problem in the short term would mean entering a positive number in ADE for the magvar. I can do that for you if needs be
 
This has me puzzling and I have been looking at why ADE reads magvar the way it does. Here is the relevant line from the SDK

magvar (optional) Magnetic variation at the airport to True North in degrees. -360.0 to 360.0 floating point value. Default = 0.0. East magvar is negative, West magvar is positive

So FS expects West magvar to be positive although generally it is published as negative (being counter clockwise)

FSX Planner follows ADE in showing MagVar as per the SDK while AFX follows AFCAD and shows the reverse. AFCAD and AFX use their own proprietary compilers so I presume they do an internal reversal to the bgl value.

ADE would need to reverse the value when creating the xml code to compile.

Consfusing..... Well I will look at making a reversal for this but then we need to explain why it does not follow the FS SDK :o
 
It is very puzzling, Jon. AFCAD 2.21 was released for FS2004 and I can't imagine why Lee Swordy would use negative for West if the SDK says West is positive. If ADE follows the SDK for FS9, I have no problem with that and I don't want to make unnecessary work changing things in ADE which might complicate its use with the SDK.

I will change the magvars for the three international airports in SA to positive numbers and test the response of the PMDG aircraft. I will remove the AFCAD files, so there is no interference or conflicts from them in the simulator.

Will report back and maybe a brief note in the ADE manual about ADE and AFCAD will suffice.
Quentin
 
Lee created AFCAD 2 before there was an SDK for FS9. Basically he was working 'blind' which is why AFCAD uses its own compiler.

As for which is the right way to do it - ADE follows the SDK so for the time being we will have to follow that until we do an update to ADE - perhaps then we will give the user a choice or show both versions in the property list.
 
IIRC AFCAD is "backwards" but it shouldn't make any difference as the bgl should be the same. It's just how it's shown in the UI.

scott s.
.
 
Scott is correct - it is the way it is displayed in the application. If you open the same bgl file in AFCAD and ADE the magvars will have different signs but in the bgl file (what FS reads) the value is the same.
 
PMDG technical support responded to an earlier ticket I raised with them to say I should run Flight1's registry repair tool as the FS entries were missing in the Windows registry. I have done this, but it doesn't appear to have made a lasting difference. At first I thought this had solved the problem, but the next time I started the simulator the problem was back. As of now, with all magvars set to positive so as to follow the ADE and SDK system, there is still a magvar discrepancy in the ND. PMDG's 747-400 makes provision for aligning the IRU's, but the success of this seems to be directly dependent on whether the magvar is positive or negative. Makes me wonder whether they followed the SDK magvar when programming the IRS system in the aircraft, or whether they followed the West is negative version. I will ask PMDG.
 
Be interesting to know. As far as we can tell magvar is not much used in FS except I guess for the magentic compass. Whichever tool is being used provided the format of the magvar in the bgl file is correct then there should not be any problem in FS. Are you seeing any issues with the magnetic compass?
 
I can tell you that I have seen scenery bgl files that have caused the magvar in FS9 to go haywire. But it's very subtle as one file in particular (was an area fill of water which seemingly has nothing to do with magvar) when in one scenery folder worked, but in another caused the magvar to go off.

scott s.
.
 
Here's an interesting discovery. It seems that provided the scenery folder of the airport has a file with "afcad" as part of the file name, PMDG's IRU's appear to respond correctly to the magvar. This may be purely coincidental, but I have found that it has worked for two airports so far. How I discovered this was by opening the ADE file for FALE with AFCAD and then saving it again with AFCAD as 'fale-afcad' in the scenery folder. The ADE files in the scenery folder were not disturbed, so signage etc remained intact.

The inference is that PMDG's program looks for and reads an afcad file, which has a West=negative approach to magvar, when the IRU's are aligned. I am waiting for PMDG's reply to this postulation. This may be a purely FS9 thing and I'm not sure what the implications are for ADE, if any.
 
This all seems very weird to me since I would expect the actual value of the magvar coded in the bgl file to be the same irrespective of the design tool used. Although AFCAD has its own compiler reading an AFCAD created bgl file with another tool gives the expected internal value (and that is what FS is reading). I can only assume that perhaps the PMDG IRU is reading the values directly and making some assumptions based on the file name! I can only re-iterate that as far as I know the compiled binary value of MagVar in a bgl file is the same irrespective of the tool used to create the bgl file it is in.

I will confirm my thoughts by test
 
OK I used a single bgl file that I opened and saved in AFCAD with a magvar value of -3.00. The internal float value of Magvar in the bgl file is 00 00 40 40

I now opened the same bgl file in ADE - ADE shows a magvar of +3.00. Compiled it and checked the internal float value of MagVar in the bgl file which is still 00 00 40 40.

The internal representation of MagVar is a float with 4 bytes as shown above and there are no transforms on it as far as we know. It is stored in decimal degrees.

So I would conclude that both AFCAD and ADE are dealing with the same number for MagVar but presenting it differently in their displays. AFCAD uses the West is negative display while ADE follows the SDK and shows West as positive (which is the way it is stored internally so I assume AFCAD reverses the number before compiling it).
 
Back
Top