Some API extension ideas
Moderator: OpenTTD Developers
Some API extension ideas
I was unable to find a function that returned the design year of a vehicle, so something like:
AIEngine::GetDesignYear (EngineID engine_id)
Also some functions for AIAbstractList:
- A way to get the list items as a squirrel array (discarding the values)
- Counting functions to complement the RemoveAboveValue, RemoveBelowValue, RemoveBetweenValue, RemoveValue
Edit: And ofcourse these constants for sorting direction:
AIAbstractList.SORT_ASCENDING <- true;
AIAbstractList.SORT_DESCENDING <- false;
AIEngine::GetDesignYear (EngineID engine_id)
Also some functions for AIAbstractList:
- A way to get the list items as a squirrel array (discarding the values)
- Counting functions to complement the RemoveAboveValue, RemoveBelowValue, RemoveBetweenValue, RemoveValue
Edit: And ofcourse these constants for sorting direction:
AIAbstractList.SORT_ASCENDING <- true;
AIAbstractList.SORT_DESCENDING <- false;
Last edited by Chruker on 19 Jul 2009 13:34, edited 1 time in total.
Re: Some API extension ideas
What is the reason for wanting to know the design year? Before that year the engine is unavailable, and unavailable EngineIDs are invalid for the AI. So you would only be able to call GetDesignYear when the engine is available, and that seems to defeat the point.Chruker wrote:I was unable to find a function that returned the design year of a vehicle, so something like:
AIEngine::GetDesignYear (EngineID engine_id)
A good idea.Also some functions for AIAbstractList:
- A way to get the list items as a squirrel array (discarding the values)
Are you asking for seperate functions (CountAboveValue, CountBelowValue, etc.) or are you asking that RemoveAboveValue should return the number of items removed?- Counting functions to complement the RemoveAboveValue, RemoveBelowValue, RemoveBetweenValue, RemoveValue
Re: Some API extension ideas
I'm playing around with the possibilities of NoAI, and my first approach is based on an idea for a model of expansion of small nested networks.
In my experiment I'm exploring the use of helicopters, so undervalued by most players (low benefit). The project is still very immature to anyone who might be interested to see what I have, but no doubt that if I achieve something that seems to me interesting, I'll share it.
In giving orders to the helicopters I found an error when the destination airport is an helistation. The reason is the upper corner of it is an hangar tile, and isn't accepted as a valid destination. I solved it with
but I'm asking myself if a new function like
but for an AirportTile would be interesting to add to the API. Maybe
It could solve the same problem with some other new airport type...
In my experiment I'm exploring the use of helicopters, so undervalued by most players (low benefit). The project is still very immature to anyone who might be interested to see what I have, but no doubt that if I achieve something that seems to me interesting, I'll share it.
In giving orders to the helicopters I found an error when the destination airport is an helistation. The reason is the upper corner of it is an hangar tile, and isn't accepted as a valid destination. I solved it with
Code: Select all
if (AIAirport.IsHangarTile(tile)) { tile += AIMap.GetTileIndex(1,0); }
Code: Select all
AIAirport::GetHangarOfAirport(tile)
Code: Select all
AIAirport::GetRunwayOfAirport(tile)
Re: Some API extension ideas
The API does exactly what you tell it to do. You give it a goto-depot order by clicking on the hangar. Your fix is correct.Abenhor wrote:In giving orders to the helicopters I found an error when the destination airport is an helistation. The reason is the upper corner of it is an hangar tile, and isn't accepted as a valid destination.
But it also clutters the API. And how to name such a function? AirportHelistations don't have a runway at all. What you want is something like: AIAirport::GetNonHangarTileOfAirport(tile / station_id). For now you can easily implemented in squirrel by looping over the airport tiles (using GetAirportWidth / GetAirportHeight).but for an AirportTile would be interesting to add to the API. MaybeIt could solve the same problem with some other new airport type...Code: Select all
AIAirport::GetRunwayOfAirport(tile)
Re: Some API extension ideas
I plan to use it to detect if an engine if within phase 2 of its reliability. So ex. only select engine designs that are between 5 and 25 years.Yexo wrote:What is the reason for wanting to know the design year? Before that year the engine is unavailable, and unavailable EngineIDs are invalid for the AI. So you would only be able to call GetDesignYear when the engine is available, and that seems to defeat the point.Chruker wrote:I was unable to find a function that returned the design year of a vehicle, so something like:
AIEngine::GetDesignYear (EngineID engine_id)
Seperate functions. However I was planning to check if the remove request would empty the list, but I think I for that purpose could just use the keeptop(x) function... but I'm sure there are other situations where it could be helpfull (I'm thinking something where looping over the list in squirrel would be much slower than having the engine do the looping)Yexo wrote:A good idea.Also some functions for AIAbstractList:
- A way to get the list items as a squirrel array (discarding the values)Are you asking for seperate functions (CountAboveValue, CountBelowValue, etc.) or are you asking that RemoveAboveValue should return the number of items removed?- Counting functions to complement the RemoveAboveValue, RemoveBelowValue, RemoveBetweenValue, RemoveValue
Re: Some API extension ideas
Another one:
AIVehicle::GetReliability(vehicle_id)
To get the current reliability of a vehicle, so that I can determine if it has some trouble finding depots.
AIVehicle::GetReliability(vehicle_id)
To get the current reliability of a vehicle, so that I can determine if it has some trouble finding depots.
Re: Some API extension ideas
Good one. I'll implement it as soon as I find the time.Chruker wrote:Another one:
AIVehicle::GetReliability(vehicle_id)
To get the current reliability of a vehicle, so that I can determine if it has some trouble finding depots.
Re: Some API extension ideas
AIVehicle::GetReliability is implemented in r16790.
AIEngine::GetDesignYear <- I'm not sure whether this is the best way of exposing this information.
- A way to get the list items as a squirrel array (discarding the values) <- can easily done in squirrel (see utils/ directory in AdmiralAI source code)
- Counting functions to complement the RemoveAboveValue, RemoveBelowValue, RemoveBetweenValue, RemoveValue <- Can be usefull, but at first I see more use in changing the current functions to return the number of deleted / remaining items.
AIAirport::GetRunwayOfAirport(tile) <- for now, just implement it in squirrel
I hope that covers all requested functions in this topic, if not, or if you don't agree with one of the above, please comment.
AIEngine::GetDesignYear <- I'm not sure whether this is the best way of exposing this information.
- A way to get the list items as a squirrel array (discarding the values) <- can easily done in squirrel (see utils/ directory in AdmiralAI source code)
- Counting functions to complement the RemoveAboveValue, RemoveBelowValue, RemoveBetweenValue, RemoveValue <- Can be usefull, but at first I see more use in changing the current functions to return the number of deleted / remaining items.
AIAirport::GetRunwayOfAirport(tile) <- for now, just implement it in squirrel
I hope that covers all requested functions in this topic, if not, or if you don't agree with one of the above, please comment.
Re: Some API extension ideas
AwesomeYexo wrote:AIVehicle::GetReliability is implemented in r16790.
Thats the best I could think ofYexo wrote:AIEngine::GetDesignYear <- I'm not sure whether this is the best way of exposing this information.
Very easily, it was more to add to the basic AIAbstractList functionality. Main reason I was looking for an API call was for speed. (I have not done any speed testing.)Yexo wrote:- A way to get the list items as a squirrel array (discarding the values) <- can easily done in squirrel (see utils/ directory in AdmiralAI source code)
Returning numbers using the existing functions is also usefull. But as with the above function the main reason for the API calls is for speed.Yexo wrote:- Counting functions to complement the RemoveAboveValue, RemoveBelowValue, RemoveBetweenValue, RemoveValue <- Can be usefull, but at first I see more use in changing the current functions to return the number of deleted / remaining items.
Re: Some API extension ideas
No offending. Well, I think :
one of Chruker point is something like 'AIAbstractList..CountIfRemoveValue(x)'
without actually remove items.
AFAIK, if something could be done in squirrel it would not go into API, because it has no opcode restriction. thus make the game run slower due to much resources was needed by AI.
for example: play on 512x512 map.
create an AITileList and fill with all tiles of map.
Valuate this list and the game will not run as smooth as if you evaluate this list using for-loop in squirrel.
well, I think game speed is on top off AI speed. and current AIAbstractList still have much power to do it job.
am I right?
one of Chruker point is something like 'AIAbstractList..CountIfRemoveValue(x)'
without actually remove items.
AFAIK, if something could be done in squirrel it would not go into API, because it has no opcode restriction. thus make the game run slower due to much resources was needed by AI.
for example: play on 512x512 map.
create an AITileList and fill with all tiles of map.
Valuate this list and the game will not run as smooth as if you evaluate this list using for-loop in squirrel.
well, I think game speed is on top off AI speed. and current AIAbstractList still have much power to do it job.
am I right?
Re: Some API extension ideas
Yeah, that was the point.fanioz wrote:No offending. Well, I think :
one of Chruker point is something like 'AIAbstractList..CountIfRemoveValue(x)'
without actually remove items.
Re: Some API extension ideas
Some better debug information would also be nice. Currently you have to throw an exception to get error messages with line number, file name and call stack.
Squirrel have a function called getstackinfos which returns an array like this:
But that was disabled to avoid AIs being too dependant on squirrel internals, so that updating the AIs to the NAIL would be easier.
Anyway when is NAIL even due?
Squirrel have a function called getstackinfos which returns an array like this:
Code: Select all
{
func="DoStuff", //function name
src="test.nut", //source file
line=10, //line number
locals = { //a table containing the local variables
a=10,
testy="I'm a string"
}
}
Anyway when is NAIL even due?
Re: Some API extension ideas
I think allowing the AI to interact with the game interface to some extent would be helpful for debugging.
There would need to be an interface option in the main menu "bool Allow_AI_To_Use_Interface_Controls"
Proposed methods:
AIGameInterface.PauseGame(uint ticks); //Allows the AI to pause the game for a while to allow the author to examine game state at specific times.
AIGameInterface.CenterScreenOnTile(tile); //Moves the screen to the tile.
AIGameInterface.OpenExtraViewPort(tile); //Opens a viewport centered on the tile.
-Dustin
There would need to be an interface option in the main menu "bool Allow_AI_To_Use_Interface_Controls"
Proposed methods:
AIGameInterface.PauseGame(uint ticks); //Allows the AI to pause the game for a while to allow the author to examine game state at specific times.
AIGameInterface.CenterScreenOnTile(tile); //Moves the screen to the tile.
AIGameInterface.OpenExtraViewPort(tile); //Opens a viewport centered on the tile.
-Dustin
Re: Some API extension ideas
While I agree some better debugging facilities would be nice, its probably not a great idea to allow AIs control over the UI.
Just Sleep() for something like 1000 ticks to give you time to hit puase yourself.Dustin wrote:AIGameInterface.PauseGame(uint ticks);
Just place a sign with some text that you'll recongise, and then wait for it to show up in the sign list. Then you can clikc the name in the sign list and the view will centre on it.Dustin wrote:AIGameInterface.CenterScreenOnTile(tile);
AIGameInterface.OpenExtraViewPort(tile);
PathZilla - A networking AI - Now with tram support.
Re: Some API extension ideas
I agree.Zutty wrote:While I agree some better debugging facilities would be nice, its probably not a great idea to allow AIs control over the UI.
On the other hand, if you really want these functions, it's easy to add them to the API and compile OpenTTD yourself.
Re: Some API extension ideas
Will a sleep run out if I pause the game? What I really want is sort of a debugger effect, so it would step one iteration at a time under my control.Zutty wrote:While I agree some better debugging facilities would be nice, its probably not a great idea to allow AIs control over the UI.
Just Sleep() for something like 1000 ticks to give you time to hit puase yourself.Dustin wrote:AIGameInterface.PauseGame(uint ticks);
Just place a sign with some text that you'll recongise, and then wait for it to show up in the sign list. Then you can clikc the name in the sign list and the view will centre on it.Dustin wrote:AIGameInterface.CenterScreenOnTile(tile);
AIGameInterface.OpenExtraViewPort(tile);
I am doing this stuff what you describe. But I am at the point where the things that I need to see are between long periods of nothing much interesting. I would be nice to leave it to run and have it pause and change focus. So I can, say, do the dishes while the AI runs until it hits an interesting point and stops.
I agree it might not be nice to have the AI mess with the screen while you are using it, so those options would have to be disabled unless you check "Allow AI controll of interface for AI debugging." in the Interface menu.
Re: Some API extension ideas
In my Helper class in PAXLink I have a function that creates a break point. It is called with a tile as argument and it places a "break" sign on that tile and waits until the sign gets removed. In addition it requires debuging to be on and I think also it needs a "enable breakpoints" sign to be present.
The exact text on the signs may not be what I have written as it is out of my mind and not from the code.
If you apply my Filter Sign List patch you can make it so only break point signs appear (or rather all signs that contain "break") in the sign list.
The exact text on the signs may not be what I have written as it is out of my mind and not from the code.
If you apply my Filter Sign List patch you can make it so only break point signs appear (or rather all signs that contain "break") in the sign list.
My OpenTTD contributions (AIs, Game Scripts, patches, OpenTTD Auto Updater, and some sprites)
Junctioneer (a traffic intersection simulator)
Junctioneer (a traffic intersection simulator)
Re: Some API extension ideas
Interesting. I had thought of doing something similar, but didn't want to spend time meta-programming when my AI still has so many rough edges.Zuu wrote:In my Helper class in PAXLink I have a function that creates a break point. It is called with a tile as argument and it places a "break" sign on that tile and waits until the sign gets removed. In addition it requires debuging to be on and I think also it needs a "enable breakpoints" sign to be present.
The exact text on the signs may not be what I have written as it is out of my mind and not from the code.
If you apply my Filter Sign List patch you can make it so only break point signs appear (or rather all signs that contain "break") in the sign list.
Re: Some API extension ideas
Hello,
I would like to determine the age of stations, which is something a player can do with the query tool if he has forgotten how new a station/connection is.
I am trying to write the save/load for CluelessPluss so that the save-function does not do anything and when a save game is loaded it reads stuff from the map and construct the internal data structures from that. Now, one of the things CluelessPlus uses for its internal management is the date a connection was built. I though it would be a good approximation to use the date one of the stations were built. But may opt for picking the age of the oldest vehicle of a connection.
For implementing, one suggestion could be to add a GetConstructionDate(station_id) function to AIStation.
I would like to determine the age of stations, which is something a player can do with the query tool if he has forgotten how new a station/connection is.
I am trying to write the save/load for CluelessPluss so that the save-function does not do anything and when a save game is loaded it reads stuff from the map and construct the internal data structures from that. Now, one of the things CluelessPlus uses for its internal management is the date a connection was built. I though it would be a good approximation to use the date one of the stations were built. But may opt for picking the age of the oldest vehicle of a connection.
For implementing, one suggestion could be to add a GetConstructionDate(station_id) function to AIStation.
My OpenTTD contributions (AIs, Game Scripts, patches, OpenTTD Auto Updater, and some sprites)
Junctioneer (a traffic intersection simulator)
Junctioneer (a traffic intersection simulator)
Re: Some API extension ideas
Added the constants to the list.
AIAbstractList.SORT_ASCENDING <- true;
AIAbstractList.SORT_DESCENDING <- false;
AIAbstractList.SORT_ASCENDING <- true;
AIAbstractList.SORT_DESCENDING <- false;
Who is online
Users browsing this forum: No registered users and 4 guests