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

Ade_gp 0.0.96

I suspect you'd also agree that 0.0.95(h) has some shortcomings.
Click to expand...

None that I have yet found.
Click to expand...
Did you put a big, V-shaped poly in the middle of your airport as I suggested? If not, then you wouldn't see the problem.

Don
 
Why would I wish to place a big "V"-shaped poly when there isn't one there in real life :confused:

In fact, it depends on what you mean by "big":

I've just placed these two:

 
Last edited:
Why would I wish to place a big "V"-shaped poly when there isn't one there in real life
Click to expand...
Because it would have demonstrated the issue in 0.0.95 that is fixed in 0.0.96 - which was the whole point of my suggestion.

Don

EDIT. In this context, "big" means big enough to require one or more 100m lat or lon slices. Also, are your test cases lines or polys?
 
Last edited:
They are not "test cases", but production, 52 x 1.5 metre lines.
Click to expand...
Then they are not big enough nor the right type to trigger the problem in 95(h).

In any case, I've found and fixed the issue in 96(a). I had neglected to apply the cos(lat) factor to the longitude limit. Thus the longitude partitioning was using only 63m. rather than the full 100 - which resulted in many more line segments than necessary.

I'll have version (b) out shortly.

Don
 
Interestingly, with 95(h) I needed an invisible polygon at the ARP to force display of other GP objects. With 96(b) I don't.
 
Another problem forces me back to 95(h). 96(b) fails to compile a very small line:

 
While I'm not doubting your word that this object doesn't display in FSX, I don't know how you know it didn't compile. Also, it doesn't seem possible with the current algorithms that an object wouldn't compile and no error message would be issued.

Please send me the file and I'll investigate. (From here on in, where you have a specific issue, please send the file along with the report.)

Don
 
Every GP line on the ADE display appears on my FSX display, including the one that doesn't appear on your system, i.e., the small curve in the vicinity of 51.5049, 0.04150.

The two "not triangulated" messages need further investigation. Based on the reported coordinates, they appear to be two very short line segments at the end of the most southerly long line on the display.

UPDATE: I've just noticed on the FSX display that the line backing extends beyond the end of the line proper. I also just realized that line backing, like lines, needs to be partitioned prior to triangulation. At the moment, that's not being done.

Don
 
Yes, I know.

But 95(h) isn't going to make you happy under certain other circumstances. For example, having to include an invisible poly to get certain other polys to display.

96 is going to make you very happy - once we get in infantile bugs out.

I've found the problem in 96 and am currently fixing it.

Don
 
96(c) attached. It adds line-backing to the list of items requiring pre-triangulation partitioning. Failure to pre-partition line backing was responsible for the earlier triangulation error messages.

Don
 
Last edited:
Hi Don !!

Sorry to bother you with this old issue again which reminds me of a song called "Never ending story" ;). As you can see the autogen tree thief is back.

I am using GP 0.0.96c for the moment. I saw that you want the ADE3 file so
here it comes. I guess that you will back in 24 hrs and I wish you good luck.

Best regards:

Floda
 

Attachments

  • ESGG_ADEX.ad3
    ESGG_ADEX.ad3
    119.7 KB · Views: 454
  • Autogen missing.jpg
    Autogen missing.jpg
    309.1 KB · Views: 492
Thanks, George.

Floda, are you compiling with the third option selected? If not, doing so seems to be effective. (The autogen suppression seems to be triggered by too many gp objects in a group. You may have to try several group sizes before you find one that works for you.)

Don

EDIT: Floda, I have confirmed that using 500m as the group size brings your autogen back.

Don
 
Last edited:
I have just discovered while testing Floda's airport that the Local Elevation compile option doesn't use the local elevation. The ARP elevation is still used.

This has been fixed and will be available in the next release. (You can get the desired result with the current release - 95 (c) - by selecting the multi-group option and setting group size to 10000m.)

George, re the missing curve you reported yesterday, if it's still missing in 95(c), please try using the multi-group option with group size set to, say, 500m to see if it makes a difference.

Don
 
You must log in or register to reply here.
Back
Top