-
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.92
- Thread starter gadgets
- Start date
- Messages
- 34,981
- Country
George, Jon and I are working on something else using conditional-compile, so it should have no effect on you. Apparently, conditional compile, adds to the size of the binary.
Tom, I am surprised! The fix is a simple "OR" between what worked for you and what worked for everyone else. Go back to the special version. I'll go back to the "drawing board".
Don
Tom, I am surprised! The fix is a simple "OR" between what worked for you and what worked for everyone else. Go back to the special version. I'll go back to the "drawing board".
Don
Tom, good news!
I have now been able to duplicate (actually, induce) your line issue. I thought the problem was that in your situation, a conditional branch was not being taken. So, I 0.0.92, I fixed it so you would take that branch.
Actually, the problem was that you were taking that branch when you should not have been. In the special release, I actually prevented you from branching (even though I thought I was doing the opposite).
Now, to fix it properly ...
Don
I have now been able to duplicate (actually, induce) your line issue. I thought the problem was that in your situation, a conditional branch was not being taken. So, I 0.0.92, I fixed it so you would take that branch.
Actually, the problem was that you were taking that branch when you should not have been. In the special release, I actually prevented you from branching (even though I thought I was doing the opposite).
Now, to fix it properly ...
Don
Tom's line issue is now fixed. It was due to the slight difference that results when a metric value is converted to Ft. and then back to metric. Tom displays line width in Ft. The rest of use were using metric and so didn't experience the error.
Don
Don
tgibson
Resource contributor
- Messages
- 11,841
- Country
I cannot re-create the error box, but I do get very odd results. I have added a vertex and moved one in ADE, and then went to the GP Editor:
As you can see the display is nothing like the new shape of the polygon, and there are only 5 vertices in the GP Editor while there are 6 in ADE. When I only move vertices (without adding one) then all is OK. It always seems to happen if the FIRST thing you do to an existing polygon is add a vertex. If you move existing vertices first, then the vertex sometimes gets added OK (but sometimes not). Once the error happens, it seems to be permanent. The display in FS is also very odd - it appears to be textures from a single pixel or perhaps an average of all the pixels in the texture. I used the red crosshatch texture, and it initially looks fine in FS. When I add a vertex and edit it (the polygon is the wrong shape in the editor with the wrong number of vertices) and click OK I end up with no lines, just a solid semi-transparent red polygon.
As you can see the display is nothing like the new shape of the polygon, and there are only 5 vertices in the GP Editor while there are 6 in ADE. When I only move vertices (without adding one) then all is OK. It always seems to happen if the FIRST thing you do to an existing polygon is add a vertex. If you move existing vertices first, then the vertex sometimes gets added OK (but sometimes not). Once the error happens, it seems to be permanent. The display in FS is also very odd - it appears to be textures from a single pixel or perhaps an average of all the pixels in the texture. I used the red crosshatch texture, and it initially looks fine in FS. When I add a vertex and edit it (the polygon is the wrong shape in the editor with the wrong number of vertices) and click OK I end up with no lines, just a solid semi-transparent red polygon.
Attachments
Last edited:
I'm making some progress, but this could take a while. Basically, you'll get different "answers" depending on the relative position(s) of the affected vertices. So, for example, if you add a new vertex between vertices 1 and 2 and move vertex 4, you may get a different result than if you moved vertex 0. Believe it or not, this logic has been well (but, obviously not well-enough) tested with objects containing 30 vertices and, without exception, performed flawlessly. There is also the x/y issue noted by Tom which I have found and corrected. I may have introduced that one about a week ago.
As for the exception you experienced, George, for the moment at least, I suspect it to be the same cause. Sometimes vertices get ignored, so I can envisage that, sometimes, indices will get corrupted.
(This is what happens when you try to be "everything to everybody".)
It will be fixed ASAP.
Don
As for the exception you experienced, George, for the moment at least, I suspect it to be the same cause. Sometimes vertices get ignored, so I can envisage that, sometimes, indices will get corrupted.
(This is what happens when you try to be "everything to everybody".)
It will be fixed ASAP.
Don
tgibson
Resource contributor
- Messages
- 11,841
- Country
Well, at least half the problem seems to have been fixed. Nobody specifically mentioned delete as an issue yesterday, so I thought I'd leave "well enough alone". Guess I should have checked.
There are only a few lines of dedicated code for delete, so the issue shouldn't take long to isolate. Perhaps something I did yesterday affected those few lines.
Another update ASAP.
Don
There are only a few lines of dedicated code for delete, so the issue shouldn't take long to isolate. Perhaps something I did yesterday affected those few lines.
Another update ASAP.
Don
Before I cheer too loudly, I's like you to try the attached.
As often is the case, one's first attempt at coding a complex function is usually complex - sometimes overly so. And that seems to have been the case with the new poly processor. Fix one thing and it goes bad somewhere else.
Do that enough times and you give up saying "I've got to find a simpler approach!"
I've tried many combinations - including, moves, additions and deletions in the same "pass". This new, much simpler, implementation has handled everything I've thrown at it.
Your turn.
Don
As often is the case, one's first attempt at coding a complex function is usually complex - sometimes overly so. And that seems to have been the case with the new poly processor. Fix one thing and it goes bad somewhere else.
Do that enough times and you give up saying "I've got to find a simpler approach!"
I've tried many combinations - including, moves, additions and deletions in the same "pass". This new, much simpler, implementation has handled everything I've thrown at it.
Your turn.
Don
Last edited:
tgibson
Resource contributor
- Messages
- 11,841
- Country
Hi,
Actually you can infer that I forgot to test it...
Seems to work well - I can edit both polygons and lines just fine.
For many of the polygon manipulations the GP Editor retains my resizing, but at some point it reverts to the "default" listed in the Def file. This is not a bug, but it would be nice to retain my resizing throughout.
Thanks,
Actually you can infer that I forgot to test it...
Seems to work well - I can edit both polygons and lines just fine.
For many of the polygon manipulations the GP Editor retains my resizing, but at some point it reverts to the "default" listed in the Def file. This is not a bug, but it would be nice to retain my resizing throughout.
Thanks,