Hi Mike,
to answer your question for PHNL and to give some more information about the work in the background the fs-engine produces...
The fs-engine loads (of course) all needed bgls into the memory it has to - depending on the entries from scenery.cfg exactly in the order you could manipulate. Very early the standard-fs-directories are loaded and in these directories are for example the standard flattenings FL* and the standard airport AP* files. Mostly last but not least the "newer" addon scenery-bgls.
Very interesting is:
If you start at an airport, fly around in this fs-cell and land again, all bgls from this airport are loaded last and - more important - they are used correctly. It will lead to no problem, you would be able to place lwm-files for flattening under the standard-airport-altitude. And you could put the complete airport (in the afcad file) on a deeper or higher level as the standard-airport-altitude. All this works and - if in the betatests there were no flights from another destination - this looks all correct.
But the problem begins if you come from another fs-cell, another airport, which is a little bit far away. So that the fs-engine has to load this cell-bgls while flying around. In this case the engine use the method "the first found entry counts". Sadly the first entry is the first airport entry the engine gets. Mostly the standard-entries in the ap-files are the first files. This is the reason why if s.o. have to change the airport altitude to a deeper altitude the designers put altitude-correction-files in the standard-directorys (like world/scenery - it's written "earlier" than the standard AP-files). Or manipulate the standard AP-files (like jabbgl).
Of course you get problems (like in this case) when the AP-files altitude wouldn't be at the same altitude than the airport itself.
In the AFCAD file Fabrizio used the same altitude like standard. So no problem here. But the airport flattening is made nowadays with a lwm-flatten. Sadly the engine isn't able to use an exact definition like 13.36 ft. No, it uses the code from my last statement one page earlier with the fragments for meters and x/128... This leads to many mistakes - not only here...
When approaching from another destination: AP-files found, airport altitude is set.
And now the lwm-flattening (which is deeper I said in my last statemant) puts the flattening "underneath" the AP-files-altitude -> this leads to such a problem like described. I'm sure Fabrizio put the photo bitmap exactly 0ft above his lwm-flattening. Correct Fabrizio?
So there are many reasons if a customer has problems only while landing at an airport, not when starting.
Maybe you (Mike) have changed the standard-ap-altitude in the standard file (from another older addon) or somewhere in your sceneries is another AFCAD with a deeper altitude. I have no problems in PHNL, so there are no faults from standard fs to fsdreamteam-addon without the older influence from another PHNL-Addon.
BTW: this fact often is the reason for sunken wheels or floating aircrafts a view feet above the ground. Only to add this... (not the fact here)
Sorry if I have made errors in writing in english.
Ciao,
Rainer.
