[req]huge airports for ottd

[CommanderZ]

Cool reading, MarkyParky! Especially option 4 sounds really great. It wouldn't be easy to implement as you said though.

[richk67]

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.

Err... I think I already included this in the design. The design is a lot further than the coding here.

My design includes marking locations as "do a callback test here", and the result would be the next step in the state machine; so you can do nifty things like send cargo planes one way, and passenger planes another. I constructed all the sample state machines including this callback byte, but have not implemented support yet.

Animation will be controlled in precisely the same manner as newstations does it. It is totally dependent on completing the integration with newstations - a task that has me 99% demoralised at the moment. Basically any special newgrf animation stuff that can be done on stations will be possible on the airports. Obviously radars is the obvious one, but beyond that, baggage trolleys and airbridges etc may be possible to animate.

Interesting stuff on approach patterns. Especially since one of the ideas I was kicking around about a year ago was separating the holding stack(s) from the airports themselves. This would then make it a doddle to close an airport for a rebuild - you just dont let aircraft leave the holding stack for injection into the airport state machine. (Oh, and of course force all aircraft on the airport to take off and rejoin the stack.)

Already there is a dummy holding stack used when deleting an airport. This would just allow custom holding stacks. Incidentally I have changed the motion in the state machines, and you can now climb/descend on gradual slopes rather than the 45 degree nonsense we currently have. Its quite cool when you first notice an OTTD aircraft take 10 tiles to drop 2 height levels.

[gks]

A solution for approach would be changing the aircrafts attitude.
We know that in real BIG airports in our real world airplanes dont just spin around if they cant land,no theyre heading straight to the runway.
K=plane (=runway
K K K K K K K (((((((((((((((
now the problem is how to "teach" aircraft to keep the right distance from the other while approaching runway.
If they keep distance,its for sure that when one plane is out of the runway the plane behind manages to land.
Its all timing.
(If you cant understand,sorry.Also i had a hard time explaining this)

[MarkyParky]

Just two small note regarding the coding of approaches - talking about NewGRFPorts, I would rather not separate holdings from FSM - because you can make custom holding of airport by changing the holding in FSM by GRF code - for example there will definitely be different approach when you try to implement airport with runway used for takeoff and landing at once and different approach when you have separate runways for take off and landing. So if you choose NewGRFPorts approach I think that at least holdings before final approach definitely shall be part of FSM.

On the other hand, with "create by tiles" approach, holdings shall probably be attached to runway piece. The 4 examples I have mentioned are possible to implement flexible in code, solving the problem of creating holds automaticly without need to make some special GUI to write them or at elast simplify the GUI.

[Dimme]

1.st post.

Thank you for supporting me
It is also good to hear that you have tested the app a little. I see there are some downloads and no more bug reports, but that says nothing if noone has tried to find some bugs

Flight patterns.

Nice reading. I remember from playing MS flight sim. that the holding patterns were oval, that was what I based the holding pattern in the app on. The big issue, as I see it, is not how to make holding patterns for single-runway airports. Using the setup from your situation 2 is close to the one currently implemented, and works well. The only reason to change to situation 3, is you don't want planes to fly on top of each other. Situation 4 seems very efficient, though, so I will try to keep at least the idea in mind.

The main issue is scaling. How to make a consistent system of holding patterns for a 5, 6, 7... runway airport (remember that any layout is possible, also the ones that are silly in RL). If you want several holding patterns, they cannot overlap, as that will make the system look messy. Introducing more than one holding pattern per runway makes it even more complicated.

I have an idea on how to solve the problem of a large amount of runways, but unfortunately it does not contain any of the elements you listed.

Several planes approaching runway at the same time.

This should be possible to allow (and making sure they have the correct distance is should be fairly easy), but it demands that the planes on approach have a place to go if the plane on the runway is not able to get off the runway due to inefficiency on ground, or in the case of a crash. Therefore, I would like to wait with introducing this ingame. As I have listened to richk67's advice that this is a huge project, let's make that part simple for now.

Interesting stuff on approach patterns. Especially since one of the ideas I was kicking around about a year ago was separating the holding stack(s) from the airports themselves. This would then make it a doddle to close an airport for a rebuild - you just dont let aircraft leave the holding stack for injection into the airport state machine. (Oh, and of course force all aircraft on the airport to take off and rejoin the stack.)

Already there is a dummy holding stack used when deleting an airport. This would just allow custom holding stacks. Incidentally I have changed the motion in the state machines, and you can now climb/descend on gradual slopes rather than the 45 degree nonsense we currently have. Its quite cool when you first notice an OTTD aircraft take 10 tiles to drop 2 height levels.

Great My idea would be (when closeing an airport) to keep the holding pattern until the airport opens again, and if there are changes, order all the aircraft into the new pattern.

@graphics:
I don't know much about .nfo coding, so I cannot say much about this, except that I appreciate the warning that it should be taken care of from the start. I had hoped that it could be done later (as part of my making-this-simple project)

Can someone who knows more than me answer the following (regarding graphics):
1. Is the current treatment of hangars for road and rail sufficient, so that we can use som of that code for aircraft hangars?
2. Is the current treatment of roads sufficient, so that we can imitate that for the taxiways?
3. Will the same kind of treatment be enough for gates, helipads, and/or runways? (I would guess not as you wanted animated gates?)
4. My idea was to let only the terminal building work as a "station". Some decent amount of code should probably be shared with newgrf_stations here.
5. Should the tower graphics have the same flexibility?
6. Eyecandy such as ground radar and wind measurement tools? Maybe they can influence safety (% of crashes) at a later stage?

The reason for why I'm splitting the question so much is (as explained earlier) that I would like a separate gui for each of these elements, similarly to rail, road and marine GUIs.

I consider this part of the implementation the most difficult, as I have good ideas to how aircraft movement both on ground and in air should be done. It is also the part that needs to be done first, and that is good, as having the most difficult part first makes sure we don't waste time on something that is too much work

[MarkyParky]

This should be possible to allow (and making sure they have the correct distance is should be fairly easy), but it demands that the planes on approach have a place to go if the plane on the runway is not able to get off the runway due to inefficiency on ground, or in the case of a crash. Therefore, I would like to wait with introducing this ingame. As I have listened to richk67's advice that this is a huge project, let's make that part simple for now.

This is a problem in reallife as well and there exist a standard solution. It is called a missed approach procedure and generaly it is a predefined path leading the A/C after aborted landing back to IAF.

The main issue is scaling. How to make a consistent system of holding patterns for a 5, 6, 7... runway airport (remember that any layout is possible, also the ones that are silly in RL). If you want several holding patterns, they cannot overlap, as that will make the system look messy. Introducing more than one holding pattern per runway makes it even more complicated.

I have an idea on how to solve the problem of a large amount of runways, but unfortunately it does not contain any of the elements you listed.

Automatic generation of holding fixes/IAFs and their assignment to runways can be a solution. These will be kind of invisible to a player, will work on the background. At present moment the best solution is to place them using my situation 2 or 3 and an algorithm for placing IAFs. This algorithm can work like this:
- there is a default position for three IAFs, that are separated and in ideal distance from FAF regarding flyingtime. If a single runway for landing is made, theese default positions are used. If two (or more) positions overlap, algorith would calculate position of new holding fix, that would be used instead all overleaping.

I have read your idea of aircraft circling the whole airport choosing first aviable runway on his way. I do not like this idea so much, as this looks very unrealistic to me.

Can someone who knows more than me answer the following (regarding graphics):
1. Is the current treatment of hangars for road and rail sufficient, so that we can use som of that code for aircraft hangars?
2. Is the current treatment of roads sufficient, so that we can imitate that for the taxiways?
3. Will the same kind of treatment be enough for gates, helipads, and/or runways? (I would guess not as you wanted animated gates?)
4. My idea was to let only the terminal building work as a "station". Some decent amount of code should probably be shared with newgrf_stations here.
5. Should the tower graphics have the same flexibility?

The reason for why I'm splitting the question so much is (as explained earlier) that I would like a separate gui for each of these elements, similarly to rail, road and marine GUIs.

I consider this part of the implementation the most difficult, as I have good ideas to how aircraft movement both on ground and in air should be done. It is also the part that needs to be done first, and that is good, as having the most difficult part first makes sure we don't waste time on something that is too much work

Regarding the idea of separating stations (terminals and boadring bridges) from taxiways/hangars/etc.. in my oppinion brings more difficulties in implementation than "good stuff". I think that to make this project succesfull, it has to be divided into several parts. Some of them are independent, some of them are depending on the others. These parts are following:

a] Base functionality needed to be able to build airport from tiles (how the airport will be represented in maparay and how it will be displayed)
b] Generating logical airport structure (even statemachine?) from a] using your algorithms and handling aircraft within this structure while retaining some compatibility (do not modify unneccesery too much in aircraft handling, allow backward compactiblity with old airports).
c] GUI for a] and b]
d] Adding some enhanced functionality (as eyecandy described lower)

If I think carefuly about these things, my opinion is that you don't need to split functionality of the airport and separate hangars from taxiways. If I look closer at those parts, I see following ideas:
- if you keep the airport together, everything in a] will remain station tiles of one station and it will be much easier for algorithm b] to work
- if you keep the airport together , you will not need change present aircraft handling completely - you "only" need to by able i) generate structure dynamicaly and ii) navigate aircraft through the structure using new algorithm. But IMHO you do not need to change the aircraft behavior completely. And less complex changes - more likely the solution will be done in an acceptable way to get to trunk.
- GUI has nothing to do with airport structure or internal implementation. You can still have nice and friendly GUI while keeping airport structure
- keeping airport as komplex structure also makes implementing all the fancy functionalities mentioned bellow this article easier
- last but not least, people are used to it and why to create some comlex solution for them, if a simple one exist.

6. Eyecandy such as ground radar and wind measurement tools? Maybe they can influence safety (% of crashes) at a later stage?

I think that there should be a place to expand this - but as a second step. First step should be simple conversion of present situation to new engine. There is a plenty space for influencing the airports behavior using different improvements, some examples:
- Runway improvements
-- surface, length - limitation of aircraft aviable
-- equipment (lights, instruments) - safety improvements
-- rapid exit taxiways, LAHSO (land and hold short of procedure) - reducing time needed to vacate runway or allowing more aircraft at runway at same time
- other improvements
-- radar - allows more than one aircraft on approach at the same moment (allows generating holding stacks used in my example No.4)
-- jetways - increases speed of loading of the aircraft

But all theese should be ideas for future, as I said, first step IMHO shall be replace current static FSMs with your system of generating structure that provides some basic function and do it in a clean way.

[Dimme]

On the other hand, with "create by tiles" approach, holdings shall probably be attached to runway piece. The 4 examples I have mentioned are possible to implement flexible in code, solving the problem of creating holds automaticly without need to make some special GUI to write them or at elast simplify the GUI.

(I don't have time to answer your previous post now, but there are many interesting points.)
You may be right that one large ring is not the best, but anyway, here it is: (see also attached figure)

The system is based on tiles, for simplicity.
Runways, in this post, means only landable runways.
We here define the smallest circle a plane can take to have 8 sides with sidelengths 3 tiles, or 2 tiles*sqrt(2)=2.83 for the diagonal directions. Also assume all circular motion to be counter-clockwise.

Situation 1:
First, calculate the smallest possible holding pattern for a single runway. This defines points A_1 to A_8 (and the calculation is simple). In situation 1 there is only one runway, so this is then the holding pattern. The point L_A is the FAF and IAF points, where the decision to land is made, and from where the plane descends.

Situation 2:
1. For all runways, calculate points A_1 to D_8.

2. Then find the northernmost of A_8, B_8, C_8 and D_8, the NE-ermost of A_1 .. D_1 and so on. This determines the smallest circle that contains all the small circles. This is the holding ring, and is marked as a red circle. It has the corners F_1 ... F_8. These detemines the points where planes going to the airport will aim (in the figure, a small sector drawn by point F_3 shows which planes will choose to go to F_3. If they are inside the circle, they must first get outside.

3. Then, for all runways that has a small circle that is part of the holding ring, IAF is the final point that is part of the holding ring. Here, the planes must decide whether they will land or not. FAF is the same as before. This applies to runway A, C and D, IAFs are marked as L_A, L_C and L_D.

4. For runways where the small circle is not part of the holding circle (runway B in the fig.) it is more difficult. We must then move the small circle in the direction away from the runway, until it hits the holding ring. This can be done by calculating three points (L_B^(1) .. L_B^(3)) and choosing the closest one. I find this calculation a little hard to explain, but it involves finding the intercept with the lines that determines the outer sides of the holding ring, and choosing the inner one of these, which in fact is the holding ring. This determines L_B^FINAL as the IAF. FAF is still the point closer to the runway, to avoid hitting any mountains in the way. If the distace between IAF and FAF is large, the runway will be less efficient (unless aborted landings are allowed).

Known advantages:
The calculation is in fact quite simple, it probably involves a lot of switch or if-else statements, but it is fast (and the calculation time scales only proportionally to the number of runways).
Planes will move in an obvious pattern, with few crashes in air.
No load balancing is needed.
Can easily be expanded to include diagonal runways.
Can be expanded to allow for aborted landings (as indirectly proposed by gks)
It acts similarly to current multirunway airport. (Yes, the intercon)

Known disadvantages:
It does not look very much like in RL . I could not find use for the trick in markyParky's sit.4 either
It may be slow for large (or actually widespread) airports, but only if airspeed is slow (which I think is silly, other measures for balancing should be taken, such as increasing time spent at the gate). This does not apply if the holding pattern is thought of when the airport is designed, though.
Planes will still move on top of each other.

I hope this was understandable to most of you! Comments?

holding pattern.pdf

Figure of holding patterns for one simple, and one large (general) airport

(246.98 KiB) Downloaded 242 times

[Dimme]

The main issue is scaling. How to make a consistent system of holding patterns for a 5, 6, 7... runway airport (remember that any layout is possible, also the ones that are silly in RL). If you want several holding patterns, they cannot overlap, as that will make the system look messy. Introducing more than one holding pattern per runway makes it even more complicated.

I have an idea on how to solve the problem of a large amount of runways, but unfortunately it does not contain any of the elements you listed.

Automatic generation of holding fixes/IAFs and their assignment to runways can be a solution. These will be kind of invisible to a player, will work on the background. At present moment the best solution is to place them using my situation 2 or 3 and an algorithm for placing IAFs. This algorithm can work like this:
- there is a default position for three IAFs, that are separated and in ideal distance from FAF regarding flyingtime. If a single runway for landing is made, theese default positions are used. If two (or more) positions overlap, algorith would calculate position of new holding fix, that would be used instead all overleaping.

I have read your idea of aircraft circling the whole airport choosing first aviable runway on his way. I do not like this idea so much, as this looks very unrealistic to me.

The idea to place many holding patterns so that they don't overlap may very well be possible. Note that ideally the paths between the holding patterns and the runways and back should not cross either. That system also demands that the missed approach procedure is implemented (but that will look good anyway). It also demands a decent load balancing between the runways, and if there is a crash, all planes waiting to land on the runway must be directed to another runway.

The most realistic solution is not always the best, so I'm not sure what will be best in OTTD.

Regarding the idea of separating stations (terminals and boadring bridges) from taxiways/hangars/etc.. in my oppinion brings more difficulties in implementation than "good stuff". I think that to make this project succesfull, it has to be divided into several parts. Some of them are independent, some of them are depending on the others. These parts are following:

a] Base functionality needed to be able to build airport from tiles (how the airport will be represented in maparay and how it will be displayed)
b] Generating logical airport structure (even statemachine?) from a] using your algorithms and handling aircraft within this structure while retaining some compatibility (do not modify unneccesery too much in aircraft handling, allow backward compactiblity with old airports).
c] GUI for a] and b]
d] Adding some enhanced functionality (as eyecandy described lower)

If I think carefuly about these things, my opinion is that you don't need to split functionality of the airport and separate hangars from taxiways. If I look closer at those parts, I see following ideas:
- if you keep the airport together, everything in a] will remain station tiles of one station and it will be much easier for algorithm b] to work
- if you keep the airport together , you will not need change present aircraft handling completely - you "only" need to by able i) generate structure dynamicaly and ii) navigate aircraft through the structure using new algorithm. But IMHO you do not need to change the aircraft behavior completely. And less complex changes - more likely the solution will be done in an acceptable way to get to trunk.
- GUI has nothing to do with airport structure or internal implementation. You can still have nice and friendly GUI while keeping airport structure
- keeping airport as komplex structure also makes implementing all the fancy functionalities mentioned bellow this article easier
- last but not least, people are used to it and why to create some comlex solution for them, if a simple one exist.

This is the core stuff I'm glad that we agree that it is important to keep it simple. What remains then, is to figure out what is needed, and what can be omitted.

I agree with your numbering of what must be done, except that I think we don't need a gui at all for . IMO, everything must be automatic.
How the GUI for [a] will be, depends on what we want to do. I agree that it is not important to allow several stations on one airport. I thought maybe that it would be simpler to not support too much newgrf stuff (I know this would not be popular here in the graphics forum though ). But if it is so that "upgrading" the system later demands a lot more work, then that must of course be supported in some way.

My idea was to keep the gui familiar for those who have not played with newgrf_stations (like myself) but as long as it is intuitive, that does not matter.

One thing that I consider important, though, is that taxiways should be placed by dragging (using some kind of auto-tool), and that placing should be quick. Otherwise, players who are not perfectionists regarding how the airport looks will not like it. Other then that, the gui should be up to the person making it, and if too much newgrf support is needed, that certainly is not me (still listening to richk67 )

Firstly, then, we must decide how to store the various tiles in the map array (hoping that the intercontinental airport has not filled it up ).
When that is done, someone must create a useful gui, with the necessary support for newgrf. When that is done, I will be available to help with the rest:)

Eyecandy:
I think that there should be a place to expand this - but as a second step.

Agreed.

[That Guy]

lol I'm glad the interest is really picking up here
I made some mock graphics of taxi ways, but i still need to make block sections running east to west, and three, maybe four ways (if you guys want to include four way junctions). Take a peak and make plenty of critical comments, that way i can get it right sooner. one more thing, if it seems like the sprites aren't always lined up its because my mockup was done in Photoshop and made with layers; the actual sprites aren't off center.

Todo:
1 - E-W blocksec
2 - Three-ways and four-ways
3 - Aprons and terminal gates
4 - terminal pieces

oh by the way, has anyone thought about elevation changes? I need to know if i need to make taxiways on hills; i don't think its realistic but i thought id ask.

[Dimme]

Looks good. I like that you try to make it look realistic. I'm no graphics expert though.

I'd like four way junctions

There will also be a need for arrows (in 4 directions), to show what direction of movement is preferred. If this is difficult to do in a realistic way, we can make them visible in construction mode only. (and it may be possible to reuse the arrows for one-way roads unless you come up with something better)

No need for elevation changes. The closest I have ever seen in RL is plane elevators on aircraft carriers

[richk67]

Dalestan once posted a link to an airport that has a sloping runway... we are talking a serious gradient... almost like a skijump for aircraft!

[edit]I think it is the Mountain Air airport.

[EXTspotter]

Here is a 4-way taxiway junction

[MarkyParky]

Dalestan once posted a link to an airport that has a sloping runway... we are talking a serious gradient... almost like a skijump for aircraft!

Courchevel (CVF / LFLJ) is the most known in Europe and even operating a comercial line (with Dash-6). http://www.airliners.net/photo/-/-/1221388/M/

But regarding the conversion code itself, initialy it would be better to keep it simple and do not allow steep runways/taxiways.

[DaleStan]

Dalestan once posted a link to an airport that has a sloping runway... we are talking a serious gradient... almost like a skijump for aircraft!

[edit]I think it is the Mountain Air airport.

Swope Farm. WV11.

Somewhere I got the idea that the runway has an 11% grade, but I can't find that any more.

[YukonRob]

Somewhere I got the idea that the runway has an 11% grade, but I can't find that any more.

http://members.tripod.com/airfields_fre ... .htm#swope

Also generally grades at larger airports should not exceed 1.5% and 2% for utility airports.

[That Guy]

Here is a 4-way taxiway junction

lol thanks saved me a bit of trouble. you used the corner graphics right?

UPDATE

[richk67]

Here is a 4-way taxiway junction

lol thanks saved me a bit of trouble. you used the corner graphics right?

UPDATE

Can I suggest that you do not include the grass on the tile, but leave it transparent. That way the "grass" can be replaced with snow, desert, to make the airport climate responsive. Also, in other locations, it would be possible to have the taxiway placed over a concrete or tarmac ground tile.

Nice taxiways btw... I like them a lot.

[MarkyParky]

Yep, they are nice, only one think to mention - "yellow cross" on taxiway means "taxiway closed" in aviation, so we have to figure out different "marking" of priority

[EXTspotter]

Holding points look like this:

http://www.schofields-flying-club.com.a ... _point.jpg

Plus it has a holding point board, with the letter of the taxiway it is on and the runway direction (i.e. 09L/27R or 09R/27L like at London Heathrow, 08/26 at Exeter or Plymouth which is 13/31)

Also for a plane stand here is a good photo of one I took at Manchester (MAN) stand 215L/C/R, including all of the nose gear stops with the 767 taking me and another 280 passengers to the caribbean.

[gks]

The one from the uk planeset forum!
I suggest using two way taxiways like in jfk!