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

Move airport, altitude and Save

Messages
216
When "Move Airport" is used, the altitude in airport properties is set to 0 (although runway keeps the original altitude).

Is this normal ? (I don't remember this in older versions).
I suppose the only fix, is to "Change Airport Altitude" just after the Move ?

After "Move", even if you press "Save", nothing is saved (just lost 2hrs work). You have to "Save As".
Can this be rectified?
 
It is 1.60.5153.25746.

pleas also note that after "Change Airport Altitude", runway has the old+new alt, i.e. double the correct one.
 
So the airport has no altitude and the runway has the old altitude plus the new altitude..............
 
OK I can confirm the problems. I will try and get it fixed as soon as possible.
 
"Save" does not work also after "Rotate"; you have to use "SaveAs".

Is there any way to bring the runway back to correct altitude, in the meantime ? (altitude in runway properties is greyed out).
 
You can change the runway altitude using the Raw Data View accessed from the Tools Menu. I have noted the issue with Rotate. What is happening is that ADE is sticking with the temporary Move project and not copying it over the existing project.
 
oops...forgot about Raw Data View.
Corrected runway alt (along with Start alt) from there. So now .ad3 looks ok.
Haven't compile it yet, but I suppose that I can expect a stub file (for the alt).

Thanks Jon for taking care of us (even with sporadic senior moments).
 
I hope to get a look at it over the weekend
 
Jon,

I think I'd reported the saving problem already in the past but it might be that the connected level change and moving behaviour has covered this. Unfortunately I did not test meanwhile those functions again. In the meantime I'm rather thinking about a proposal to add an option (!) changing the altitude of vertices having the same level than the runway at once to the new one. It's a pain having a complex airport background poly surrounded by quite a bunch of other polygons with individual levels of the outside vertices (where they are not bordering the background). Sometime level changes are trial an error based even if they are well prepared.
 
There are several previous bugs and other reports on this. I have fixed a couple. It seems that I need to check it all again. Changing altitudes was never part of it since ADE cannot know the altitudes at the destination unless it is linked to FS after the move.

Sent from my Sony Xperia with Tapatalk
 
I have found the issue with altitudes on move/rotate. It seems that some code which I changed to fix this before did not get into the current version. I have fixed this so now the airport reference altitude is maintained when a move/rotate is made. It seems that the file name issue has been present in ADE since 1.55. I am not sure why it has not been spotted before. Basically ADE creates a temporary move file and this is what is saved unless you use SaveAs. It may be (and here my memory is faulty) that the creation of a temporary file is indeed intended since there is no undo for a file move and getting to wrong could mess up a good project file. So I think that Move/Rotate should always be saved other than over the existing project file. I will add some code to ADE to make this much clearer and offer the user a chance to set the file name.
 
Changing altitudes was never part of it since ADE cannot know the altitudes at the destination unless it is linked to FS after the move.
Jon,
This constraint looks like a big chance in case you are linked to FS to change such "floating" altitudes of vertices not in the vicinity of fixed ones - still as an option. Why moving an aircraft around to do this? In case a user needs to follow own ideas of an ideal altitude the present process could remain the default one. I'm looking forward... :duck: (well, I know it's kinda cheeky; hmm it's time to say that I really love ADE even as it is and I very much appreciate your engagement, not forgetting the people around you, Jon :coffee:).
 
Axel I agree that if you are linked to FS at the time of the move then the user aircraft could be moved to the new location and the Ground Altitude read, An offer could then be made by ADE to change the airport reference altitude to the ground altitude at that point. I will add it to my list ;)
 
Hi Jon,

I'm not sure whether we are not talking about different things. I prepared a picture that hopefully makes things more clear. If you are changing an airport altitude, the background poly has to be changed, too (if it already exists). Today you can change the "main-poly" without any problems in one step but if you have already adapted the whole thing to the landscape by vertices with individual levels (marked RED) it would be nice if those being somehow linked to the poly in the centre could be changed in one step too or if they optionally would follow their neighbours having the same level (marked in GREEN). Today you have to do it manually for each of the vertices being "attached" to it in order to avoid steps.

During the construction phase it would be even cool if ADE (being connected, of course) could optionally adapt to the landscape levels if it finds polys with editable individual points being not in the vicinity of a fixed level poly (RED). Even if it does not work for the one or other this would be much better than sliding around with an aircraft.

These are two different topics (and I know that I'm just dreaming).:rolleyes:

2014-02-26_20h38,45_ADEXv01.60.5153  (Pro)_ UHNN - AB.jpg
2014-02-26_20h38,45_ADEXv01.60.5153  (Pro)_ UHNN - AB.jpg
 
Back
Top