NewGRF (Air)ports - general discussion

Forum for technical discussions regarding development. If you have a general suggestion, problem or comment, please use one of the other forums.

Moderator: OpenTTD Developers

Locked
richk67
Tycoon
Tycoon
Posts: 2363
Joined: 05 Jun 2003 16:21
Location: Up North
Contact:

NewGRF (Air)ports - general discussion

Post by richk67 » 18 Jul 2007 10:59

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.
Attachments
NewGRFAirports.zip
Current NewGRF ports spec.
(15.77 KiB) Downloaded 3417 times
SanFran.png
San Francisco - asymmetrical airport with holes
SanFran.png (40.78 KiB) Viewed 38154 times
Slondinghall Transport, 27th Jun 2004.png
Some new graphics
Slondinghall Transport, 27th Jun 2004.png (37.24 KiB) Viewed 38152 times
Last edited by richk67 on 02 Sep 2008 10:01, edited 14 times in total.
OTTD NewGRF_ports. Add an airport design via newgrf.Superceded by Yexo's NewGrf Airports 2
Want to organise your trains? Try Routemarkers.
--- ==== --- === --- === ---
Firework Photography

MarkyParky
Engineer
Engineer
Posts: 89
Joined: 20 Nov 2003 15:20

Re: Help Wanted... its a dirty job, but someone's gotta do it...

Post by MarkyParky » 18 Jul 2007 11:53

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

User avatar
PikkaBird
Graphics Moderator
Graphics Moderator
Posts: 5382
Joined: 13 Sep 2004 13:21
Location: The Moon
Contact:

Re: Help Wanted... its a dirty job, but someone's gotta do it...

Post by PikkaBird » 18 Jul 2007 16:01

Ooh... :P

MarkyParky
Engineer
Engineer
Posts: 89
Joined: 20 Nov 2003 15:20

Re: Help Wanted... its a dirty job, but someone's gotta do it...

Post by MarkyParky » 18 Jul 2007 18:51

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

CobraA1
Route Supervisor
Route Supervisor
Posts: 480
Joined: 07 Nov 2003 17:52
Location: USA

Re: Help Wanted... its a dirty job, but someone's gotta do it...

Post by CobraA1 » 18 Jul 2007 18:56

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.
"If a man does not keep pace with his companions, perhaps it is because he hears a different drummer. Let him step to the music he hears, however measured or far away" --Henry David Thoreau

richk67
Tycoon
Tycoon
Posts: 2363
Joined: 05 Jun 2003 16:21
Location: Up North
Contact:

Re: Help Wanted... its a dirty job, but someone's gotta do it...

Post by richk67 » 19 Jul 2007 00:45

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.
OTTD NewGRF_ports. Add an airport design via newgrf.Superceded by Yexo's NewGrf Airports 2
Want to organise your trains? Try Routemarkers.
--- ==== --- === --- === ---
Firework Photography

DaleStan
TTDPatch Developer
TTDPatch Developer
Posts: 10285
Joined: 18 Feb 2004 03:06
Contact:

Re: Help Wanted... its a dirty job, but someone's gotta do it...

Post by DaleStan » 19 Jul 2007 01:31

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.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser

MarkyParky
Engineer
Engineer
Posts: 89
Joined: 20 Nov 2003 15:20

Re: Help Wanted... its a dirty job, but someone's gotta do it...

Post by MarkyParky » 19 Jul 2007 08:48

I thought so :wink: . 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. :lol:

User avatar
Bilbo
Tycoon
Tycoon
Posts: 1710
Joined: 06 Jun 2007 21:07
Location: Czech Republic

Re: Help Wanted... its a dirty job, but someone's gotta do it...

Post by Bilbo » 19 Jul 2007 15:53

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 ...
If you need something, do it yourself or it will be never done.

My patches: Extra large maps (1048576 high, 1048576 wide) (FS#1059), Vehicle + Town + Industry console commands (FS#1060), few minor patches (FS#2820, FS#1521, FS#2837, FS#2843), AI debugging facility

Other: Very large ships NewGRF, Bilbo's multiplayer patch pack v5 (for OpenTTD 0.7.3)

MarkyParky
Engineer
Engineer
Posts: 89
Joined: 20 Nov 2003 15:20

Re: Help Wanted... its a dirty job, but someone's gotta do it...

Post by MarkyParky » 19 Jul 2007 16:06

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".

richk67
Tycoon
Tycoon
Posts: 2363
Joined: 05 Jun 2003 16:21
Location: Up North
Contact:

Re: Help Wanted... its a dirty job, but someone's gotta do it...

Post by richk67 » 19 Jul 2007 16:11

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.
OTTD NewGRF_ports. Add an airport design via newgrf.Superceded by Yexo's NewGrf Airports 2
Want to organise your trains? Try Routemarkers.
--- ==== --- === --- === ---
Firework Photography

User avatar
Bilbo
Tycoon
Tycoon
Posts: 1710
Joined: 06 Jun 2007 21:07
Location: Czech Republic

Re: Help Wanted... its a dirty job, but someone's gotta do it...

Post by Bilbo » 19 Jul 2007 16:16

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.
If you need something, do it yourself or it will be never done.

My patches: Extra large maps (1048576 high, 1048576 wide) (FS#1059), Vehicle + Town + Industry console commands (FS#1060), few minor patches (FS#2820, FS#1521, FS#2837, FS#2843), AI debugging facility

Other: Very large ships NewGRF, Bilbo's multiplayer patch pack v5 (for OpenTTD 0.7.3)

richk67
Tycoon
Tycoon
Posts: 2363
Joined: 05 Jun 2003 16:21
Location: Up North
Contact:

Re: Help Wanted... its a dirty job, but someone's gotta do it...

Post by richk67 » 19 Jul 2007 16:19

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 :)
OTTD NewGRF_ports. Add an airport design via newgrf.Superceded by Yexo's NewGrf Airports 2
Want to organise your trains? Try Routemarkers.
--- ==== --- === --- === ---
Firework Photography

richk67
Tycoon
Tycoon
Posts: 2363
Joined: 05 Jun 2003 16:21
Location: Up North
Contact:

Re: NewGRF (Air)ports - help request, and general discussion

Post by richk67 » 20 Jul 2007 09:31

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.
OTTD NewGRF_ports. Add an airport design via newgrf.Superceded by Yexo's NewGrf Airports 2
Want to organise your trains? Try Routemarkers.
--- ==== --- === --- === ---
Firework Photography

Aydan
Traffic Manager
Traffic Manager
Posts: 196
Joined: 28 Feb 2003 14:49
Location: Germany

Re: NewGRF (Air)ports - help request, and general discussion

Post by Aydan » 20 Jul 2007 09:36

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?

richk67
Tycoon
Tycoon
Posts: 2363
Joined: 05 Jun 2003 16:21
Location: Up North
Contact:

Re: NewGRF (Air)ports - help request, and general discussion

Post by richk67 » 20 Jul 2007 10:13

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.
OTTD NewGRF_ports. Add an airport design via newgrf.Superceded by Yexo's NewGrf Airports 2
Want to organise your trains? Try Routemarkers.
--- ==== --- === --- === ---
Firework Photography

CobraA1
Route Supervisor
Route Supervisor
Posts: 480
Joined: 07 Nov 2003 17:52
Location: USA

Re: NewGRF (Air)ports - help request, and general discussion

Post by CobraA1 » 20 Jul 2007 17:49

Wow, you've already got a lot of stuff planned 8o. 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
"If a man does not keep pace with his companions, perhaps it is because he hears a different drummer. Let him step to the music he hears, however measured or far away" --Henry David Thoreau

User avatar
PikkaBird
Graphics Moderator
Graphics Moderator
Posts: 5382
Joined: 13 Sep 2004 13:21
Location: The Moon
Contact:

Re: NewGRF (Air)ports - help request, and general discussion

Post by PikkaBird » 20 Jul 2007 18:46

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.

User avatar
Ben_K
Tycoon
Tycoon
Posts: 1166
Joined: 01 Jun 2006 15:15
Location: Sydney, AUS

Re: NewGRF (Air)ports - help request, and general discussion

Post by Ben_K » 20 Jul 2007 22:10

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. ;)

8)

User avatar
JazzyJaffa
Engineer
Engineer
Posts: 35
Joined: 13 Jul 2007 13:41
Location: Oxford, UK

Re: NewGRF (Air)ports - help request, and general discussion

Post by JazzyJaffa » 21 Jul 2007 00:09

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.

Locked

Return to “OpenTTD Development”

Who is online

Users browsing this forum: Google [Bot] and 2 guests