[NewGRF] New Airports

[Darkvater]

To me, this is PBS. Two vehicles entering the signalling block, as long as their paths do not overlap. And very simply done with a bitmapping.

That is not PBS and even in PBS it would be impossible. All that needs is the splitting up the large middle-block into smaller ones and it already works. No PBS needed.

First, is that code correct, to the extent that it is provided? If not, please correct it; I believe the intended behaviour should be readily apparent.
Assuming that code is correct, when an aircraft leaves the hangar, one of AirportFindFreeTerminal or AirportFindFreeHelipad is called, according to the aircraft's type.
First let us consider airplanes. Assuming all three of TERM_GROUP_n_block are reserved, what happens? Does AirportFindFreeTerminal fail (and if so, please enlighten me as to which code controls that; I could not find it), or does AirportFindFreeTerminal go on to entry 4?
Repeating this procedure for AirportFindFreeHelipad: Does it skip entries 1..3, as it should, and begin with entry 4 (same "which code" question), or does it start with entry 1?

The code is correct (well it works, doesn't it? ).
The workings are explained in the code in AirportFindFreeTerminal(). AirportFindFreeTerminal succeeds if a terminal is free. If you have more groups it succeeds it the group-check-block is free and a terminal is free. If this is not the case it checks all other groups (which are on the same line of the FTA), otherwise it fails.

So in your example if all blocks are used (1-3), AirportFindFreeTerminal() fails and the plane remains in the Hangar.

Ah wait I get your question now: the above is valid partly. But with heligroup and term-group mixed through eachother, the airplanes will also check 4 and 5. So with the current state of the code things would go pretty bad

[richk67]

To me, this is PBS. Two vehicles entering the signalling block, as long as their paths do not overlap. And very simply done with a bitmapping.

That is not PBS and even in PBS it would be impossible. All that needs is the splitting up the large middle-block into smaller ones and it already works. No PBS needed.

I hope you took into account I was using the City airport as a block illustration, not intending to replace the currently working City airport, nor in any way criticising it. In no way am I suggesting using the PBS engine, etc, etc. (Wish I had never made the ANALOGY).

What do you call PBS then (the concept, not the buggy code)? As I said, AFAIK - and please correct me if I am wrong, PBS allows 2 vehicles to enter a controlled block as long as their paths do not cross. OK it does a whole load of destination calculations, but it still looks at a bit pattern (in the landscape data), and reserves the bits it needs.

OK, if you want to call my system Aircraft Navigation Access Lines , then that will take away all the railway overtones. Its the same principle.

I think this would be a powerful, and simple addition. Dalestan's system works, but does it in a more complex fashion (IMO). Reserving single blocks does work, but being able to test & reserve multiple blocks I think would aid in complex airport design. The *current* airports dont need it, but I could code them in less instructions with my multiple block idea.

[edit]removed whinge... Im calmer now

[richk67]

Idea: Change <check-block> to a single byte (check that block, or no block if it is FF), except that if the byte is FE, read the check instructions from the following bit-field (width to be determined sometime) instead?

Actually, hopefully simpler than that.... have a list of blocks_to_reserve. So if byte is FE, read each following byte as a required block until the next FE (or whatever) is reached.
So a single block is one byte: eg. 04
Two blocks is 4 bytes: FE 04 06 FE
Five blocks (my example) is 7 bytes: FE 0F 10 11 07 02 FE (15,16,17,7,2)
This keeps the data shorter, but is pretty easy to parse/interpret/encode.

And I haven't yet seen an airport layout that requires airport-PBS. No point in designing support until it is needed.

Which is why we are having to heavily recode airports now... because no future designing was built in to cope with > 31 blocks, >6 terminals, and >2 helipads. IMO it is always a good idea to design future support if it can be done easily now.

Using the above block-list, you can have as many or as few blocks requested and reserved. If someone (ermmm me ) wants to reserve more than 1 block for the movement, let them. The additional complexity to us is trivial now, but may be a major headache in the future.

All blocks not assigned to a terminal/helipad are generic blocks. The current international airport uses what? 22 blocks for 8 total pads? If the relationship is linear, then 32 pads (22 terminals and 10 helipads, maybe?) would require a total of 88 blocks, which is painfully close to that rather arbitrary 96 block limit.

I dont think its linear - it should diminish hopefully. Larger taxi blocks, larger terminal groups, not necessarily lots more blocks (hopefully!).

I would definitely add a "medium" size in there as well.

What meaning would "medium" have? Aircraft come in three types.

D'oh!! Brainfailure imminent, reboot?

Prop 1D sets the types of aircraft that can land here:
00 : airplanes only
01 : all (default)
02 : choppers only

I think a better structure for this is to just have a set of bits:
Bit 1: large airplanes
Bit 2: small airplanes
Bit 3: helicopters
Bit 4: airships (so we can make special airports for them)

Airships are choppers in every way that matters. Including the fact that they have rotors.

An airship airport may be some strange structure at which a normal helicopter cannot land. IIRC some skyscrapers had docking towers, and extended gangways up to the cabin. (No WAY would I personally use such a thing. I have bad enough vertigo as it is!!)

[edit] OK, just found this. But who said OTTD had to be 100% realistic http://www.esbnyc.com/tourism/tourism_f ... ly2000.cfm

And this would allow the rather illogical arrangement of an airport that permits large airplanes to land, but not small ones. Personally, I don't even like the the concept of an airport where choppers are not allowed to land.

Although it allows that illogicality, it should be that if the large airplanes flag is set, this overrides/ignores the small planes flag. So you can have airports where only small planes will land, and larger ones will skip.

Now that I think about it some more, I am considering just stripping this property entirely, and saying "The user is responsible for not sending airplanes to heliports." The main purpose of this property is for preventing the user from sending an airplane to a heilport.

Obviously for German WWII experimental aircraft

However, you can't prevent the user from building an airport, issuing orders, and then replacing the airport with a heliport, and since that defeats what is basically this property's only function, I guess I don't much see the point in having it.
I put it in because it existed elsewhere, but that's not always a very good reason.

Might be that they have thought of something we have missed, but dunno. I'd be ready to code it back in when we discover 747s trying to land at oilrigs!

[DaleStan]

What do you call PBS then (the concept, not the buggy code)? As I said, AFAIK - and please correct me if I am wrong, PBS allows 2 vehicles to enter a controlled block as long as their paths do not cross. OK it does a whole load of destination calculations, but it still looks at a bit pattern (in the landscape data), and reserves the bits it needs.

But there are separate bits for the separate rail-pieces. On an airport, there's only one bit per block. If you want multiple non-interfering paths through a single block, then you have to split it into multiple blocks, otherwise you won't have the necessary additional bit(s).

Splitting TAXIWAY_BUSY_block into TAXIWAY_BUSY_1_block (positions 7 and 2) and TAXIWAY_BUSY_2_block (positions 1, 5, 6) would require that a plane from the hangar or terminals 2 or 3 be able to reserve both of TAXIWAY_BUSY_2_block and TAXIWAY_BUSY_1_block, and then suppress the TAXIWAY_BUSY_1_block check when moving from position 6 to position 7. This is possible in the current format.

However, the plane would also have to check OUT_WAY_block. (It could reserve or not; either way would work.) This is not yet possible. But it does demonstrate that such power is needed.

I think this would be a powerful, and simple addition. Dalestan's system works, but does it in a more complex fashion (IMO).
I have no particular desire to recode the airport system to replace one complex system, with a similar complex system with complex coded data. This is only worth doing if it is *simpler*.

Unfortunately, you cannot increase power without increasing complexity, nor can you reduce complexity without reducing power. (ACME::DWIM notwithstanding)

Current scheme is just a differently coded way of doing the same things - and is less legible.

That's the first objective. Produce a new format that can do what the current format can do. Then you adding things that the current format cannot do: more than 6 terminals, more 2 helipads, helipad groups and terminal groups at the same airport, more than 31 blocks, checking/reserving multiple blocks in one go, positions with different Z values at the same airport, &c.

It should not be too difficult to change AirportFTAClass_Constructor to generate props 17, 19, 1A from something that closely resembles the current state machine format, but I'm not sure that particular exercise would be worth wile.

Idea: Change <check-block> to a single byte (check that block, or no block if it is FF), except that if the byte is FE, read the check instructions from the following bit-field (width to be determined sometime) instead?

Actually, hopefully simpler than that.... have a list of blocks_to_reserve. So if byte is FE, read each following byte as a required block until the next FE (or whatever) is reached.
This keeps the data shorter, but is pretty easy to parse/interpret/encode.

Done. Except that I'll use FF as the terminator, so that block FE can still be checked (using FE FE FF). And, under most reasonable circumstances, this should still be shorter than specifying the full field.
I propose that the use of the FE * FF format suppress the implied "check and reserve <next>'s block", and that FE FF be reserved later use. Most likely for "call the block checking and reserving callback", if/when that gets spec'ed.

All blocks not assigned to a terminal/helipad are generic blocks. The current international airport uses what? 22 blocks for 8 total pads? If the relationship is linear

I dont think its linear - it should diminish hopefully. Larger taxi blocks, larger terminal groups, not necessarily lots more blocks (hopefully!).

I don't really know what it is; I just guessed that linear would be somewhat reasonable.
I just just ran some regressions, with the five current airports as data points, and a linear regression fits pretty well. However, running any statistical analysis on only five data points will rarely produce good results, especially when trying to extrapolate two data-ranges beyond the given data, so I won't bother with quantitative results.

Adding a single pad has to add a minimum of one block (this should be obvious). This means that MIN_BLOCKS is at least O(pads), but really isn't significant for small numbers of pads.

[DaleStan]

It seems to me that this should be relatively easily extensible to larger RV bays. Possibly realistically-sized ship docks too; the same FTA system should not have trouble moving RVs and ships around.

A few bits of <flags> would obviously have to be undefined or redefined in such contexts, but that doesn't seem like it should pose a major problem.

Format version 3: Additions and changes are marked in bold, removals are marked in red


Prop 16 contains the feature of the vehicles that will use this station, default is 00. (Currently only 00 and 03 are supported)


Prop 17 defines airport movement data and the state machine. It is variable-lengthed and formatted as follows:
<num-pos> <pos-data>...

<num-pos> is a byte.

<pos-data> is variable-length and repeated <num-data> times.
The <pos-data> corresponding to the hangar(s), if any, must be the first entries in the <pos-data> array, and must correspond to the hangar locations given in prop 19.

It consists of:
<X> <Y> <Z> <flags> <block> (<next-info>)*

<X> and <Y> are words, interpreted as signed integers. They are the X and Y locations of this postion relative to the north corner of the airport. (A tile is 16 (10h) units in each direction.)

<Z> is a byte, as an unsigned integer, giving the height above the ground for this position. One landscaping level is eight units. Aircraft in flight ignore this setting. The default for heliports is 3C and for oil rigs is 36. This is intended to allow placing a helipad on top of a building while still allowing other things at ground level in the same airport.

<flags> is a word, formatted as follows:
The high nine bits are flags:
07 : Movement for current state (possibly) completed; call the state handler for the current state.
08 : Do not clamp speed to taxiing limit.
09 : This is an airplane take-off location.
10 : Aircraft must wait several ticks prior to turning in this position.
11 : This is an airplane landing location.
12 : Force aircraft facing.
13 : Play the airplane brake noise when switching to this position.
14 : This is a helicopter take-off location.
15 : This is a helicopter landing location.

(bits 9..15 map to the AMED_* constants.)

If bit 12 is set, the low three bits specify the direction that the aircraft is turned to face upon reaching this position.

<block> is a byte, indicating which block this position is a part of. Block FF may have any number of aircraft in it at any one time; all others may have at most one at a time. If <block> is the controlling block for a single terminal or helipad, it must have the same value as the <heading> for going to that terminal/helipad. All other block values may be used in any way you desire.

<next-info> is three bytes, in one of the two following formats:
1) <heading> <check-block> <next>

<heading> is a byte.
If heading is in 00..3F, it specifies the number of the terminal this aircraft is going to.
If heading is in 40..7F, the low 6 bits specify the number of the helipad this chopper is going to.
(Yes, airports can have up to 64 each terminals and helipads. This should be sufficient for most purposes.)
The following special values are also available:
80: HANGAR -- Aircraft is going to a hangar, or if at a hangar, enters it for servicing. (Next: TAKEOFF, HELITAKEOFF, TERMn, HELIPADn) [0][1]
81: TAKEOFF -- Airplane is headed for the runway for takeoff. (Next: STARTTAKEOFF_*)
82: STARTTAKEOFF -- Airplane is accellerating down the runway; (Next: ENDTAKEOFF) [4]
83: ENDTAKEOFF -- The aircraft is rising into the air. (Next: none; enters state machine of next airport, with state FLYING)[2]
84: HELITAKEOFF -- Like TAKEOFF, but for choppers. (Next: ENDTAKEOFF)
N/A: FLYING -- The aircraft is in the air, headed for its next order. (Next: LANDING, HELILANDING) [3]
85: LANDING -- The airplane wants to land. (Next: ENDLANDING)
86: ENDLANDING -- The airplane is rolling down the runway, and will come to a stop at the end. (Next: HANGAR, TERMn) [0][4]
87: HELILANDING -- Like LANDING, but for choppers. (Next: HELIENDLANDING)
88: HELIENDLANDING -- Like ENDLANDING, but for choppers. (Next: HANGAR, HELIPADn, TERMn if no helipads) [0][1]
89: HELIENDTAKEOFF -- Like ENDTAKEOFF, but for choppers. (Merged with ENDTAKEOFF)
89: STARTTAKEOFF_SMAll -- The version of STARTTAKEOFF used for small planes.
8A: STARTTAKEOFF_LARGE -- The version of STARTTAKEOFF used for large planes.
8B: ENDLANDING_SMALL -- The version of ENDLANDING used for small planes.
8C: ENDLANDING_LARGE -- The version of ENDLANDING used for large planes.
FF: ELSE -- All headings not previously mentioned (also used to mark the last <next-info> entry)
Note that the next information only applies if bit 7 of <flags> is set. If it is clear, the state will not change, and the action associated with that state (eg servicing at the hangar, loading/unloading at a terminal, &c.) will not happen.

[0] These states have TERMn nexts, and should have terminal selection instructions if multiple terminal groups exist and bit 7 of <flags> is set.
[1] These states have HELIPADn nexts, and should have helipad selection instructions if multiple helipad groups exist and bit 7 of <flags> is set.
[2] This is currently the machine exit state. To guard against additional states being added, <next-info> should be be FF FF <cur-pos>, that is "Always return here" or a duplicate entry at the same position with except with a <flags> of 0080h should be added, and that position should have the "Always return here" loop.
[3] No plane will ever query the state machine in the FLYING state; it will update to LANDING or HELILANDING first, and return to FLYING if it did not find an acceptable landing location.
[4] These are pseudo-states. No aircraft will ever arrive in either of these states, but they are useful for catching both of STATE_SMALL and STATE_LARGE.

<check-block> is one of
A) A single byte, specifying a block ID. If <check-block> matches <next> -> <block>, no block-reservation checks are performed. Otherwise, both <next> -> <block> and <check-block> must be clear for the plane to proceed. (As in <block>, block FF may contain any number of planes and is therefore always clear.) If both are clear <next> -> <block> is reserved.
B) The byte FE, followed by an FF-terminated list of blocks to check. If all are clear, all are reserved.
C) FE FF -- reserved. Use the single byte <next> -> <block> if you need to specify "check no blocks".

2) <type> <check-block> <group> (Select terminal/helipad from group)
<type> is a byte, either FE (terminal selection) or FD (helipad selection).

The aircraft needs to know what terminal to go to. If <check-block> is clear, select the first free terminal from <group> (terminals are assigned to groups by prop 1A), and then return to this position with the selected heading. If <check-block> is occupied, or no free terminals exist in <group>, continue to the next terminal selection, or wait in this position if no more selections exist.
These may be specified anywhere in the <next-info> list.

These entries are used when provided and bit 7 of flags is set, but are not necessarily useful if the airport has only one group of the relevant type. The *ENDLANDINGs should contain <*ENDLANDING> FF <self-pos> entries to keep the state machine here until it wakes up to the fact that it needs to select a terminal. [mistaken content generated by misinterpretation of the FTA code]


Prop 18 functions as prop 0A and 0F, but copies prop 17 instead.


Prop 19 sets the hangar postion(s). It consists of a byte specifying the number of hangars, and then that many <X> <Y> pairs (both bytes, as unsigned integers) giving the (X,Y) tile offset of each hangar from the north corner of the airport.


Props 1A and 1B set the number of terminals and helipads in each terminal/helipad group, respectively:
<num-in-group>* 00
<num-in-group> is a byte, and is repeated until a 00 is encountered.
The sum of all <num-in-group> for each property must not exceed 64.

The <heading>s 00..7F (in prop 17) are assigned by these properties; 00/40 to the first item in the first group, 01/41 to the next item in the first group or the first item in the next group, &c.


Prop 1C is a byte which sets the airport type (small/large/heliport) for the purposes of LA build permissions, crash probablilty, and vehicle variable 44. Oil rig (03) exists internally, but may not be set by .grf files.

Prop 1D sets the types of aircraft that can land here:
00 : airplanes only
01 : all (default)
02 : choppers only

Prop 1D is two bytes; the first being the entry position for airplanes, and the second being the entry position for choppers. Must be set properly for both types, even if one type cannot land here. (This airport could be a replacement for an airport where that type could land.)


Prop 1E sets which tiles are animated:
<num-animated-tiles> (<X> <Y>)...
The tile at each (<X>,<Y>) is redrawn every tick. Callback 14 is also called to determine which sprite arrangement to use for this tile.


To control which aircraft types can land at this airport, code the state machine (prop 17) appropriately.
If a distinction between choppers and airships becomes necessary, an additional value will be added to airplane prop 09, and and s/HELI/AIRSHIP/ states will be added.


Properties 08, 09, 0A, 0B, 10, 12, and 13 function as for rail stations, except that bit 1 of prop 0B must be set.
Properties 0C, 0D 0E, 0F, 11, and 14 are meaningless (and ignored) in the context of airports.

Callback 13 works as for rail stations.
Callback 14 works as for rail stations, but may also return 100h to indicate "Build no tile here."
Callback 3C (no action 0 bit) is called whenever a plane in the TAKEOFF or LANDING states selects a new position, and whenever a plane is given an order to this airport.
Variable 10 is formatted as follows:
xxxxxxpp
pp is a position from property 17, the value given as the first byte of prop 1D if an order was added. The other bytes are reserved.

The return value is the length of the longest runway accessible from the given position.
If the plane is in the air and no free runway is long enough, it circles.
If the plane is on the ground and there is no long enough runway accessible from the current position, the plane goes to the hangar and stops.
If the plane is on the ground and there is a long enough runway accessible from the current position, but no entries can be followed (because the runway is too short or <next>'s block is reserved), the plane waits in its current state until a sufficiently long runway clears.
This callback may also be called for position 00 when a plane is checking to see if it can safely visit this airport for servicing.
When called for position 0, a return value of zero also means that this airport has no runways, and that airplanes cannot be built in its hangar(s).
If this callback fails, the value of prop 1C is used to generate a default.

Actions 1..3 work as for rail stations.
Action 4 works as for rail stations for C5xx IDs, and possibly for the C4xx IDs.

The third byte of vehicle variable 44 will have at least the following distinct (and airport-independent) values:
- In hangar
- On a pad
- Taxiing
- Taking off
- Landing
- In flight

The high byte of vehicle variable 44 will contain the <Z> value for the current position.

[Blackandy]

We would need a big airport like we have here. I has 1 runway(we should atleast have 2 . And it has 8 of the loading points so buses have to drive the passengers to the terminals. So then they gotta go via bus or car. But our biggest airport isn't near any houses.

Here's a pic:

[Baxtrey]

Hello, I hope you are well, I would like to know how I can turn this airport design into a functional newGRF for the game? This design was taken from a user who made the airport, that patch has different airports but until now no one has been able to pass it to a new GRF I would like but unfortunately I do not understand how to do it especially with the language barrier, I know some English but not so advanced to understand many instructions and the translator suffers from making mistakes when translating into Spanish.

http://imgfz.com/i/BmgxWrt.png

[kamnet]

Hello, I hope you are well, I would like to know how I can turn this airport design into a functional newGRF for the game? This design was taken from a user who made the airport, that patch has different airports but until now no one has been able to pass it to a new GRF I would like but unfortunately I do not understand how to do it especially with the language barrier, I know some English but not so advanced to understand many instructions and the translator suffers from making mistakes when translating into Spanish.

http://imgfz.com/i/BmgxWrt.png

It cannot be made into a functional airport. There is currently no way to create a modular, user-designed airport. The proposal here was never developed into a functional patch or integrated into OpenTTD.

[Baxtrey]

Hello, I hope you are well, I would like to know how I can turn this airport design into a functional newGRF for the game? This design was taken from a user who made the airport, that patch has different airports but until now no one has been able to pass it to a new GRF I would like but unfortunately I do not understand how to do it especially with the language barrier, I know some English but not so advanced to understand many instructions and the translator suffers from making mistakes when translating into Spanish.

http://imgfz.com/i/BmgxWrt.png

It cannot be made into a functional airport. There is currently no way to create a modular, user-designed airport. The proposal here was never developed into a functional patch or integrated into OpenTTD.

To use it you have to download the file and play it directly from there and not from the app that is downloaded directly from the Openttd page.

It really is a good airport, its capabilities far exceed the intercontinental, I have been reading something to see if I can understand a little more about how to pass that airport to the official games, but I do not know much, and I have been reviewing many topics for that, because I think if a group worked or at least explained me in depth, I could do it.

[kamnet]

To use it you have to download the file and play it directly from there and not from the app that is downloaded directly from the Openttd page.

I see the other post that you've now made, and now I understand your request better.

I have been reading something to see if I can understand a little more about how to pass that airport to the official games...

At this time, you it is not possible to do that. To do so you would have to first patch the game (which is what Terminus Airport is, a modification to the default game), and then have that patch be accepted by the game developers. OpenTTD developers have neither accepted Terminus Airport patch or the NewAirports patch as acceptable code.

[Baxtrey]

To use it you have to download the file and play it directly from there and not from the app that is downloaded directly from the Openttd page.

I see the other post that you've now made, and now I understand your request better.

I have been reading something to see if I can understand a little more about how to pass that airport to the official games...

At this time, you it is not possible to do that. To do so you would have to first patch the game (which is what Terminus Airport is, a modification to the default game), and then have that patch be accepted by the game developers. OpenTTD developers have neither accepted Terminus Airport patch or the NewAirports patch as acceptable code.

I understand, but developers should inform or give us some guidelines to make patches acceptable codes. When you test airports are efficient, better than what is official, I mostly when I play I like to focus on airplanes, since they are the hub of my companies and they are what makes me the most money, but the intercontinental, at 45 or more aircraft is obsolete.

What happens is that the patches suffer from leaving the game and it gives me an emergency save, although if you know any way to solve that, it would help me a lot.

[kamnet]

I understand, but developers should inform or give us some guidelines to make patches acceptable codes.

That's why we have the development forums here, with 15 years of writing, recommendations, tips and feedback from developers.