• 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 Version 1.60.4836 Beta Released

Status
Not open for further replies.
If I move the horizontal scroll bar, the picture doesn't change but when I release the mouse button, the scroll bar disappears
If you look carefully at the screenshot, you'll see that, after scrolling left, the horizontal scroll bar is no longer needed, so it disappears
I can just about live with the re-sizing problem but not with the save/load.
Thanks for doing that testing, George. Unfortunately, without a narrative, I'm not sure what most of it means.

The reason I asked you to run three texts was so I could see:
  • what arrived from ADE
  • what the editor sent back, and
  • what ADE stored and returned
From the first two tests, I can see that the X/Y screen positioning previously saved by ADE is the same as the editor returned on OK, and that the vertices are positioned accordingly. While you didn't perform the third step, I think it's safe to infer from the first (which is the data the editor returned previously) that ADE is sending and the editor is returning the correct X/Y position. The texture U/Vs, however, are not consistent - and I thought you may have put your finger on it with your suggestion that the problem is related to zooming (which I didn't realize you were doing). But no, I've tried zooming and my display always initializes to the zoom level it was at when the data was last returned to ADE.

That being said, there is definitely a problem with the resize function (resizing the vertex display, not the window) in that the scale parameter (the last item in the data message) is not being updated. I'll get that fixed and send a new update shortly.

Don
 
Unfortunately, without a narrative, I'm not sure what most of it means.

That is the problem when there isn't a log file showing the operations.

I'll edit the previous post and add what I think were the operations.
 
I wasn't asking for that, George. Let me track down the scaling problem I know exists first.

Don

PS. Found the problem!!. The vertices are being positioned correctly. It's the textrure scaling that's wrong
 
Last edited:
I wasn't asking for that, George. Let me track down the scaling problem I know exists first.

Don

PS. Found the problem!!. The vertices are being positioned correctly. It's the textrure scaling that's wrong

I edited the post anyway.
 
George, the attached contains the texture scaling fix. It has had no regression testing (obviously), so I may have broken something else. But, I need to know if the texture and vertices are now properly positioned on your system.

I've also adjusted the redraw logic to see it this helps or hinders your disappearing display issue.

Don
 
Last edited:
Quote:
My outlines don't seem to work quite right.

I can see that. I made some changes in the poly triangulation area yesterday. Perhaps I broke something. I take a look.
Yes, Gary, I did break the compiler yesterday. Hopefully, that was the cause of your outlines problem. It is now fixed and I'll re-release after I hear back from George on the other issues.
I guess I don't understand the use of the numbers/ground graphics despite multiple re-reads of the instructions, but I've not had much time to experiment. I'm struggling with resizing the polygon (in gp poly edit box or adex) vs re sizing the texture sheet (can't seem to do that) so I'm getting the entire sheet displayed. But that's another topic...not here, not now.
The provided textures are those I use for my own airports. They are really a "starter kit" for other users. Other than gp_Patterns.bmp, the generic line and plain and cross-hatch poly patterns, I expect most users will supply what they need. (The "numbers/ground graphics" to which I assume you are referring is texture sheet gp_ParkingDes.bmp. These are, for the most part, gate lead-in starters and jetway parking markers from my CYYJ. If you take a look at my CYYJ (http://stuff4fs.com), their use will be clear). Hope thios helps.

Don
 
That is almost perfect Don :)

I started with a new triangle and on entering the editor I could see the texture sheet and the triangle :eek:

I compiled and saved.

I then reloaded the project and, on entering the editor, the texture was visible but not the triangle :mad:

However, after a quick re-size of the window, the triangle appeared :)

I moved the vertices to a different symbol and during the move, there was no flickering and the triangle remained visible throughout :)

This was on XP, I haven't tried W7 but I assume it will be equally as good.

Here are the results in FSX:





Thanks for sticking with me.
 
You're welcome, Horst.

Version 0.0.21 attached. In addition to preserving vertex positioning on the display, I have:
  • reworked the resize logic to preserve the aspect ratio of the vertices,
  • fixed the triangulation error introduced in Version 0.0.20,
  • fixed the scroll bars so the textures now scroll, and
  • adjusted the scroll bar limits so the scroll bars are visible if either a vertex or a portion of the current texture are off-screen.
During this last "exercise" I have come to realize that George's "disappearing vertices" issue is a result of the internal timing/sequence of picture box update, picturebox background update and dialog update. I can introduce various such errors by adjusting my display update sequences. (Hopefully, I haven't lost the recipe during my explorations, George. If I have, I now know how to get it back - with a little trial and error.) Presumably XP has different sequences from Win 7. What's disturbing is the apparent difference between Win7 on George's system and Win 7 on Jon's, my and other users who have "reported in" systems.

Anyway, we're closer to "golden" than we were a few hours ago.

Don
 
Last edited:
What's disturbing is the apparent difference between Win7 on George's system and Win 7 on Jon's, my and other users who have "reported in" systems.

Yes, my W7 behaved exactly the same as XP in the flickering and disappearing acts :D
 
Far fetched input; but when making all those transparent gates at ENGM...I was told the graphis cards makers also have not yet solved issues regarding transparency - to this date. The reason why I let my sceneries have some "bugs", not ever trying to explain it, just telling in the readme, this is an issue I can't overcome. Look at some of the default towers from MS. They have issues. I see the same in other games. Thats why I coolly release my scenerys with bugs included. One must have that kinda habit working with MSFS stuff. To survive or not survive :D

To get on track, may this have to do with the fact transparency worked better in FS9, and was "broken" with one of the FSX SP's?

Cheers,
:stirthepo
 
Last edited:
reworked the resize logic to preserve the aspect ratio of the vertices
I don't understand. I can change the position of the vertices independently.



However, selecting individual vertices is problematical. I can select the first with a single click, but there is no way to de-select it so the only way is to use a rubber-band selection of another vertex.


During this last "exercise" I have come to realize that George's "disappearing vertices" issue is a result of the internal timing/sequence of picture box update, picturebox background update and dialog update. I can introduce various such errors by adjusting my display update sequences. (Hopefully, I haven't lost the recipe during my explorations, George. If I have, I now know how to get it back - with a little trial and error.) Presumably XP has different sequences from Win 7. What's disturbing is the apparent difference between Win7 on George's system and Win 7 on Jon's, my and other users who have "reported in" systems.

I don't see why W7 and XP should be different and they aren't on my two systems.

I still have the situation that on initial entry to the editor, the polygon is not visible. I need to re-size the window for it to become visible, therafter it remains visible until exit.

Initial screen:



After a slight re-size:

 
Quote:
Originally Posted by gadgets
reworked the resize logic to preserve the aspect ratio of the vertices

I don't understand. I can change the position of the vertices independently.
I was reporting on RESIZE, George; you are demonstrating DRAG. You really should be more trusting ;)
However, selecting individual vertices is problematical. I can select the first with a single click, but there is no way to de-select it so the only way is to use a rubber-band selection of another vertex.
I'm not real happy either with the current operation, but I'm limited in what I can do at that point. However, I'll take another look to see if it can be improved.

I still have the situation that on initial entry to the editor, the polygon is not visible. I need to re-size the window for it to become visible, therafter it remains visible until exit.
That's the best it's ever been and, frankly, until we understand why your system is different, I don't see that changing. What's happening is that your system is late drawing the background (i.e., the texture and distance markers) when the window is first opened and the foreground, i.e, the vertices, are overwritten. I can't move the texture to the foreground, since that was the cause of the earlier flickering. I call for a redraw of the foreground after every call for a background redraw. I don't know what more I can do.

I appreciate it's an annoyance. But, we now have 5 people who are using the editor without such difficulty. Perhaps one of those two Net.Framework adjuncts you have installed is "misbehaving". I note that Microsoft plans to discontinue Net.Framework Client. They claim its because Framework 4.5 is so much smaller and more efficient that 4.0, so it's no longer required. Maybe that's not the whole story - or the cause of your difficulty. But, definitely, your machine seems unique.

Don
 
Don,

I can confirm that with your latest release things works like supposed to :)

  • compile errors are gone
  • single vertex operations are possible
  • polygon and textures appear in sim as intended
  • on re-edit the polygon and texture appears as saved

Great work !!
 
Just when I thought everything was hunky dory :D

I used a new feature, patterned lines.

In XP, added a line, compiled, saved and ran FSX. Great:



To complete the test, I then copied the ADE project file to W7 and got a "Problem on start-up" message box on entering the editor.

Not to be beaten, I went back to XP, loaded the project and, lo and behold, I got the same error :eek:



It seems as though patterned lines are not being saved correctly.

Project attached.
 
Last edited:
Don,

I changed an existing short test line in ADE into a long line, running all way paralle beside a runway as a border.

After I chaged the length in ADE and clicked on the line, I received a message saying something about an arithmetic overflow. Then the editor window opens, but in a loop saying "maximum zoom has been exceeded".

I guess that the line lenghth is longer as supported or as you have expected one to be. And in order to show it completely in the editor window the code tries to set a zoom factor that is not supported.

--> added
Seeing George's parallel post above it might not be the length of the line alone
 
It seems as though patterned lines are not being saved correctly
They were, in fact, being saved correctly. But, I overlooked something when applying the vertex positioning changes yesterday. Version 0.0.22 fixes.

(To keep things moving in a beta environment, I do minimal regression testing. So some issues like that are bound to "get through".)

After I chaged the length in ADE and clicked on the line, I received a message saying something about an arithmetic overflow. Then the editor window opens, but in a loop saying "maximum zoom has been exceeded".
Martin, not sure how you got to the zoom logic with that error. But, obviously, you did. I've checked zoom at all practical values and it seems solid. The error you experienced must have been related to the "overflow" error - which is no longer.

Don
 
Last edited:
Don and Jon, great job on this!

I do have a question. I'm using v0.21 with WinXP. I created an asphalt polygon, with a darker asphalt outline using layer 40. Worked great in FS9. ADE made the polygon red in color. Then I created another polygon on top of my red asphalt polygon and made it layer 45. I then textured it with the words CONTACT TOWER, and compiled it. Showed up fine in FS9. But the second polygon I created was also red, and thus is invisible on the red background polygon. Is there a way to change the color of that polygon when viewed in ADE?

Also, I had some scaling issues when later changing the proportions of that second polygon (the shape never changed in FS), but I haven't worked those out methodically for a report yet.

Thanks,
 
Status
Not open for further replies.
Back
Top