NewGRF (Air)ports - general discussion

[Bilbo]

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.

Automatically generating effective state machine from some pieces you've scraped together may be hard problem.... quite hard problem, I think ...

[JazzyJaffa]

Hard yes, insoluble no. I'll put this at the end of my "wacky ideas to code when I have infinite time" list. It would add a lot to the aircraft gameplay, there would be more art to it.

[Bilbo]

I guess someone will develop "very efficient airport" like the one attached - plane lands, goes to square at end of runway, tosses out passengers, loads new ones and almost immediately takes off. Very efficient, but higly unrealistic

With same area as intercontinental airport you have 11 runways (instead of only 4), 11 stands (instead of 8), shorter taxiiing distance (2 tiles/plane instead of about 10-20) ... very efficient, huh?

With little modification you can perhaps have 2 squares at both ends of runway (double the stands!) - I think even more effective (and less realistic) airport could be made that way :)

[belugas]

By the way, i find PikkaBird pretty interesting...
Crazy callback nightmare, but sure it is quite helpfull.
Something worthy of attention, i would say

[JazzyJaffa]

I guess someone will develop "very efficient airport" like the one attached

By implementing restrictions like "runway proximity limit" and "terminals must be connected by at least a foot tunnel or shuttle bus" you could ensure only realistic designs got built.

[PikkaBird]

By implementing restrictions like "runway proximity limit" and "terminals must be connected by at least a foot tunnel or shuttle bus" you could ensure only realistic designs got built.

There's no reason to limit this at all; we should give grf creators at least some credit. Note we're still talking about GRF defined airports here, not airports that players can lay out themselves.

(Also, there's nothing preventing grf authors making other extremely unrealistic things, like vehicles with no running costs and extreme power/speed).

[JazzyJaffa]

There's no reason to limit this at all; we should give grf creators at least some credit.

Sorry, crossed wires, I was talking about programmatic restrictions on player laid airports. Of course the grf authors can create what ever wonderful things they like.

[richk67]

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.

Wow, go away for one evening and this thread goes ballistic...

Other than dropping it into TTDP speak, ie. OTTD_states=nodes, OTTD_blocks=locks, using callbacks than just having the program run, OTTD_heading=target node, ... your spec seems the same as how OTTD handles its state machine.

The one minor improvement is that your conditional actions can be extended to test many more parameters - eg. if cargo_type=freight, go left, else, go right. etc.

OTTD could still handle complex actions by a callback. I have extended the <flags> parameter to be a full word, so one of the additional bits could indicate "at this point in the airport, check and act on the callbacks first. It they pick a new route, choose that, else continue using our state machine commands".

To me, this makes more logical sense. Define the state machine for the normal actions. If something special is needed, call the callback first.

However, I am not convinced your system will handle more complex locking systems, especially as there doesnt seem to be a concept of a group of positions (nodes) all locking the same lock. It seems as though there is a 1:1 of nodes to locks. In OTTD's model, you can have one position (node) lock many blocks on selection of a heading, and in my spec, I can release these blocks individually as the plane traverses the airport. (ie. reserve a whole route, and then release the parts that are no longer needed as required.) If you can lock and release multiple nodes at each stage, then I think our state machines are identical.

In fact, reading it in more detail, our proposals are nearly identical. You define your state machine in callbacks, I define it explicitly using the OTTD conventions. Functionally, they are identical.

Have you thought of how to extend this scheme to handle the other forms of transport? Sea? Road?


[edit]Having had a further further read I can see that your system can also handle multiple locks and releases. As such, it is exactly the equivalent of this system.

[edit]Have attached latest spec.

[richk67]

Hard yes, insoluble no. I'll put this at the end of my "wacky ideas to code when I have infinite time" list. It would add a lot to the aircraft gameplay, there would be more art to it.

It may turn it into a more creative process, but there would have to be enormous limitations on the finite state machine. For example, it would be quite difficult to have more than one taxiway block, so it is likely one restriction would be that only 1 aircraft moves at a time. OK for tiny airports - but my new Munich airport can have 15+ aircraft in motion. This complexity will be so complex to add via a generic interface, you may as well have a pre-defined airport.

[bulb]

Hard yes, insoluble no. I'll put this at the end of my "wacky ideas to code when I have infinite time" list. It would add a lot to the aircraft gameplay, there would be more art to it.

It may turn it into a more creative process, but there would have to be enormous limitations on the finite state machine. For example, it would be quite difficult to have more than one taxiway block, so it is likely one restriction would be that only 1 aircraft moves at a time. OK for tiny airports - but my new Munich airport can have 15+ aircraft in motion. This complexity will be so complex to add via a generic interface, you may as well have a pre-defined airport.

I believe it is a complete nonsense to attempt to construct a state machine for a player layed out airport, but there is really no need for it either. Basically each piece would just have it's own state machine and normal pathfinding would be used to find the route. It would just be slightly special in that the aircraft can go from any aerial leavepoint to any aerial entrypoint.

The blocks would be basically limited to the individual pieces that way, which would mean every single tile of taxiway would have it's own block. Kind of path-based signalling would have to be used to prevent the aircraft dead-locking, but it's really quite easy. Basically, every lock would be a queue. The aircraft would atomically put itself to the queue for all it's way to a free apron, hangar or air. Than it would enter those segments where it would be first in the queue.

It is just required, that the aircraft only starts towards apron when it's either free and no other aircraft is heading there, or the aircraft there already reserved it's route out. This would limit the throughput at aprons. It could be improved somewhat by using clever tricks, but it probably wouldn't be as efficient as hand-designed airport where you know which routes the leaving aircraft will never want to use.

[DaleStan]

Wallyweb just set a nasty thought in my brain. For truck stations, it'll probably be necessary to be able to sort trucks by length and/or number of articulations. Does the FSM spec allow for this? It would also be desirable to make some trucks reverse into their loading bays. George's doubly articulated buses may also need some special handling.

[richk67]

It sort of supports it. When a position is reached, the system will check a callback flag. If set, it does any callback defined for that position, and takes its result in priority.

So you could define a callback to test if a lorry is more than a certain length, go left, otherwise do normal processing. This should provide all necessary functionality that isnt already within the scheme.

[athanasios]

Wallyweb just set a nasty thought in my brain. For truck stations, it'll probably be necessary to be able to sort trucks by length and/or number of articulations. Does the FSM spec allow for this? It would also be desirable to make some trucks reverse into their loading bays. George's doubly articulated buses may also need some special handling.

We need at least double depth loading bays.

[richk67]

Well, since the system lets you define a) the graphics, b) the movement, c) the size and shape of the station, you could design it with whatever shape loading bays you want. There should be no need for special supporting code on my side At least, thats the plan.

To indicate it has reached a location, all that is required is that the X,Y,Z are at the required X,Y,Z. It then knows "I've arrived somewhere." It then checks, "Im here, but is HERE special in any way?" eg. loading bay, hangar, takeoff, etc. If so, then perform actions. (The action for a loading bay will just be "arrived at terminal" as with airports.)

BTW I think the Commuter airport is now fully working. I havent seen a dodgy moment for a loooooooong time.

[DaleStan]

AIUI, with the hard-coded FSMs, aircraft couldn't be made to reverse. Does the new FSM support "proceed backward towards ..."? "Spin 180 degrees in place" is nasty enough with aircraft. I shudder to think what might happen with aRVs.

It might also be necessary to be able to ask the vehicle how it wants to be unloaded; box trucks should back up to a loading bay, but most other types of truck should not.

[richk67]

No, there is no support for "proceed backwards" for any of the vehicle types. My priorities on this are to get FSM airports working as well/better than old airports. (There are some FSM improvements I will incorporate). Second is then to look at seaports. Last is roads.

For the moment, we have to accept that instant turnarounds will happen. Once the vehicle is in motion its up to the designer of the movement orders to make sure it looks smooth for artics. (ie. no really tight turns, etc.)

As of last night, the FSM for the commuter handles multi-block locking and release. Ive thrown oodles of aircraft at it, with no visible problems that I noticed.

I will probably start adding the rotation code soon, as I already have a working non-FSM patch for it.

I will try to resolve the aircraft waggle-dance, it just looks so rotten. Main idea is that if the change in direction required to get to the target location is less that 22.5 degrees, then it carries on in the normal direction, but slides across. So if an aircraft needs to slide left 2 pixels in 8 forward, then it would slide 1 pixel at 4, and 2nd at 8. Mostly this should give imperceptible movement across tiles. When the change is greater than 1 in 4, then it would turn to the angled heading, and then realign.

[zombie]

Hi.

I just built a Win32 binary of the NewGRF_Ports branch using BuildOTTD to take a look at the new airports. Where can I leave bug reports or feature requests for this branch if I find any? Should I add them to flyspray?

Kind regards

Zombie

[richk67]

Its still very much in development, and there are a host of things that do not work. I would prefer only feature requests for the moment - as long as it is NOT modular airports. I aint doing it!

[belugas]

Don't want to speak on behalf of Richk67, but since the branch is still on heavy work, i doubt it would be really usefull nor pertinent to fill bug reports about it.
Although, for sure, feature requests could be done, but (IMHO), they would be better off done right here then on FS.
My opinion only...

[richk67]

Seconded. Well put, Belugas.