Hi,

After some testing I've found some issues:

1. there is a limit of 24 [approach]es that will load in one control area regardless of [approach] or [transition]
2. [approach] doesn't work for runways not at the main airport
3. There is a limit of 19 [transition]s that will load for secondary airports (i.e. slot 20-24 only work for the main airport)
4. There is a limit of 49 [area]s

Here is a set of test airports showing 1, 2, and 3:

https://gist.github.com/ckwng/3d577c54953501af086418b63f6f0162

And here is a test airport showing 4:

https://gist.github.com/ckwng/c1b30454e33ae75e642c0033e6b63ed1

Aside from 2 which is just a plain bug, is there anyway these limits can be removed or at least greatly increased?

Since an approach is needed for each runway and for each initial fix, if you want 4 initial fixes for each runway direction for a simple X runway configuration airport, that's already 16 approaches for one airport...if it was a triangle configuration airport, that would be 24 approaches already for one airport...

Complex airspace can also quickly consume [area]s...

Also, it would be really useful if the initial fix upon entry was available for secondary airport arrivals instead of just the main airport. The benefits of this of course would be dependent on the removal of the approach limit.

While I'm at it, I list some suggestions (though I will admit I really want the first three):

1. Airport to airport flights. For example in RJTT (available on the community github), we could add ferry flights between RJTT <-> RJAA? Perhaps allow a [departure] to specify "route# = name, <pronunciation>, <code>, <beacon>, <altitude>" where <code> is the destination airport , and it would fly the departure to <beacon> climbing to <altitude>, and hold there like a normal arrival with normal arrival behaviour thereafter? Having "arrival" aircraft originating at points other than the airspace boundary could be interesting.
2. Specify a departure/arrival fix for traffic instead of nswe. For example, in RJTT, RJAA departures to Korea depart to the west, but the airspace is configured that most arrivals from Korea arrive from the north. Unfortunately, specifying "nw" in arlines would result in Korean traffic departing north and arrivals from all directions (because there is no arrival from the west). Perhaps we could specify something like this in airlines? "airlines = \n\t<code>, <frequency>, <type/type...>, <callsign>, <arrival/arrival...>, <departure/...>", e.g. "kal, 2, a332/a333/b789, korean air, TEPEX, SWAMP"
3. Probably necessary for the previous, defining a point where arrivals spawn. So instead of a bearing relative to the map center from which the plane would spawn at the boundary of the airspace, we could define a lat/lon and altitude range where planes would spawn? Then we could simulate planes arriving from above our airspace, or planes departing an airport just outside our airspace and landing at an airport inside our airspace. (e.g. planes departing from RJTF Chofu in RJTY airspace to land at RJTO Oshima in RJTT airspace) Something like "entrypoints = \n\t<origin>, <inbound>, <min_alt>, <max_alt>" e.g "SPENS, XAC, 22000, 26000"?
4. Transits, say a format similar to the current departures, but instead of assigning a runway, assign a point where the aircraft would originate. Then we could simulate planes transiting the airspace. If we could define altitudes for each point (min and max?), then we could even simulate planes descending through the airspace to land at an airport just outside the airspace boundary or departing from an airport just outside and transiting our airspace on departure (e.g. departures from RJTY Yokota transiting RJTT airspace on their way to oceanic routes to the USA), or define actual paths along airways for the in-cruise overflights the game sometimes generates.