Now that we have user-contributed airports with buildings in X-Plane 10.25, I have a few topics to cover regarding airport authoring. The first is taxi routes. (I will get to the contribution and sharing process in a few posts – please bear with me.)
The short of it is: if you do not provide taxi routing in an airport layout, X-Plane will generate a taxi route, and the route X-Plane generates is not particularly good. The algorithm is slow, so it hurts loading time, it produces a relatively ugly layout, often with errors, so the AI behavior is bad, and I suspect that sometimes the whole algorithm crashes.
While all of these things can be improved, there will always be a trade-off between load time and algorithm quality. For example, the layouts could be rendered using more memory, but the loading would be even slower.
And we don’t want to be generating AI layouts – we want this data to be in the apt.dat where it can be built by smart humans who can carefully author.
For example, consider an airport with a huge tarmac, where the taxi routes are simply painted onto a big slab of concrete. The AI algorithm doesn’t understand this line structure at all – it isn’t smart enough to ‘get’ the taxi instructions. So the AI network lets the plane drive straight across the slab of concrete, traffic flow be damned! The AI also has no idea what any taxiway is named, so ATC can’t provide good route names.
The pictures above show the actual generated taxi layout at KJFK – red indicates active segments where the aircraft hold short before crossing runways. Nerds will recognize that this layout is created by a straight skeleton erosion algorithm, a strategy for analyzing images that comes from OCR.
The moral of the story is: while the AI taxiing behavior can be quirky, a lot of the problems come from X-Plane trying to auto-generate layouts off of the apt.dat file without a real taxi route structure. If you create such routes, the sim loads faster, provides better directions, and provides more plausible taxi routes.
Have Laminar considered only allowing AI aircraft to take off and land from airport that have a custom built Taxi Route? It might prevent complaints about 747’s loading on top of the user, or loading at small airfields, it would decrease loading time, and it might promote end users to create Taxi Routes that could then be submitted for inclusion in the default sim data. It might make things better for the dodgy ATC too.
Not originally – in fact, we wrote autogen taxi layouts because we didn’t want the ATC feature to depend on custom data. It is possible that once we get user submitted taxi routes with significant coverage we could disallow AI (or even user flight) without ATC data, or even save the generated taxi routes to apt.dat files so that users can ‘clean’ them with WED (although they are so ugly in terms of stair-stepping that cleaning them might be slower than making one by hand.). But while we’re in the early stages, I think we will keep permitting auto-gen taxi routes.
Couple of questions:
1. If we have a situation where AI need to turn around at the end of the runway before taking off, is it worth adding AI taxi lines to facilitate a U-Turn, or is it worth leaving alone. Big planes in particular shoot off into all sorts of interesting tangents for their take-off run.
2. If we turn off AI altogether, are the taxi routes still autogenerated when loading scenery?
For 1, yes, I think you should put a taxi segment on the runway…generally you’ll always want this so if a plane over-shoots the last turn-off it can get back.
For 2, taxi routes are always generated because the entire ATC system is never off…when you are at an airport ignoring ATC with AI planes off, ATC is there — the controller is playing solitaire and drinking coffee.
(This doesn’t burn much CPU time – the controller work-load is pretty close to zero when he has no airplanes.)
For 1, I had that problem with my airport (single rwy, apron in the middle with 2 short exits to rwy). By putting taxi segments in the runway isn’t that going to create another problem? Where the aircraft will hold short of runway?
To avoid that overshoot, I tried to make the taxi segments to end of rwy and put there the “hold” point, but that was a total failure; aircrafts were taxing on the runway the same time others were taking off / landing.
After a lot of time observing things, I notice that aircrafts accelerate before fully aligned with the runway. That has the result some of them to overshoot or side-slide (although they are doing great job to correct the latter- like WRC drivers!).
I think that the solution could be to have the aircraft to delay the use full throttle until 2 conditions are met; they are on the centerline of the rwy and aligned with the take off heading
For taxi-back, you need to create a taxi route segment that is marked ‘runway’, and labeled with the runway number of the runway it covers. That way X-Plane can do occupancy checks, e.g. you can’t back taxi while a plane is landing on the same runway.
Hi,
I am really looking forward to some more coverage of the scenery submission process as right now it seems a little “undefined”. Lots of inaccurate or downright false data getting submitted without the necessary process in place to check that.
As far as taxi-routes go – at this point I can´t get myself to consider using or providing paths for the AI. The current implementation is simply not worth spending time on the AI, and I doubt that the architecture allows it to ever reach a state where anyone will consider it so.
Yes, it can be hilarious to watch the “full fidelity flightmodels” skid off the runway in a huge crosswind – for about 2 minutes. I wish the system had been designed with a more practical use in mind, where we can get a realistic number of airplanes moving on realistic trajectories with somewhat realistic ATC interaction. Its possible, and the competition has been doing it for decades.
Jan
I’ve used WED quite a bit, but I find Taxi and flows to be a whole different beast. Is it possible to have WED throw us a bone and auto-generate some of the taxi way flows for us. So all that’s left is to tweak the pathways? Because it seems like XP10’s taxi path autogenerator seems pretty good it just needs some hand-tuning to iron-out some on the drunk-walking in the auto-gen’d algorithm … yeah you might call it laziness on the scenery developer’s end but hey the algo already exists, including it in WED would be a pretty nice feature me thinks.
X-Plane’s generator makes a huge number of extra vertices, which makes cleanup not much fun. We looked at other auto-generation algorithms for WED but didn’t find one we liked. Maybe someday we’ll have better generation tech.