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

FS2004 Array Elevation wrong?

H

hgschnell

Messages
1,604
Country
germany
Hi Don,
I think the elevation is to enter in feet, otherwise the compiled bgl is wrong.

array2.jpg
 
I realized I was wrong after posting that. Sorry about that. I'll try to do better
 
Indeed there is. The AGL selection was not being ignored. It was being overwritten. BUT, there is another issue . This was working prior to the general release. So, apparently, I've changed something unintentionally.

I'll re-release ASAP (this one may take a while). In the meantime, please don't use the Array Elevation feature, i.e., leave it at 0 AGL.
 
there is no need to hurry.
Click to expand...
Yeah! There is, Guenther. I've been working on this project for almost a year and I'm getting sort of tired of it. I just want it to be "perfect", so I can get on with something else.

Yesterdays fix was unnecessary and problematic. The need for it was so obvious (then), that I didn't thoroughly test. Glad that you did.

I have just posted Development Release 4.4.2.3. This time, your elevation issue is fixed - at least as far as I can test it with my own airports. For those of you who have enabled detection of Development Releases, you'll get an invitation to download the release the next time you start AFLT. Otherwise, you'll have to fetch it manually. Please note, it will only benefit those who have chosen an array elevation other than 0 AGL.
 
Re Update Control File message. Are you still getting it. The file itself is fine.

Calculation is wrong: elevation has to be entered in feet.
Click to expand...
Could you be a little more descriptive, please. It's not clear what you mean.
 
As I downloaded 4.4.2.3 manually I cannot get this message until a newer version exits. So I will report in this case.
An example for my airport (EICK 502ft, 153M):
If I enter 153 for array elevation, the array is under the ground on about 44m.
If I enter 502, the array is pretty correct on 153m with lovely long posts on my mesh.
 
I can find nothing wrong. I wonder if this situation is a result of misunderstanding due to British units being automatically selected for FAA-type approaches (e.g., AFLT2) and metric units for ICAO approaches (e.g. Calvert2).

If this is not the case, please send me your Project file, the airport .bgl and detailed instructions for triggering the issue.
 
Hi Don,
sorry about my late reply. I was gone fishing and thinking about how I could explain our misunderstanding.
It is all about the "(M.)" on the window for editing approach lights.
If it would read "(Ft.)" all would be perfect for me.
On my airport EICK the elevation is 502ft/153m. If I enter 153, the AFLT_Cork 2_Bases_9.bgl gives the following, if I decompile it with BGL2XML:

<SceneryObject
lat="51.8555693328381"
lon="-8.49960386753082"
alt="47.134M"
altitudeIsAgl="FALSE"
pitch="0"
bank="0"
heading="159.889526367188"
imageComplexity="NORMAL">
<LibraryObject
name="0dcf00724320d0e63858c7a3434869d2"
scale="1.00"
/>

Only if I enter 502, the altitude is correct.

AFLT1.jpg


If that is only on my pc the case, I will ofcourse send you all necessary files.
 
Don, I believe that Guenther is saying when he chooses a Calvert approach and AFLT switches to Meters, this box is still in Feet, even though it says M. So there appear to be two choices - change the printed M to Ft, or change the units used in that text box from Feet to Meters. Hope this helps?
 
I believe that Guenther is saying when he chooses a Calvert approach and AFLT switches to Meters, this box is still in Feet, even though it says M.
Click to expand...
Yes, that's exactly what happening, The reason is that only the distance conversion constant is automatically changed, but the elevation constant isn't. So, as you suggest, while the box title says "M", the constant will be whatever it was before. So, sometimes it will work, sometimes it won't.

Since I now know what I'm looking for, the problem should be easy to fix - hopefully tomorrow.
 
Glad to read all is clear now.
By the way, the user manual pdf contains only the History content since 4.4.2.2
 
You must log in or register to reply here.
Back
Top