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

Adex 4932

N

normandean

Messages
100
Country
unitedkingdom
Just installed 4932 and I find that for my own textures if I use the GP texture editor in the drop down menu they show as no def. I have tried to use a separate line_def.txt and combining my definitions in the base.txt and they still show in the GP editor as no def. However, they are available for use in ADE.

Norman

Edit: however, the sizing is wrong.
 
Last edited:
OK, found the answer. When I installed the complete new install I removed my textures and line_defs, for safety, and then added them back after installing. This is what failed to work. I have therefore installed the beta again, this time with my files and line-defs in situ and it has installed fine.

Just one problem noticed now and that is that I am getting a warning about triangulation of ground poly objects when I have only used lines.

Norman
 
I am getting a warning about triangulation of ground poly objects when I have only used lines.
Click to expand...
The term "ground polys" applies to both lines (which are a series of connected polys) and polys.

That being said, I can't image why you'd get that warning for a line.

Norman, please send me your AD3 file so I can investigate - either by attaching it to a post or via e-mail to don at stuff4fs dot com.

Don
 
Hi Don, sorry to be slow responding. I have the warning with two different airfields that I have made. I attach a file for Exeter.

Norman
 

Attachments

Thanks for sending the DA3 file, Norman. You've certainly put a lot of effort into that airport

I expected the issue was due to the 100m "chunking" for FSX. But, I disabled that feature and the results are the same. (In some respects, this is good news!)

I see no other obvious cause.

I'll dig into this deeper tomorrow and get back to you ASAP.

Don
 
Hi Norman,

The problem is that all of your gp-numbers polygons have only three vertices (or a duplicate vertex), there should be four.

This could be the same problem that Roby has, where he apparently lost a vertex or two vertices were in the same position.

Edit. If I attempt to create a new one, four vertices are displayed but I cannot position them, getting "Maximum zoom has been exceeded".
 
Last edited:
Thanks for pointing that out George. If that's the case I may be able to "kill 2 birds with 1 stone".

Don
 
It looks like the new poly processing introduced a couple of weeks ago is "eating" vertices under certain, as yet undefined circumstances (but I suspect it only affects 4-point polys).

I can reproduce this effect, so it shouldn't be too difficult to isolate it - tomorrow.

Hang in there guys,

Don
 
Yes, I had noticed that although when first textured there were four vertices, on trying to edit the poly only three remained. I also got the warning Maximum Zoom Exceeded, but this happened only once, so I thought that it was just a one off.

Norman
 
I now know what is causing the problem. It thinks a vertex has been deleted when, in fact the ADE-reported position of all four vertices is identical to the last ADE_GP-processed position. Don't know why, yet - but it's only a matter of time.

I hope the maximum zoom is related. It's a nice sunny summer day here so I've got better (at least nicer) things to do that dig through code.

Don
 
I have found and fixed the two problems which, it turns out, were related.

The issue involved only rectangles and other polys that had two exactly-parallel sides. The way I had implemented the new poly-handling treated this situation as a deletion. (I won't go into details.)

I will be forwarding an update to Jon momentarily.

Norman, as regards your compile error messages, they are legitimate. The lines which are the source of the "complaints" have and extra, superimposed vertex at one end. Get rid of those vertices and all should be well.

Don
 
Norman, I've now had an opportunity to explore the other two compile-problem sources in more detail. It turns out they are not lines but, rather, 8' circular polys drawn with about 40 VERY tightly-packed vertices.

Despite the error message, the file does appear to compile OK - which suggests it was the very last triangle (also the smallest with the most tightly-packed angles) that caused the error - suggesting computation precision (which is the maximum available) is inadequate in this particular instance. So, doing nothing in these two cases may be the best approach.

I can find no way to manipulate these objects because even at the highest ADE zoom level, individual vertices are not selectable. If you reduce the number of vertices, the error message will probably go away.

Nonetheless, I will take another look at the triangulation code to ensure there's not a more fundamental problem.

Don
 
gadgets said:
Norman, I've now had an opportunity to explore the other two compile-problem sources in more detail. It turns out they are not lines but, rather, 8' circular polys drawn with about 40 VERY tightly-packed vertices.

Despite the error message, the file does appear to compile OK - which suggests it was the very last triangle (also the smallest with the most tightly-packed angles) that caused the error - suggesting computation precision (which is the maximum available) is inadequate in this particular instance. So, doing nothing in these two cases may be the best approach.

I can find no way to manipulate these objects because even at the highest ADE zoom level, individual vertices are not selectable. If you reduce the number of vertices, the error message will probably go away.

Nonetheless, I will take another look at the triangulation code to ensure there's not a more fundamental problem.

Don
Click to expand...

Use the Z key to reduce the size of vertices.
 
Thanks, Jon. But, that turns out to be unnecessary.

Norman, underneath each of those two 40-vertex polys is another 8' circular poly with 200 vertices. This seems a little excessive and no doubt requires computation precision well in excess of that available to triangulate.

When I eliminate the 200-vertex polys, leaving only the 40 vertex polys, the file compiles without error.

Don
 
There's a fundamental difference between triangulating lines and polys. Lines are triangulated as a series of 4-vertex polys. A 200-vertex circular poly 8' across requires extremely precise computation - apparently more precision than is left after the number of calculations required for triangulation.

Were it a larger object, the 200 vertices may be OK, but not for something that small.

Don
 
Hi Don, Yes, those two spots are made with 200 nodes, a figure that I use with all circles, except very large ones, where I use 360. The file I sent you was the ad3 file and the guide shapes were still in it so that would be the other circle that you found. In fact 200 appears to be a magic figure, because even with smaller arcs fewer nodes gives a more disjointed line. For example, with a arc of, say 10 deg and a radius of about 20M, if you select 36 nodes then you end up with a line with four or five nodes. In other words the selected number of nodes when forming an arc appears to relate to a complete circle and not the length of the arc. I have tried various figures for nodes but the number of nodes in an arc doesn't appear to be proportional to the number of nodes selected in forming it. I agree that by using a high number you do end up with an excessive number in a short arc, but I can't seem to find a happy medium.

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