API for 1.3.1-RC1

[Aphid]

What is the proper API version for 1.3.1?

E.g. a script with

Code: Select all

	function GetAPIVersion()	{ return "1.4"; }

in the info.nut file will work with all Nightly editions beyond 1.3 which have the required functions in them (if any new functionality is used). It will not work with 1.3.1 RC1, however.

Using:

Code: Select all

	function GetAPIVersion()	{ return "1.3"; }

will not work with the functions for 1.3.1; or any more recent functions for that matter. Using

Code: Select all

	function GetAPIVersion()	{ return "1.3.1"; }

OR

Code: Select all

	function GetAPIVersion()	{ return "1.3.1-RC1"; }

Doesn't work at all (script will not even appear in trunk).

[Brumi]

I think 1.3 should be the correct choice. What exactly does not work?

[Zuu]

On bananas you will be able to select 1.3.1 as minimum version when its out. That will not stop someone to have 1.3.1 and 1.3.0 installed on the same machine and grab your AI using 1.3.1 and then play with it in 1.3.0.

However, I also wonder what in 1.3.1 is it that you need that is not in 1.3.0?

[planetmaker]

On bananas you will be able to select 1.3.1 as minimum version when its out. That will not stop someone to have 1.3.1 and 1.3.0 installed on the same machine and grab your AI using 1.3.1 and then play with it in 1.3.0.

However, I also wonder what in 1.3.1 is it that you need that is not in 1.3.0?

Maybe http://vcs.openttd.org/svn/changeset/25 ... ngelog.hpp ?

[Aphid]

It's not 'bananas' I'm worrying too much about, that is just the distribution. If that fails it just means people wanting to play a script on 1.3.1 RC1 can download it via the forums or manually on bananas. The scripts themselves also have to specify an API version. That is done through the callback function GSController::GetAPIVersion, henceforth addressed as 'GetAPIVersion, which allows the script author to specify an API version and use it later in the script. What's the version that's:

- Available in 1.3.1 RC1
- Has the following function in it:

introduce GetTerrainType

This function is NOT in API version 1.3. If I use it in my script I need to specify a later version. '1.4' is incorrect for it does not exist in 1.3.1 RC1. What do I need to specify for 1.3.1. RC1 to get access to this function in that version of the openTTD client as my 'GetAPIVersion' function? It currently seems to me that this function is inaccessible due to an oversight.

Specifically the following things happen:

- Up until now API functions have only been introduced in major revisions.
- New functionality gets introduced in a minor revision.
- The versioning system breaks down.
- The new functionality is unavailable in some versions of OpenTTD where it does exist.

Unless there actually does exist some calling scheme for minor revisions for 'GetAPIVersion'. I can't fathom what it is out of thin air though, so that's the question.

[planetmaker]

- Up until now API functions have only been introduced in major revisions.

Not really... http://noai.openttd.org/api/1.3.0/ai__c ... _8hpp.html

Additionally to declaring 1.3 API version you need to check OpenTTD version, if you want to check vor availability of features introduced in a bug fix release: http://noai.openttd.org/api/1.3.0/class ... 435ab8047f

[Aphid]

http://nogo.openttd.org/api/trunk/class ... e1a795c3a5

What valid return value is for 1.3.1 RC1?

I -know- the feature exists in 1.3.1 RC1. I just can't get it to actually work because there's no compatibility layer.

[planetmaker]

1.3.1-RC1 is part of the 1.3 branch. Thus you use API version 1.3. The API version does not change within a branch.

[Rubidium]

The API version is meant for backward compatability when we change APIs (rename or remove). Not (really) for the addition of APIs; we don't actively hide APIs in the compatability script, so even if you set API compatability 0.7 you will be able to get the GetTerrainType function.

[Steffl]

But there is still the problem when someone who still plays with 1.3.0 then uses this AI which uses functions introtruced in 1.3.1-RC1. The old version think it can run the AI, but it can't because it don't understand the new function the AI uses.
Ok, you can set the right version in bananas, but there are other ways to get an AI, too.

[Rubidium]

Then you need to check for the appropriate version and use a fallback if it is not new enough.

[Zuu]

An alternative way to check for specific APIs is this solution:

API detection
edit: the smart version

Code: Select all

if ("GetTerrainType" in AITile) {}

Should works for any openttd versions.

This way you explicitly check for the API method rather than going via OpenTTD version.


Eg. Set 1.3 as API version in your AI and then use fallback code if the API is not available. Many Linux distros only supply 1.x.0 and don't update to the point releases. So there is a user base who will be stuck at 1.3.0 and not get 1.3.1. SuperLib version 28 will contain a fallback method for checking if a town is desert/snow town in OpenTTD versions before 1.3.1. However, that is mainly intended to GSes who alter the town cargo goals. For AIs you can just check the town cargo goal directly and do not need to go via the tile terrain type of the town.


Edit: Here is the API to check cargo delivery requirements of towns: http://nogo.openttd.org/api/1.3.0/class ... 56f8722d04