• 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 GP and custom ground lines

Layer 24? While all other GP layers in P3Dv4 are negative??? That for sure will create havoc.
Click to expand...
Roby, perhaps that's another reason why you are having difficulty with PV4 GPs. The GP Layer number is not used as the Bias offset. (The intent is that the user specifies the GP in exactly the same way regardless of the destination FS version.) If you specify a negative layer number I doubt you'd get what you are looking for.

Don
 
gadgets said:
http://www.fsdeveloper.com/forum/threads/gp-and-custom-ground-lines.440977/page-4#post-781176

Gerald, give me some credit. I don't need your help in seeing what's on my display. When I right-click on an apron, THERE IS NO OPTION TO CREATE A GP!!!

As I said before, I was unaware of that feature. I have no idea why it is displayed on your system (or why it isn't displayed on mine) or what it does.

Creation of a GP at layer 24 is meaningless without knowing at what layer any GPs to be displayed on that background are created.

Don
Click to expand...


< Referee blows whistle; 'opponents' sent to their respective corners in the arena... :p >


Please refer to: o_O

http://www.fsdeveloper.com/forum/threads/gp-make-custom-ground-poly-command.438432/

apron-to-gp-png.36908


Don and Gerald, when an opportune moment presents itself during a calm interlude in this 'vigorous' discussion, could you both please clarify once again which numeric version (aka "Build") of ADE each of you are using for this troubleshooting scenario related to Gerald's GP ? :scratchch

Thanks for your diligent, cooperative, ongoing efforts to fully explore the multiple inter-related issues here. :)

GaryGB
 

Attachments

  • Apron to GP.PNG
    Apron to GP.PNG
    170.6 KB · Views: 985
Last edited:
Hi Gary,
attached a copy / paste from the About section from ADE:
Versions:

Application 01.75.6400.23940
Engine 04.75.6381.10476

Regards,
Gerald
 
I just need to say that this function does exist:

upload_2017-9-16_20-30-38.png


I checked and it is not a ProKey function so it should be available in all versions. It is present in ADE v1.61 which is the earliest that I still have. The function takes the shape of an apron and creates a GP that is the same. It opens the GP Editor and presents the shape so that the user can set the properties:

upload_2017-9-16_20-34-51.png


It is probably not much used since it has been present for some years and not reported as any sort of issue. There is a bug with it in that it leaves something of the apron behind. It seems that didn't matter in earlier versions of FS and P3D but now in v4 something happens that means the GP poly is hidden under the rogue left over apron.
 
:oops:Oops!. Didn't select the apron before right-clicking . There it is (just like you show)!

Apologizes for the outburst. (This has been a "trying" situation.)
Don
 
No worries Don - happens to me all the time. I need to sort out the bug on this

Meantime, do I recall that this issue is arising at a specific airport and not others? Also that the method used to generate GPs in P3D v4 is different than earlier methods? This is a complete flyer but is there any chance that we are seeing a problem here with loading priority - that is the bgl file containing the aprons is loading after the one containing the GPs and thus hiding them in this case. It is an exact hide since one if made from the other

As I say - I am probably talking nonsense but just wanted to get that out of the way.
 
do I recall that this issue is arising at a specific airport and not others?
Click to expand...
I noted way back at the beginning that I had never seem these symptoms before. That statement was not intended to exclude anything (other than what I've seen). In light of the "water under the bridge", it would seem the difficulty is related to converting aprons to GPs.

is there any chance that we are seeing a problem here with loading priority
Click to expand...
Shouldn't make any difference in PV3. GPs are assigned a bias = -GP layer. Further, if the standard file naming is not changed, the _GP file will get loaded last. In my tests, standard naming was used.



Don
 
Just to say: I converted all APRONS (that had markings or GPolys on them) into GP and deleted the APRON beneath it. Scenery shows perfectly (custom lines, custom GP, parking positions,... ).
 
I have been testing this today and it gets me no closer to what is actually going on
  • I compiled Gerald's project file and saw that the aprons overlay the GP objects.
  • I added my own apron and made a GP poly from it. After compile my poly had the same problem as the others with the apron over the poly
  • I added aprons and made polys from them at a number of other airports. In all cases the poly overlaid the apron
  • I opened the stock LRTR and added an apron, made a polys from it and compiled. The apron overlaid the poly
  • I deleted the apron, recompiled and the poly showed up.
  • Finally and most bizarrely I made a new apron in ADE - unconnected in any way with the poly and partially dragged it over the GP poly. I recompiled and this is what I got

upload_2017-9-18_17-10-25.png


The conclusion here is that any apron at this airport appears to overlay a GP poly. Given the way things work this should not be possible. I can fix the issue of ADE not removing the apron when a GP poly is made from it but no way can I 'fix' the independent apron overlaying the poly. So far I have only checked a few airports in different continents but LRTR is the only one displaying this behaviour. I am going to make a last test for airports near LRTR and see if I can get the problem

Meantime until I fix the way ADE leaves the apron behind then deleting that apron will bring the polys into view. But, as I said above that won't fix independently created aprons overlaying the polys
 
I just tested at the nearest airport listed to LRTR - that is LRAR and this is the result:

upload_2017-9-18_17-18-10.png


So the poly overlays the apron at an airport a few miles away from LRTR. There really isn't much else I can say.
 
Jon, what is the z-bias for the overlaying apron. The z-bias for the poly will be -layer number. Presumably, the absolute value of the apron z-bias is less than the GP layer number (which defaults to 24).

Also, if the elevation of this airport has been changed to a value higher than the stock airport and there is no elev_adj file, the poly will be displayed based on the stock airport elevation. Setting a large offset for the GPs (at compile-time) should, however, overcome this.

Don
 
Don, I am sorry but I am not sure I understand the question about z-bias. There is no such property for an apron but there is x-bias and z-bias for the vertex that define the apron. These are offsets from the ARP as I understand it and are an alternative to using lat/lon. ADE never uses the bias settings but always uses actual coordinates. I am not aware of an altitude bias for apron vertex.

When I carried out the exercise on the stock airport LRTR the problem was present. There were no files left from Gerald's revision and I have no ALT file for this airport in Scenery\world\scenery. So perhaps there is something being created that I am not familiar with and was compiled separately?
 
Last edited:
not sure I understand the question about z-bias. There is no such property for an apron
Click to expand...
Of course, I should have realized that. Presumably, its effectively 0.

if the elevation of this airport has been changed to a value higher than the stock airport and there is no elev_adj file, the poly will be displayed based on the stock airport elevation.
Click to expand...
I tried loading the stock airport to determine if this was the case. Unfortunately, it appears 1.75 has difficulty opening stock airport files. I tried with both 1.75RC and the latest 1.75.6421. Same with both; they appear to go into a loop.

I did manage to open stock LRTR with 1.67 and the airport elevation has not been changed.

Is it possible there are still some remnants of those old aprons lurking - like whatever is causing the backing width to be reported and displayed as 35m when, in fact it's only 0.35m?

I have examined the data entering the GP compiler and it appears to be OK. I have also confirmed that the z-Bias is being properly set.

Don
 
Don

It sounds like the model footprint database https://scruffyduck.screenstepslive...89324-detailed-library-object-footprints-1-70 wasn't copied into the 1.75 installations. This can make loading stock airports very slow while ADE populates the database itself. If you don't have it then you can get it from here: http://www.mediafire.com/download/expvjbbzcieryyq/MFDB.zip wasn't copied into !.75.

The backing width error I saw but I can't say why. ADE is drawing it wrong but as soon as the line is clicked it reverts to the correct size so it seems the correct size is stored in the project file
 
scruffyduck said:
When I carried out the exercise on the stock airport LRTR the problem was present.
Click to expand...
Well this is spooky. I will try the same test on LRAR and report back (give me 2 days though).
We have some relatives in Romania and fly a lot on LRTR...now I will always look at that ARP as VOODOO.....:yikes:
 
It sounds like the model footprint database https://scruffyduck.screenstepslive...89324-detailed-library-object-footprints-1-70 wasn't copied into the 1.75 installations.
Click to expand...
That was the problem, Jon. But loading is still VERY slow.

A simple airport, like LRTR takes several seconds to load (I have unchecked "Draw detailed footprints"). A more complex airport, like CYYJ *with only a few stock buildings), take 15-20 seconds. (I have never experienced this issue with any prior release save for 1.75RC.) In all cases, the progress bar immediately goes to about 75% and then stalls with the message "Loading Detailed Footprints" (which, I suspect means "calculating detailed footprints" since the time required varies by airport").

If I don't ask ADE to draw detailed footprints, why should the presence (or not) of this data base make any difference? This experience leads me to believe that ADE is calculating detailed footprints whether or not "Draw detailed footprints" is checked.

Please note, the ADE Global folder contains a 50mb MFDB.dbs immediately after installation. Obviously, this is not the preferred version, since I downloaded and installed the one you directed and it consumed 375mb.

as soon as the line is clicked it reverts to the correct size
Click to expand...
That's true. But, if you don't edit the line, it reverts to the "wide display".

Don
 
Gerald Krutsch said:
Compiling the same project for P3D v4, the ARP is missing some features. All custom ground lines and custom ground polygons are missing. Furthermore, if I open any DEF ARP from P3D v4, add a custom ground line, compile etc. I don't get to see that line.

Now since I did it right for FSX:SE (because I can see them), I have no idea what's wrong in P3D v4. I only use the stuff within ADE (no sketchup, GMAX, and other voodoo things o_O ).

Could you pls advise me?

Thank you from lake Constance,
Gerald.
Click to expand...

Shortly, Don and I have been into this before. ENZV compiled for FSX shows all GP lines, but for P3D3 and up not. The theory was about QMID grid and moving the ARP around, and ENZV is still not solved. Compiled for FSX all is well, but compiled for P3D I just have to tell folks the lines up north and west will disappear now and then. This is my "solution" and I just left thinking & discussing it for the sake of peace. Mostly for my own peace!
 
You must log in or register to reply here.
Back
Top