Transport Tycoon Forums

Please NOTE: ALL PERMISSIONS TO USE REALWORLDAIRPORTS.GRF IS RESCINDED. RealWorldAirports.GRF is not to be distributed without my permission (as author).

RichK
--------------------------------------------------------------

This is the main thread for the NewGRF (Air)ports branch: [url]svn://svn.openttd.org/branches/NewGRF_ports[/url]

The concept is to remove the hardcoded airports from OTTD, and provide them as modifiable and replaceable newgrfs, so allowing users the ability to design and include their own airports, along with specific new graphics.

Specific new features provided in this branch:
New GUI, with preview picture.
Rotateable airports (where defined)
Asymmetrical airports with holes!
Part land/part sea airports (for seaplanes)
Multi-tile depots so that a hangar can be scaled better to cross more than one tile.

State Machine changes:
More advanced block locking and releasing, including multi-block test, lock & release
Explicit Choose Terminal/Helipad commands
Force Heading command
Choose route by Minimum Runway length
Short takeoffs & landings
Allow heights to go below height of st->airport_tile (useful for seaplane airports)
Explicit z-height given in state machine position

New airports & graphics:
Use of Skidd13's airport graphics in airportsextended.grf.
New Real World Airports: La Guardia, NY; San Francisco, CA; Munich 2011, Germany
Seaplane airport

What it is NOT:
NB: It is NOT Modular Airports, and all discussion of Modular Airports in this thread is off topic, and I will ask a moderator to remove it.

Currently working on this branch are:
RichK: Main coder of airport state machines
Rubidium: Code correction, and general cleanup.
Skidd13: Graphics supremo. Creator of some wonderful new airport graphics.

Bug reports via PM to myself please, but not if it is an unfinished area. Its not really fair on me & Rubidium as developers to deal with bug reports on items that are still work in progress. It just wastes our time. If there is an issue with a completed item (see below), then yes, let us know. But asking me to explain why the Munich airport doesnt yet work, is because it aint done yet. NewGRF_ports is effectively being developed in public since anyone can download the svn, however that doesnt mean to say the public should expect a slick working product all the time. Give us the room to get on with it, please

I would not trust the results with BuildOTTD. We are messing with some of the OTTD data files, and BuildOTTD has sometimes created problems by not disabling files we had disabled. If you have built using BuildOTTD, and the error occurs before any game is loaded, that is most likely BuildOTTD missing replicating some file change. OTTD is more than just the .exe.

Current Development Status

What does work (and I think is pretty much finished):
User interface
Airport rotation
Placement mask for partial land/sea placement
"Holes" in airports
Addition of Choose Terminal, Force Heading commands
Introduction of new replacement graphics for airportsextended.grf. Basic airports will use traditional sets. 90%
Multi-tile depots

City Airport
Metropolitan (using Skidd13 replacement graphics)
Commuter - although I may add the other orientations. (with Skidd13 replacement graphics)
International
Intercontinental
Helistation
Heliport
Oilrig
Helidepot (with 4 orientations)
La Guardia (realworldairports.grf - RWA)
San Francisco (realworldairports.grf)
Seaplane airport

Minor tweaks:
Small airport - update with improvements made to Seaplane airport

Graphics OK, state machines NOT working:
-

Not really there yet... but in progress:
Munich 2011 - graphics sorted, state machine begun (and at 85 positions already, it isnt finished! City Airport has ~25 positions!)
Schiphol - basic layout worked out, but no state machine design work done.

Ideas:
Gatwick - long thin with single ultra high capacity runway, multiple landings in progress, etc. Lets see whether I can simulate BenK's normal daily routine.

When I complete an airport (to my satisfaction), I usually commit it as a Feature.

To Do: Lots
a) Noise level relative to airport size. (Already added to trunk)
b) Choose runway by length command
c) Free flight concept - once an aircraft leaves an airport, it leaves state machine control. This model will be required for other transport types, so it would be good to model here.
d) Aircraft "waypoints" - use balloon graphics, or perhaps a cloud, or something as a waypoint marker. This could organise the skies better for those who like that sort of detail. <-- An idea - may not be implemented
e) TTDP states translation, so that new state machine can trigger aircraft graphic changes ... gear up, angle down, etc.
f) Callback for choice of next aircraft position under NFO control. Triggered only when aircraft reaches an exact position, and that position is marked as "allow callback here". This would open up the possibilities for choice of terminal by cargo type, etc.
g) Review physical movement scheme. I would like to have better angled glide slopes, but its not friendly using integers.
h) Airport closure & replacement. (adapt cirdan's work)
i) Adjust balance for helicopters. Higher payments for helis. Maybe also have "luxury" aircraft type too, with its own payment rate. Thus, early aircraft can be luxury, and we can also have 20 seater executive jets paid luxury rates. (Maybe as cargo type "executives"; special passengers generated in business districts - perhaps 1 passenger in 500 in a business district).
j) Aircraft fuel consumption. Aircraft have to refuel - refuelling takes time based on distance to next airport. Cost payment for fuel added to running costs (current r.costs are regarded as maintenance. maybe only charge maintenance charge when the aircraft is serviced). If not defined, default to a flat rate "landing fee".
k) Aircraft range. Limit range to aircraft capability. If no range defined, must default to "any range" to support early aircraft newgrfs that dont define the property. Scale range across map.
Base j&k stuff on discussion in thread from zutty and CARST.
l) Any aircraft broken down will go to the nearest (capable) airport hangar. (Im even considering allowing emergency landings at opponents airports. Call it CAA/FAA rules ) Broken down aircraft get landing priority always.


Phase II
Extend concept to docks. Make ships enter state machine for handling in docks. Whole ship movement needs looking at.

Phase III
Extend concept to road vehicles.

If you have any nice ideas, I'm happy to look at them.

I am realy interested in this stuff, so I will take a closer look and than pick up some airport and try to help.

Ooh...

Do you have any (even simple) alpha/beta patch of GRF loading for testing if the conversion is done correctly?

Hey, I'm the developer of the aircraft queuing patch, and my latest version includes some modifications of the airport state machine - so I'm familiar with that area of the code. I'll take a look and see what I can do.

No guarantees, though - I'm looking for a job in real life, and getting a job means less free time.

MarkyParky wrote:Do you have any (even simple) alpha/beta patch of GRF loading for testing if the conversion is done correctly?

Chicken and egg problem. I will use the spec and my commuter airport translation to aid in writing the FSM loader. It is only a minor part that it loads. That it then works after that is down to what the states commands do, which is why I need the side-by-side comparison to verify that the translation looks ok.

After that, it will be down to hours of debugging, and maybe redesigning some of the airport state machines to work within the new system. Making old games loadable (mandatory) will be quite tricky, translating old states etc into new newgrf locations.

To see what the current system can do... ie. without any state machine loading at all, checkout the svn://svn.openttd.org/branches/NewGRF_ports branch.

Over here you can find copies of NFORenum[0] (which I assume behaves) that can check airport action 0s, and confirm that they have the proper format. It won't confirm that they're logical, but it will confirm that they have an appropriate number of bytes.

[0] win32 and i486 Linux binaries, patch, and source archive. The documentation lives with the official distributions.

I thought so . I am trying now to understand how the statemachine works and meaning of those headings and states and as soon as I will understand I will start some airport translating.

Hmm ... well, I have not read the specs, but wouldn't it be possible to make a program that will convert the machines automatically? It may be simpler and more error-prone than doing it by hand ...

As far as I have looked no, because:

a) You need to parse code containing small diferences easily recognisable by human, but hardly by script
b) It is not 1:1 conversion, it is more likely "making the new structure behaving the same way like the original one does".

Bilbo wrote:Hmm ... well, I have not read the specs, but wouldn't it be possible to make a program that will convert the machines automatically? It may be simpler and more error-prone than doing it by hand ...

LOL - I think you mean *less* error prone

As markyparky says, it will be close, but does need a human touch. Some of it is not that easy to convert. It may be able to make a reasonable stab, almost making a template of it.

It does make sense though to make a small utility to convert these over, even if they then need lots of human review. I can then provide it with the current definitions, and it can do the replacements. That will then be a start point.

I have several unreleased airports - one of which has 85 positions, with complex block lockings. I dread to think how horrid that will be to convert!

One of the thoughts Celestar and I discussed early on in this project is putting together a small utility where you can create a finite state machine, and it would spit out the NFO code. I would only code it for Windows, though, as it would be principally for me to use. I would of course let other interested parties have the source to modify it for their platform.

Looks like Im doing some coding tonite.

richk67 wrote:

Bilbo wrote:Hmm ... well, I have not read the specs, but wouldn't it be possible to make a program that will convert the machines automatically? It may be simpler and more error-prone than doing it by hand ...

LOL - I think you mean *less* error prone :)

Oops, typo :)

richk67 wrote: As markyparky says, it will be close, but does need a human touch. Some of it is not that easy to convert. It may be able to make a reasonable stab, almost making a template of it.

It does make sense though to make a small utility to convert these over, even if they then need lots of human review. I can then provide it with the current definitions, and it can do the replacements. That will then be a start point.

I have several unreleased airports - one of which has 85 positions, with complex block lockings. I dread to think how horrid that will be to convert!

Yes, if the FSM in the openttd source changes, you won't need to do the whole process again ... if you have some utility to doit for you or at least help you with it.

Bilbo wrote:Yes, if the FSM in the openttd source changes, you won't need to do the whole process again ... if you have some utility to doit for you or at least help you with it.

Once this project completes, the current openttd source FSMs will be removed, and OTTD will by default include the "standardairports.grf" for all older games. Translating between old and new will be... errr.... fun.

There will be some updates to the spec. Ive already pretty much decided that prop 09 should be exactly as all other Action0s, and that its orientation feature is moved within prop 0E layouts. So changes are afoot. Its a dev project after all

OK, Ive coded a small utility that takes the existing state machines and spits out the appropriate NFO code. It occurred to me that a number of items need to change in the spec; mainly that the OTTD flags (eg. AMED_BRAKE, etc.) need to be fully stored in a 16bit word rather than the tight 8bits. No room for expansion.

It also occurred to me that AMED_LAND, AMED_TAKEOFF, AMED_HELIRAISE, and AMED_HELILOWER, can be best achieved by use of the Z parameter changing.

The Z parameter actually opens up the possibility of having flight levels, spiralling holding stacks, shallow angle landings, etc. For heli takeoffs, the state would be HELITAKEOFF, and the target Z parameter would be say, 64. On the previous FSM position, it would pick up its target X,Y, and Z, by looking up the details in the next_pos position. So given a target with a Z > current, and a next_pos->state of HELITAKEOFF, it would spin up the rotors and play the takeoff sound.

Similarly, on a LANDING heading, the Z parameter would change from its flying level, say 80, to a target next_pos->Z of 0. When the current Z reaches 0, and the state LANDING is reached, the wheels would make their landing squeal noise.

will it be possible to have different holding patterns for different types of airplane like prop,jet,heli and also designated runways for slower/faster aircraft?

You can already do the alternative holding patterns for helis & aircraft. Its just a matter of where you direct the vehicle at the initial FLYING state. The current airports dont make use of it, but I have 3 new ones in development that do use quite different holding patterns.

As for short landings and takeoffs, this new system does allow for them, where you can use SMALLTAKEOFF as a heading. It will need programming that if a TAKEOFF is found, but you are looking for SMALLTAKEOFF, that the small aircraft regards it as a takeoff. The restriction will be that given a list of possible routes, the SMALLTAKEOFF command must appear before the TAKEOFF one. This way a small-takeoff capable aircraft will choose the SMALLTAKEOFF first, but if it cannot due to a block fail, or if it isnt a short-takeoff capable aircraft, it will try the TAKEOFF command instead.

In my Real World Airports patch (not released), all small-airport capable aircraft will takeoff 1-2 tiles earlier than their big brothers.

Wow, you've already got a lot of stuff planned . If this gets into the trunk, I'd have to rewrite portions of my aircraft queuing patch.

I do recommend leaving some room for flexibility, as you never know what people may add to it . My own patch adds an extra state and block for the descent phase of landing, so that an aircraft can be in a position to land by the time it enters the landing state. It also gives the impression of an "emergency abort" because if the runway block is full, the aircraft will go back to the holding pattern and return to the flying state.

One thing that really annoys me about the current airports is that right after landing aircraft will often rotate right to turn left. Not only is it annoying visually, but it also adds a small amount of time between when the aircraft is landed and when it leaves the runway. It may not seem like a long period of time, but it drastically reduces the throughput of the airport because the next aircraft can't even begin landing until the runway is clear.

One thing to note about airports: In real file, the scale is very, very different - I've seen airports dwarf small towns, and the time between landings in real life is more than enough for an aircraft to taxi off the runway. The taxiways in real life are also long enough to accommodate many aircraft, and often parallel the entire length of the runway - which itself is likely to be a hundered times the length of the aircraft.

IMHO, the scale in OpenTTD is itself a pretty big limiting factor affecting the throughput of our airports. Perhaps doubling their size may help?

Some images of real airport layouts:
http://images.google.com/images?q=airpo ... s&ct=title

CobraA1 wrote:I do recommend leaving some room for flexibility, as you never know what people may add to it .

My own ideas for a newgrf statemachine used a callback for the pathfinding and for the locking/unlocking of paths, which made it extremely open-ended.

CobraA1 wrote:...the time between landings in real life is more than enough for an aircraft to taxi off the runway. The taxiways in real life are also long enough to accommodate many aircraft, and often parallel the entire length of the runway - which itself is likely to be a hundered times the length of the aircraft.

Hmmm... At work, when its busy, I will be moving 1 aircraft per minute, either take-off or landing. Also, many places do have parallel taxiways, yes, and holding points next to the runway too. Do remember though, that there are many which don't, and some fairly large airports still have to 'backtrack' some aircraft down the runway.

I'm not sure if this has been proposed before, but a fantastic system for airports would be a "build your own". Basically you get single tile pieces to put together into your own design that could grow with demand. Tile pieces could be runways, taxi ways, terminals, hangars, radars and control towers (needed for bigger aircraft). The state machine would then be generated from the tiles you placed.
This is obviously an audacious scheme, but one that could co-exist with the current airports.