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

Quote:
Originally Posted by gadgets View Post
If you have moved other lines, you may have to reset them before they display properly. But newly-moved lines should be OK now.

Don

I have no idea what you mean

What are "other lines"?

What are "newly-moved lines"?
Click to expand...
I was simply referring to other lines in any project that may have been moved/dragged while the problem I fixed yesterday existed. They may not have self-corrected.

If you have edited every line after moving (which, until we're sure there are no more issues, seems like a wise practice) you should not have any such difficulties.

Don
 
Today, while importing some work I'd done previously, I discovered a problem whereby imported polys could not be edited. It was minor (code-wise) and the attached contains the fix.

Don
 
Last edited:
I have another problem that perhaps you can advise on. When I make my own textures for a line I enter the co-ords into the Line_def document. When I run ADE, I go to the GP Texture Editor in tools and check the entry, making a definition up date if it is a new one. On making a test line I find that my original co-ords are a bit out, so I return to the Liune_def document and adjust it. This can need a couple of adjustments. On returning to ADE and using a line I now find that there may be two or three entries available, all apparently having the same cords. I then tried to delete one of these entries using the GP editor, and not only were both removed from the editor, but the entire entry was removed rom the line_def. Then, when I remade the line_def entry I found that all the originals, plus one more were back in the GP editor. What am I doing wrong here?

Norman
 
Norman, I gather what you are telling me is that when you attempt to edit an item with the texture Editor, ADE_GP instead creates a new, duplicate entry.

I'll take a look. If, however, you are telling me something else, please be a little more specific and, perhaps, include an example.

But, other statements suggest you are also entering data manually into Lines_Def.txt and/or Texture_Def.def. If so, then I need to see the files in order to help you.

Don
 
Norman, I gather what you are telling me is that when you attempt to edit an item with the texture Editor, ADE_GP instead creates a new, duplicate entry.
Click to expand...
And you'd be right!

Fixed by the attached.

Don
 
Last edited:
A couple more changes to import that should make that experience a little better.

Don
 
Last edited:
Thanks, Don, that is what I meant. I would have included a screenshot, but every time I tried the sub menu closed before I had a chance.

I'll try the new dll and report back.

Norman
 
New version with "flickering fix" attached. (I was able to retrieve the backed-up version of the compiler, so only had to apply the fix.)

Hopefully it solves your flickering problems also and doesn't re-introduce autogen suppression. (Both seem to be fine on my system.)

Don
 
Last edited:
Gp

Hi Don :)

After installing gp 0.0.95g I got this autogen suppression back.
I went back to gp 0.0.90 and my autogen trees are back.

Sorry to bother you with this old issue.

Best regards:

Floda
 
Floda, I've done a considerable amount of experimentation over the past few days regarding flickering of shadows and suppression of autogen. The fix for one often causes the other.

If you do a search in fsDeveloper you'll discover that the autogen issue appears to be related to the number of ground poly objects in each grouping in the file. In my own case, I imported about 1000 ground poly objects onto one of my airports and autogen suppression returned. However, I was able to get the autogen back and avoid any flickering by using the third (lowest on the dialog) compile option which controls the group size and hence, the number of objects in it. (500m group size worked for me)

However, that solution may not work for you with the current release. I'll be making a new one in the next 24 hrs.

Don
 
gp

Hi Don !

I just wanted you to know what happened and don't worry , I and I suppose
all of us trust you 100% when it comes to gp and your good work.

B.t.w. is there a way to make the green taxi lights visible when they are on the same line as gp. line. Now they are buried below the gp-line.

I will keep a eye on you in the next 24 hrs. ;)

Best regards:

Floda
 
Hi,

No - GP objects will always cover other ADE objects, sorry.

The only way I know to make them shine through would be to make the GP lines partially transparent (using an alpha channel in the line's texture).
 
Version 0.0.95(h) attached.

It includes:
  • a refinement to the anti-flickering and anti-autogen-suppression logic, and
  • a minor change in the triangulation routine that may avoid some triangulation issues.
As indicated in earlier posts, I had found a solution to the shadow-flickering problem. Unfortunately, I discovered afterwards it re-introduced autogen suppression. But, when I fixed the autogen suppression in the traditional way, the flickering returned along with the autogen. Somewhat of a dilemma, I think you'll agree!

I then spent a lot of time scouring fsDeveloper for posts on the topic. There are quote a few - none, however, offering a solution to both issues simultaneously. However, there did seem to be a consensus that the autogen problem was related to the number of polys in each group in the .asm file. (The file always groups by layer and, if the user requests, also by geography.)

So, I restored the flickering fix and used the geographic grouping compile option. Lo and behold, the autogen was no longer suppressed.

So, I'm updating the user manual (available later today) to reflect this.

I'm not sure it will work in every case, but it's the best I can do with what I've got to work with.

Don
 
Last edited:
gp

Hi Don :)

Thank you for the elegant support.
Everything is as it it was before ,plus the new things you have fixed which I haven't discovered yet.

Best regards:

Floda
 
gp

Hi Tom, and thanks for your reply.

Could you please give me a hint on how to make a GP-line partially transparent. What happens in day light? Will I still see the yellow lines?

Due to my age I appreciate if you explain it like for dummies.

Best regards:

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