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

P3D v4 Custom lines (e.g. Taxi) do not allign

Hello guys,

I just started with my second project with a slight different approach: I decided to make all the markings (taxi lines, edge lines,...) using the Custom Lines feature!

Mostly (80%) the custom lines work very well. In 20% of the cases, they missalign badly.

I have read the other topics related to this issue (long lines to be split by vertices, and so on due to earth curvature) but none of the fixes seems to work.

My ARP shows offsets also with short lines e.g: 90deg RWY exit -> the right ARC from RWY mid to TXW mid connects perfect, the left ARC shows a big offset. Both ARC's are drawn as sepparate Custom Line's....

Would appreciate any help. Thank you.
BR, Gerald
Hello Don,

here you go. I added pictures from ADE and P3Dv4 including the AD4 file. In the ADE screenshots you will see how much I had to displace some lines so that they show correct in P3D.
2017-12-19 09_00_51-AIRPORT DESIGN EDITOR P4  v01.75.6400 RC 1_ EDJA - Allgau [Ver. 00.00.6562].png 2017-12-19 09_02_23-AIRPORT DESIGN EDITOR P4  v01.75.6400 RC 1_ EDJA - Allgau [Ver. 00.00.6562].png 2017-12-19 09_08_24-Lockheed Martin® Prepar3D® v4.png 2017-12-19 09_09_39-Lockheed Martin® Prepar3D® v4.png 2017-12-19 09_12_03-Lockheed Martin® Prepar3D® v4.png


  • EDJA_ADEP4_GK.ad4
    196.2 KB · Views: 84


Resource contributor
Gerald, its not clear what you are trying to convey. We know that, due to the way P3D renders GPs, long lines are a problem. This was not an issue with FSX

In your first screenshot, in the center you have a long line, the right hand portion of which is broken up into numerous, apparently arbitrary, very short segments. The left-hand end of that line does not align with the line to its left. No surprise there. But, the alignment with other features seems perfect at the right-hand end of that long line, suggesting that using shorter line does work.

Frankly, I'd have drawn things a little differently. I'd have drawn the taxiway centerline as a single line and placed nodes at every point where it intersects with other features - keeping segment short otherwise. Then, I'd have drawn the other features with start and end nodes directly over a node in the centerline. Give that a try, please and get back to me.


I already tried that with no joy!

1. I firstly had one long line going the entire length from West to East (APRON 2 - APRON 1 - TXW N). The lines of Parking 1 were perfectly alligned, the lines of Parking 2 were way off.
2. I broke up the long line with vertices EXACTLY where the other lines should met -> did not work
3. I deleted the long line and added shorter lines broken by vertices -> did not work
4. I tried to break some of the lines with more vertices in the area I thought the displacement takes place -> this is the file I have sent you

Have a look at the end of TXW N where it meets the RWY (pictures attached).
There is 1 Center line (SHORT) and 2 ARC's (left and right also short). I had to displace ONLY the left ARC to line up with the center line. The right ARC allignes perfect in ADE and the SIM.
So if the "long line theory" works, why are 2 arcs of the same length, converging in the same spot, different?
2017-12-19 20_01_57-AIRPORT DESIGN EDITOR P4  v01.75.6400 RC 1_ EDJA - Allgau [Ver. 00.00.6563].png
2017-12-19 20_02_54-AIRPORT DESIGN EDITOR P4  v01.75.6400 RC 1_ EDJA - Allgau [Ver. 00.00.6563].png


Resource contributor
FOUND IT !!!! (or rather, implemented a workaround. It's a long story.)

Release 2.2.13(a) attached for your confirmation. Please report once you've had a chance to test it.



  • ADE_GP 2.2.13(a).zip
    153.3 KB · Views: 117
Dear Don,

I'm away till week 2 of 2018 therefore can't test the fix. I will definitely report back.
Until then I wish you all happy holidays and a happy new year!

Dear Don,

I had the chance to test the fix! It is working flawlessly!!!! Thank you so much! This issue was a real PITA.

Is there by any chance this fix can be applied to ADE Aprons? I think that some of those also have an offset in the sim when compared to the ADE view... (but I'm not certain because I need time to redo all the custom lines).

Best regards from lake Constance!


Resource contributor
Glad to hear that issue is finally resolved, Gerald.

As for whether ADE aprons could be improved, that's a question Jon will have to answer. (That's a totally separate process.)

Jon, based on Gerald's glowing assessment, the latest version od ADE-GP should become the standard. I'll send you a new .dll later today (I'm not at my development system currently.)



Resource contributor
Jon, et al. Attached is the ADE-GP 2.2.14 .dll which should eliminate the GP misalignment problem.



  • ADE_GroundPolys.zip
    153.5 KB · Views: 86


Staff member
FSDevConf team
Resource contributor
I don't think aprons get offset. At least it has not been reported at all in the past to my recollection.
Please look at the attached screenshots ADE compared to P3Dv4.
In ADE (red arrows for lines):
1) The upper edge line is at the outher upper border of the dark apron
2) The center line is in the center of the TXW
3) The lower line is in the mid of the lower dark apron
2018-01-01 19_21_57-AIRPORT DESIGN EDITOR P4  v01.76.6549 BETA_ EDJA - Allgau [Ver. 00.00.6576].png

In P3D v4 the APRONS (or the lines) have a small offset (they are shifted).


Resource contributor
Gerald, what I changed was the relative positioning of GPs. The change should have had no effect on absolute positioning.

When first implementing GPs for P3D v3/4, I discovered that airport elements were displayed at slightly different locations than in FSX - as if the airport had been stretched all round. I found that I could largely compensate for this (after lots of experimentation) by stretching the GPs by 0.33%. When I introduced the latest changes, it appeared that this "fudge-factor" was no longer required - so I thought about removing it. But, since it didn't seem to be having a noticeable effect in the test case and having learned the hard-way about changing designs unnecessarily, I left it in.

Attached is a new version of ADE-GP with the fudge factor removed. Please give it a try. If it corrects the issues you have highlighted, I'll re-release generally. If not, then I suspect you're looking at the best I can do.


PS. If the problem persists, please send me the current version of your .ad4 file so that I can experiment further.


  • ADE_GroundPolys_2214(a).zip
    153.5 KB · Views: 82
Hello Don. Unfortunately nothing changed with 2214(a).

Attached the .ad4.

Best regards,


  • EDJA_ADEP4_GK.ad4
    190.4 KB · Views: 73


Resource contributor
Unfortunately nothing changed with 2214(a).
Not did I expect it to.

But, I could have saved this last round had I read your earlier post more carefully. I hadn't appreciated that you were comparing the Pv4 display with the ADE display. (My mind said you were comparing Pv4 with FSX, as suggested by my response.).

Rather, you are concerned that ADE displays GPs relative to other airport items slightly differently than does Pv4.

Had you compiled your airport for the FSX and compared the display to ADE, you would have found the two essentially identical. So, a better question might be, why does PV4 not position everything as does FSX. And, the answer is, because LM has made internal changes with which we have limited ability to cope. These changes have resulted in GPs being positioned slightly differently in PV4 than they were in FSX.

Perhaps I can find a way to improve upon that by "fudging" GP positions when outputting to PV4. While I'm not hopeful of success, I will try. In the meantime, so long as your GPs do not use FSX materials, you can use the FSX version of the GPs with PV4.



Resource contributor
I have spent almost the entire day searching for a way to avoid the offset between the ADE airport elements and GPs in Pv4 - without success.

The underlying problem is that ADE submits the geographic position of each airport element node to the compiler which, in turn, computes the display position. FS9 and FSX GPs are processed in a similar manner. Pv3/4GPs, on the other hand, are submitted to the compiler as fully processed .mdl files which specify the display position of the GP nodes relative to the ARP. The result is a slight lateral offset between the Pv3/4 GPs and the airport elements.

ADE-GP uses standard coordinate conversion algorithms. It would seem the PV3 compiler does something different.

If anyone KNOWS the coordinate conversion algorithms used by the compiler to determine display position, please enlighten me and I'll try again. Failing that, if you must use Pv3/d GPs, you may need some trial and error for accurate positioning. But, if you don't need the use FSX materials, simply compile your GPs for FSX (it's an option on ADE=GPs compiler dialog.)

What I did, discover, however, was that in eliminating the misalignment between segments of GP lines, I inadvertently disrupted the processing of GP Polys. The attached ADE-GP 2.2.15 .dll fixes that latter problem.



  • ADE_GroundPolys_2215.zip
    153.5 KB · Views: 88