One small bug: if you delete a helipad tile, there will still land helicopters on it. (whatever you build over it.
Fixed, updated first post.
To reduce the number of blocks, if you add the ability to state that one should claim certain tarmac tiles together, a user can make smart dcisions on where to reduce the block count.
Adding that ability will make the airport less efficient, not necessarily consistent anymore (which is really important). I think it is better just to let it be as it is, even though it limits the size of the airport.
Finally, I had some trouble getting planes to leave; do you take into account that a plane may have to taxi on the runway (in my case over the entire runway) before it is in position to take off?
Yes, I do, it is however ATM not allowed to move directly from one runway to another, or directly between gate and runway (may be added later). In heavy traffic, aircraft may (and quite often do) get stuck, due to that their path needs to be totally clear before they can reserve it (especially if you use only landing-runways). This is not IMO a deadlock, as they get to move when traffic becomes less dense, it is also a result of bad airport design. I will try to fix this by letting aircraft stuck this way update their orders from time to time, to check for alternatives.
Last but not least, it may be possible to feed the state machine into a model checker like Spin that can search for deadlocks in a systematic way. (So you know there is no deadlock rather than just suspecting it.)
Before a lot of work is put into that, I will attempt to prove that it is consistent (actually, while doing so, I realised it is not, but it can be corrected). So, here it is:Proof of consistency!
1) Movement to hangar from tarmac is always possible, as the hangar has unlimited space.
2) Movement to gate/helipad from tarmac is possible as long as the gate/helipad is reserved by the aircraft, which is always the case.
3) Movement to take-off-runway from tarmac will always be possible, as any aircraft there always will fly away.
4) Movement with arrows is one-directional, in the sense that movement in the opposite direction first must be reserved.
5) Movement perpendicular to arrows is temporarily one-directional, as it is made sure by reservation that no aircraft can move in the opposite
direction until the aircraft that reserves has passed the reserved two tiles (actually it is the movement from one tile to another that is reserved).
6) Movement on a one-directional route (including both case 4 and 5) that does not 'bite itself in the tail'
(is not a circle) can be considered a queue, a queue will always move as long as the front of the queue moves.
7) The front of a queue will move due to points 1, 2 and 3 which are the only allowed front ends of a queue, in all other cases the entire route must be reserved.
8 ) Movement on a one-directional route that 'bites itself in the tail'
is not consistent (remember that even though the same aircraft never will move around the full circle, the circle might get totally filled up with aircraft, so that none of them can move). This must be checked for. If this case is found, it is possible to let all the aircraft in the circle move simultaneously. I have not done this yet (I discovered the case yesterday when working on this proof) and it is probably not possible to do this kind of check when made for NewGRF. Note that I didn't manage to reproduce this in practice, as it probably demands a larger than 20*20 airport, which is the limit of my gui. Also note that one measure has been taken to limit the occurence of this, and make traffic in general less dense: to exit from gate, runway, helipad or hangar, it is demanded to reserve at least
the first two tiles of movement.
9) Reserved movement to a tile from which the above points guarantees free movement is always possible when no traffic is in the way.
10) Movement from gate, helipad, runway or hangar must always be reserved according to 9. Note that if the first movement ends in the queue, only reservation of this tile is necessary, reservation is done for the first two tiles anyway, due to reasons stated in point 8.
11) Movement to landing-runway to take off demands reservation of the entire route, and is therefore possible when no traffic
12) Landing is only possible on helipads and landing
-runways. The entire runway/helipad must be clear and reserved in advance.
13) Takeoff can be done from both kinds of runway, and demands reservation of the entire runway.
14) Movement on runway when landed is possible, but demands reservation according to 9.
15) Movement on runway in order to take off is possible, as long as reservation to the end of the runway where take-off starts
16) Crossing runways is possible as long as reservation that assures that the aircraft gets off the runway is present (must be done according to 9)
17) Points 11-16 makes it possible to have several aircraft on the runway at the same time, as long as no plane is taking off or landing.
I know this is not an easy proof, but I think it is correct (please challenge!)
Sorry for jpg-images.
File comment: For movement from left to right, cases 1 are considered movement with, cases 2 perpendicular to, and cases 3 against the arrows.
rules of movement.jpg [ 17.85 KiB | Viewed 16263 times ]
File comment: A queue such as this, only demands reservation of the next tile, as long as the target is a gate, a helipad, a hangar or a takeoff-runway.
queue.jpg [ 9.08 KiB | Viewed 16267 times ]