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.

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

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.

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.)

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.

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