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

[Gerald Krutsch]

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

 

[gadgets]

Please post a screenshot of some badly-misaligned lines and your .ad4 file.

Don

 

[Gerald Krutsch]

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.

 

[gadgets]

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.

Don

 

[Gerald Krutsch]

Don,

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?

 

[robystar]

Copy coordinates and paste.

 

[gadgets]

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.

Don

 

[Gerald Krutsch]

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!

BR,
Gerald

 

[gadgets]

Perhaps someone else can take a look and confirm the problem is fixed. As far as I can tell, it is.)

Don

 

[Gerald Krutsch]

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!
Gerald

 

[gadgets]

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

Don

 

[gadgets]

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

Don

 

[scruffyduck]

I don't think aprons get offset. At least it has not been reported at all in the past to my recollection.

 

[scruffyduck]

Thanks Don

 

[Gerald Krutsch]

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

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

 

[Gerald Krutsch]

And for the record, a screenshot of the perfectly alligned GP lines with the new .dll from Don. Thanks again!

 

[gadgets]

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.

Don

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

 

[Gerald Krutsch]

Hello Don. Unfortunately nothing changed with 2214(a).

Attached the .ad4.

Best regards,
Gerald

 

[gadgets]

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.

Don

 

[gadgets]

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.

Don