Transport Tycoon Forums

• Why there are bits for the helipads but not for the runways? In fact, can't these bits not be merged? The aircraft itself is already aiming for either HELI* or TAKEOF/LANDING, so this can be coded in the state machine.
• related: how does CHOOSERUNWAY work?, I don't seem to be able to specify a set of bits that it should check for availability of the runway.
• One step further, why does a hardcoded set of bits exist at all for terminals,
  and pads? I suspect that it comes from the desire to implement
  CHOOSE{TERM,HELIPADS}. However, that can also be coded in the state-machine as
  far as I can see, and it needs to be coded any-way in order to move the
  aircraft in the right direction.

Aydan wrote: The markers might be two four bit values designating entrance and exit point for the tile.

Alberth wrote:An aircraft travelling in the same direction may not be possible, since then you don't know when you can safely remove the bits for the direction (ie after the second plane, another one may come, you don't know).

MarkyParky wrote:I welcome any comments about airport scaling

Finaly I would like to ask one question - I noticed, that it is not possible to code an airport with more than 256 tiles. You can build 16x16 or even 15x17, but as soon as you go over 256, game crashes. This is feature or bug?

Alberth wrote:I really like your idea. It very different from my ideas.
An aircraft travelling in the same direction may not be possible, since then you don't know when you can safely remove the bits for the direction (ie after the second plane, another one may come, you don't know).

I don't understand why you need so many bits for a position. From the NewGRF
airports description, it seems that I only have bits 0x40 to 0x7A (ie 64-5 = 59
bits). With 8 bits per position, we'd run out of bits very fast.

I thought about this yesterday on the way home, and came to the conclusion that
one bit is needed for recording an aircraft at the position (to prevent an
other aircraft bumping into it), and one bit for each direction that an
aircraft may go to (and the latter only if there is a possible deadlock).

One problem that your approach doesn't seem to solve is a cycle, except with
your idea, a cycle consists of three or more positions instead of blocks.
Not sure whether this is fixable.

Another thing that needs to be addressed is the ability of testing set bits.
The NewGRF airports docs seem to allow testing for unset bits, but not for set
bits.

With respect to NewGRF airports, I have a lot of questions about them. Maybe
someone can help me to explain a few things.
(note: Below are a few (I suspect) akward fundamental questions. Please don't
feel offended by them, my only intention is to clear up unclear points and/or
to expose weak points so we can work on improving them).

• Why there are bits for the helipads but not for the runways? In fact, can't these bits not be merged? The aircraft itself is already aiming for either HELI* or TAKEOF/LANDING, so this can be coded in the state machine.

[*] related: how does CHOOSERUNWAY work?, I don't seem to be able to specify a set of bits that it should check for availability of the runway.

[*] One step further, why does a hardcoded set of bits exist at all for terminals,
and pads? I suspect that it comes from the desire to implement
CHOOSE{TERM,HELIPADS}. However, that can also be coded in the state-machine as
far as I can see, and it needs to be coded any-way in order to move the
aircraft in the right direction.[/list]

I realize that letting go of these things makes coding the state machine more
difficult. (What I am kind of asking about is a more general and simpler
implementation (less hard-coded limits), and move the hard-coded limits of bits
towards guide-lines for an airport design.)

Hence my final question. I kind of
expect that somebody has written a code generator that reads a human-readable
textual description of the state-machine, and outputs the bytes. Can I download
that somewhere?

Aydan wrote: You'd need a reference counter for that. Or maybe a reservation stack for each tile. This reservation stack would also allow planes to prereserve conflicting routes and wait their turn.

richk67 wrote: Im a bit lost following what you and Aydan are discussing. The features you want are all present already in the NewGRF Airports system. The whole block locking and release system can control the aircraft fine. If you are discussing a proposed modular airport system, then please start a new thread. At the moment I have little idea how/whether your discussion is even relevant to the NewGRF airports.

I realize that letting go of these things makes coding the state machine more
difficult. (What I am kind of asking about is a more general and simpler
implementation (less hard-coded limits), and move the hard-coded limits of bits
towards guide-lines for an airport design.)

Once there is a demand for more than 36 terminals and 24 helipads on an airport, then it may be worth considering removing the limit and implementing a different way. However, other than stupid mega-ports that are totally impractical, I dont see that even 36/24 will be reached.
The most likely limit to be reached first will be the number of custom blocks (40h-7Ah). My Munich airport uses somewhere around 40 blocks, but it is about reaching the limit of sanity. I suspect the limit may be hit when I build Schiphol, but you can always save on blocks by having larger taxiing zones.

I may write an editor in future, but if you keep your .nfo well commented, I find there is little need for dropping out of .nfo hex coding, since you will need to modify bits of it there anyway. One of the joys of .NFO ... NOT.

#         P2 -- T3
# HAN    / \                  L: landing
#    \  /   T2                F: flying holding pattern
#     P1         T1          Pn: intermediate-pos n
#       \       /           HAN: hangar
#        P3    P5            Tn: terminal n
#          \  /              ST: start take-off
#           P4 -- HET        ET: end take-off
#          /  \              SL: start landing
#        P6    P7 -- HL      EL: end landing
#        /       \           FT: flying take-off
# ST -- P8 ------ P9 -- ET  HET: heli end take-off
#  L                    EL   HL: heli landing

# end landing -> Terminal x
path types = plane,
     state = ENDLANDING, heading = TO_TERMINAL, new_state = TERMINAL,
     positions = EL(P7) P9(P7) P7 P4 P5 T1 ;

block P1P2P3P4 = P1 P2 P3 P4 ;

bit P2: AC(heli)@P7, HELIENDLANDING, heading TO_TERMINAL, [P7 T3]
bit P6: AC(plane)@P4, HANGAR, heading TO_TAKEOFF, [P2 P3 P1 P4]
bit EL: AC(plane)@P6, HANGAR, heading TO_TAKEOFF, [P6]
bit P7: AC(plane)@P9, ENDLANDING, heading TO_TERMINAL, [EL T1 ET P8 P9 L ST]

• make the entire airport 1 block (this is what the algorithm does)
• have a plane also claim P7 when landing. The rationale behind it is that having this position enables the new plane to get out of the way for outgoing planes. Also, it prevents more planes from landing. (I suspect this is what OpenTTD does, but I am not sure.)

skidd13 wrote:After a longer time of drawing abstinence I started to work on the sprites for the set again.
Here are a few ideas I'm on.

richk67 wrote:My only other wishlist item would be a double width hangar.