Hi Ed:
Thanks for your reply and information on the "Apron Path" Link; sorry I did not initially acknowledge the applicability of that airport object type in the context of this discussion, as AFX refers to these objects as "Apron Links" (Page 18 in the AFX Manual).
Additionally, I had previously assumed one could properly address such matters as you described in your opening post for runway visibility ...via the use of "
invisible runways" in the airport file underneath the photoreal airport background.
Apparently FSX SP1 and SDK SP1A restored support for FS8-style "invisible" runways, that IIRC was previously possible in FS8 and FS9
http://msdn.microsoft.com/en-us/esp/cc789354.aspx
IIUC, this most often is done by
making runways at the minimum width of 1 Meter, which does not allow the runway texture to be displayed by FS.
I also got the impression (apparently incorrectly, and colored by my own "wishful thinking"
) from a cursory initial read of Arnos reply, that if "special tweaks" could alter "ground roll" Effect behavior of pilot-controlled aircraft on photoreal imagery ground textures (as a form of mesh-clinging custom land class ...and therefore "terrain scenery") superimposed on underlying airport objects via changing XML attributes of those airport objects, there might also be a way to tweak the behavior of photoreal ground textures if draped over non-flat terrain such as a water ramp.
However, I suppose we may find that FS airport objects are always intended to be flat, so I am not certain there is a way to put an Apron Path or Taxiway Link on sloping terrain.
That subject brings us to the other part of your question in regards to airport
taxiways.
I tend to assume most developers of FS airports would likely set them up for AI with Apron Paths and Taxi links (even though I don't use AI myself very often, if at all).
But it is apparent there are a number of ways folks might opt to design and code their airports to deal with making airport objects "invisible" while still having an impact on airport display and function as Jim Vile explains here:
http://www.fsdeveloper.com/forum/showthread.php?t=4015
http://www.simforums.com/forums/forum_posts.asp?TID=22204&PID=126030
...And an important caveat Jim also points out about moving airports in general:
http://www.simforums.com/forums/forum_posts.asp?TID=14884&PN=1
Regarding the airport "Apron" tweak Arno mentioned:
I'm not sure what exactly is involved in the XML code tweak alluded to by Arno using ModelConverterX that can "
convert the aprons from XML code to these SCASM Surface Type commands" by a process that requires one to "
run the XML file through the special tool in ModelConverterX and this will give you a SCA source where your apron areas will be hard."
IIUC, the result is not the same as SCASM runways and is
not vulnerable to the performance hit SCASM "
runway" code incurs in FSX SP2, but instead specifically imparts a "hard" attribute to the airport Apron Path which IIRC, is treated as form of Taxiway ?
So IIRC, one would be
removing that particular Apron area from the airport Apron XML code otherwise being rendered by FS.
Thus, via the tweaked SCA intermediate file, that airport Apron area in question will then be rendered in FS via a SCASM compiled BGL ...
instead of via XML code compiled by FSX SP2 SDK BGLComp (or the semi-proprietary run time compiler in AFX ...after one re-opens and saves the re-compiled XML airport in AFX).
Perhaps Arno could be so kind as to explain this process in further detail when he gets a chance ?
BTW: I believe Arno meant that if one were to use an airport object (such as a runway) created via SCASM, one might find that it is more challenging to move it in the SCASM code form than it would otherwise have been in the XML code form; I presume this same caveat might apply to the Apron Path as well. :spushpin:
So one might infer he was advising one to be certain all airport objects are positioned where they are wanted
before processing any of that airport's code via the ModelConverterX method (that ends up going through SCASM code intermediates before compiled into the BGL to be used at the airport).
No doubt your airport objects are positioned where they are wanted, as they are aligned with properly geo-positioned aerial imagery used for the airport background.
Like you, I would like to better understand "
what the properties of the "apron path" are and how that could be applied, if at all, to an area poly".
And I too, wonder if one could alter the attribute of photoreal airport backgrounds so that one might (via a non-airport vector terrain poly) be... "
In effect applying an invisible hardening layer over the photoimage".
Alas, so much to learn... so little time !
Hope this helps !
GaryGB