FSX AI Traffic - what is the meaning of minRange?

[gsnde]

Does anybody know what the minRange parameter in CustomAircraftTypes.csv is supposed to do? Would it prevent the compiler from accepting a flight plan for an aircraft to another airport 30 n-miles away if the minRange definition says 50 n-miles? But where would be the sense in that?

Another thing I am not sure about is how the compiler rejects flight plans due to "no parking condition". Let's say I have a MIL_CARGO aircraft with parking size 23m. In the airport file I have several MIL_CARGO parking spots with 30m and 40m. I would expect the compiler to accept the aircraft as fitting into the much larger parking spots of the same parking type. Nevertheless the compiler complains about "no parking". The error disappears as soon as I define one of the over-sized parking definitions to 23m. Has anybody else made the same observations or has an explanation?

Thanks and cheers,
Martin

 

[gadgets]

FSX will not park a GA AI in a parking spot more than 5m larger than the wingspan or airline traffic more than 10m larger. (Actually, its half the wingspan rounded up to the nearest full meter and then doubled).

As for minRange, this appears to be used only for generation of default traffic. Thus, it wouldn't schedule a 747 (which presumably would have a large minRange) for island hopping. This value has no effect on custom scheduling; if you specify an a/c for a given custom flight plan, that a/c will be used irrespective of its minRange so long as other conditions are met (e.g., min runway length, parking available).

On the first point above, please note that FSX reserves one parking spot of each type for the user aircraft and, from my tests, there must be at least three spots of a given type before any AI for that size parking is scheduled. This latter issue, i.e., min 3 spots vs 2, may be fixed in SP1; I haven't yet had a chance to check.

Don

 

[rfields]

One other factor is the airport traffic scalar value in bold -

KDCU,34.652647153,-86.945366710,180.4,G,2,0.70,United States
{
RUNWAY,5105,100,HARD
PARKING,10.0,RAMP
PARKING,10.0,RAMP
PARKING,10.0,RAMP
PARKING,10.0,RAMP
PARKING,10.0,RAMP
PARKING,10.0,RAMP
PARKING,10.0,RAMP
PARKING,10.0,RAMP
PARKING,14.0,RAMP
PARKING,14.0,RAMP
PARKING,14.0,RAMP
PARKING,14.0,RAMP
PARKING,14.0,RAMP
}

By that math there are only 5 - 10M and 3 - 14M spots available to be used at this airport.

 

[gsnde]

I had assumed there is only a minimum check for the parking size. Is this check only done during compilation of the flight plan? I understand you are saying that in FSX the same rule applies as well.

And I indeed completely missed the traffic scalar factor - just did the reading in the SDK.

Thank you both very much.

 

[Mace]

One other factor is the airport traffic scalar value in bold -

By that math there are only 5 - 10M and 3 - 14M spots available to be used at this airport.

Huh? You mean the traffic scalar (0.70 at just about every airport I've seen in FSX) reduces the number of parking spots? I thought traffic scalar was an unused variable in this ver of FS.

If it has the effect you describe, I did not know that. If so, why on earth would Microsoft have done this? What would the point of having, in the example, 8 10m spots and 5 14m spots?

Why not just specify 1.0 with the scalar, and have 5 and 3 parking spots, respectively?

 

[rfields]

Options, giving us options when we build to our traffic files.

The TDBB SDK says:

Traffic scalar factor = number in range from 0.01 to 1.00 that determines busyness of airport.

Our testing shows this is a major decider on how many aircraft will be allowed to park at an airport when TDBB is used to create traffic files.

No one that I've heard of has found that the value, which is in every airport scenery file, has an impact during a FS session.

For example, if I took Henry T's Single Engine Cessna package and ran them with TDBB, I'd probably want a traffic scalar of 35-40% for the airports - so that there would be room for other GA aircraft.

If you ran the traffic scalar at 100%, there would be no room for other AI.

The default 70% setting fills airports nicely, but allows additional traffic to be added by the user.

.

 

[jvile]

A followup on the scaler percent factor

If it has the effect you describe, I did not know that. If so, why on earth would Microsoft have done this?

The Scaler is a Throttle valve for AI Plane traffic into a given airport. That does not mean it has to be .70 for all airports and should be decided by the designer based on his knowledge of coded ground operations and AI Traffic availablity as per Reggie's post above.

FS9 used a hidden hardcoded ratio of parking spots to the amount of AI traffic at any given airport. FSX exposed the scalar to allow throttling AI traffic at certain airports. The problem at some of these airports that do not have taxiway segmentation is the ratio of parking spots to a minimal taxiway infrastructure or what is called choke points which causes head to head gridlock. The TrafficScalar set to a default in the Airport record and the TrafficDatabase compiler (0.70 percent) helps to eliminate this problem also.

Smaller Airports do not have taxiways segmented into several or in some cases many parts (C1, C1, C1 or see KJFK as an example) which at large airports helps to eliminate the chock points without scaler percentages added. Many AFCAD designers delete all these dupicated taxiways and then don't understand why their airports like KJFK, EHAM, KMIA, KIAH, etc. have head to head AI Plane gridlock.

Ttool compiler knows nothing about the Scaler value.

Some of what I said here comes directly from MS and is not part of the SDK information.