[NewGRF] New Airports

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

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

Post by DaleStan »

Darkvater wrote:2. You control the facing with the AMED_EXACTPOS flag and the number after that. I always forget which number is which direction so you have to experiment with 0-7 :)
richk, if you haven't figured this out yet, and assuming the directions 0..7 are the same in TTD and OTTD, 0 is N, 1 is NE, 2 is E, and so on, rotating clockwise through 7 being NW. ("Northbound first, rotating clockwise")
Darkvater wrote:Anyone up for some newgrf magic with action13?
No.

This belongs in action 0..4 feature 04 (or maybe action 0..4 feature 0E). I don't like the idea of action 13 at all. New airports may have graphics/callbacks and definitely have strings (airport type, at least), so why not just keep the whole 0..4 thing, instead of duplicating it into 13..17?

I may have a go at writing a spec for the necessary properties ... later.

If anyone else wants to have a go, the first necessary thing (if using feature 04) would be to add a byte-sized prop 16:
00 for train stations (default)
X1 for rv stations (high nibble indicates type: truck stop/bus stop/bus station)
X2 for ship stations (High nibble indicates type (?): dock/bouy)
X3 for airports (High nibble indicates type: small/large/heliport(?), can be overridden by plane prop 1A (byte): minimum permissible runway length.)
(Set high-nibble to zero and determine other info using a callback instead?)

Take a look at station prop 09; it may be helpful (in either its current state or a similar one) for creating the necessary graphics support. The state machine will almost certainly require its own property.

Regardless of feature, I also believe that making a runtime-configurable aircraft build window would be necessary, as there's no way of knowing at compile time how many airport types will be available. Magic would also have to be worked on plane variables E2 and E6 (maybe a 40+x var instead?) so new airports can't break them.
EDIT: Also, the sprites (at the very least, the ground-level helipad) in openttd.grf would require real sprite numbers so they could be accessed by the 09-equivalent property. You might as well make them changeable by action A at the same time too.
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

User avatar
Darkvater
Tycoon
Tycoon
Posts: 3054
Joined: 24 Feb 2003 18:45
Location: Hong Kong

Post by Darkvater »

DaleStan wrote:This belongs in action 0..4 feature 04 (or maybe action 0..4 feature 0E). I don't like the idea of action 13 at all. New airports may have graphics/callbacks and definitely have strings (airport type, at least), so why not just keep the whole 0..4 thing, instead of duplicating it into 13..17?

I may have a go at writing a spec for the necessary properties ... later.

Regardless of feature, I also believe that making a runtime-configurable aircraft build window would be necessary, as there's no way of knowing at compile time how many airport types will be available. Magic would also have to be worked on plane variables E2 and E6 (maybe a 40+x var instead?) so new airports can't break them.
As you can see my newgrf knowledge is not that great. I thought action13 for the state-machine and positions-code as there is no action so far I have seen that uses anything close to this.
Right now the airport count is fixed and changing it requires quite a lot of other relevant changes (station_cmd.c, station_land.h, airport_gui.c, etc.). Hand in hand with the newgrf dev would be changing these of course, otherwise it is not of much use :). But until there is no external loading capability there is not much sense doing all that work.
TrueLight: "Did you bother to read any of the replies, or you just pressed 'Reply' and started typing?"
<@[R-Dk]FoRbiDDeN> "HELP, this litte arrow thing keeps following my mouse, and I can't make it go away."

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

Post by DaleStan »

Darkvater wrote:I thought action13 for the state-machine and positions-code as there is no action so far I have seen that uses anything close to this.
I take it you haven't looked too closely at station prop 09[0]. If Action 0 can be subverted to do that, it can be subverted to do absolutely anything.

[0] MB has written a prop 0E that is 58263 bytes long. Yes, there are five digits there, and no, MB didn't just tack an extra 55k of data on the end for no good reason. NFORenum tells me that there is not a single extra byte, and I am inclined to believe it.
DaleStan wrote:I may have a go at writing a spec for the necessary properties ... later.
And here goes:
This was basically constructed by reading airport_movement.h and building an NFO format around it. Some named constants in airport_movement.h were unclear to me and were left as "NAMED_CONSTANT", instead of "Text description".

The international airport uses some constructs I cannot parse:

Code: Select all

{0,HANGAR,NOTHING_block,2}, {0,255,TERM_GROUP1_block,0}, {0,255,TERM_GROUP2_ENTER1_block,1}, {0,HELITAKEOFF,HELIPAD1_block,2}, {0,0,0,2},
What do the 255s mean? I thought they meant "never take this branch", but there's no point in putting that anywhere except in the first entry.
In any case, this format cannot encode that.


Prop 16 contains the feature of the vehicles that will use this station, default is 00. (So the high nibble is always 0, contrary to my previous post.) (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>+1 times.
It consists of:
<X> <Y> <flag> <direction> <block> (<heading> <check-block> <next>)* [FF]

<X> and <Y> are words, interpreted as signed integers. (Significance of AirportMovingData::x and AirportMovingData::y?)
<flags> is a bit mask:
0 : Do not clamp speed
1 : This is an airplane take-off location
2 : AMED_SLOWTURN
3 : This is an airplane landing location
4 : Force aircraft facing (see <direction>)
5 : AMED_BRAKE
6 : This is a helicopter take-off location
7 : This is a helicopter landing location

If both bits 1 and 3 are set, this is the point where airplanes enter this state machine.
If both bits 6 and 7 are set, this is the point where choppers enter this state machine.

<direction> is a byte, and ignored unless bit 4 of <flags> is set. If that bit is set, the aircraft is turned to face the specified direction.

<block> is a byte, indicating which block this position is a part of. Block 00 may have any number of aircraft in it at any one time; all others may have at most one at a time.

<heading> <check-block> <next> triples are repeated as necesary and terminate with either a triple with a <heading> of FE, or an FF byte.

<heading> is a byte.
If the high bit of <heading> is clear, the low seven bits specify the terminal/pad this aircraft is going to. If necessary, use the state machine to keep planes and choppers separate.
The following special values are also available:
80: HANGAR
81: TAKEOFF
82: STARTTAKEOFF
83: ENDTAKEOFF
84: HELITAKEOFF
85: FLYING
86: LANDING
87: ENDLANDING
88: HELILANDING
89: HELIENDLANDING
FE: All headings not previously mentioned (marks the last <heading> <check-block> <next> triple)

<check-block> is a byte, indicating which block must be clear before traveling to <next>. As in <block>, block 00 is may have any number of aircraft in it, and is therefore always clear. If <check-block> matches <next> -> <block>, that block is not checked.

<next> is the locations that this aircraft will go to once <check-block> is clear.


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


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


Prop 1A sets the number of terminals and helipads in each terminal/helipad group:
<num-term-groups> <num-pad-groups> <num-terms>... <num-pads>...
All are bytes.
<num-terms> appears <num-term-groups> times; <num-pads> appears <num-pad-group> times.
The sum of all <num-terms> and <num-pads> must not exceed 128.


Prop 1B 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.

The <heading>s 00..7F (in prop 17) are assigned by this property; 00 to the first item in the first group, 01 to the next item on the first group or the first item in the next group, &c.


Prop 1C sets the types of aircraft that can land here:
00 : airplanes only
01 : all
02 : choppers only


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 with a set minimum-runway-length wants to switch to a LANDING or STARTTAKEOFF position (may be adjusted once these named constants are explained), and whenever a plane is given orders to this airport (assuming it passes prop 1C).
Variable 10 contains the position that the plane wishes to enter, or FFFFFFFF if an order was added.
The low byte of the return contains the length of this runway (ignored when 10 is FFFFFFFF), and the high byte contains the length of the longest runway at this airport.

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

Example: the Country Airport (aka Small Airport) would read as follows:

Code: Select all

17 16 //Prop 17, 16h locations
35 00 03 00 10 03 00 // 00 In hangar
   80 00 01 // HANGAR: go to 01
   FF
35 00 1B 00 00 00 09 // 01 Taxi to right outside depot
   80 00 00 // HANGAR: go to 00
   00 01 02 // Terminal 1: check TERM1_block and go to 02
   01 00 04 // Terminal 2: go to 04
   84 00 13 // HELITAKEOFF: go to 13
   FE 00 06 // ELSE: goto 06
20 00 17 00 10 07 01 // 02 Terminal 1
   00 00 01 // Terminal 1: go to 01
   FF
0A 00 17 00 10 07 02 // 03 Terminal 2
   01 00 05 // Terminal 2: go to 05
   FF
2B 00 25 00 00 00 09 // 04 Going towards terminal 2
   01 00 05 // Terminal 2: go to 05
   80 00 01 // HANGAR: go to 01
   81 00 06 // TAKEOFF: go to 06
   84 00 01 // HELITAKEOFF: go to 01
   FF
18 00 25 00 00 00 09 // 05 Going towards terminal 2
   01 02 03 // Terminal 1: check TERM1_block and go to 03
   FE 00 04 // ELSE: go to 04
35 00 25 00 00 00 09 // 06 Going for takeoff
   FE 00 07 // Always go to 07
3D 00 28 00 10 01	09 // 07 Taxi to start of runway (takeoff)
   FE 00 08 // Always go to 08
03 00 28 00 01 00 00 // 08 Accelerate to end of runway
   FE 00 09 // Always go to 09
B1 FE 28 00 03 00 00 // 09 Take off
   FF // The aircraft has left this state machine.
B1 00 28 00 05 00 00 // 0A Fly to landing position in air
   86 00 0B // LANDING: go to 0B
   88 00 14 // HELILANDING: goto 14
   FE 00 15 // ELSE: go to 0F
38 00 28 00 09 00 09 // 0B Going down for land
   FE 00 0C // Always go to 0C
03 00 28 00 21 00 09 // 0C Just landed, brake until end of runway
   FE 00 0D // Always go to 0D
07 00 28 00 00 00 09 // 0D Just landed, turn around and taxi 1 square
   87 00 0E // ENDLANDING: go to 0E
   01 00 05 // Terminal 2: go to 05
   FE 00 0E // ELSE: go to 0E
35 00 28 00 00 00 09 // 0E Taxi from runway to crossing
   FE 00 01
E1 FE C1 00 05 00 00 // 0F Fly around waiting for a landing spot (north-east)
   FE 00 10
01 00 01 00 CF 00 00 // 10 Fly around waiting for a landing spot (north-west)
   FE 00 11
01 01 01 00 05 00 00 // 11 Fly around waiting for a landing spot (south-west)
   FE 00 12
11 01 31 00 05 00 00 // 12 Fly around waiting for a landing spot (south)
   FE 00 0A
2C 00 25 00 42 00 00 // 13 Helicopter takeoff
   FF // The aircraft has left this state machine
2C 00 28 00 05 00 09 // 14 In position above landing spot helicopter
   FE 00 15 
2C 00 28 00 80 00 09 // 15 Helicopter landing
   FE 00 01
19 01 03 00 // one depot, at (3,0)
1A 01 00 // one terminal group and no helipad groups
   02 // (Terminal) group containing 2 items; gets <headings> 00..01
Example: The International airport's props 19..1A would be:

Code: Select all

19 02 00 03 06 01 // two depots, at (0,3) and (6,1)
1A 02 01 // two terminal groups and one helipad group
   03 // (terminal) group containing three items; gets <heading>s 00..02
   03 // (terminal) group containing three items; gets <heading>s 03..05
   02 // (helipad) group containing two items; gets <heading>s 06..07
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

User avatar
belugas
OpenTTD Developer
OpenTTD Developer
Posts: 1507
Joined: 05 Apr 2005 01:48
Location: Deep down the deepest blue
Contact:

Post by belugas »

Wow!
You did covered a lot of the needs for airport NFO indeed.

I assume that the graphical side of it (i.e. concrete with fence and so on) would be handled exactly as for regular station. Which in fact means get rid of hardcoded sprites arrays :)

In fact, I think that some of the graphical aspects in question would require identification too. A radar tile need some special treatment, obviously. A hangar too, since it can be an order target. I hope I explain myself clearly, which i doubt... :oops:
If you are not ready to work a bit for your ideas, it means they don't count much for you.
OpenTTD and Realism? Well... Here are a few thoughs on the matter.
He he he he
------------------------------------------------------------
Music from the Bloody Time Zones

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

Post by DaleStan »

belugas wrote:I assume that the graphical side of it (i.e. concrete with fence and so on) would be handled exactly as for regular station. Which in fact means get rid of hardcoded sprites arrays :)
Yes and yes.

Prop 09 defines up to 255 sprite arrangements (and each arrangement can contain near-infinite numbers of sprites). Callback 14 is called for each tile to determine which arrangement to draw, and then the full power of varactions is available to select different sprite sets to attach to each arrangement.

Once someone explains what the 255s mean and I expand the format to encode that, writing a parser to turn the information in aircraft.c and aircraft_movement.h into a prop 17 should be relatively simple. (Not that they're much more human readable than the formatted NFO above.)

Oh, and I missed the "variables" bit:
Basically the same as for rail stations, but:
40/41/49 : (synonymous)
46/47 : (synonymous)
42 : Only low byte (terrain type) is meaningful
44/45 : Meaningless

It would also be possible to define the state machine using a callback:
Reduce prop 17's <pos-data> to "<X> <Y> <flag> <direction> <block>", put block-usage info into var 65 (param=block id), put <pos> and <heading> info into var 10 or 18, and call the callback. The return value would be the position to go to next. This would be more powerful than the prop 17 format I proposed, but might also be harder to automatically generate.
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

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

Post by richk67 »

DaleStan wrote:Once someone explains what the 255s mean and I expand the format to encode that, writing a parser to turn the information in aircraft.c and aircraft_movement.h into a prop 17 should be relatively simple. (Not that they're much more human readable than the formatted NFO above.)

Code: Select all

{0,HANGAR,NOTHING_block,2}, {0,255,TERM_GROUP1_block,0}, {0,255,TERM_GROUP2_ENTER1_block,1}, {0,HELITAKEOFF,HELIPAD1_block,2}, {0,0,0,2},
The 255s in your example mean "additional groups follow". If no terminal can be found in TERM_GROUP_1_block, then that clause fails, and it moves to the next clause. Granted the 0 as the destination on the end of the clause is confusing, as it means that when a terminal is available in TERM_GROUP1_block, loop back to 0, so it should never leave the hangar!
Also, in the coding for the city airport, there is only 1 group, and yet it has a 255 "more groups follow" heading in a couple of locations.
The final {N,0,0,M} clause is a catch all (the first 0 meaning "any" state, the second 0 meaning "no specific block"), used to move the state engine on, or often to loop it back to the start of current command to ensure the options are checked again.
Its explained better by Darkvater on his airport design page (but that doesnt clarify fully the problems I outlined here): Airport Design
One or two quirks also exist in the control of sounds associated with the locations. The aircraft TAKEOFF sound is triggered when the TAKEOFF state is reached in the finite state machine. However, the helicopter takeoff is triggered on AMED_HELI_RAISE in the movement part, not the state machine. I had real fun debugging that one! (not)
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

peter1138
OpenTTD Developer
OpenTTD Developer
Posts: 1646
Joined: 30 Mar 2005 09:43

Post by peter1138 »

Hmm, I suppose I should finish off the station resolver then... AFAIK it's the same code that draws the station/airport tiles.

And something to convert the FTA (and perhaps tile layout) to an nfo line would be handy (even if it's DaleStan :D)
He's like, some kind of OpenTTD developer.

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

Post by richk67 »

peter1138 wrote:Hmm, I suppose I should finish off the station resolver then... AFAIK it's the same code that draws the station/airport tiles.

And something to convert the FTA (and perhaps tile layout) to an nfo line would be handy (even if it's DaleStan :D)
Coding up the FTA into NFO wont help at all. All that will happen is that less people will be able to comprehend what is going on. Its complicated enough as it is (in almost plaintext), without having to hex code it as well.

(Ive just spent hours debugging a minor quirk in the FTA for my commuter airport. Even in plaintext, the problem wasnt obvious, let alone the solution. In HEX / NFO, it would be an order of magnitude more difficult to debug - without of course taking it back to plaintext... in which case, why use NFO at all?)

I would far rather the FTA data is stored as external text files that are easily viewed and amended. I totally agree there should be no logical reason why it needs hard coding and compiling - its only data. It would require a small text-reading & parsing engine to initialise the structures at game start. (Parsers are a doddle... give me the job if you want.)

But to go down the (TTDP) NFO route is a retrograde step IMO. It places yet more onus on a few NFO experts, rather than throwing it open to all users to mod away.

(Text data can be as easy or complicated as required. The whole Europa Universalis game works off text files for AI and game status. It is therefore simple to look in the savefile and see why such-and-such happens in 1603. Yes, the files are very large 3Mb/game, but they are plaintext readable/editable.)
Last edited by richk67 on 28 Feb 2006 14:39, edited 1 time 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

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

Post by richk67 »

Darkvater wrote:Right now the airport count is fixed and changing it requires quite a lot of other relevant changes (station_cmd.c, station_land.h, airport_gui.c, etc.). But until there is no external loading capability there is not much sense doing all that work.
The airport count is currently 16, but since only 6 are currently used (8 if you include my 2 new ones, 9 if you include my in-development InterContinental), there is no current pressure on space.

The biggest problem is on the terminal & helipad structures, where currently it is hard-coded in aircraft_cmd.c to look for terminals starting at state "TERM1". This means you cannot add extra terminals without disturbing the other state-engine features.... until now.

I have a (albeit temporary) solution for changing the count of terminals and helipads.

I will add a cross-table that has an index of the sequential list of terminals/helipads, and then cross-refers to the State, and the Flag. This way, you can add TERM7, with state=19, flag=22.

In aircraft_cmd.c, FindFreeTerminal, use this cross-reference to prime the state and block flag settings.

This *should* break the 1:1 link between TERMn and STATEn. So you can add new terminals/helipads anywhere in the state and flag lists.

A long-term better solution is to have a state-list and flag-list for each airport type, defined along with the airport. This should then give total flexibility to rename as required (since its enum, and the state name is only for our visual interpretation). This then allows all the data in airport_movement.h to be hived off to separate "airport1FTA.txt", "airportCommuterFTA.txt" definition files etc, and then have the list of airport definitions stored in config.cfg where the [airports] section would list the airport definition files. (in the same manner as adding newgrf files to the list)
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:

Post by DaleStan »

richk67 wrote:The 255s in your example mean "additional groups follow". If no terminal can be found in TERM_GROUP_1_block, then that clause fails, and it moves to the next clause. Granted the 0 as the destination on the end of the clause is confusing, as it means that when a terminal is available in TERM_GROUP1_block, loop back to 0, so it should never leave the hangar!
I think I follow. When the {pos,255,block,next} format is encountered, next changes its meaning to "terminal group number", so the {0,255,TERM_GROUP_1_block,0} means "If v->air.heading is FIND_A_TERMINAL (255), and TERM_GROUP_1_block is clear, and at least one of the terminals in group 0 is free, mark the first free terminal as occupied, and set v->air.heading to that terminal"?
richk67 wrote:The final {N,0,0,M} clause is a catch all (the first 0 meaning "any" state...
That I got, but I moved it to FE (and I think I'll move it again, to FF) to allow for 80h terminals.
richk67 wrote:One or two quirks also exist in the control of sounds associated with the locations. ...
What fun. Anyway, both the TAKEOFF state (<heading> 81) and AMED_HELITAKEOFF position (<flags> bit 6) are available.

From reading the source, it looks like I'll have to place a restriction on <block>: When <block> is for a terminal, its ID must match the heading that causes a plane to go to that terminal. (So the block surrounding the first terminal must have ID 00; the second, ID 01, &c.) This also means that NO_BLOCK (00) must be moved; I think it'll go to FF instead.

I managed to miss a the heading descriptions on that page the first time around. The only thing that's still unclear to me there: Does ENDTAKEOFF apply to aircraft, or only to airplanes?

One other thing I'm not quite understanding: "{0,HANGAR,NOTHING_block,1}," seems to say "when at position 0 (in hangar), and heading for HANGAR, go to position 1". but where's all catch-all? Is it guaranteed that aircraft leaving the hangar have the HANGAR heading?
Unless someone can come up with a very good reason for me not to, I'm going to pull the "terminating FF byte" concept from the spec, and require that a catch-all be present.
richk67 wrote:In HEX / NFO, it would be an order of magnitude more difficult to debug - without of course taking it back to plaintext... in which case, why use NFO at all?)
Because:
1) OpenTTD already (mostly) supports NFO, and
2) No other available container can reliably attach FTA info to its graphics.
(http://www.tt-forums.net/viewtopic.php?p=406765#406765)
richk67 wrote:I would far rather the FTA data is stored as external text files that are easily viewed and amended. I totally agree there should be no logical reason why it needs hard coding and compiling - its only data. It would require a small text-reading & parsing engine to initialise the structures at game start.
And this parser will attach the FTA information to its graphics information ... how? NFO was designed to attach static data to new graphics, so it does that quite well.
richk67 wrote:Parsers are a doddle... give me the job if you want.
Done. Write a parser that takes as input your preferred HRC, and produces as output a corresponding action 0 setting at least prop 17, and optionally 19 and 1A. (But I will be changing the NFO format, so you might not want to do anything more than design the HRC format yet.)

If you want to do the reverse too, there's a quite competent (albeit poorly commented) NFO reading engine readily available, and it can relatively easily be subverted for other uses.
richk67 wrote:But to go down the (TTDP) NFO route is a retrograde step IMO. It places yet more onus on a few NFO experts, rather than throwing it open to all users to mod away.
"For all users to mod away"? On AIRPORT STATE MACHINES? Am I the only person who has the impression that airport state machines are not entirely simple? NFO is, by nature, a information-dense format, and the country airport is the simplest airport, but even so, that prop 17 is 257 bytes long. Even the heliport requires 106 bytes of prop 17. It would not at all surprise me if the international airport required over 600 bytes, and I've seen mock-ups of larger.
richk67 wrote:I have a (albeit temporary) solution for changing the count of terminals and helipads.
Is there some major with just moving the non-TERM* headings into the 80..FF range, and assigning TERM* according to the setting of prop 1A?
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

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

Post by richk67 »

DaleStan wrote: I think I follow. When the {pos,255,block,next} format is encountered, next changes its meaning to "terminal group number",
Ahh!! That explains a mystery for me!!

I'll take a look at most of the rest of your reply later... bottom line is if there is a quick tool/extension that can pre-prepare an airportFTA.txt into NFO compilable format, then yeah, should be ok.... even if I/we have to write one. About time I took a loooooooooong look at NFO methinks. (been avoiding the pain!!)
DaleStan wrote:From reading the source, it looks like I'll have to place a restriction on <block>: When <block> is for a terminal, its ID must match the heading that causes a plane to go to that terminal. (So the block surrounding the first terminal must have ID 00; the second, ID 01, &c.) This also means that NO_BLOCK (00) must be moved; I think it'll go to FF instead.
Not sure I like implication of that... almost seems as though it will restrict no. of terminal blocks = no. of directions. As long as tons of reserved space is allowed for more terminals/helipads, it wont be a problem. Currently problem is that theses values run together in a nasty collision of codes.
DaleStan wrote:I managed to miss a the heading descriptions on that page the first time around. The only thing that's still unclear to me there: Does ENDTAKEOFF apply to aircraft, or only to airplanes?
Just airplanes. Helis have HELITAKEOFF, which can just go to empty afterwards. Personally I would like a POST_HELITAKEOFF / ENDHELITAKEOFF to allow guidance for helis away from the pad.
DaleStan wrote:
richk67 wrote:In HEX / NFO, it would be an order of magnitude more difficult to debug - without of course taking it back to plaintext... in which case, why use NFO at all?)
Because:
1) OpenTTD already (mostly) supports NFO, and
2) No other available container can reliably attach FTA info to its graphics.
(http://www.tt-forums.net/viewtopic.php? ... ht=#406765)
1) is not a good reason IMO. Its there, so lets use it, is like saying the AI is there. Doesnt mean its worth it!! (Of course, NFO is *better* than the AI, its just I dont think its a strong reason.)
2 is a reasonable reason. I did have to fiddle with station_land.h quite a bit to get the right graphics.
Dalestan wrote:
richk67 wrote:Parsers are a doddle... give me the job if you want.
Done. Write a parser that takes as input your preferred HRC, and produces as output a corresponding action 0 setting at least prop 17, and optionally 19 and 1A. (But I will be changing the NFO format, so you might not want to do anything more than design the HRC format yet.)
When I can understand that paragraph, sure ;) Parser=simple. Coordinating with NFO=harder.

If you want to do the reverse too, there's a quite competent (albeit poorly commented) NFO reading engine readily available, and it can relatively easily be subverted for other uses.
Dalestan wrote:
richk67 wrote:But to go down the (TTDP) NFO route is a retrograde step IMO. It places yet more onus on a few NFO experts, rather than throwing it open to all users to mod away.
"For all users to mod away"? On AIRPORT STATE MACHINES? Am I the only person who has the impression that airport state machines are not entirely simple?
Good point. Ive noticed the "idea abandoned as too hard" syndrome that seems to go around. And airports have had lots of ideas, and only Darkvater's managed to implement any.

Maybe NFO is the ideal super-complexity to really make FTAs incomprehensible to all !!! ;)
Dalestan wrote:
richk67 wrote:I have a (albeit temporary) solution for changing the count of terminals and helipads.
Is there some major with just moving the non-TERM* headings into the 80..FF range, and assigning TERM* according to the setting of prop 1A?
Yeah, the terminals must all be listed first, then the helipads. This is hard-coded, and is expected to be 6 terms, with helipads starting at 7. So if you want more terms, you have to overcome this. If I dont provide a translator, then all existing airports in games (including the splash screen game) will crash as the wrong destinations/headings/states etc will have been stored, and the FTA crashes. (What gives you the idea I tried ;) ).

So if you move other states (FLYING) etc. to a different value, then suddenly all games dont know where the aircraft is. My way, the states are preserved, but future expansion is not prevented. Certainly a good "for now" solution, even if a bit ugly long term.

(I would need to create a state-translator for the SaveLoad routines. Not fun. Do not want to go there....)
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:

Post by DaleStan »

richk67 wrote:
Dalestan wrote:From reading the source, it looks like I'll have to place a restriction on <block>: When <block> is for a terminal, its ID must match the heading that causes a plane to go to that terminal. (So the block surrounding the first terminal must have ID 00; the second, ID 01, &c.) This also means that NO_BLOCK (00) must be moved; I think it'll go to FF instead.
Not sure I like implication of that... almost seems as though it will restrict no. of terminal blocks = no. of directions. As long as tons of reserved space is allowed for more terminals/helipads, it wont be a problem.
In the current format, the first 128 headings are available for terminals, and the other 128 headings are reserved for special values. If you think that's not enough space, it's not (at this point) hard to move the special group up, and provide more terminal headings and fewer special headings.

The first NUM_TERMINALS blocks are reserved for use with the corresponding terminal, but all other blocks are free to be used for whatever you like. (So, on an airport with 8 terminals and 3 helipads, each terminal gets a heading and block in 00..07, and each pad gets a heading and block in 08..0A. All remaining blocks (0B..FF) can be used for whatever you want.)
richk67 wrote:
Dalestan wrote:Does ENDTAKEOFF apply to aircraft, or only to airplanes?
Just airplanes. Helis have HELITAKEOFF, which can just go to empty afterwards. Personally I would like a POST_HELITAKEOFF / ENDHELITAKEOFF to allow guidance for helis away from the pad.
Done. (Well, added to proposed spec, anyway.) (heading 8A)
richk67 wrote:
DaleStan wrote:Is there some major problem with just moving the non-TERM* headings into the 80..FF range, and assigning TERM* according to the setting of prop 1A?
[translating FTAs in savegames]
Right. That could present a problem.

I was more thinking about the NFO format there. It is designed to match the internals, but also to be somewhat logical. To the latter end, I don't intend to move the specials back down into the lower range. It shouldn't be difficult to convert the in-NFO <heading> bytes to whatever internal values Open uses, though.
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

User avatar
Darkvater
Tycoon
Tycoon
Posts: 3054
Joined: 24 Feb 2003 18:45
Location: Hong Kong

Post by Darkvater »

DaleStan wrote:<X> and <Y> are words, interpreted as signed integers. (Significance of AirportMovingData::x and AirportMovingData::y?)
Position offset from top-left or airport (st->airport_tile) where the moving code breaks and an airplane makes a decision in the FTA. Eg AirportMovingData's element zero's X/Y tells that FTA's element zero (hangar) at what coordinates is.
richk67 wrote:The 255s in your example mean "additional groups follow". If no terminal can be found in TERM_GROUP_1_block, then .... Granted the 0 as the destination on the end of the clause is confusing, as it means that when a terminal is available in TERM_GROUP1_block, loop back to 0, so it should never leave the hangar!
Almost correct. The file in the link at part 'terminal groups'(airports.html) explains it better. Shortly a plane will always try to fill up terminal 1, then 2, then 3, etc. With blocks you can control this, this is what the 255 means in the SECOND element. First check the terminals in GROUP1 IF and ONLY IF TERM_GROUP1_block is free. Otherwise go check the other group for free terminals. Now if the first block is not free the FTA will check other groups. If all pre-entry blocks are in use, don't even reserve a terminal and stay in the hangar. The last element just tells us that we should go to position 1 if we want to move at all. For example if the plane wants to take off, or has already reserved a terminal and needs to move. With the terminal groups there is NO physical moving instruction.
richk67 wrote:Also, in the coding for the city airport, there is only 1 group, and yet it has a 255 "more groups follow" heading in a couple of locations.
The final {N,0,0,M} clause is a catch all (the first 0 meaning "any" state, the second 0 meaning "no specific block"), used to move the state engine on, or often to loop it back to the start of current command to ensure the options are checked again.
You have to make a difference between a 255 in the heading of the FIRST element and next elements. In the case of next-elements it's purely for terminal-groups. A 255 in the first element just tells us we have other choices to go to/pick from in the FTA and nothing else.

I see nothing wrong with coding FTA's into the NFO. Mostly for a few reasons:
1. There is already a newgrf loader available and a whole lot of specs which will take care of flags (introduction date, cost, whatever else), and graphics
2. If someone really adventurouos wants to do custom airports for TTDPatch, they already have the specs (which I think work quite fine, but I might be a bit biased ;) ). I think somebody already started, but he's been at 1% - researching for at least 6 months
3. Doing it in plain text would need a parser into OpenTTD itself for yet another format. With the same effort you can write it in your favourite text-file and parse that into NFO. Even XML to NFO for I care, doesn't really matter.

Too many posts today..so I'll just reply to something that I noticed from richk67 who said something about changing the states and updating the SaveLoad code will be a pita. I don't think it's that bad. I solved it in UpdateOldAircraft(). What I did is reset the airport to free, and kick all the airplanes up in the air wanting to land. Ok, not the best solution, but it works and it will only have to be done once if your cross-reference is done.
TrueLight: "Did you bother to read any of the replies, or you just pressed 'Reply' and started typing?"
<@[R-Dk]FoRbiDDeN> "HELP, this litte arrow thing keeps following my mouse, and I can't make it go away."

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

Post by richk67 »

DaleStan wrote:In the current format, the first 128 headings are available for terminals, and the other 128 headings are reserved for special values. If you think that's not enough space, it's not (at this point) hard to move the special group up, and provide more terminal headings and fewer special headings.
I really cant envisage anyone realistically creating an airport with more than 20 terminals. The state machine would be a nightmare with that many anyway. So yeah, 128 / 128 split would work. I would suggest reserve 00-3F for standard movements, terms at 40-7F, helipads 80-BF, and C0-FF for expansion custom movements. This way we can keep the current states supported, and only need to translate the terminals/helipads. It also means the bit states can be stored cleanly in 4 x int64 flag vars; movements, terminals, helipads, custom_moves. The only drawback is that we need to store 16 bytes every time we refer to the block. But it would be the ultimate in flexibility.

The blocks corresponding directly is fine, and as long as we have the saveload translation into the new state/block schema, then the new block definition is more logical.

One feature I really want to see (and is obviously easy with this bitmapped method) is to check and reserve several blocks (can you say "PBS for airports"). I tried to see if I could do it with the current OTTD blocks, but it looks like no.
Dalestan wrote:
richk67 wrote:Personally I would like a POST_HELITAKEOFF / ENDHELITAKEOFF to allow guidance for helis away from the pad.
Done. (Well, added to proposed spec, anyway.) (heading 8A)
Given the flexibility the new design would have, adding extras is easy. Problem comes with custom blocks, where one new airport .grf blocks may conflict with the block definitions for another .grf.
DaleStan wrote:Right. That could present a problem.

I was more thinking about the NFO format there. It is designed to match the internals, but also to be somewhat logical. To the latter end, I don't intend to move the specials back down into the lower range. It shouldn't be difficult to convert the in-NFO <heading> bytes to whatever internal values Open uses, though.
We'll need to recode the aircraft_cmd.c to work with the new system, but its fairly logical code - and in some places well commented too! :shock:

If we dont mess with the currently defined states, (except terms of course), then the recoding can be reduced.

My cross-reference table can solve the short term problem of >6 terms, >2 helis. Recoding the rest would be a bigger job, but not impossible.

BTW dont forget the positional data - the AirportMovingData as opposed to the AirportFTAs.
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
Darkvater
Tycoon
Tycoon
Posts: 3054
Joined: 24 Feb 2003 18:45
Location: Hong Kong

Post by Darkvater »

richk67 wrote:One feature I really want to see (and is obviously easy with this bitmapped method) is to check and reserve several blocks (can you say "PBS for airports"). I tried to see if I could do it with the current OTTD blocks, but it looks like no.
Yes, this is not possible. There is a special exception with terminals which a plane has reserved ages ago. But for other blocks the airport scheme needs new functionality, mainly remembering for each block what plane has reserved it. Checking multiple blocks is already possible, and being done.

Also it doesn't matter what you use to design the airport, I bet only about 1 out of 50 people can design an airport. I mean a big airport, not a tiny one-terminal type. In that case they can handle with a bit obscure text/xml/whatever format and convert it to nfo if that's the way to go.
The only dummy-proof airport-builder would be component-based. Like runway, terminal blocks, etc. Even then you either have simple, a bit variadic airports, or give full customizibility (lots and lots of work) in which case the dummies will end up with a deadlocked airport in 99% of the cases.
TrueLight: "Did you bother to read any of the replies, or you just pressed 'Reply' and started typing?"
<@[R-Dk]FoRbiDDeN> "HELP, this litte arrow thing keeps following my mouse, and I can't make it go away."

User avatar
Born Acorn
Tycoon
Tycoon
Posts: 7571
Joined: 10 Dec 2002 20:36
Skype: Bornacorn
Location: Wrexham, Wales
Contact:

Post by Born Acorn »

To break the pattern of really long posts, is it possible to have runways going in the opposite direction? Like in this mock-up I made a while back. You can see I didn't plan it very well, as how can planes get into the middle terminals? :P
Attachments
airportmock.png
(78.96 KiB) Downloaded 334 times

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

Post by DaleStan »

Rich, I think you're confusing blocks and headings there. Current code req
richk67 wrote:One feature I really want to see (and is obviously easy with this bitmapped method) is to check and reserve several blocks
I think that if you get a design where you have to check or reserve multiple blocks, it's time to switch to callbacks.
richk67 wrote:Given the flexibility the new design would have, adding extras is easy. Problem comes with custom blocks, where one new airport .grf blocks may conflict with the block definitions for another .grf.
Blocks are specific to a single airport. If one airport uses block 08 for a terminal, and a different one uses the block 08 for a queue, who cares? They're just numbers.
richk67 wrote:BTW dont forget the positional data - the AirportMovingData as opposed to the AirportFTAs.
It's also part of prop 17; since every position must have both MovingData and FTA info, I decided it made the most sense to just merge the two into one property.
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

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

Post by DaleStan »

belugas wrote:In fact, I think that some of the graphical aspects in question would require identification too. A radar tile need some special treatment, obviously. A hangar too, since it can be an order target.
I've added a property for animation; all other tiles should be redrawn only as necessary.

My belief is that prop 1A and/or the <X>/<Y> of the hangar positions are sufficient to indicate the location of the hangars for orders and similar.
DaleStan wrote:Rich, I think you're confusing blocks and headings there. Current code req
Um ... what happened there? I'm not sure quite where I was going, but I'll try again:
Rich, I think you're confusing blocks and headings there. Each plane has a single heading (or state); airports have some positive number of blocks, each of which is either reserved or not reserved. Blocks may be assigned basically however the coder desires, as long as the first NUM_TERMINALS blocks are assigned to the terminals and the next NUM_HELIPADS blocks are assigned to the helipads.
If defined, the states 00..7F are attached to "going to a terminal" or "going to a helipad" ; the states 80..FC are either undef or attached to a one of the special named constants: HANGAR, TAKEOFF, STARTTAKEOFF, &c.
FE and FF are not states, but rather special cases for terminal selection and TO_ALL.

Terminal selection is currently utterly insane, and I don't want to post a new format until get it figured it out.
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

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

Post by richk67 »

DaleStan wrote:Terminal selection is currently utterly insane, and I don't want to post a new format until get it figured it out.
Err... does that mean you dont want to discuss it before... (bit exclusive that!) :?: :? :lol:

I dont think Im confused on the OTTD blocks and headings/states. I do get a grey mist fogging over when you get into Prop this, and Action that. High level description was invented for a purpose ;)

I think it sensible to have the backwards compatibility with existing games vis the movement states and blocks; a new format is good, but if we can do it so old games load easy into the new, thats OK.

On the different .grfs conflicting, each .grf will define the format and machine for a different class of airport. There is however, only 1 state machine engine that has to know that some states (TAKEOFF, HANGAR, etc.) have special meanings. This is best supported by fixed IDs for those, and yes, let the rest float. As long as the state & block definitions for each airport type are kept associated with the airport type, and not merged into a single structure, then there should be no collisions. If merged, they will clash.
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:

Post by richk67 »

Born Acorn wrote:To break the pattern of really long posts, is it possible to have runways going in the opposite direction? Like in this mock-up I made a while back. You can see I didn't plan it very well, as how can planes get into the middle terminals? :P
Yup, no problem at all. You could even have diagonal landings/takeoff as well. The AMED_TAKEOFF and AMED_LAND only affect the vertical level of the aircraft, not its position or direction, which are given by the x,y and direction parameters. You can fly, taxi, land, takeoff in any direction.

So if you (BA) sort the graphics, we'll sort the engine. (Nice airport design... rather large though. I suspect this is probably viable, but may not be as efficient - runways blocked by taxiing aircraft.)

PS. that is *not* a general offer to all comers to say "code my airport"... "why isnt it done yet" etc... You have to design 2 things IMO. The graphical layout of the airport, and the block layout. Think really hard about the movement of the aircraft on the ground. Can you lock up your airport? Will planes overrun each other? etc. Once that is done, post a piccy, and talk us through it. Then if its viable, why not!
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

Post Reply

Return to “OpenTTD Development”

Who is online

Users browsing this forum: No registered users and 5 guests