A proposal for an FSX AI Parking framework

AI aircraft parking has changed in FSX from previous versions of FS with AI traffic. The most significant change is how FS determines the ‘size’ of the aircraft – moving from the Model Radius value to ½ of the aircraft.cfg wing_span= value.

This creates a serious problem for the movement of FS2002 and FS2004 created AI aircraft to FSX – because very few aircraft have real world values for this setting. Luckily, this value can be changed without major impact upon the flight characteristics of the aircraft.

While parking codes, parking types and other parts of the parking spot assignment process have a significant impact, the size of the aircraft as compared to the size of the parking spot remains the most important factor in the parking process.

My proposal is very simple:

AI aircraft of a similar class should all have the same wing_span= value

The complete proposal, suggested values and spreadsheet are available - http://www.flightsim2004-fanatics.com/FlightSim/FSXKB/FSX_AI_Parking_Proposal.htm

THIS IS NOT A MANDATE - but a starting ground for discussion - I may be full of hot air - but I do think it is something we need to discuss.

NOTE - I have not specifically addressed General Avaition or Military aircraft or helicopters. My experience with FS is that we need to establish a general framework first. Passenger and cargo aircraft are the most common. Once a methodology is agreed upon - the other aircraft can be added to the matrix.
Last edited:
I'm going to bring in something from another forum - one which champions simplicity

14m all commuters up to E170/Q400
18m small airliners (A320/B737)
27m medium up to 767 ( 23 for A300/310/B757)
31 for A330/340/B777
36m for 747/346/773X
40m for A380
Simple is good.

Even if a methodology is agreed upon, it may not necessarily be followed by all designers.

I like your idea, insofar as I have encountered weird parking behavior with FSX, as we/I are using AI aircraft designed 2-3-4 years ago, before FSX was on the radar screen.

A set of "standard" parking sizes and wing_span vals might be nice. I will look at the recommended vals and maybe incorporate them into what I'm working on now and see how they work with the AI.

The big problem would be getting designers to follow set guidelines. I don't know how possible that is. I am for whatever is simple and works. For designing airports, I would want my airport parking to work with anyone's AI packages. Right now with the wing_span values we have floating around, that is no guarantee.
If we can come up with standards, maybe we can get the designers of Afcad replacement GUI programs for FSX to incorparate them as standard settings, with the ability to manually set it different if you wish. Lee did something similar with Afcad with a set of standard choices, then the ability to manually set your own figures. Most casual users of an afcad type program will pick from standard settings.
:D Sorry Reggie, but I can't agree with you on this.
At a minimum I feel we need:

RAMP_PAX – for commercial passenger aircraft – regional turboprops and small jets (15.0M)

RAMP_PCARGO – C208, SA227, and EMB110 sized cargo aircraft (12.0M)
RAMP_SCARGO – F-27, B727F sized aircraft (20.0M)
RAMP_MCARGO – A300, B707, DC-8 sized aircraft (24.0M)
RAMP_LCARGO – Large cargo aircraft (37.0M)
Let's try and make it easier for new users to get the results they want in their AFCAD. Using Ramp over and over again for all types of aircraft (GA, Cargo, MIL Cargo and Combat) can be confusing to some people. Can we flip the titles around? We have Gate (for pax airline) small, medium and large, why not drop Ramp completely and have Cargo, GA, MIL Cargo and Mil Combat spaces in small, medium and large sizes? It seems like it would be easier for all of us if the aircraft type is first, followed by the size. ;) I wouldn't mind a seperate category for GA_Jet_small, medium or large either. That would make it much easier to segregate aircraft when neeed.


Resource contributor
Having just wrestled with the conversion of my FS9 AI traffic for CYYJ to FSX, I don't see the value in such standardization. While it's created some difficulties, in general, I think the use of wingspan for determining minimum parking size is a good thing. At least it's a measureable quantity and relates to the specific airplane, not an arbitrary number decided upon by the aircraft designer that may or may not be compatible with other aircraft models. Granted, many aircraft.cfg files mis-state wingspan, but than can easily be corrected. (Incidentally, FSX uses 1/2 the wingspan rounded up to the nearest whole meter.) Any "standard" that attempts to lump airplanes into discrete categories would be in constant flux as new aircraft are introduced and "new" old aircraft are modelled. Besides, who would have "the final say"? Using a well-defined parameter such as wingspan allows maximum flexibility for airport designers to customize parking to reflect real-life situations.

Now, if you want to change something, how about convincing Microsoft to get rid of the upper +5m and +10m upper size limits on parking spots in FSX.

Let's not impose any more artificial constraints on airport design.

why not drop Ramp completely and have Cargo, GA, MIL Cargo and Mil Combat spaces in small, medium and large sizes?

Would definitely be easier to understand than RAMP.

I suspect MS uses only two types of parking (GATE, RAMP) for hard/soft surface areas to make the cascade down easier to accomplish.

A graphical program to create airport parking could use any terms the designer wished to make standard size parking spots. Even Lee Swordy added his own wording for a parking type - using UNKNOWN in AFCAD2 rather than the RAMP_GA type parking in FS2004.

Maybe a better question / request to Microsoft would be to have the atc_parking_types entry in the aircraft.cfg match up exactly with the type code in the TaxiwayParking spot properties.
At least it's a measureable quantity and relates to the specific airplane, not an arbitrary number decided upon by the aircraft designer that may or may not be compatible with other aircraft models.
Which number do you use, the real world wingspan or the wingspan of the AI model?

Which real world wingspan number do you use, airliners.net, Wikipedia, the manufacturer's' web site?

How many people will enter the number in meters - I'm willing to be a lot will.

How many people will enter the number as 111.11 for 111 feet 11 inches rather than 111.92?

The difference of the second decimal place will mean a whole meter difference in the parking spot size needed for the aircraft.

I've found that a fourth decimal place of a meter - i.e. from 15.9999 to 16.0001 in the converted half-wingspan value will make an aircraft not park in the 16.99M spot, but must have a 17.x M parking spot.

Again, I'm not saying my suggested numbers are prefect, or even the right ones to use.

And we are not talking about how we build our favorite home airport.

We are hoping to have a common framework for all the airport parking files which will appear on the internet.

So that my, or your, AI traffic will work at least reasonably well on an airport created by someone else.

Frankly the most common issue I see with many FS2004 AFCAD files is what I call too much customization.

An AFCAD must be workable with the AI traffic files of the end user. Real world detail should not be the ultimate goal of an AFCAD creator. Working AI traffic should be the goal.

An example is the amazing KBOS scenery of George Grimshaw. I've never seen an AFCAD file which works correctly for that airport because all the current AI traffic schedules and AI packages for American Airlines place 17 AAL aircraft MD8X/ B737 size or larger aircraft at KBOS. Add to that 8 regional jets for American Eagle. That's 25 parking spots needed for AAL/AALX aircraft - either at gates or in overflow areas.

As near as I can tell, KBOS has between 10 and 11 gates for AAL main line aircraft - along with four regional jet sized spots. Most AFCAD flies also have 14-15 AAL/AALX parking spots.

Most do not have 10 overflow spots for the aircraft of all airlines, much less the overflow from just AAL/AALX.
Last edited:


Resource contributor
I think the rounding up is both unnecessary and, as you (rfields) point out, problematic. (That a 1 mm. change in wingspan can require a 1m. change in minimum parking radius isn't helpful.) And the fact that parking spot reference numbers and the order in which parking spots are declared are no longer taken into consideration by FSX has also caused me grief. So, let's add both of those to the list of things we want MS to undo. (But, I'm not going to hold my breath!)

Standardized parking radius for groups of aircraft is a "one-size-fits-all" approach. What are the benefits in return for this loss of flexibility? In creating the parking scheme for an airport, the designer inherently adopts his/her own standard. ("I want aircraft of this type/size here and, therefore, I need parking spots of a certain size to accommodate them".) But, because that "standard" works at one airport doesn't mean that it is suitable for all others. Where AI parks is the airport designer's decision - whether the goal is realism, AI volume, variety of a/c types or whatever. Let's not make it any more difficult.

My points are simple:

1) Wingspan is a real-world parameter and, from my perspective, that's better than an arbitrary number. Presumably, a model's wingspan is intended to emulate that of the real airplane. As for what number one uses for wingspan, so long as it's not grossly in error, it shouldn't matter. (Any parking scheme that relies on 3-decimal point precision isn't likely to work well anyway.)

2) Some of the other things MS has done re AI parking in FSX are much more difficut to cope with.

Perhaps a better objective for standardization is a database that sets out the actual wingspan of each aircraft type (as specified by the aircraft manufacturer) and encourage both aircaft modellers and airport designers to use those values. Perhaps one of the major AI "manufacturers" would volunteer to create and maintain such a database. Since the database would contain actual values, there should be no disagreement among AI "manufacturers" as to "correctness". Since AI resides on the user's computer, user's whose AI "misbehaves" when parking could be directed to this database and recommended to update their applicable aircraft.cfg files accordingly.

Is the use of aircraft.cfg wingspan the perfect method for determining parking spot size? Of course not. Is it better than an arbitrary model radius? I think so. Is it worth the pain associated with conversion from FS9? No! But, then, MS didn't give us a choice.



Resource contributor
Hi Reggie,

Looks like a good plan to me. One minor thing with the Cargo table - the DC-6's and DC-7's have a wingspan of 117 ft, and they really would fit better (operationally) into spots designed for the 727 and 737 (120 ft limit).

However, the DC-7C has a wingspan of 127 ft, and would not fit into those spots. So there is a quandary how to deal with them. If you are talking ONLY modern day there are no DC-7C's left in service, so they could be ignored.

Hope this helps,

For FS2004 we had the Standard Recommended Radius Specs that eliminated alot of problems. We now need a Recommended Half Wingspan value for FSX.

It was very easy to add the FS2004 spec sheet to all my airport uploads so everyone knew exactly where the AI Planes by Airliner, Cargo, Mil, GA were going to park if their model radius was set per the standand.

Just recently Phantoms and I spent many hours working through parking problems for one of my FSX upload airports. Many modlers do not use correct specs which causes wingtip overlap.

Unless someone actually designs airports and uploads for users they cannot comprehend the chaos if a standard is not used (based on AI Planes available).

AVSIM is reporting since June 2004 that the total downloads for my airports are over 100,000. My Kai Tak airport alone has over 12,000 downloads so you can imagine the e-mails I would get if the Recommended Radius Parking Spec was not used.

As I move towards FSX I simply point out in my readme files that if the user wants to see all the correct AI Planes park in their correct position (example KATL FSX) then they must make sure the wingspan is set properly in their .cfg

I can't get modlers to understand correct Empty Weight is also just as important for ATC arrival runway control so yes their needs to be a standard.
Some weeks ago I posted on another forum (before it -the post- was lost
in dismantling and reconstruction) a quick reference memo with all
halfwing span that I could find. Here it is again. I've made some minor
adjustments and added the 747-8 that I had forgotten. I have also added
the length of some large aircraft at or above 60 meters long.
The challenge with this new standard is that the AFCAD designers have to
be extra careful also with traffic taxiing behind parkings, especially
with large aircraft. The somewhat limited radius sticking to the wingspan
must not make us forget what's going on behind.

Only civilian airliners (recent or not) are listed. It is not an exhaustive one of course. I have included some cargos at the end plus the Concorde.
Sources: Airbus.com/Boeing.com/Airliners.net

AIRCRAFT HALF-WING SPAN (m) WL= WingLet *=rounded up ie 24* is = or >23.5

A380 40 L73
B747-8 34 L76
B772LR/773ER-F 33* L64/74
B744 32 L71
A345/6 32* L68/75
B789 31 L63
A358/9 31* L59/65
B772/73 31* L64/74
A332/33/42/43 30 L63/63/59/63
B788 30 L57
B741/42/43/SP 30 L71/ SP56
IL96 30 L55
B764 26 L61
B783 26
MD11 26 L61
DC10-30/40 25
L1011-500 25
L1011-100 24*
DC10-10 24*
B762/63 24
A306 23*
DC8-62/63/72 23*
DC8-43/55/61 22*
A310 22
B707 22
IL62 22*
IL86 24 L60
TU204/34 21
B752/53 19
TU154 19
B736/3G/38/39 17/18 18 WL
YK42 18*
A318/19/20/21 17
B722 17*
MD81/83/87/90 17*
ERJ190/5 15*
B733/34/35 15*
TU134 15*
F50 15*
F27 15*
B731/32 14
F100 14
F70 14
F28 14
DC9-21/32 14
B717 14
B111 14
DH8-400 14
ATR72 14*
DC9-15 14*
ERJ170 13
DH8-100 13
LET610 13
ATR42 13*
YAK40 13*
SAAB2000 13*
BAE146 13
CRJ700 12*
SH360 12*
CRJ100-200 11*
SAAB340 11*
ERJ135-140/5 10
EMB120 10
DH6 10
LET 410-420 10
B1900D 9
JS-41 9
B1900C 9*
EMB110 8*
JS31 8
C402 7*

L-100/C130 HERCULES 20
AN-124 37*


Broken lines are supposed to reflect, in my opinion , the category changes.
Although the separation between Heavy, Medium and Small may be easy, it is not the same thing for the separation between small and regional airliners. I call regional those aircraft (jet or not) that usually do not use/need a jetway to board passengers. As you can see the half wingspan is not the sole element that can make the decision.
I have now make up my my mind about creating a lower limit inside gate_small at 14m to send commuters/feeders/regionals to these parkings.

I would tend to thing to let the aircraft and traffic designers
(sometimes they do both) do their job as far as they put the good value
in the .cfg file. If they don't, it would be easier to correct it via the .cfg file.

About the parking category inside AFCAD, I share the idea that the Ramp
category is useless. I have never really understood what it means

Reggie your final proposal of:
is perfect. At least we know what we have and where we go.
I have a slight disagreement on your proposal about the cargo spot size.
My experience and opinion is that the cargo radii should be exactly the
same than passenger ones in their respective category. Most cargo
aircraft nowadays are the same than passengers ones. They may be
conceived for or converted to cargo, but the geometry of these aircraft is the same in almost every case and I don't see the point to have a
discrepancy between cargo aircraft and others.

Btw is it possible to open and look into the bowels of aircraft's mdl
with any software?
Although the separation between Heavy, Medium and Small may be easy, it is not the same thing for the separation between small and regional airliners. I call regional those aircraft (jet or not) that usually do not use/need a jetway to board passengers. As you can see the half wingspan is not the sole element that can make the decision.
I have now make up my my mind about creating a lower limit inside gate_small at 14m to send commuters/feeders/regionals to these parkings.
Re: the above point, you wouldn't always want to send RJ's to ramp parkings.

In my real world experience I have seen regional jets use jetways most of the time at the decent-sized airports...and rarely "ramp" except at the small fields.

The problem I encountered in design, was getting commuter props to go to the right places. The regional jets I made GATE only; (no RAMP). Whereas the commuter props got RAMP only (no GATE)...but I am not sure my little solution would work everywhere.
Each airport has its own apron procedures and constraints and a solution possible for one may not be good for another one. That is the interest of AFCAD to find the best possible solution for the destinated airfield. I do not put "ramp" inside my AFCADs and use only 'gate 'or 'cargo' and the solution that I apply correspond to the real situation.
I have never really understood what use I could make of the "ramp" category and what it "means" exactly, hence its absence from my AFCADs.
Another problem about "ramp" raised by Paul "BASys" is the absence of push-back vehicle in FSX that won't be available there. It might halt its use by aircraft designers.

Edit : full text
Last edited:
Regarding small jets and turboprop passenger aircraft.

I have long been a proponent of GATE for all passenger aircraft.

The problem with atc_parking_types=RAMP is which type of ramp parking.

RAMP_GA (Afcad mistakently calls this Unknown)

My testing in FS2004 showed that the size of the parking spot made the determinant. RAMP in the aircraft.cfg has equal preference for any of those types of parking.

So far the FSX testing shows the same to be true.

Yes a parking code will keep the aircraft in the proper area - but as always the key to successful parking is handling overflow aircraft.

At KABQ, you are going to get the Mesa B1900's parking in fighter spots if you use RAMP in the aircraft.cfg.

There are over 100 commercial passenger airports served by regional jets and turboprops in the US with military reserve components on the airport - and there should be military combat parking about the same size as the regional parking at each of them.

Additionally - there are even more airports served by ATR, F-27, EMB-120, EMB-110 and C208 sized FDX, UPS and DHL feeder aircraft. Regional jets and turboprops will end up at these parking spots very often.

While these two issues are largely a US problem today, they still have impact in many different countries.

Also, in the US, more and more airports are no longer using regional jets and turboprops at non-Jetway parking.

Almost all the US CRJ/ERJ fleet has been converted to jetway capable doors. And turboprops are moving that way. In fact the last aircraft I flew upon which used non-jetway parking and an internal airstair for loading was an American Airlines MD-8X about a month ago - at KLGB.

The solution for FS2004 was to have one radius for the jets and a larger radius for the turboprops.

Which made it easy for parking at jetways to be placed for, and limited to regional jets. The one meter larger parking for the turboprops was also overflow parking if too many jets were on the airport.

It appears from the discussions so far the people are not interested in maintaining that separation with parking spot size.

I'm wondering if separate parking codes might be preferred.

Using UALX for both the UAL regional jets and turboprops was a simple use of parking code - but UALJ and UALP would also work.

Personally I preferred the X designation because it was extremely easy to spot a regional aircraft by the code. Maybe UALX for jets and UALY for turbo props ?

However, remember this - if the parking spot size is the same for the turboprops and the regional jets - you can never exclude the turboprops from those parking spots.

FS parking only has one way to exclude an aircraft from a parking spot - size - the spot being smaller than the aircraft.

Everything else is preferences. FSX does has some better controls on preferences with deletion of aircraft on occasion due to major size mismatches. But nohting on the order of regional aircraft size differences.
Last edited:
GATE = Pushback tug, baggage cart, baggage loader
RAMP_CARGO = Pushback tug
Those are the only 2 that also spawn the Living World animated vehicles that run around the airport. My testing shows it is based on a percentage of how many parking spots are added.

Animated vehicles also have a model radius simular to aircarft for proper spacing when pulling up to a plane. If you park your user Cessna in a large 36M parking spot and call for the fuel truck it does not get anywhere near the plane. If you park a user B747 in a 10M parking spot the fuel truck disappears into the fuselage. If crash detection is turned on you will have a crash and reset.

If you back a AI Plane into a parking spot such as a GA then the fuel truck parks in the wing when fueling because the wing is in a reverse position.

FSX made sure that they made animated tracks (roads) for the living world vehicles. If roads are not added then animated vehicles default to taxiways from one parking spot to the next. Now we are confronted with head to head lock down simular to 2 AI planes facing each other on the same taxiway.

The animated road is also a taxiway link line but coded as a VEHICLE. This assures that a AI Plane cannot taxi on that line but a animated vehicle can run on a VEHICLE and a taxiway link line. Animated also run on or across runways and always have the right away. Many airports use a road around the runway. FSX AFCAD's have showed up that are not well designed because animated was not a considerstion.

Parking radius needs standardizations but we also have to consider what the animated vehicles will look like when pulling into the parking spot.
About the 4 letters code, we already have available the C (cargo) and X (regional/Commuter). The idea to add two or more possibilities sounds interesting and applicable but what will happen if one AFCAD made for one airport doesn't include it because the author is not aware that these new codes exist and might be used by any traffic or plane maker?
Moreover it will become (and it's already) pretty difficult for an AFCAD maker to decide between "normal"or C/X/Y/J/P etc...
For example the X is used also for subsidaries airlines operating for major ones. It
is the case here, where AFR have some subsidiaries such as BCY RAE BZH. Some AIs traffic makers included these airlines but Traffic Explorer indicated that AFRX was also used in the .cfg file in lieu of the other airline codes.
All codes AFRX BCY RAE etc... in the example above are good but for small jet/prop liners and the additionals J or P (to AFR or BCY?) may be disconcerting and the choice difficult to make. We might end up with six or more codes possible for one jet aircraft making regional flight but requesting or not a jetway. Troubles ahead. The streamlining that we seem to all look for radius should also be apply to the airlines codes. But if everybody is going in the same direction why not.
We need an Academy...

The animated road is also a taxiway link line but coded as a VEHICLE. This assures that a AI Plane cannot taxi on that line but a animated vehicle can run on a VEHICLE and a taxiway link line. Animated also run on or across runways and always have the right away. Many airports use a road around the runway. FSX AFCAD's have showed up that are not well designed because animated was not a considerstion.
Oh yes! I've seen amazing situations where vehicles quietly used active runway to do their little business! I've separated the two networks (plane and vehi) but each parking spot must be connected to the "vehi" system for servicing via the apron link. Lenghty task.
It also has a direct impact on fps. (the more "gates" the more vehi...)
Jim or anybody else, have you already experienced crash with AI vehi that are not the refuelling truck? I hop and think it's not possible but...
I think that MSFS made a mistake with that. Most people can't understand that a crash could occur because of this vehicle(s).
And all these VEHI wandering here and there forcing the ATC to order AI planes to give way! Ah ah ah!
Last edited:
Well, with a couple AFCAD replacements for FSX already showing preview pics, a standard is sorely needed. Has there been any more work on it?