Transport Tycoon Forums

Posted: **01 Aug 2011 21:48**

Hi,

For some time OpenTTD have supported for NewGRFs that define new airports. As of now, they can't define new state machines (movement patterns). What they can do is to create more views/rotations of airports. In the OpenGFX+ Airports set there exist a 180 degree rotation of the small airport.

In order to support the NewGRF movements in airports, some work need to be done on the NoAI API. I start this thread in order to open up for thoughts about how this API expansion should be done to keep backward compatibility as good as possible while still providing a good API for the future.

My initial proposal:

We need APIs to interact with views/rotations
Acquire information about airports that previously could be hard coded in the AIs

New:

Code: Select all

AIAirportTypeList()  // List of airport types
AIAirportViewList(airport_type)  // List of available views for a given airport type
AIAirport.IsValidAirportView(airport_view)

These exiting functions would gain an extra argument at the end "airport_view". If possible the argument will default to 0. If not, it will have to become mandatory and the compatibility layer for API 1.1 and lower will provide the old functions with fewer arguments. (given that overloading is supported by Squirrel - if not, these functions have to be renamed)

Code: Select all

AIAirport.GetAirportWidth
AIAirport.GetAirportHeight
AIAirport.BuildAirport
AIAirport.GetNoiseLevelIncrease
AIAirport.GetNearestTown

Since views are just rotations and can not have different introduction dates there is no need to include the concept of views in functions like IsValidAirport and IsAirportInformationAvailable.

To clean up a bit I would propose a rename as follows. I personally think that AIAirport.IsAirportInformationAvailable better fit under the name "IsValid" and the IsValid.. function could go under the name "IsBuildable". However such a rename could potentially cause unnecessary confusion.

Code: Select all

AIAirport.IsValidAirport => AIAirport.IsValidAirportType
AIAirport.IsAirportInformationAvailable => AIAirport.IsAirportTypeInformationAvailable

As for getting more information about airports via the API, now that you soon can't trust hard coded values anymore, I here just give an idea of what I have in my wish-list: (that I also think could be possible to implement) Some of these might not be possible with the current NewGRF Spec. In that case we AI authors will have to work with the NewGRF people to find a solution.

Code: Select all

AIAirport.GetHoldingQueueLength(airport_tile) // Get the number of aircrafts that are waiting to land on the airport
AIAirport.GetNumberOfRunways(airport_type) // Gets the number of runways that a given airport type have
AIAirport.GetNumberOfHelicopterLandingPlaces(airport_type) // Gets the number of places where helicopters can start and land
AIAirport.GetNumberOfLoadingBays(airport_type) // Gets the number of loading bays for aircrafts of a given airport type.

Note that a function such as AIAirport.GetAirportCapacity() will most likely never be possible unless NewGRF authors themselves judge the performance of their airports and hard code some value. Something which might lead to anarchy. For it to work OpenTTD would need to support a way to build airports in memory (but not on the game map) and stress test it, something which is far from easy to do (but not impossible, just a lot of work).

As for actually implementing this it is something that will take some time and I will probably see what I can do, but before getting started with actual code, it is useful to get reflections on this proposal which is just based on my initial thoughts.

Posted: **01 Aug 2011 23:01**

- We need catchment area -> http://wiki.openttd.org/images/thumb/2/ ... ntarea.png
it's base to get cargo, one building a 16 runways airport with a 20x20 airport size with catchment area of 1 is a certain failure, a huge structure, lot of runways, but all aircrafts will be kept loading with too few cargos.

- We need not only runway numbers, but runway usage, a 4 runways airport with 3 takeoff runway+ 1 landing is not the same 2 takeoff + 2 landing runway. (even it's not logic to build a 3+1, newgrf would need to choose for a 3 runways airport).

- We also need runway positions or way to detect runway tiles :
> http://wiki.openttd.org/Image:Airport_m.png
> http://wiki.openttd.org/images/9/9e/Airport_i.png
Because runway position influence airport flow, first one with the two next to each other = an aircraft landing or taking off will block the runway need as it cross it
While for the 2nd airport, as they are oppose, one landing aircraft will never block another from taking off, a better design (for me).
It could be like that, because they have not the same size, but nothing prevent newgrf author from doing that with the same size as the 2nd airport, but still 2 runaways like the 1st airport sample and take space for dunno, fancy graphics, more choppers place, more loading bay...

- A new function to avoid AIStation.GetLocation returning hangar position if a newgrf author add an hangar at topleft position of the airport-> AIAirport.GetLocation() didn't exist for previous AI, so it will kept compatiblity, while specific to airport to not break too much the classic rule, first tile = Location answer.

- Also forget, ensure newgrf can indeed build new airport type, but prevent them from using airport type value (0-8 for now), else older AI API will get in trouble trying to use them thinking it's the "classic" airportype : (like if a newgrf author build an heliport with AirportType 0 and AI mistake that for AT_SMALL (and then trying to use aircrafts on an helipad or something that could only handle choppers).
They will still have 9-254 for their usage, but if none prevent them, sure they will take 0-8 without thinking it could be problematic.

- For the same purpose, because it will have no more usage to have AT_SMALL, AT_LARGE enum in openttd code, i suppose they will get away, so AI authors should stop using them and use value instead, but the enum should be kept for a while for compatiblity. But this could be easy done in the squirrel compatibility file.

Posted: **01 Aug 2011 23:23**

krinn wrote:- we need catchment area -> http://wiki.openttd.org/images/thumb/2/ ... ntarea.png
it's base to get cargo, one building a 16 runways airport with a 20x20 airport with catchment area of 1 is a certain failure, huge things, lot of runway, but all aircrafts will be kept loading with too few cargos.

Since views are just rotations, the coverage radius should not change when airports are rotated. Thus the existing AIAirport.GetAirportCoverageRadius function should be enough.

krinn wrote:- we need not only runaway numbers, but runaway usage, a 4 runaways airport with 3 takeoff runway+ 1 landing is not the same 2 takeoff + 2 landing runaway. (even it's not logic to build a 3+1, newgrf would need to choose for a 3 runways airport).

I'm sure it will be useful to know, question is how easily available this information is.

krinn wrote:- and we also need runway positions or way to detect runway tiles.
look http://wiki.openttd.org/Image:Airport_m.png
and this one : http://wiki.openttd.org/images/9/9e/Airport_i.png
because runway position influence airport flow, first one with the two next to each other = an aircraft landing or taking off will block the runway need as it cross it
while for the 2nd airport, as they are oppose, one landing aircraft will never block another from taking off, a better design (for me).
could be like that, because they have not the same size, but nothing prevent newgrf author from doing that with the same size as the 2nd airport, but still 2 runaways like the 1st airport sample and take space for dunno, fancy graphics, more choppers place, more loading bay...

I don't know if the runways are bound to be on specific tiles. Se for example the diagonal airport available for the "NewGRF Airports" branch. (you need the airports NewGRF available in the thread of that branch).

krinn wrote:and a new answer with AIStation.GetLocation to avoid hangar position at uppertile answer (but just because we're lazzy to figure out where the airport tiles are) -> AIAirport.GetLocation(), didn't exist for previous AI, so keep compatiblity, while specific to airport to not break too much the classic rule, first tile = Location answer

I don't see any proposal on which logic AIStation.GetLocation would have. What is your idea?

Posted: **01 Aug 2011 23:30**

Sadly for AIStation.GetLocation() there's no solve, AI author handle it or not, so it should be kept as-is, adding a note to the AI API AIStation.GetLocation stating it could be unsafe to query an airport location with that function and the good function is AIAirport.GetLocation()
It might be solve without AIAirport.GetLocation() if openttd check AIStation.HasStationType()==AIStation.STATION_AIRPORT and in this case return a tile of the airport if it's not an hangar tile. AI won't see any difference, compatiblity kept.

I forgot the AIAirport.GetAirportCoverageRadius function, it's doing what i was asking

Posted: **01 Aug 2011 23:36**

And in response to your last edits:

krinn wrote:- Also forget, ensure newgrf can indeed build new airport type, but prevent them from using airport type value (0-8 for now), else older ai api will get in trouble trying to use them thinking it's the "classic" airportype. (like if a newgrf build heliport at with airporttype 0 and ai mistake that for AT_SMALL (and then trying to use aircraft on an helipad or something that can only handle choppers)
They will still have 9-254 for their usage, but if none prevent them, sure they will take 0-8 without thinking it could be problematic.

AFAIK, NewGRFs don't say which ID they want. They get an ID assigned by OpenTTD. An ID, which already can't be 0-8. Optionally NewGRFs can decide to override an old airport in which they get a new id above 8. From what I've seen and heard from Planetmaker, the override will make it so that OpenTTD redirects the old id to the new one. A proof on this is to load the OpenGFX+ Airports NewGRF and use any AI of your taste that support airports. If OpenTTD wouldn't handle the override behind the curtains for AIs, they would not be able to build and use small airports properly.

krinn wrote:- For the same purpose, because it will have no more usage to have AT_SMALL, AT_LARGE enum in openttd code, i suppose they will get away, so ai authors should stop using them and use value instead, but the enum should be kept for a while for compatibility. (but this could be easy done in a constant in squirrel compatibility file)

Might be a good idea to deprecate those. Though, if the NewGRF spec will put a restriction that airport overrides must keep the old statemachine, then the constants could be left as they are as they won't do any harm other than suggesting AI authors to hard code airport support)

Posted: **01 Aug 2011 23:43**

krinn wrote:Sadly for AIStation.GetLocation() there's no solve, AI author handle it or not, so it should be kept as-is, adding a note to the AI API AIStation.GetLocation stating it could be unsafe to query an airport location with that function and the good function is AIAirport.GetLocation()
It might be solve without AIAirport.GetLocation() if openttd check AIStation.HasStationType()==AIStation.STATION_AIRPORT and in this case return a tile of the airport if it's not an hangar tile. AI won't see any difference, compatiblity kept.

Already today, if a station have multiple transport modes, you can get a non-airport tile from AIStation.GetLocation(). For example if you join a airport with a train station. In that case the AI author will have to handle the fact that the returned location might not be an airport.

Also, if AIStation.GetLocation() would not keep returning the station sign tile, it could have quite some risk of breaking old AIs. Especially as that is the only way to know where the station sign is.

Posted: **02 Aug 2011 00:08**

If the station have more than just an airport, it will just return the location of the station, if it's the bus station attach to it, you won't get the problem, as the bus station will be a valid destination because the bus is attach to the airport and have same station ID. I didn't really tried it, but i'm "almost" sure you just have to tell the location of the StationID/location and openttd will send the aircraft to the airport part of the joint station and openttd drive the right type of vehicle to the right station part it should go.

The problem will only be seen if an newGRF author design an hangar at the exact position of the tile openttd AIStation.GetLocation is suppose to find a station (that's why it could happen to airport/heliport, as only them could have hangar within the station).

per example, the following code will not do what the AI author expect it to do:

Code: Select all

AIOrder.AppendOrder(aircraftID, AIStation.GetLocation(airportID), AIOrder.ORDER_NONE);

If an hangar is at that position, the aircraft will keep going to the hangar of the airport, and not the airport itself.
This can be easy avoid by AI author, but the author must be aware of it, or the function must make sure a station tile is return

Posted: **02 Aug 2011 20:05**

Zuu wrote:compatibility layer for API 1.1 and lower will provide the old functions with fewer arguments. (given that overloading is supported by Squirrel - if not, these functions have to be renamed)

I do not know about the overloading, but you can override functions with the same name in the compatibility layer and make them call the new ones with different arguments (take a look at existing compatibility layer).

Zuu wrote:Code:
AIAirport.GetHoldingQueueLength(airport_tile) // Get the number of aircrafts that are waiting to land on the airport
AIAirport.GetNumberOfRunways(airport_type) // Gets the number of runways that a given airport type have
AIAirport.GetNumberOfHelicopterLandingPlaces(airport_type) // Gets the number of places where helicopters can start and land
AIAirport.GetNumberOfLoadingBays(airport_type) // Gets the number of loading bays for aircrafts of a given airport type.

Mind that there is a difference between runways for small and for big planes. Resp. specific runways for some aircraft if the small/large thingie is also generalised.

Zuu wrote:krinn wrote:
- For the same purpose, because it will have no more usage to have AT_SMALL, AT_LARGE enum in openttd code, i suppose they will get away, so ai authors should stop using them and use value instead, but the enum should be kept for a while for compatibility. (but this could be easy done in a constant in squirrel compatibility file)

Might be a good idea to deprecate those. Though, if the NewGRF spec will put a restriction that airport overrides must keep the old statemachine, then the constants could be left as they are as they won't do any harm other than suggesting AI authors to hard code airport support)

Those enums will be for sure moved to the compatibility layer. The compatibility layer will then try to find a similar airport, or just fail.

Posted: **10 Aug 2011 10:58**

Can't believe we forgot that one

We have AIEngine::GetPlaneType to know the aircraft type we are about to build, but no way to know if the airport itself will support it.

For now we just use hardcoded values where we know PT_SMALL will accept any but higher death of big planes

We then should have a function to test if an airplanetype is support :

AIAirport.IsPlaneTypeAccept()
Because we cannot guess if AT_HELIPORT will accept PT_SMALL_PLANE

And
AIAirport.IsPlaneTypeSupport()
precondition: AIAirport.IsPlaneTypeAccept()=true
Because we cannot guess if AT_SMALL will not put havock when using PT_BIG_PLANE

With 2 functions like that we should have
true=AIAirport.IsPlaneTypeAccept(AIAirport.AT_SMALL, AIAirport.PT_BIG_PLANE);
false=AIAirport.IsPlaneTypeSupport(AIAirport.AT_SMALL, AIAirport.PT_BIG_PLANE);
false=AIAirport.IsPlaneTypeAccept(AIAirport.AT_HELIPORT, AIAirport.PT_BIG_PLANE);
false=AIAirport.IsPlaneTypeSupport(AIAirport.AT_HELIPORT, AIAirport.PT_BIG_PLANE);

Note: AIAirport.GetNumberOfHelicopterLandingPlaces() could still be use, even it answer like AIAirport.IsPlaneTypeAccept to the question: do that airport accept chopper, there's still room for it as one AI author that wish only do choppers might be interrest to know what choppers flow an airport could handle.
I think it's a better handling in case one newGRF author wish add an airporttype that only accept PT_BIG_PLANE but refuse PT_SMALL_PLANE (as intercontinental airport should, international airport are too busy to handle small planes).

Posted: **21 Aug 2011 15:43**

Here is a patch that adds AIAirportTypeList and moves the airport type enums to the compatatibility .nut-files for 0.7 to 1.1.

Since, the API doesn't yet have enough functions to rate airport types I think this patch will have to wait a bit, but it should otherwise be working. It does however not fix the problem in OpenTTD that eg. airport type 40 have IsAvailable() == true even if no NewGRF defines it. A problem that really have to be solved before committing this patch.

Posted: **22 Aug 2011 16:49**

Should already return 255; so futur version and api users won't trigger an error

Code: Select all

diff -r 59410fc6ced9 src/ai/api/ai_airport.cpp
--- a/src/ai/api/ai_airport.cpp	Fri Aug 19 23:38:11 2011 +0200
+++ b/src/ai/api/ai_airport.cpp	Sat Aug 20 00:19:03 2011 +0200
@@ -113,7 +113,7 @@
 	return st->airport.GetHangarTile(0);
 }
-/* static */ AIAirport::AirportType AIAirport::GetAirportType(TileIndex tile)
+/* static */ AirportType AIAirport::GetAirportType(TileIndex tile)
 {
 	if (!AITile::IsStationTile(tile)) return AT_INVALID;

thank you zuu, i think you've made the first step to big changes ^^

Posted: **22 Aug 2011 18:22**

krinn wrote:Should already return 255; so futur version and api users won't trigger an error

Sorry, I don't understand what you mean. Could you try to be more precise?

Posted: **22 Aug 2011 18:51**

This patch adds AIVehicle.IsInHolding(vehicle_id) that checks if an aircraft is in holding state. Be aware that it only works when airplanes are in holding for the city airport due to missing encoding of the holding patterns of the other airport types.

My quick try to change the other airports resulted in aircrafts being "in holding" after departure from the country airport. Thus, this patch also has to be put on hold.

Posted: **22 Aug 2011 20:01**

i mean that code should be change already as it won't affect players/AI but can affect futur ai when the noai api will state the AT enum is drop for good.
So if a futur ai is set to use that new api version where the enum are drop, the return AT_INVALID will trigger an error as AT_INVALID is only define in the compatibility file.

Code: Select all

if (!AITile::IsStationTile(tile)) return AT_INVALID;

change to

Code: Select all

if (!AITile::IsStationTile(tile)) return 255;

Posted: **22 Aug 2011 20:08**

Code: Select all

@@ -176,6 +177,13 @@
 	return ::Vehicle::Get(vehicle_id)->IsStoppedInDepot();
 }
 
+/* static */ bool AIVehicle::IsInHolding(VehicleID vehicle_id)
+{
+	if (!IsValidVehicle(vehicle_id)) return false;
+	if (!::Aircraft::IsValidID(vehicle_id)) return false;
+	return ::Aircraft::Get(vehicle_id)->IsInHoldning();
+}
+

typo: IsInHoldning();

ah looks like not, it's your const name

Posted: **22 Aug 2011 20:36**

krinn wrote:typo: IsInHoldning();

ah looks like not, it's your const name

Good spot. I've changed it to Holding which I think should be correct. (and google agrees)

Updated patch:

aircraft_in_holding2_r22713.patch: (3.89 KiB) Downloaded 163 times

krinn wrote:i mean that code should be change already as it won't affect players/AI but can affect futur ai when the noai api will state the AT enum is drop for good.
So if a futur ai is set to use that new api version where the enum are drop, the return AT_INVALID will trigger an error as AT_INVALID is only define in the compatibility file.
Code: Select all
if (!AITile::IsStationTile(tile)) return AT_INVALID;
change to
Code: Select all
if (!AITile::IsStationTile(tile)) return 255;

Ah, now I see what you mean. AT_INVALID is however defined elsewhere to be 255. So the code will compile still. And there are already two functions available for AIs to check if an airport type is valid or not. (with different criteria for the 'valid' part)

Posted: **23 Aug 2011 21:59**

Some progress: (the AI can get the information displayed about airport types without building them)

: AIAirportType.png (11.74 KiB) Viewed 1300 times

Yexo told me yesterday that the function CanPlaneTypeLand might not keep working in future with NewGRF airports. That said, I'm not too worried right now. There is problems for the GUI as well as AIs if this information can not be determined, so I don't think the spec will break this function. (other than that the implementation will have to change in case more plane types are allowed)

api-split_r22713.patch: Applies to clean r22713; (33.74 KiB) Downloaded 173 times

airport-type-api-extension_r22713.patch: Applies on top of api-split_r22713.patch; (6.53 KiB) Downloaded 164 times

The coding style is not 100% in the patches above. I know there is at least one instance of a forgotten space before '(' in a if/switch/for statement. This is more a report of progress rather than a request for review on the coding style. Comments on the API changes on the other hand are welcome.

Open question: Dose PlaneType fit better in AIAirport or AIAirportType?

In a later patch in my queue I plan to add views. The views will go into both AIAirportType and AIAirport.BuildAirport. There will probably also need to be a query function in AIAirport to get the view of an already built airport. (for those who don't know, views are different rotated variants of the same airport. all views of an airport must use the same state machine, only rotated)

Posted: **24 Aug 2011 00:40**

Zuu wrote:Yexo told me yesterday that the function CanPlaneTypeLand might not keep working in future with NewGRF airports. That said, I'm not too worried right now. There is problems for the GUI as well as AIs if this information can not be determined, so I don't think the spec will break this function. (other than that the implementation will have to change in case more plane types are allowed)

Well, changing the

Code: Select all

+		default:
+			NOT_REACHED();

to

Code: Select all

+		default:
+			return false;

If a newGRF introduce a new kind of PlaneType, ai author cannot know it (as we have no PlaneTypeList to browse (for now)), but even not knowing it, ai can still grab that info from a vehicle with AIEngine.GetPlaneType()
this way even a newGRF introduce a new plane type, and even the ai cannot be aware of that new type and can use that new type taken from AIEngine.GetPlaneType answer, the function will just tell the ai that this new plane type is not usable on anything.
Else, as Yexo point out, the NOT_REACHED will be reach

Posted: **24 Aug 2011 06:18**

krinn wrote:If a newGRF introduce a new kind of PlaneType, ai author cannot know it (as we have no PlaneTypeList to browse (for now)), but even not knowing it, ai can still grab that info from a vehicle with AIEngine.GetPlaneType()
this way even a newGRF introduce a new plane type, and even the ai cannot be aware of that new type and can use that new type taken from AIEngine.GetPlaneType answer, the function will just tell the ai that this new plane type is not usable on anything.
Else, as Yexo point out, the NOT_REACHED will be reach

Ultimately, a new label system may be required for aircraft/airport combinations, similar to railtypes.

Posted: **24 Aug 2011 10:23**

krinn:

Above in the same function this code makes sure that the plane_type is an expected type.

Code: Select all

if (!IsPlaneTypeValid(plane_type)) return false;

You are right that the implementation does not support a future plane type that the current NewGRF spec + OpenTTD code does not allow NewGRFs to implement. However, I don't see any way to do that as there is nothing too hook into yet. My idea instead was to make the API so that it will be trivial for AIs to support new plane types when OpenTTD is extended to support more plane types. Then of course the API function has to change its implementation as it now hardcode support to specific plane types as there is no general concept for that yet in OpenTTD.

An AIPlaneTypeList is something I have though of but it's something that is not high priority for now. It's not a central part of the API changes and can easily be coded at the end without influence of other parts.

krinn wrote:Else, as Yexo point out, the NOT_REACHED will be reach

That's not what Yexo pointed out. As far as I've understood him, he was more worried on the possibility of being able to implement a function that can operate on all input values and all possible NewGRFs in the future. The fact that the implementation has to change when PlaneTypes are generalized in the core of OpenTTD is not a problem.

Transport Tycoon Forums

AIAirport API improvements - towards better NewGRF support

AIAirport API improvements - towards better NewGRF support

Re: AIAirport API improvements - towards better NewGRF suppo

Re: AIAirport API improvements - towards better NewGRF suppo

Re: AIAirport API improvements - towards better NewGRF suppo

Re: AIAirport API improvements - towards better NewGRF suppo

Re: AIAirport API improvements - towards better NewGRF suppo

Re: AIAirport API improvements - towards better NewGRF suppo

Re: AIAirport API improvements - towards better NewGRF suppo

Re: AIAirport API improvements - towards better NewGRF suppo

Re: AIAirport API improvements - towards better NewGRF suppo

Re: AIAirport API improvements - towards better NewGRF suppo

Re: AIAirport API improvements - towards better NewGRF suppo

Re: AIAirport API improvements - towards better NewGRF suppo

Re: AIAirport API improvements - towards better NewGRF suppo

Re: AIAirport API improvements - towards better NewGRF suppo

Re: AIAirport API improvements - towards better NewGRF suppo

Re: AIAirport API improvements - towards better NewGRF suppo

Re: AIAirport API improvements - towards better NewGRF suppo

Re: AIAirport API improvements - towards better NewGRF suppo

Re: AIAirport API improvements - towards better NewGRF suppo