I have just uploaded Development Release 4.4.2.4. This release fixes (I hope) a recently-introduced issue with approach array elevation being expressed in m. But, its main purpose is to correct an underlying problem when AFLT-generated lights are used with P3D.
AFLT relies on P3D placing the lights at the elevation specified. However, at any point in time, P3D only knows with accuracy the ground elevation for a small radius about the point directly beneath the user aircraft. AFLT spawn lights about 20 miles from the airport - well outside this small radius. If, for example, AFLT "tells" P3D to put a light at ground level, P3D apparently places the light at the elevation of the ground then beneath the user aircraft (since it doesn't "know" the ground elevation 20 miles away). In earlier releases of AFLT, I had assumed that, as the aircraft got closed to the airport, the lights would remain at ground level. But no, they remain at the elevation at which they were spawned. So, approaching from higher ground, upon arrival at an airport the AFLT lights often were floating above the ground. Due to "ground clamping", i.e., preventing the light from disappearing below the surface", things generally were normal when approaching from lower or level ground.
This new release of AFLT monitors the elevation of the ground below the user aircraft. When it changes, AFLT waits for it to stabilize and then calls for the elevation of all its lights to be updated, thus forcing those supposed to be on the ground back to ground level. Lights with elevation specified as ASL rather than AGL, don't require this "service", but few of AFLT's lights fall into this category. One might think the ARP elevation might be useful for this purpose. Unfortunately , with PV5, every runway and taxiway light may be at a different elevation - all specified as 0 AGL.
If this additional monitoring of ground elevation creates a significant reduction in FPS, I can probably fine tune things a bit - like limiting continuous monitoring to within, say 5 miles of the airport, beyond which any elevation discrepancy would be less obvious. But, first, I want to be sure I've solved the underlying problem.
So, those of you willing to help, please load up 4.4.2.4 (remember, its a development release, so be sure to use the right menu item at the website), fly to your AFLT airport over seriously-undulating terrain and check that the lights are on the ground when you get there - checking FPS along the way. You might also try a similar flight with an earlier version and check the FPS at intermediate points (within 20 miles) to compare with 4.4.2.4.
Thanks in advance,
Don
AFLT relies on P3D placing the lights at the elevation specified. However, at any point in time, P3D only knows with accuracy the ground elevation for a small radius about the point directly beneath the user aircraft. AFLT spawn lights about 20 miles from the airport - well outside this small radius. If, for example, AFLT "tells" P3D to put a light at ground level, P3D apparently places the light at the elevation of the ground then beneath the user aircraft (since it doesn't "know" the ground elevation 20 miles away). In earlier releases of AFLT, I had assumed that, as the aircraft got closed to the airport, the lights would remain at ground level. But no, they remain at the elevation at which they were spawned. So, approaching from higher ground, upon arrival at an airport the AFLT lights often were floating above the ground. Due to "ground clamping", i.e., preventing the light from disappearing below the surface", things generally were normal when approaching from lower or level ground.
This new release of AFLT monitors the elevation of the ground below the user aircraft. When it changes, AFLT waits for it to stabilize and then calls for the elevation of all its lights to be updated, thus forcing those supposed to be on the ground back to ground level. Lights with elevation specified as ASL rather than AGL, don't require this "service", but few of AFLT's lights fall into this category. One might think the ARP elevation might be useful for this purpose. Unfortunately , with PV5, every runway and taxiway light may be at a different elevation - all specified as 0 AGL.
If this additional monitoring of ground elevation creates a significant reduction in FPS, I can probably fine tune things a bit - like limiting continuous monitoring to within, say 5 miles of the airport, beyond which any elevation discrepancy would be less obvious. But, first, I want to be sure I've solved the underlying problem.
So, those of you willing to help, please load up 4.4.2.4 (remember, its a development release, so be sure to use the right menu item at the website), fly to your AFLT airport over seriously-undulating terrain and check that the lights are on the ground when you get there - checking FPS along the way. You might also try a similar flight with an earlier version and check the FPS at intermediate points (within 20 miles) to compare with 4.4.2.4.
Thanks in advance,
Don