ADE-GP and P3D v4

gadgets

Resource contributor
#1
Users of ADE 1.71 or later should update to ADE-GP Version 2.2.16. The latest version of ADE includes this version. To update otherwise, download the Latest General Release from http://stuff4fs.com (navigate to User Applications/ADE Ground Polys (ADE-GP)). Unless you are using a very old version of ADE-GP, only the .dll need be updated.

As discussed in excruciating detail in a couple posts below, there is sometime a registration error (i.e., lateral offset) between custom GPs and other airport elements when using Pv4. At this time, the problem seems geographically localized. (There has only been one airport (EDJA) reported where this offset is noticeable.) I have tried numerous methods to eliminate the error - all unsuccessful - using three different geographical conversion libraries. Consequently, I am convinced the underlying issue is an anomaly in Pv4's display engine.

This issue should only be apparent when a GP must closely "mate" with another airport element.

Fortunately, Pv4 still supports the display of FS8-style GPs. And, equally fortunate, use of FS8-style polys eliminates the error. Unfortunately, FSX/P3D materials can't be used with FS8-style polys. If you MUST use FSX/P3D materials, then there appears to be no alternative other than either to accept the offset or tweak the GP positions in ADE to compensate.

To generate FS8-style GPs when using ADE's Pv3 or Pv4 mode, check the "Generate FS8-Style GPs" checkbox on the ADE-GP Compile Parameters dialog.

Should you experience this issue when developing other airports - using 2.2.16 - please report the fact accompanied by your .ad4 file. (Doing so may help in developing a general solution) But, first, please confirm whether or not use of FS8-style GPs eliminates the error.

Don
 
Last edited:

gadgets

Resource contributor
#2
During a forum discussion yesterday on a related topic, I realized that, while I had implemented the alternative to compile FS8-style GPs for Pv3/4 (which sometimes provides superior results to using PV3/4 style GPs), that alternative did not include all the related options to reduce/eliminate autogen suppression. The attached version 2.1.16(a) supports those options.

In part, that discussion also included the topic of using FSX-native polys (as opposed to FS8-style GPs) with FSX - thus also allowing the use of FSX materials and its additional autogen suppression capabilities. I reported that, when initially implementing PV3/4 in ADE-GP, I had included that capability for FSX as well. But the results were unsatisfactory, so I suppressed it. Turns out restoration was a very simple matter, and preliminary testing indicates that whatever caused the earlier issue is no longer doing so. Consequently, the attached version supports generation of FSX-native polys when ADE is in the FSX or PV2 mode . Be aware, however, FSX-native polys are not intended to lie directly on the terrain (as are FS8 and PV3/4 GPs), so you may have to experiment with an elevation offset to overscome flickering. Consequently, FS8-style GPs remain the default for FSX. Check or uncheck "Generate FS8-style GPs" on the ADE-GP Compile Parameters dialog to disable or enable, respectively, this new capability

This update should only be used with ADE 1.71 or latter. Hopefully some of you will find these additions useful.

The re-implementation of the FS8 autogen suppression techniques required "shuffling" some code. While these changes were quite straightforward, I'm releasing this update as a development release to allow for a reasonable "soak" period.

Don
 

Attachments

gadgets

Resource contributor
#3
A problem with the Material Editor that could lead to a "crash" of the GP Editor has been fixed. P3Dv4 airport developers who use materials with their GPs should install Development Release ADE-GP_2016(b) update attached to this post.

Don
 
#4
Hello Don,
thank you very much for this hint to use FS8-style-GP. This solved after many hours of trial & error my problem. The GPs where not visible in my current project for EDKB. In order to check that I did not lost them somehow in all other stuff I tried to generate them at a very remote location SLVO and had also the same problem. Using FS-8-style helped for both locations. I'm not sure if you are interested in, but attached the file that works for FS-8-style but not normal GPs at SLVO.
 

Attachments

gadgets

Resource contributor
#5
Thanks for the update, schmax. Decoding that .bgl into useful data is a big job. It would be much easier if you sent your .ad4 file.

But, before you do that, I suspect the reason you can't see the GPs using the PV4 format is that the area has not been flattened to ARP elevation. PV4 GPs are drawn at ARP elevation. If the terrain is higher, you'll need a shovel to see them,. On the other hand, FS8-style GPs are drawn on then terrain surface - two very different technologies.

Don
 
#6
Sorry. I actually wanted to upload the .ad4 file but seems that I mixed them up. I have read about the elevation and included a flatten which has the same hight as the airport and covers the area of the GP. But the problem still exists and is the same for EDKB.
 

Attachments

#8
Even when not FS8-style-polygons are selected? Strange. Why does it not work in my P3Dv4.0? I did chose this remote location to make sure there is no influence from any other scenery. Any ideas what could cuase the problem in my installation?
 

gadgets

Resource contributor
#9
Even when not FS8-style-polygons are selected?
yes

Why does it not work in my P3Dv4.0?
I'm afraid you'll have to sort that one out yourself. There's something in you system configuration that's affect PV4 GPs. All I can tell you is that ADE-GP is generating the proper GPs. Maybe somebody else who has experienced a similar issue can help.

I did chose this remote location to make sure there is no influence from any other scenery. Any ideas what could cuase the problem in my installation?
Choosing a remote geographic location is no guarantee that something else on your system won't interfere.

Don
 

gadgets

Resource contributor
#10
I have just made Development Release 2.2.16(e) at http://stuff4fs.com. As Jon has recently done with ADE, I have re-compiled ADE-GP for Net 4.0. In addition, this development release includes fixes for other recently-reported issues. I hope that some of you will use this new release to help confirm that it is, in fact, an improvement over the current general release and that no new problems have been introduced.

This release must be used only with Jon's latest release of ADE also compiled for NET 4.0 (i.e 1.76.6708) or later. Use with an earlier release of ADE will render ADE-GP inoperative.

Don
 
Last edited:

gadgets

Resource contributor
#11
For Pv3 and Pv4, it seems the earlier development release applied the round earth elevation correction in the wrong direction, thus ensuring that GPs would be floating. This problem is fixed in Development Release 2.2.16(f), now available from http://stuff4fs.com. Navigate to User Applications/ADE-GP and click the Development Release menu item.

This release must be used only with Jon's latest release of ADE also compiled for NET 4.0 (i.e 1.76.6708) or later. Use with an earlier release of ADE will render ADE-GP inoperative.

If I haven't had any negative reports in the next week or so, I'll promote it to a general release.

Don
 
Last edited:

gadgets

Resource contributor
#14
While updating one of my own airports, I discovered a potential shortcoming in ADE-GP. Associated backing, when used, is applied only to the sides of lines, not to the ends. Generally, this is not a concern. But, for example, if lines are used to add "T"s to parking lead-in lines, this is what you get.
Leadin - Layer29-.jpg

Not bad, but something is missing. Frankly, I only discovered ADE-GP could do this well a few days ago.

A little experimentation resulted in this:
Leadin - Layer 30+.jpg


So, I've just posted Release 2.2.18 to http://stuff4fs.com. It will cap lines as shown immediately above in Layers 30 and above. Layers 29 and below are not affected by this change.

This new release also includes a new texture named "gp_PatternedLines_Backed_40.bmp". It is essentially identical to the existing "gp_PatternedLines_40.bmp" but, by increasing the line width, backing will be included in the texture, avoiding the need for associated backing and, thereby, reducing the number of polys to be drawn.

Please note, Release 2.2.18 is only useable with the ADE 1.76.6715 or later, since (like that release of ADE) it is compiled with NET 4.0.

Enjoy,
Don
 
Top