ADE-GP and P3D v4

[gadgets]

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

 

[gadgets]

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

 

[gadgets]

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

 

[schmax]

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.

 

[gadgets]

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

 

[schmax]

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.

 

[gadgets]

Your GPs display for me just fine.

Don

 

[schmax]

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]

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]

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

 

[gadgets]

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

 

[Tom Valley]

Great work Don!

Works perfectly.

Tom V.

 

[gadgets]

Glad to hear. I'll give the others the rest of the week to find any other issues. If not, I'll ask Jon to include it.

Don

 

[gadgets]

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.

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:

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

 

[Bavarello]

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

Finally, after several unsuccessful attempts, the solution was FS8-style GPs.
My version of ADE 1.76.6715 and ADE-GP 2.2.19

 

[gadgets]

Bavarello, it's not clear what is the problem to which you are referring. I have compiled your airport with PV4 GPs and don't see anything wrong with the GPs.

Don

 

[Bavarello]

Hello Don, thanks you for reply

I have tried dozens of times to compile the GP looking for a solution to the fact that the file _GP.bgl was not displayed correctly ... I read the manual a few times looking for a solution .... then I saw this post ... check the "Generate FS8-Style GPs" checkbox on the ADE-GP Compile Parameters dialog. Everything's gone.
Before I used Local Elevation, Full Visibility and then Offset GP Elevation by 7mm ... without success.

 

[gadgets]

Don't know what to tell you. This what appears on my system.

 

[gadgets]

I have discovered an issue in ADE_GP 2.2.19 that could result in a noticeable (and irritating) delay in the display of the GP Editor when you double-click on a GP or select Edit from the context menu. That issue is fixed in ADE-GP 2.2.20 which you can download from http://stuff4fs.com.

This version of ADE-GP should only be applied to ADE 1.76 or later.

Don

EDIT:
One of the .dlls in ADE on which ADE_GP depends (ASToFRA.ObjectModel3D.dll) was updated recently, requiring a change to ADE_GP. This new version of ADE_GP requires ASToFRA.ObjectModel 3d.dll date-stamped "2019-02-11" (at least that's what it is in ADE 1.77.7018 Beta on my system). You should confirm that version of the .dll is in your ADE folder before updating ADE_GP.

 

[gsnde]

Hi Don.

After I have updated the files from V.2.2.20, I get this compile error:

System.MissingMethodException: Methode nicht gefunden: "ASToFra.ObjectModel3D.Vector3d ASToFra.Coordinates.CoordinateConverter.LatLongWGS84toRelativeGeoCentricXYZ(ASToFra.ObjectModel3D.Vector3d, ASToFra.ObjectModel3D.Vector3d)".
   bei ADE_GroundPolys.mdlProcessing.MakeMdlFiles(List`1& listGP_Group, Int32 nLayer, List`1& listXML, Double latRef, Double lonRef, Single elevRef, Int32 fFSVer)
   bei ADE_GroundPolys.Generate_BGL.btnGo_Click(Object sender, EventArgs e)
   bei System.Windows.Forms.Control.OnClick(EventArgs e)
   bei System.Windows.Forms.Button.OnClick(EventArgs e)
   bei System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
   bei System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   bei System.Windows.Forms.Control.WndProc(Message& m)
   bei System.Windows.Forms.ButtonBase.WndProc(Message& m)
   bei System.Windows.Forms.Button.WndProc(Message& m)
   bei System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   bei System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

I have reinstalled the old version - no error on compile there.

Cheers
Martin