Follow up after further explorations. The World Map "From" field has changed slightly. My version now offers saved coordinates, as a destination. At first, I'd thought it had been my own saved coordinates, from when I work on my scenery, but I do not have the airport package in Community folder, so I can spawn at that location to work on it. However, the saved coordinates go to a city in the Midwest called "Austin," a place I'd never look for, so I believe the saved coordinate destination was placed there to alert simmers that one can type geo coordinates into the search bar and have it generate a custom spawn point at 1500' altitude.The feature is not new, it has always worked this way, the only thing that has changed, is now there is a set of coords to select.
Also, FSPackagetool compiles much more quickly. This is especially noticeable, if you use a desktop icon, or other process to load just the compiler, as I do. I just drop the XML onto the icon and the result is just short of instant.
As to my project, it remains botched and I can't start there, unless I use a float plane, or custom spawn. This despite some exploration and discoveries. I'd actually decided this is not a consequence of SU10 and I am still not convinced, despite the latest comment and it seems more likely this is a consequence of issues with ADE, or making poorly supported changes, which would be helpful to confirm, with the commenter above.
I am trying to determine this, currently. I have done some investigations and they tend to discount "a universal custom scenery bug," or anything like that. It seems much more likely a software error, I am suspecting issues I had using ADE, but this would involve the premise that ADE introduced a glitch that remained "dormant," until SU10 uncovered it, which seems preposterous. Additionally, other airports I made in the area, to support AI operations, do not have this issue, so although this happened exactly at the transition to SU10, it seems difficult to relate the two. I had not performed a build with SU10, until I tested to see if doing so would remedy the issue.
Can you tell us if your airport.xml has a similar value for runway surface type, as does mine, an image of which is below?
With what software do you edit your airport details? Have you used ADE lately?
After some initial tests in the sim, I took a deep dive into the PackageSources folder.
View attachment 84124
I discovered an apparent anomaly in the airport XML, in that every other taxiway has a surface type that looks like a GUID, but the runway has type "00000000-0000-0000-0000-000000000000," which seems incredibly improbable, so either runway surface GUID is always 000, or previous versions ignored runway surface type while SU10 discriminates it, or maybe when ADE allowed me to add an NDB and then crashed due to its presence it left a "present."
Yes, older airport XML documents
do have a numerical value for that GUID, but no, replacing the zeroed out one, changes nothing. Besides, how could SU10's FSPackagetool, edit the contents of my PackageSources folder, without even changing the modification date? Please also explain how this SU10 FSPackagetool
then leaves my corrected XML in the PackageSources folder, builds an airport project with a numerical valued GUID surface type, that remains a water runway.
So essentially, two things happened, on the coincidence, of SU10 update.
1) my airport.xml zeroed out it's surface type designation.
2) my airport is now a water runway, regardless if surface type is zero, or copy/pasted from previous versions.
Also, I see no AI activity whatsoever. No planes, no boats, no GAIST, no custom. Not the current issue, but it is ominous.
I suppose I could try editing one of the other airports, to see if that screws things up worse.
