I was quite the Man on a Mission this past weekend, having taken on the challenge of creating realistic AI ground movements for LHSimulation's freeware LHDC Debrecen airport. The airport, with one runway and essentially one taxiway as well as a single main apron, lent some interesting challenges and surprises - made all the more difficult thanks to the rather inane if somewhat-predictable behaviour of the FSX AI system.

Design Overview

Let's first get an idea of what we are dealing with here. There are 15 gates, and numerous paddocks for which additional ramp parking can be added that's not in the latest version release. Of these 15 gates, 9 of them are drive-through parking. Of these 9 gates, 5 of them are suitable for large airliners. The paddock areas offer an additional 9 parking spaces.

Pathing aircraft to pull in and out of spaces with only one exit is easy - aircraft pull in, then push back and spin around to get out. Drive through parking (DTP) is a technique that is meant to make aircraft enter and exit a parking space facing the same direction the whole time. Because this is not how parking spaces are intended to work in the simulator, implementing this requires a bit of finagling around with setting up your path links.

The best reference for DTP is this document written by Don Grovestine and much of his advice and forewarning went into the development of the "piping" for this airport. It should be read as I will not be explaining any concepts in this write-up already covered in Don's reference.

The final result of the network required to achieve ground movement appropriate for this airport is below. There are three separate networks:

• The RED network is the departure network that services parking spots requiring DTP
  
• The GREEN network is the departure network that services parking spots that do not require DTP
  
• The BLUE network is the arrival network servicing all parking spots in the airport
  

Why 3 networks instead of 2?

The Major Design Hurdle

There was one serious problem with developing the pathing network for this airport - parking nodes are not end nodes. This was something that threw me for a loop, although I'm not too surprised this is how the AI works in FSX. I always imagined that when you connected a path to a parking space that path was terminated at the parking space. However it appears that FSX treats a parking space as any other node in the network. This means when the system was originally designed with two pipes (arrival and departure) the following problem presented itself:

In the image above, BLUE represents the departure network and RED represents the arrival network. You can see how aircraft are supposed to arrive and pull into the two top parking spots from behind, and then exit straight out the other side. The two parking spots on the bottom are regular pull-in parking.

In the image above, RED represents the path arriving AI from runway 05R should take to reach the parking location and BLUE represents the path the AI actually takes. What is happening? AI route from runway to parking via the shortest path possible. Technically, pulling into the spot from the bottom is shorter than driving past and swinging around to pull in from the top. So the AI jumps networks by pulling in towards the parking spot and leaving the arrivals network and moving on to the departure network so it can travel the shortest distance. The aircraft does not pull all the way in to the spot - the slight dip in the path line is a fair representation of how much the aircraft deviates from the main taxiway before turning back. It also does not care if there is another aircraft currently occupying that bottom parking spot. Additionally, swapping the node positions would have no effect, the aircraft would simply spin about when jumping networks.

The worse part about all this is that all the non DTP spaces, with exception to Gate 10, were located on the Runway 23L-side of the airport, which meant aircraft taxiing in from 05R would pass them and could use any of them to hop networks.

Working Towards a Solution

My first thought was to simply remove access of non-DTP spots from one of the networks. Well, if I only left them attached to the departures network, AI could still spawn and depart but with only gates 1-10 able to accept aircraft that limited capacity at the airport for people who like having a lot of AI running around. On the other hand, if I only left them attached to the arrivals network aircraft would be able to arrive but you'd also have aircraft that would spawn and be unable to depart.

Next I decided that really only gates 1-5 were affected by this problem, and only airliners service these gates thanks to parking code assignments. So I attempted to "capture" GA aircraft and route them separate from airliner arrivals. I did this by noting where the airliners received their gate assignments while on the runway, and placing a node to the arrivals network before this, so only smaller GA aircraft would pick it up as the airliners would be past this after they landed. I then created a new arrivals network for the airliners towards the end of the runway and routed them straight to gates 1-5. It made the airport piping look like this:

In the image above, which shows arrival piping only, the BLUE represents both airliner and GA arrivals and the RED represents airliner-only arrivals. Note though that GA aircraft landing on Runway 05R will stop shorter and intercept the BLUE path whereas airliners will land past the node at the start of the BLUE path and instead take the RED path. Landing on Runway 23L this whole path jumping issue is non-existent due to the taxi-in distance for the proper path to the gates being the shortest. Also notice that I'm not piping the airliners all the way up to the parking location, I'm simply denying them access to the non-DTP spots at the bottom of the ramp and hooking them back into the main arrival network as soon as possible to avoid laying down too many extra nodes. While this technique did work at consistently capturing GA aircraft versus airliners as intended, it had one insurmountable flaw.

Once I confirmed this was working I went to test Runway 23L landings and was dismayed to find that every single aircraft, GA and airliner alike, would now turn about after landing and back-taxi to leave the runway! It was a bit astounding to me as these were aircraft that would be heading to gates on the main ramp and as such a back-taxi and taxi in along the longer Taxiway B to get to the main ramp area does not seem shorter to me. However sometimes FSX AI is simply unfathomable. What was apparent however is that there was nothing I could to to stop aircraft from back taxiing without simply reverting to my previous runway pathing. Due to the fact that AI are arriving and departing on separate taxi networks, even if another aircraft was holding short for Runway 23L at the time a plane was landing and taxiing off they would simply pass right through each other. AI only yield to other AI traveling on the same path network.

I did attempt a last-ditch effort by playing around with putting breaks in the runway link, but once I realized an aircraft doesn't need a runway link to land, it will simply choose the closest apron/taxi link and follow it, I gave up.

Finally I decided that if I can't put in a separate taxi in network I would put in a separate taxi out network, which brings us back to the image at the top of this entry:

You'll notice that the GREEN network joins up with the RED network near the runway. This is where the hold short node is located, and this node is located closer to the runway than the hold short node for the arrival network. This means I can combine the two departure networks and not have to worry about aircraft jumping because they are already past the point of doing so when they get their final taxi in route. With this three-route network AI aircraft can arrive and depart from every available parking location and do so in a proper manner depending on the DTP nature of that spot.

Nothing Is Ever Perfect

There still remains a minor drawback to this system, and really to any taxi system that employs more than one route. The issue I mentioned earlier with aircraft taxiing through one another still exists - there's a chance that an arriving aircraft can taxi through a departing aircraft because they only react to other craft on their network (they could even taxi through the user aircraft depending on which network the AI decides you're on given your position). This can happen either when and arriving aircraft taxis past a departing aircraft pulling out onto the taxiway, or it could happen when an aircraft taxiing faster on a path with less nodes overtakes an aircraft taxiing slower on a path with more nodes (explanation: AI aircraft taxi speed is determined by the distance between nodes. The more nodes closer together on a path than spaced far apart, the slower an aircraft will taxi).

however here is where LHDC's single runway and taxiway actually mitigates this problem significantly. There are no intersections or runway crossing where separate path networks can cross over each other and lead to aircraft passing through one another. Everyone is always heading in the same direction. Add to that parking located across the length of the airport instead of one dense area and not a lot of traffic arriving/departing even on the highest traffic levels, and the chances of witnessing a "non-collision" are extremely slim.

Testing Procedures

The DTP implementation for LHDC works - on my system. This has been proven through rigorous testing with help from Super Traffic Board. Coupled with UT2, it is a powerful tool. In addition to real time data like location and status (such as noting when gate assignment is given upon landing, as mentioned earlier) I can call down any aircraft I want that's scheduled to arrive to land at any time at any runway. A B737 will hit the runway just under 2 minutes at 4x speed after I create it 20nm downrange on approach. A much slower Piper Cub will make it down in just over 6 minutes. I can also land mutiple copies. So within 10 minutes I can fill up 5 gates to test the AI's arrival to each one. Similarily, I can dispatch aircraft on command. So I can load up the airport with only a few parking spots available (due to sizing the rest too small to accept aircraft) and immediately send off all aircraft parked to test their departure from each spot. So every parking spot on the airport has been tested to make sure AI craft arrive and depart properly from both runways.

It also helps to have both FSX and UT2 traffic sliders at full to give me lots of activity to stress-test operations at the airport. Leaving the sim running at 4x speed while using my screen capture time-lapse technique to monitor it, I can come back hours later (like after sleeping) after many more hours have passed in the sim and spend a fraction of the time making sure there were no anomalies during normal operations.

I also tested with all the WoAI packages that are available for this airport.

The Final Result

I'll be sending this off to the LHSim people for additional testing - LHDC is compatible with AES and I am unfamiliar with how that application operates - it may not like what I've done to the AI network at all. I also may have missed something unique to my FSX environment that will cause the pathing network to fail on other systems. But hopefully this is an improvement that LHSim can include in the next version release, and regardless I certainly learned a lot in how to successfully plumb out an airport for DTP.