Attributes that are not Honored or effect FS

[jvile]

This thread is about certain coding in a decompiled AP9/APX bgl that is not honored by FS even though some records and the SDK tell us what we can place in the record for a proper compile. Just because the compile process will create a bgl without errors does not mean that what was changed is honored when FS is running.

I will start with some altitude issues and then add additional post which will work through all areas not honored or cause problems.

The most important altitudes that SDE decompiles are the 3 that I am listing. I will address other altitudes in other areas later and what effects they have on a running FS9/FSX but first things first.


<Airport
country="United States"
state="Georgia"
city="Savannah"
name="Savannah/Hilton Head Intl"
lat="32.127583399415"
lon="-81.2021389603615"
alt="50.0F"
magvar="6"
trafficScalar="1"
airportTestRadius="5000.0M"
ident="KSAV"

<Runway
lat="32.1286137029529"
lon="-81.2036901712418"
alt="50.0F"

<Start
type="RUNWAY"
lat="32.1287478134036"
lon="-81.2182947993279"
alt="50.0F"


Every altitude listed in a decompiled Airport Record as seen with SDE is normally used for some sort of control or proper behavior of default or added scenery that is stationary or moves. Yes, some scenery in FS9/FSX is designed to move such as a AI Plane.

There may have to be some form of locking device in SDE that either does not allow these 3 altitudes to be different or a message explaining that the visual and behavior of FS9/FSX can be corrupted if these 3 altitudes are different from each other.

In the early days of FS9, scenery designers developed the Orgas Islands. After the release it was noted by many that airplanes were not sitting properly on the ground at Diamond Point airport. Peter McLeland found a work around to fix the 3rd party scenery problem which some of the work around is still used today in 3rd party scenery design.

You can read his findings about Airport/Runway altitudes here

http://www.fsaddon.com/download_instr_1.htm

Dick (rhumbaflappy) also adds to Peters instructions that the entire duplicate bgl, AFCAD or in our case the SDE records do not need to be copied to the beginning of the scenery load process. See his post here

http://www.fsdeveloper.com/forum/showthread.php?p=22031#post22031

For those that want to use SDE and change the default Airport altitude and then compile back into the AP9/APX default bgl I have a message from the ACES group. I call this my no-no text file

ACES says

As you know, currently, you have to preload FS with a basic Airport Header with the new altitude data loaded before the default airport, and then use a second Airport Header record to lay out the redesigned airport. To remove existing flattens, change airport altitudes, etc. you currently would have to edit the MS default bgl codes. A big no-no.

The Start Location altitude is also important and must always be the same as the Airport/Runway. Start Location is not the best descriptive name because it is also the End Location.

Every Flightplan generated must terminate somewhere. The Start Location of a runway is used at the end of the FP for that coding.

FS9/FSX also calculates the closest Start Location (runway end) based on the direction the aircraft is arriving from for landing. ATC intervenes and will change the ending location of the actual flight but not the FP which is based on many additional factors (weather, winds coded default runway, ILS vs visual runway, etc.).

It has been documented that if the Start Location altitude does not agree with the Airport/Runway altitudes the FP can be cancelled by ATC unexpectantly (enroute) or ATC may consider at times that the runway is closed.

It is more of a ATC confusing issue then a code that can be safely used. There is a proper way to close one end of a runway in FS9/FSX but that will be later based on other areas of the decompiled bgl which are not honored.

 

[scruffyduck]

Thanks Jim

That is a big help SDE could force runways and starts to have the same altitude as the ARP in several ways. One would be to make that property read only in the runway or start record and force it to be read from the parent airport. Thus a change to the ARP would be reflected in all those elements.

EDIT
Just reading through the fixes suggested for FS9 by placing a small bgl in the default folder setup, and presumably this works in FSX? It would be easy in SDE to generate a second simple Bgl containing the data to alter the elevation of an airport as suggested at the same time as the main modified Bgl is generated. I am not wise or experienced enough to know if this is the best way in FSX given that Shp2Vec is suggested as a method in one post. Actually future plans for SDE do include the ability to generate Shape files and compile using Shp2Vec. There is nothing in SDE which only allows one compiler type. In fact each object carries with it information about which compiler to use.

 

[phpdk]

A clarification of sorts on the ACES remark cited by Jim: By flattening in this respect they must refer to the flattening property of the runway element. It is possible to make a shp2vec-compiled flatten that overwrites/overrules the default cvx flatten even if the new cvx is "only" present in a folder with a higher priority than the default folders.


Peter

 

[jvile]

It is possible to make a shp2vec-compiled flatten that overwrites/overrules the default cvx flatten even if the new cvx is "only" present in a folder with a higher priority than the default folders.

Hi Peter

That is exactly what we have already been doing for the last 4 years with FS9 airports.

We are able to use deleteAll= statements which tells FS9 not to use certain portions of their default airport and then we substitute at a higher priority our changes (AFCAD)

Now it appears that FSX has also moved other areas of scenery toward that same concept.

The problem with altitudes does not occur when we change a default Airport and add what we want at a higher priority layer. Problems occur in Altitudes when 3rd party scenery layers their airport on top of the default at a higher elevation.

The hard floor of the airport is set by the airport ARP altitude that is in the default airport bgl for all planes that load at parking stands and the runway altitude is the hard floor for all in bound airborne planes landing. 3rd party scenery is fluid in design and their new elevation is not the hard floor that FS9 used.

You have to find a way to trick FS into thinking that the hard floor is different then the ARP airport altitude in the default bgl and that is what Peter McLeland did with an additional airport header at load time.

You see post all over the place about Airplane wheels sunk into the ramp/taxiway/runway or floating in the air because the new airport scenery does not match the default ARP altitude of the airport. So many try and Use AFCAD to fix these issues which only compound the situation.

I have created shp2vec cvx files for airports that have new runways such as KATL. Using the correct GUID I can flatten the ground to the same altitude of the original KATL ARP, add the new ground mask and remove the auto gen all in one compile.

However, this does not address the 3 altitudes that FS9/FSX uses on startup for both stationary planes (at the parking stand) and airborne inbound planes to a runway.

The 3 altitudes only become a concern when 3rd party lays down new airport sceney that their elevation differs from the default altitudes and if/when these airport scenery's start showing up in FSX then SDE has the ability to address the issues.

Shp2vec may in fact force 3rd airport scenery designers to stay with the default ARP altitudes in their future releases. Any utility that unlocks the 3 altitudes in question here should also produce warnings on the ill effects with wheel contact because of the way FS9/FSX uses different attributes for different coding for the User and AI Planes.

 

[jvile]

Moving further down in the Airport Header shows

trafficScalar="0.70"

The default traffic scaler in FSX is .70 and corresponds to Flightplans compiled with BGLComp and not TTools. Most FP's that were created with TTools in FS9 are being copied over to FSX so the scaler is listed properly but is not used based on who compiled the FP.

see Post #3 here

http://www.fsdeveloper.com/forum/showthread.php?t=4085


airportTestRadius="2000.0M"

Airport test radius by default is 2000.00M. BGLanayalyzeX decompiles at 4000.0M and I use 5000.0M for the compiler. If BGLCOMP sees any Record outside this Meter boundary of the airport it produces a whole host of error warnings but the XML still compiles. It is a warning only in the compile process.

<Services
<!-- Add service information here -->
</Services>

This is one of those gray areas in the Airport record because of the way the SDK says the following

"This element is used to add services to an airport. There are no attributes that can be applied to the Services element. This element is allowed to contain Fuel data and should not be terminated with ‘/>’.

Services DOES NOT add fuel to the airport!!!!

The <FUEL Trigger nested outside the airport record adds fuel available inside the vertex defined but only the type fuel listed in the <Fuel data record that corresponds to the <Fuel Trigger which is also nested outside the airport records.

Now, by coping the <Fuel Data information into the <Service record (nested inside the Airport record) is only used for listing what type Fuel is available for that Airport in the GPS receiver Fuel Window as information only.

FSX did not get most of the <Fuel data that is in that record copied into the <Service record nested inside the Airport Record so many airports do not show any fuel available in the GPS fuel window even though it is available in the vertex.

Maybe SDE can automatically copy any Fuel information listed in the <Fuel Data Record and create a new <Service record when it is missing which by the way is a lot of airports in the database.

Now when I am flying to a Airport I can pull up the GPS receiver Fuel Window and see what Fuel is available when I land.

 

[scruffyduck]

Maybe SDE can automatically copy any Fuel information listed in the <Fuel Data Record and create a new <Service record when it is missing which by the way is a lot of airports in the database.

Am I correct in thinking that the way to do that would be to find the trigger associated with the airport ( via some algorithm such as that used for taxi signs) and then either match the data in the service record to it? Or is it the other way around?

 

[jvile]

If you open 0302/26220 there are 180 Airports in that bgl. Out of the 180 airports in Florida SDE only found 14

<service entries in all the Airport records.

I did a spot check on just 3 major GA airports and FSX failed to list <service for those Airport Records so SDE cannot show a service if it is not a record.

I see the problem that would be very hard to code. All the Fuel Triggers and Fuel type is in the corresponding OBX26220 and looks like this.

<SceneryObject
lat="N33 27.86221"
lon="W082 2.18764"
alt="0.0000M"
altitudeIsAgl="TRUE"
pitch="0.00"
bank="0.00"
heading="0.00"
imageComplexity="VERY_SPARSE">
<Trigger
type="REFUEL_REPAIR"
triggerHeight="0.00">
<Fuel type="100"
availability="YES"/>
<Fuel type="JETAP"
availability="YES"/>
<Vertex biasX="-33.992" biasZ="11.161"/>
<Vertex biasX="-11.466" biasZ="33.890"/>
<Vertex biasX="11.263" biasZ="11.364"/>
<Vertex biasX="-11.263" biasZ="-11.364"/>
</Trigger>
</SceneryObject>

From this data in the OBX the 2 <Fuel type= would have to be copied into a <service record and nested inside the correct airport like this


<Services>
<Fuel type="100"
availability="YES"/>
<Fuel type="JETAP"
availability="YES"/>
</Services>

That means you would have to read all the Fuel Triggers and the Fuel type in the OBX and then associate that to the correct airport. Then copy Fuel type into the <Service record so it displays in the GPS.

I don't think that is worth the coding effort. Maybe a field for <service in each Airport Record so the designer can add the Fuel type as a option. That is what I have been doing once I see that <Service is not listed in the Airport I am working on.

 

[scruffyduck]

Hi Jim

I want to check back into SDE as to why it is not finding more services records. I think that there is one additional airport data record for each airport and that contain the services data. Maybe I am ignoring them if they are empty or maybe there is some problem with the way SDE handles the shifting of services from the services records to the airport record (they are stored in different places in the BGL file)

Been a while since I did that bit so I will check back

 

[jvile]

I decompiled APX26220 with bglanalyzeX and sorted out the <service records.

His decompiler listed 52 <Service Records for 180 airports.

EDIT

I just realized you already have a <Service field and all the listings of AVGAS. I don't know how I missed that record. No more hand editing on this end.

 

[scruffyduck]

OK let me check it out. The current development build of SDE has a raw view now which tells us how many of each type of scenery element is in the bgl and where it is located. If I am finding more than I am placing at airports then I have one sort of problem, if I am not finding them in the first place then I have another sort!!

EDIT

OK what I know for sure is that SDE is not processing Service records correctly. There is one record per airport but I have some weird code in the processor for that data which seems to be stopping another error and resulting in only a few records being processed

I need to go right back and work out what is going on and why

 

[scruffyduck]

Hmmm the mystery deepens.

There are certainly as many services records as there are airport records but a number of them are empty/ The way of associating services to the airport is via the ICAO. The records also contain lat and long data. Empty records have empty ICAO fields and the lat/lon are not set.

There is another problem associated with SDE which is throwing out of of memory errors indicating that some airport service records contain bad data ( as far as I can tell). So I have a combination of good records, empty records and bad records for this. Services record format is not published by the way so I am working from other forms of source code and I may have missed something although the records are actually very simple.

EDIT

I think I am looking in the wrong place there is services info in the Airport record itself. Have to go to a meeting now. Will look at it again tonight

 

[jvile]

SDE may only be finding a Service that has a valid "YES" availablity

<Fuel availability
YES
NO
UNKNOWN
PRIOR_REQUEST

records that I am looking at show many "UNKNOWN" which SDE may not be reading correctly

<Services>
<Fuel type="73"
availability="UNKNOWN"/>
<Fuel type="87"
availability="UNKNOWN"/>
<Fuel type="100"
availability="YES"/>
<Fuel type="130"
availability="UNKNOWN"/>
<Fuel type="145"
availability="UNKNOWN"/>
<Fuel type="JET"
availability="UNKNOWN"/>
<Fuel type="JET4"
availability="UNKNOWN"/>
<Fuel type="JET5"
availability="UNKNOWN"/>
</Services>

I can't see any advantage to having all these UNKNOWN's in a <Service record at airports listed in the APX.bgl

I can understand why some <Service data may be empty because those small airports don't have an associated Fuel Object model, a trigger and a Fuel type. If <service is in the Airport record then it should be empty.

Another clue in the airport record that a Library Object exsit with a Trigger vertex and Fuel type data in the OBX.bgl is that an airport will normally have a 16M radius parking spot that looks like this

<TaxiwayParking index="62"
type="FUEL"
name="PARKING"
number="1"
lat="N32 7.62123"
lon="W081 11.26072"
heading="89.73"
radius="16.0M"
pushBack="BOTH"/>

The reason for that taxiwayParking type="FUEL is so when a User Plane lands at a airport with Fuel there is a ATC option when contacting Ground Control that allows a selection to taxi to the Fuel Station which has the trigger vertex. This was not an option in FS9. If you ask Ground control for the Fuel Station they will give you the Taxiway route to follow and draw the Arrows/lines (option) on the taxiways.

 

[jvile]

While you are working on <Service issues I will continue with some additional areas that are vs are not honored.


<Runway
patternAltitude="1000.0F"
primaryTakeoff="YES"
primaryLanding="YES"
primaryPattern="LEFT"
secondaryTakeoff="YES"
secondaryLanding="YES"
secondaryPattern="LEFT">

YES/NO is same as TRUE/FALSE and either is honored by the compiler.

I suppose I could write a book on these 7 attributes on what FS9/FSX honors vs what is not honored.

I just don't want to list what FS9/FSX honors but also give others who read this a chance to digest many behavior issues they see in FS9 and now FSX.

The easiest way to understand what SDE could do here (if anything) is to group and look at the Attributes that effect one another

We will discuss these 3 first

patternAltitude="1000.0F"
primaryPattern="LEFT"
secondaryPattern="LEFT"

primary meaning Base end of the runway (RWY 1-18)
secondary meaning Reciprocal end of a runway (RWY 19-36)

This is the default of most all runway records for these Attributes. However to understand what happens if one of these are changed we first have to look at the code used for different type flights.

There are different ATC Engine codes used in FS based on what type plane (User vs AI) and FlightPlan (VFR vs IFR) the User is working with that will have an effect on the 3 Attributes listed above.

These 3 Runway Attributes have to do with Flightplans that have Touch and Go's (TNG) compiled using the TrafficDatabaseBuilder compiler or the TTools compiler designed by Lee Swordy for FS2002/FS9.

Lets rule out what is not honored if a change is made in these 3 Attributes when doing a TNG (some call it Circuit Runway flying)

1. A VFR User Plane flying Touch and Go's (TNG). User makes the decision on Pattern altitude and turn direction for the downwind.

2. A IFR User Plane normally cannot ask for a TNG by means of the ATC Control Tower popup window.

3. A IFR AI Plane flying TNG's is controlled by ATC for Pattern Altitude (uses a course grid of minimum safe altitudes) and Turn direction. If terrian is not a factor for the course grid minimum safe altitude then the compiled Altitude in the Flightplan for the IFR TNG is used. ATC will instruct AI Planes to climb to the compiled FP altitude then use a step down descent profile to the hard floor of 2000 ft. AGL prior to carrying out the TNG.

Now that we ruled out those three, that leaves one other type Plane. That one is

A VFR AI Plane with compiled FP's for TNG.

That type FP plane is not in any type control of ATC for Altitude or Pattern turns so the code must nest and be part of the Runway properties on what altitude it will fly and what turn direction to downwind it will use.

The VFR AI Traffic TNG's are performed at the pattern altitude and direction for the runway used, as specified in the Airport Facility data record.

So if a designer makes changes to these 3 Attributes they will normally see no effect in FS9 or FSX unless they build TNG FP's for VFR AI Traffic at that airport.


Now to continue on we group these 4 attributes to see what effects FS9/FSX has if one is changed

primaryTakeoff="YES"
primaryLanding="YES"
secondaryTakeoff="YES"
secondaryLanding="YES"

These 4 are a little more complex if changed and in the past (FS9) has caused a lot of debate contrary to what FS9/FSX really does with the data.

Explainations on these 4 Attributes will come next.

 

[jvile]

In my previous post above I am discussing VFR TNG aircraft behavior and said the following

A VFR AI Plane with compiled FP's for TNG.

That type FP plane is not in any type control of ATC for Altitude or Pattern turns so the code must nest and be part of the Runway properties on what altitude it will fly and what turn direction to downwind it will use.

The VFR AI Traffic TNG's are performed at the pattern altitude and direction for the runway used, as specified in the Airport Facility data record.

So if a designer makes changes to these 3 Attributes they will normally see no effect in FS9 or FSX unless they build TNG FP's for VFR AI Traffic at that airport.

The 3 attributes we are discussing in the Runway properties are

patternAltitude="1000.0F"
primaryPattern="LEFT"
secondaryPattern="LEFT"

I did not fully explain some of the Hard Code that FS9/FSX uses in conjunction with any changes made to these 3 areas.

Pattern Turns LEFT/RIGHT does exactly what it says for all TNG's, If you want a right hand downwind pattern then change "LEFT" to "RIGHT" for the Base or Recip end of the runway.

However patternAltitude="" has some additonal Hard Code in the .dll files that needs clarification.

TNG's in MS way of thinking is for small prop type aircraft. The 1000.0F AGL value is honored and all small aircraft (C172's, Mooney, Pipers, etc use the 1000 ft AGL pattern altitude correctly.

If you start writting VFR TNG's for larger airplanes FS9/FSX adds some additional altitude and extends the downwind proportionally.

If I create VFR TNG FP's for the larger Prop airplanes or turboprops (DC3, King Air etc.) then a 500 ft. Hard Code is added to the 1000 ft. pattern value so they fly 1500 ft AGL circuits.

If I create VFR TNG FP's for Jet Aiplanes then a 1000 ft Hard Code is added to the 1000 ft pattern value and they fly 2000 ft AGL circuits.

If we increase the patternAltitude="2000.0F" the small props fly this value, the larger props fly 2500 ft and the Jets fly 3000 ft cicuits. In some cases the pattern altitude needs to be higher to avoid higher terrain on downwind.

If there are real high mountains around the airport then in most cases it is best to make the TNG IFR and use a compiled FP altitude higher then the surrounding terrain. ATC will then control the TNG to that altitude but ATC will also choose the turn direction for downwind.

The order of landing when using multiple VFR TNG's flying a circuit is also based on the order of takoff. If one type faster plane overtakes another on downwind it will be told to go around because it is out of takeoff sequence.

The FS9/FSX TDBB compiler will only allow 3 VFR TNG's to be compiled and fly in the circuit at one time. However, TTools compiler does not use the same restrictions imposed and will allow as many VFR TNG's compiled and takeoff untill Tower clears the first one to land. The best I have done is 5 C172's in the pattern at one time. Of course you have to hold all the planes from taking off until they are nose to tail at the hold short node.

 

[José]

Revision

Hi, Jim

I found your explanation on things FS/FSX honored, related with some runways's attributes for pattern's direction (20 feb 2007).

YES/NO is same as TRUE/FALSE and either is honored by the compiler.

I suppose I could write a book on these 7 attributes on what FS9/FSX honors vs what is not honored.

We will discuss these 3 first

patternAltitude="1000.0F"
primaryPattern="LEFT"
secondaryPattern="LEFT"

These 3 Runway Attributes have to do with Flightplans that have Touch and Go's (TNG) compiled using the TrafficDatabaseBuilder compiler or the TTools compiler designed by Lee Swordy for FS2002/FS9.

The VFR AI Traffic TNG's are performed at the pattern altitude and direction for the runway used, as specified in the Airport Facility data record.

So if a designer makes changes to these 3 Attributes they will normally see no effect in FS9 or FSX unless they build TNG FP's for VFR AI Traffic at that airport.

Now to continue on we group these 4 attributes to see what effects FS9/FSX has if one is changed

primaryTakeoff="YES"
primaryLanding="YES"
secondaryTakeoff="YES"
secondaryLanding="YES"

These 4 are a little more complex if changed and in the past (FS9) has caused a lot of debate contrary to what FS9/FSX really does with the data.

Explainations on these 4 Attributes will come next.

Perhaps, today some knowledge about those concepts could have changed.

So, I would ask you if there is any effect on AI traffic departures specifying left or right pattern.

What I want to know is if the AI traffic will turn left, turn right or just follow the great circle route imediately after take off, even flying straight ahead.

I have an airport near a high mountain on the left side and specified for that airport a right hand pattern to help the AI aircraft to gain altitude but that is not happening and the airplane goes in the left direction and cannot fly over the mountain.

Is there any solution for this lack of "intelligence"?

Regards,

José

 

[jvile]

patternAltitude="1000.0F"
primaryPattern="LEFT"
secondaryPattern="LEFT"

Jose

In my original post I failed to also include the User plane behavior when requesting a closed circuit TNG from the Ground Controller.

If the Airport has ATC and a Pilot ask for Take off "Stay in the pattern" the Control Tower will say the words Left or Right closed Traffic approved based on the above settings.

If the airport does not have ATC then the User Pilot is on his own and must announce which way he will fly the closed traffic pattern. The AI Plane on a VFR TNG will always fly the closed Traffic Pattern based on the above statements and also use the PatternAltitude= that you set as a value. Even if your compiled FP says fly the Pattern at 6000ft AGL the AI Plane will default to 1000 ft or what ever is set for the pattern.

primaryTakeoff="YES"
primaryLanding="YES"
secondaryTakeoff="YES"
secondaryLanding="YES"

In regards to AI Planes turning after takeoff we still have not found anyway to force planes to turn in a direction other then which way the FP says to turn. No listed Attributes in both the runway records or approach data have any effect on forcing a turn after takeoff. AI are going to always take the shortest radius value of the circle to align them on the FP route. That means if a mountain range is in the way then on climb out they will fly though it.

I have learned and wrote procedures on how to make AI Planes fly offset approaches in clear weather so when landing they will avoid a straightin approach. Many approaches around the world are offset or curved to clear mountains and this can also be done in FS9/FSX in the Approach code.

There does appear do be some behavior changes in the above listed Primary/Secondary Takeoff/Landing attributes which both Reggie and I are testing.

In FS2002 these 4 areas allowed us to close/open one end of a runway. In FS2004 we found that only parallel runways where effected by these areas and now in FSX it has been reported that MS has once again made some kind of change in the way the dll files reads this data.

The problem with the SDK's is that they do not explain how each entry of a = value impacts behavior but only explains what can be placed into the field after the ='s. It takes time to study each change made and what effect it has on both the Use and AI Plane.

The APXnnnnn.bgl is like a tree with branches and each branch can be either a User Plane or AI Plane. Each branch can also point to a different dll file which means a simple change in the Runway records can have less then desirable results toward the AI Plane but work fine for a User Plane.

Some of the Runway Record and Approach data is strictly for AI Behavior. Some is strictly for the User Plane behavior and some of the data effects both type Planes. Only after many hours of study can we start to draw conclusions on what is effecting what.


Further study will eventually yield any difference in these 4 areas of the AI/User behavior between the 2 latest versions of FS.

 

[José]

Artificial Inteligence...

Hi, Jim

Your answears are allways welcome, since are carefully written.

I think FSX should allow inserting waypoints in AI routes as a solution to avoid unwanted obstacles.

Thanks for your attention,

José