[req]huge airports for ottd

[Dimme]

Hi rick67,

I am very impressed by the work that you have put into the airports that are already in the game, and the NewGRF ports branch. I will really urge you to continue the development!

I do, however, not believe it is the final solution to airports in OTTD. The fact that this discussion comes up from time to time, indicates that there is an interest in modular airports, and, I am quite sure, it can be done. A lot of effort is indeed needed, and it is not easy to split the work into small incremental steps, as modular airports are not interesting unless made totally complete.

User Interface - you wont be able to just "drag-and-drop". There will be decisions to be made - like what entries onto a tile are permitted, what exits are permitted (remember that the current airport system can move pixel by pixel, not just tile by tile - and in 8 directions - arguably 9 if you include takeoff points). And somehow all this needs conveying in a simple clean way to the player.

For simplicity, it will be best to only consider the 4 directions used by e.g. road vehicles first, but adding the 4 other directions will definitely be possible later (at least by using blocks larger than a tile). Blocks smaller than a tile will not be practical in any way, and I don't see that as a problem.

Logic engine - if you restrict the whole system to tiles, then it is not as bad; but it still needs an engine that can detect potential locks and prevent them. Basic pathing is already built into the NewGRF_ports system - so aircraft should never cross a requested path (if properly encoded in .nfo). The logic engine would need to handle that and re-analyse the airport every time a piece is added.

Yes, you need an engine that can detect potential locks. In my solution, you will need to close an airport (including waiting until all aircraft are gone, or in a hangar) before doing any changes to it. When construction is finished, you will then need to click a button to "open" the airport, a pathfinder will then calculate all possible routes, save them (to make a state machine) and if some routes cannot be found, a very specific error message will be given.

Support - when problems crop up, many users badger the developers for a "fix", when the problem is really them and the nonsense airport design they have created. If such a system were introduced, then I bet none of the developers would want to support it; it might be a stock "if your self-designed airport is broken - that is your fault. Scrap it and try again."

When no more error messages occur, you can be 100% sure the airport is not broken

Design efficiency - it is not the number of runways that make an airport efficient, but the speed of transfer in the runway-to-terminal, and terminal-to-takeoff taxiing. In the static designs within NewGRF_ports, I have heavily optimised these, and can get nearly the same throughput on a (new design) International (with 2 runways/6 terms), as an original Intercontinental with 4 runways & 8 terms. (I created the Intercon + Commuter btw). My brand new design "La Guardia" is a 2 runway airport in 26 tiles with 4 terms... and yet it is only just short of the throughput of a (current) International (49 tiles, 6 terms). My point being: without the programmed power of the state machine system, you will never get as efficient airports as you wont have access to some of the load balancing tricks that can be done in the FSM.

Now, this is interesting. With my system, it is also possible to make airports a lot more efficient than the intercon and probably also the international (I cannot test them in OTTD, but I consider this quite obvious, the intercon is very inefficient). This because blocks are smaller (one tile), so that more aircraft can move simultaneously. You are right that you can do some more load balancing when you do it manually, but I would be surprised if it gives very significant results. My system tries to balance the load on takeoff runways (by considering how many aircraft are queueing atm), and does that very fine when the airport design is good. Balancing on landing runways is not done yet, but that cannot be too difficult. It is not possible to make airports that will not work (and still pass the tests), but it is possible to make very inefficient, or very efficient airports, so putting an effort into the design (of large airports especially) will be an important part of gameplay.

You may want to micromanage airport construction, but many players just want to slam an airport down and get on with setting up the transport services to/from it.

Sure, and this is why I would be very happy if you finished your project. It is not impossible to keep both systems anyway It seems, however, that most people play more with trains than with aircraft, and I am not surprised if this is partly because playing with aircraft is not challenging enough.

I am definitely listening to you, though, and any useful comments or ideas are very welcome

[prissi]

The problem with a user layout airport, as rick67 said, is that deadlock are easy to generate and nearly impossible to find an origin for it. A "very specific error message" is just the computer equivalent of reading the users mind. Beacuse deadlocks rarely occur from a single tile: every crossing can cause a deadlock with the right connections. (This is the same as people want to know at which tile no route to destination is found ... )

Just consider this Airport:
HHHHH
+-------+
======

It will work non-bliocking for up to four planes. But with the fifth plane waiting for the last stop to free it will block. No way to autodetect this, or with outher words, only single stops are probably deadlock free (but useless).

Hoever, as I have implemented airports in Simutrans, I had faced the same troubles. There would have been several solutions, however, the most practical was, that planes cannot block each other on taxiways. This way, nearly all user created catastrophies are useful, albeit planes will go through each other. If you can live with that, then just the runway is a simple block and all other ways are non-blocking.

[EXTspotter]

Could we impliment a system like planes can only land if a speified exit tile is clear, therefore it would prevent total deadlocks caused by planes trapped on runways preventing departures. As for how to sort out deadlocks on single tiles, make tiles dragable in the specific direction you want 1-way, i.e. if you drag a line of tiles from north to south, you have a tile, planes can only enter from the north and only exit in the south, but it is "2 way" if there are plane stands to the east or west. Therefore planes cannot try and park in a space occupied, blocking up the exit, plus you could make a "holding point" where planes are kept until a parking space becomes available, which is assigned to that specific aircraft until it pulls off the space again.

[Dimme]

Just consider this Airport:
HHHHH
+-------+
======

It will work non-bliocking for up to four planes. But with the fifth plane waiting for the last stop to free it will block. No way to autodetect this, or with outher words, only single stops are probably deadlock free (but useless).

You should also take a look at this thread. For this specific airport, I would demand that a hangar is built. Landing aircraft will then go to the hangar, which can hold an infinite amount of aircraft. No aircraft will ever head for a gate without reserving the gate first (the drawback is that this makes the airport a little less efficient, or at least demands a larger gate/runway ratio).

If I am able to convince you that this works, would you be interested in helping with the implementation?

regards

Dimme

[gks]

Been there, argued this one dozens of times. I *do* know what Im talking about since Ive coded the new airport system.

I dont doubt of your capabilities,actually your great!

[That Guy]

Yea, put that in your pine and smoke it!

what you hate pines
anyway,someone interested?

wow thats a bad type-o

but the problems you listed should be avoidable.

example:
---> = Normal taxiway
-x-> = Block section taxi way
--->--->--->-x->--->--->--->-x->--->--->--->

see my point is that i know it would be very hard to code a modular airport in separate pieces that are expected just to work, but with if you build them with just like rail lines (minus the drag and drop) and occasionally throw it a block section. Oh and for Newbee's, well they can use the Airport originals, anyway who cares if newbees screw up there airports, they do it with rail already!

and why not have the path finding engine count the planes as they land and take off, as well as count the block sections, then keep planes from landing when only one section is free.

[richk67]

Would you have the modular placement system replacing the current airports (disadv: not everyone wants to build their airports in bits), or keep the current system alongside (disadv: doubles up on code)?

You need to consider the *whole* feature - logic engine, GUI, and support. Fail on any of these and it will never see trunk. Heck, Im still not sure my airports-as-grfs will ever make trunk, but at least it ticks most of the boxes. (Code optimisation not currently passing, as well as some missing functionality).

The other item that is *totally* unhandled in the java demo, and all other proposed ideas Ive seen - control of the inflight holding pattern motion. In my system, I estimate about 1/3 of all locations and commands are to control the motion and runway choices of the holding pattern; for aircraft, and for helicopters. Controlling this aspect is important to the look and feel of an airport - it may move OK on the ground, but if aircraft are turning right angles in flight, it just looks plain stupid. Creating a GUI to design the 3D (arguably 4D - as it is time based too) requirements would be a horror.

There are dozens, if not hundreds of subtle choices that need coding support, and in a build-your-own system, would require a GUI to enter them. I doubt people will want to have to code up their airports - e.g. if at terminal 4, use runway 5 for takeoff, use hangar 2 for depot, use... etc. or... if landing on runway 2, check if a terminal is free in term group 3, then term group 8, then term group 6, then term group 1, if all fail go to depot 2. Also, bear in mind that some events (such as Goto Depot orders and automatic servicing) can happen once an aircraft is "en-route" around the airport; in the current system an aircraft can be re-routed at the next decision point to go immediately to depot - this would need to be programmed into a constructed tile system as a self-routing abort system... and the player/designer would need to account for that in their designs... yik!

The GUI would be horrific... having to show 3D positions, potential movements, conditional movements, etc.

The more I think of how it could be done, the more I think it can be done, but will make NFO coding seem delightfully simple in comparison.

[Dimme]

Many reasonable questions there, I certainly don't have all answers yet. This is a big project that I will never continue alone...
My ideas are currently:

Would you have the modular placement system replacing the current airports (disadv: not everyone wants to build their airports in bits), or keep the current system alongside (disadv: doubles up on code)?

The option to simply place airports is important for starters, so at first I would like to keep the current code alogside. Later, it may be possible to make new readymade airports using the modular system, so that these can be placed and modified ingame. Then the code will not be doubled anymore.

The other item that is *totally* unhandled in the java demo, and all other proposed ideas Ive seen - control of the inflight holding pattern motion. In my system, I estimate about 1/3 of all locations and commands are to control the motion and runway choices of the holding pattern; for aircraft, and for helicopters. Controlling this aspect is important to the look and feel of an airport - it may move OK on the ground, but if aircraft are turning right angles in flight, it just looks plain stupid. Creating a GUI to design the 3D (arguably 4D - as it is time based too) requirements would be a horror.

I have two different solutions to this, one simple (probably too simple), and one very much more advanced.
The simple solution:
Having one holding pattern per runway, like the one on the city airport. This will look terrible if many runways are placed close to each other, but should be simple to implement. A load balancing system between the different runways must be made.
The advanced solution:
Let the holding pattern be a large ring around the airport calculated from the placing of the runways, sufficiently large to allow landing on all landing-runways simply by taking a turn inwards in the ring. This would look like a larger version of the holding pattern for the intercontinental airport, and keep in-air "crashes" at a minimum. The main disadvantage that I can see (beside the difficulty of the point calculation, which I have not looked very closely at yet) is that this might make the airport less efficient due to a long holding pattern. A solution to this can be to adjust the speeds of aircraft (of their entire flight) so that they arrive at a certain timeslot (as in RL), and use the holding pattern only if something unexpected happens (including that the airport does not have the capacity to take down all aircraft. Details need to be worked out though.
In any way, the holding pattern needs to be calculated automatically, so no horror-GUI will be needed

There are dozens, if not hundreds of subtle choices that need coding support, and in a build-your-own system, would require a GUI to enter them. I doubt people will want to have to code up their airports - e.g. if at terminal 4, use runway 5 for takeoff, use hangar 2 for depot, use... etc. or... if landing on runway 2, check if a terminal is free in term group 3, then term group 8, then term group 6, then term group 1, if all fail go to depot 2. Also, bear in mind that some events (such as Goto Depot orders and automatic servicing) can happen once an aircraft is "en-route" around the airport; in the current system an aircraft can be re-routed at the next decision point to go immediately to depot - this would need to be programmed into a constructed tile system as a self-routing abort system... and the player/designer would need to account for that in their designs... yik!

The GUI would be horrific... having to show 3D positions, potential movements, conditional movements, etc.

The more I think of how it could be done, the more I think it can be done, but will make NFO coding seem delightfully simple in comparison.

I have some ideas/points to make the GUI better than in the java program (and how to handle the transformation into OTTD):
1. It should be as similar to the rail and road GUIs as possible.
2. An auto-taxiway tool should be made, in the style of the autoroad and autorail. When dragging from left to right, the arrows should point from left to right.
3. Placement of hangars should be similar to road and rail, and placement of runways should have a similar look to rail station placement (with variable runway length. Placement of gates and helipads is rather trivial, but it should be demanded that they are placed next to a terminal buiding.
4. Placement of terminals should be similar to placement of rail stations. Only the terminals will have a catchment area, and if there are several terminals in one airport, the player must e.g. create a bus route between them if playing with cargodest. (This idea is not for simplicity, but for enhanced gameplay)
5. Every airport needs one tower. If you click the tower, a simple GUI with a few options appear:
Open airport (all calculations are done when clicking this button)
Close airport, all aircraft leaves
Close airport, all aircraft leaves or goes to hangar
Close airport, all aircraft leaves or goes to hangar or gate/helipad

Only the first two must be implemented, the two latter will ease modification.

Regarding goto depot orders, this solution demands that the current order is finished before the goto depot order can be executed. It may be possible to take shortcuts in some cases, but you cannot be sure to always avoid deadlocks if changing orders when moving. I disagree that this needs to be solved though, it's only a minor disadvantage.

The aircraft will automatically choose the closest (pathfinder-wise, moving on runways or moving against arrows are weighted) hangar, the closest available gate/helipad (of the chosen terminal). When choosing takeoff-runway, the number of planes queuing also adds to the weight.

Thank you for the questions and comments! Keep them coming

I will need a lot of help to get this working, so the most important right now is to convince people that it is possible. All help is greatly appreciated

[That Guy]

The other item that is *totally* unhandled in the java demo, and all other proposed ideas Ive seen - control of the inflight holding pattern motion. In my system, I estimate about 1/3 of all locations and commands are to control the motion and runway choices of the holding pattern; for aircraft, and for helicopters. Controlling this aspect is important to the look and feel of an airport - it may move OK on the ground, but if aircraft are turning right angles in flight, it just looks plain stupid. Creating a GUI to design the 3D (arguably 4D - as it is time based too) requirements would be a horror.

I have two different solutions to this, one simple (probably too simple), and one very much more advanced.
The simple solution:
Having one holding pattern per runway, like the one on the city airport. This will look terrible if many runways are placed close to each other, but should be simple to implement. A load balancing system between the different runways must be made.
The advanced solution:
Let the holding pattern be a large ring around the airport calculated from the placing of the runways, sufficiently large to allow landing on all landing-runways simply by taking a turn inwards in the ring. This would look like a larger version of the holding pattern for the intercontinental airport, and keep in-air "crashes" at a minimum. The main disadvantage that I can see (beside the difficulty of the point calculation, which I have not looked very closely at yet) is that this might make the airport less efficient due to a long holding pattern. A solution to this can be to adjust the speeds of aircraft (of their entire flight) so that they arrive at a certain timeslot (as in RL), and use the holding pattern only if something unexpected happens (including that the airport does not have the capacity to take down all aircraft. Details need to be worked out though.
In any way, the holding pattern needs to be calculated automatically, so no horror-GUI will be needed

Yea the calculated boundary could be something like station spread size.

There are dozens, if not hundreds of subtle choices that need coding support, and in a build-your-own system, would require a GUI to enter them. I doubt people will want to have to code up their airports - e.g. if at terminal 4, use runway 5 for takeoff, use hangar 2 for depot, use... etc. or... if landing on runway 2, check if a terminal is free in term group 3, then term group 8, then term group 6, then term group 1, if all fail go to depot 2. Also, bear in mind that some events (such as Goto Depot orders and automatic servicing) can happen once an aircraft is "en-route" around the airport; in the current system an aircraft can be re-routed at the next decision point to go immediately to depot - this would need to be programmed into a constructed tile system as a self-routing abort system... and the player/designer would need to account for that in their designs... yik!

The GUI would be horrific... having to show 3D positions, potential movements, conditional movements, etc.

The more I think of how it could be done, the more I think it can be done, but will make NFO coding seem delightfully simple in comparison.

I don't know why when you think modular you also think this means you have to place everything yourself, including every positions in the sky, we're not suggesting that at all. Hell we don't want that, were only talking about once they hit the ground. I don't know why but it seems like you really hate this idea for some reason. Just listen to the pitch we're selling on before you decide what it involves, we didn't say anything about flight paths anyway.

If we're gonna make this thing i can do the sprites needed.

as far as code, i could try but i'd be going soooo slow and probably do it wrong anyway.

[maquinista]

This is my suggestion:
A new difficulty option to make the runway lanes much larger. It would make a bit difficult the use of planes in OTTD.

[athanasios]

I suggested that centuries ago, and it was opposed.

[richk67]

I don't know why when you think modular you also think this means you have to place everything yourself, including every positions in the sky, we're not suggesting that at all. Hell we don't want that, were only talking about once they hit the ground. I don't know why but it seems like you really hate this idea for some reason. Just listen to the pitch we're selling on before you decide what it involves, we didn't say anything about flight paths anyway.

You might not say anything about them... that to me just means that the problem is being ignored. You may only be talking about when they hit the ground, but its all part of a single system... you cant have controlled landings without a controlled airspace.

Dont be so condescending making it seem as though this is the first time its been proposed. This has been done to death over about the last 3 years in dozens of threads.

I dont "hate" the idea... it just is an exceedingly complex replacement that will just add complication to gameplay rather than make it simpler. ie. the cost of effort:reward ratio is very poor. Lots of effort, little reward.

If you are that determined to ignore the advice of someone who has probably spent more time in the airport code than any other current dev, sure, fine... knock yourself out. Go for it. If you succeed I'll be the first to applaud the system. But I certainly wont expect a polished solution before Xmas 2009.

[bartpp7]

What about that GRF called fake airports thats pretty fun and kind of easie to use and its good to use when you have lots of planes or just build lots of interntional airports

[gks]

but fake airports is fake no?cant use planes on it(at least thats with me)

[Dimme]

...

I think richk67 has some valid points, and the best way to answer critical questions is not to say they are silly. A solution for flight paths is needed. I have been thinking about it a little, and i think it can be done. I will write a detailed analysis report

All help is appreciated. We need someone who knows the code well, and has a lot of experience, so that we can do it on the first attempt though. If we can use the graphics that is already made(?), only a few sprites are needed, and not until quite late in the project.

A new difficulty option to make the runway lanes much larger.

This is one of the things that can be done later. A solution is to allow drag and drop for runways, and then let the grfmakers decide what length every plane needs, or something like that. As the airports will be modular, it will be easier to place them in the terrain, so longer runways is more likely to be useable.

Other things that can be done after the needed elements are in place, includes diagonal movement, bridges and more. The opportunities are many when the basic system is ready.

Dont be so condescending making it seem as though this is the first time its been proposed. This has been done to death over about the last 3 years in dozens of threads.

I dont "hate" the idea... it just is an exceedingly complex replacement that will just add complication to gameplay rather than make it simpler. ie. the cost of effort:reward ratio is very poor. Lots of effort, little reward.

If you are that determined to ignore the advice of someone who has probably spent more time in the airport code than any other current dev, sure, fine... knock yourself out. Go for it. If you succeed I'll be the first to applaud the system. But I certainly wont expect a polished solution before Xmas 2009.

The proposal has been made many times, but I have never seen a solution that even comes close to showing that it is possible. This changes things, at least a little. I don't expect a polished solution that early either. I won't ignore your advice, I'm certainly listening, but the point is that I think it can be done, and that the final solution will benefit OTTD enough for me to say that I volunteer to participate in the process.

I showed the java program to some friends of mine, and they quickly made large, working airports, so it is not too complicated. The current system is too simple for most OTTD players, IMO.

Even though I don't expect you to volunteer, I hope you will continue to ask difficult, detailed questions. It certainly helps the project!

[gks]

An idea
double lanes like in JFK


===================== +-runway
___|_____________________|
___|_____________________|

[MarkyParky]

Hello,

My work in reallife is connected very close to flying so I am reading any OTTD airport-related stuff very carefully. I have downloaded Dimmes demonstration aplication and I am really plasantly surprised, so I would like to write some comments on mentioned stuff:

a) Deadlocks. Till I saw this aplication, I considered possibility of deadlock as main problem why not custom build airports. I am now playing for more than hour with Dimmes application and I have not been able to create deadlock so far. From this point of view the most significant argument against custom made airports has fallen and from this moment on I feel that this approach is worth of looking closer at it.

b) Capacity and throughput - eventhough you will probably never by able to have the same efficiency as with premade airports, you still can make pretty efficient airports, the only cost is their size. This might be considered as drawback by some, but I see it more like bringing more realism to the game. It is common create to create train stations bigger than original airports (and even bigger if you include all the entry/exit yards near them) and if you look at reallife comparation of average airports and railway stations you suddenly feel that original OTTD airports seem to be too tiny. So from this point of view, forcing people to create bigger airport structures for a good throughput is a good idea.

c) GUI/difficulty to build - Praticaly I see no difficulty here. Example aplication have pretty simple GUI allowing to create very complex airports within few minutes. When I compare difficulty to code my home airport in a simplified form using NewGRF ports and easines with creating almost the same structure using this example programe, the diference is hours vs minutes and effeciency of airports is almost the same. There was one problem mentioned regarding GUI, which is flightpaths/holding patterns. I will cover this in separate article.

d) Reconstructing airport on the fly - as mentioned, one problem is, that you will probably not be able to reconstruct airport on the fly. But this is the same with present airports, so I don't feel it like problem of this method of creating airports, but as problem of OTTD airports in general. I think that proposed solution with "tower" is generaly good and it has been already proved, that it does work (it was used for constructing rollercasters in RCT).

e) Graphics - generaly there shall be some basic graphics for start, but if actions 2, 3 and possibility to detect callbacks would be implemented later on for airport tiles, it would allow much greater variability than any other approach while keeping GUI simple. I know that this is very soon to speak about graphics, but I feel it important to mention, because I feel lack of possibility to change sprites by callbacks as the main drawback of NewGRFports approach. It woud be good to be prepader for dynamicaly changeable graphics from the begining.

f) Flightpaths/holding patterns - I would like to go slightly deeper in the aviation history here as it might help and also it is part of my daily job, so I will write a longer reply about this problematic in this thread later. But in a breif - you don't need complicated 3D GUI, placing radiobeacons on the ground as places for holding might be good enough.

g) Last but not least - support. It was several times mentioned, that support is needed. Beside the fact, that given example is quite intuitive, I would say that it is quite easier to understand than f.e. using presignals or YAPP. I would say, that if the logic of building stays simplier than given examples used with trains, it is ok and it does not need so much greater support than trains have (means few explanation on some wikis/forums with nice pictures).

h) Conversion - definitely needs a solution, but I see one clear and easy - premade airports. This solves two problems at once - both people that are not interested in building airports in bits and in converting old savegames. The only problem that needs to be solved is state of the aircraft in old savegame airport to be converted, but this generaly only means to have 1:1 transition table between old state and new position + reservation.

[richk67]

When I compare difficulty to code my home airport in a simplified form using NewGRF ports and easines with creating almost the same structure using this example programe, the diference is hours vs minutes and effeciency of airports is almost the same.

LOL, very true. But that is principally because a NewGRF_port has no construction gui... Im quite a whiz with cut/paste from existing airports' .nfo files.

I feel lack of possibility to change sprites by callbacks as the main drawback of NewGRFports approach. It woud be good to be prepader for dynamicaly changeable graphics from the begining.

Maybe that callback part just hasnt been built yet.... In fact very little of the extra callback support has been written. Im not entirely sure what you are getting at here, since the whole point of the NewGRF_ports is that the .grf provider can supply replacement airport graphics. If you want to override those with your own airport graphics, then you are creating a .grf yourself, and you may as well edit the NewGRF_port itself.

Since the NewGRF_ports graphics are self-contained, they are no better/worse for graphics replacement than overriding any graphic in a .grf. It should already be supported, but I havent tried it.

[MarkyParky]

Ans as promissed now few words on holding pattern and approach procedures.

First I would like to explain some terms and general rules, later some examples of implementations. I would like to mention, that most of the ideas I will write here are generalised - local procedures at some countries or airports might differ a lot. But it may be simplification good enough for implementation to OTTD. I will also mention procedures used in comercial traffic, controlled airfields and instrument flying only - general aviation sometimes use different procedure on uncontrolled aerodromes, using visual flight rules, but that is not covered by TTD. I am also not covering special procedures, like enroute holding, shortcuts, etc.. as they are not neccesary for the game.

We can divide flight of aircraft to several parts, each covering a different "relationship" between aircraft and airport. Not all parts/procedures are used on all airports generaly, but

* Take off - Aircraft is on the airport (doing take off run on the runway).
* Departure - Aircraft is navigating from airport to its first enroute point through terminal area around the airport (either guided by radar vectors or following SID - standard nstrument departure - or specific departure clearance).
* Enroute flight - Aircraft is flying along its planed route
* Arrival - Aircraft is navigation from its last enroute point to IAF (initial approach fix - point where approach procedure starts) through terminal area around the airport (either guided by radar vectors or following STAR - standard arrival route - or specific arrival clearance).
* Holding/Transition/Radar vectors - Aircraft is in the terminal airspace of the aerodrome, doing some prescribed procedure or guided by radar vectors, usualy between Arrival and Approach, which is ment to delay the aircraft before it starts the approach or brign the aircraft to final approach at exact time. Radar vectoring is common procedure where radar is aviable and ATCs are giving exact instruction to bring pilots exactly where they need them. Holding is determined either for non-radar enviroment or for longer delays (more than couple of minutes) - aircraft are doing holding patterns over prescribed point (mostly IAF) waiting until his time comes. Transitions are used used only on the bussiest aerodromes to delay aircraft only few dosens of seconds - aircraft flies along the transition until it fits into final sequence and then it recieves radar vectors to get there. Both holding and transitions are mainly placed at IAF just before approach, eventhough at large aerodromes, there might be also holding patterns defined on the begining or in the middle of arrival procedure so the aircraft do not get crowded.
* Approach - Aircraft is following special instrumental procedure that will lead him from IAF or radar vectors to very short final of the runway
* Landing - Aircraft is on the airport (landing on the runway and vacating the runway).

Not all parts mentioned above are neccesary to implement, but it is good to know them, to fully understand the procedure. I would divide my talking into two parts - one is simple (Departure, Enroute flight and Arrival), the other (rest of manuevers) is more complicated.

We can almost drop Departure, Enroute flight and Arrival part in OTTD - aircraft are departing straight ahead form the runway and then proceed almost direct to their destination where the approach/holding starts. If we want to add some realism to this part, we would need some "checkpoints" for aircraft - for example represented by VOR/NDB beacons on the ground. But this would be more eyecandy than real gameplay effect and it has nothing to do with airports, so I will skip this part now.

On the other hand holding/transition, apporach, landing and take off are really interesting, because implementing them does affect the throughput of the airport. I will now show several examples, how arangement of there procedures might look at real life and and also look at their gameplay implementation. But before we do so, I need to explain some few more terms:

IAF - initial approach fix - is a point, where the approach starts. It is usualy also as a holding fix (there is a holding published at this fix). On modern airports a transitions sometime starts at this fix as well. I will mark IAF with yellow square on my pictures and the initial approach with dark red arrow.
FAF - final approach fix - is a point where the aircraft finish all initial approach manuevers, usualy is in front of the runway and starts its final descend. I will mark FAF with light blue square and final approach with dark blue arrow.
holding pattern - is an oval trajectory of the aircraft in holding. You can imagine it as oval lane on the stadium, where the holding fix is placed at one "corner" of the holding pattern. I will draw it in bright red.

The arrival of aircraft will be drawn with dark green arrow and runway as black line.

Situation 1:
The simpliest (and less effective) solution on old aerodroms was one navigation beacon placed on the airfield. The aircraft was heading to this navigation aid and it served as IAF, holding fix and approach beacon at once. When the aircraft apporached it either started its approach using "procedural turn" orstarted holding. Aircraft could not leave the holding pattern and start approach until previous aircraft was on final approach. As you can imagine, it was very slow, especialy because it take approximately 1,5 more to fly from IAF to FAF via procedural turn then making of final approach, so you are kind of vasting the time on the turn.

This is easy to implement ingame - aircraft simply holds above the airfield. If the initial approach is free, it leaves hold and starts approach. You can have 2 aircraft approaching at the same time.

Situation 2:
Slightly better efectivity and still simple - IAF and FAF are merged - aircraft simply holds at IAF (eg. before the runway and final descend). If the final approach si free, it starts. Still you can vaste soome time, as aircraft has to finish its turn before starting the descend.

This is also easy to implement ingame - in fact this is how aircraft holds at small aerodroms nowadays.

Situation 3:
More effective solution is to use different navigation beacon or fix for holding and IAF and different instrument for approach itself. The rules are the same, but you can generaly increase the throughput by choosing a good place of IAF and reducing flying time from IAF to FAF. Often there are two or more IAFs connected with one runway - usualy two on each side of the runway, sometimes even third on the "long final".

This has very simmilar implementation to situation 2 but it can improve the performance a lot.

Sitation 4:
The most effective solution today is either radar vectoring or combined use of Transitions and radar vectoring. IAFs are usualy placed abeam the FAF on both sides of the runway. When approaching IAF, aircraft do not enter holding, but they either recieve a radar vector or are cleared to follow transition. The air traffic controller gives them simmilar speed and by turning them to runway in right time he can make minimum spacing between the aircraft. This way you can have several aircraft doing the approach safely in the same time, and the only limiting value is time neccesary for preceeding aircraft to vacate runway/take off. If you have paraler runways, you can even use both of them in the same time and use one system of transition for balancing load between both of them or dedicate one runway to takeoffs and the other to landings which also increase througput.

This is probably hardest one to code, but also it has greatest improvement impact.

[MarkyParky]

When I compare difficulty to code my home airport in a simplified form using NewGRF ports and easines with creating almost the same structure using this example programe, the diference is hours vs minutes and effeciency of airports is almost the same.

LOL, very true. But that is principally because a NewGRF_port has no construction gui... Im quite a whiz with cut/paste from existing airports' .nfo files.

Yes, I do quite understand this and until I saw this program I was also convinced, that your approach is the only good one. I was only trying to show the difference from "I am ordinary player and I want to construct my own airports too" point of view.

I feel lack of possibility to change sprites by callbacks as the main drawback of NewGRFports approach. It woud be good to be prepader for dynamicaly changeable graphics from the begining.

Maybe that callback part just hasnt been built yet.... In fact very little of the extra callback support has been written. Im not entirely sure what you are getting at here, since the whole point of the NewGRF_ports is that the .grf provider can supply replacement airport graphics. If you want to override those with your own airport graphics, then you are creating a .grf yourself, and you may as well edit the NewGRF_port itself.

Since the NewGRF_ports graphics are self-contained, they are no better/worse for graphics replacement than overriding any graphic in a .grf. It should already be supported, but I havent tried it.

This is a bit missunderstanding between us - I was not talking about replacing whole graphics. That is of course aviable. But I was talking about changing graphics "inside the code" of the GRF depending on callbacks - animations of gates depending on whenever the aircraft arrived, rotating radars, etc. I am certainly sure that you would probably implement that later. But main point of view was - if you try to implement NewGRFports in this dynamic way, you will probably need to split the structure into two parts (simmilar to current implementation of industry) - "Port" - that defines tile layout and FSM in its action0 and maybe preview graphics, and "PortTile" that defines graphics of single tiles in action0 and which is assigned by action3 and later on controlled by action and varaction2 - and that is why I mentioned it - I am not saying that NewGRF will never do this. I am only saying that the first imlpementation didn't take it to account and that it will probably need massive rewrite to allow this. So I wanted to warn to start thinking about graphics from the first moment to avoid such a massive rewrite in future.