Discuss the new AI features ("NoAI") introduced into OpenTTD 0.7, allowing you to implement custom AIs, and the new Game Scripts available in OpenTTD 1.2 and higher.
Zutty wrote:
Is there some way to tell a vehicle to skip an order with the API, and if not do you think it would be possible to implement it (I'd put in a feature request)?
Reading is challange Hehe Okay, it is not in the place you might expect, but still
AHA!! I KNEW it must have been in there somewhere, but I spent ages straining at the AIOrder doc page to find some cryptic wording or something!! Cheers
Fairly obvious what it does when you see it, but its not clear from the API docs/Wiki that you can do this, and the first time I needed this I did it the hard way by getting the current tiles x/y. Just posting it to point out that prehaps the documentation shouldn't assume a AI developer is familiar with the games source.
Edit: Another thing, when tostring'ing a tile into the debug window, you get decimal, but the query land tool displays a tiles location as hex, this is sort of annoying.
Zutty wrote:
Is there some way to tell a vehicle to skip an order with the API, and if not do you think it would be possible to implement it (I'd put in a feature request)?
Reading is challange Hehe Okay, it is not in the place you might expect, but still
Errrr hang on a sec, another question... where do I get that order ID from? It isn't returned by AIOrder.AppendOrder(), and there is no method to enumerate orders for a vehicle. How am I supposed to know what order IDs to use?
Am I missing something?
Edit: Aaaah! Its zero based per vehicle isn't it?! When it said orderID I had assumed it was a globally unique ID.
I think this should go in the Wiki. Its not obvious! (At least, that's my excuse!)
Last edited by Zutty on 28 May 2008 20:11, edited 1 time in total.
Zutty wrote:
Errrr hang on a sec, another question... where do I get that order ID from? It isn't returned by AIOrder.AppendOrder(), and there is no method to enumerate orders for a vehicle. How am I supposed to know what order IDs to use?
Am I missing something?
Very good point. You can safely assume the logic order of the order_id, going from 0 to N - 1, where N is the amount of added orders. Append adds a new at the end, Insert at the point you request (documentation is clear there ).
AppendOrder can't return the order_id, because if you do:
(this is pseudocode of course!!), the order added with AppendOrder is no longer order_id '0'. So it would be very useless. I will extend the documentation to tell you what order_id is exactly, and how you can use it.
The only thing necessary for the triumph of evil is for good men to do nothing.
Fairly obvious what it does when you see it, but its not clear from the API docs/Wiki that you can do this, and the first time I needed this I did it the hard way by getting the current tiles x/y. Just posting it to point out that prehaps the documentation shouldn't assume a AI developer is familiar with the games source.
Edit: Another thing, when tostring'ing a tile into the debug window, you get decimal, but the query land tool displays a tiles location as hex, this is sort of annoying.
Feel free to add it to the wiki. Instead of complaining, you can make yourself useful too
The only thing necessary for the triumph of evil is for good men to do nothing.
Zutty wrote:
Errrr hang on a sec, another question... where do I get that order ID from? It isn't returned by AIOrder.AppendOrder(), and there is no method to enumerate orders for a vehicle. How am I supposed to know what order IDs to use?
Am I missing something?
Very good point. You can safely assume the logic order of the order_id, going from 0 to N - 1, where N is the amount of added orders. Append adds a new at the end, Insert at the point you request (documentation is clear there ).
AppendOrder can't return the order_id, because if you do:
(this is pseudocode of course!!), the order added with AppendOrder is no longer order_id '0'. So it would be very useless. I will extend the documentation to tell you what order_id is exactly, and how you can use it.
That makes sense, thanks
I'm used to Java and such, where everything is very very explicit!! I'll get the hang of this eventually!
DaleStan wrote:Beg pardon? The return value from AppendOrder should be guaranteed to remain valid in spite of any possible future changes to the order list?
Isn't this like saying that the return value from strlen should remain valid after a following strcat?
From my understanding of it, the identifier is the index of an order within the vehicles order list.
From the example given, it'd be like strpos(0) doesn't equal strpos(0) after appending a character to the front of the string (prepending?).
Hey I have a REEAALLY cheeky request! Could we please have a sync with trunk at your soonest convenience, if you're not too busy! (See how nice I am?!)
The bug that causes difficulty settings not to be saved is REALLY annoying, but I notice that its been fixed in trunk. (r13309)
Zutty wrote:Hey I have a REEAALLY cheeky request! Could we please have a sync with trunk at your soonest convenience, if you're not too busy! (See how nice I am?!)
The bug that causes difficulty settings not to be saved is REALLY annoying, but I notice that its been fixed in trunk. (r13309)
Awesome, that bug was annoying. Automated builds back, synced so bugs are fixed, you guys are awesome at this.
I'll have to hold off more work on my AI, I've got exams until mid-June. I'll hang around though, if I get some time I'll start updating the wiki some more.
All coast tile are of the 'water' class by design. Otherwise you'd have different types for coast tiles where one can run ship on and coast tiles one can't run ships on. Furthermore building on coast tiles is way more expensive than not building on coast tiles.
The town's location is by default a road tile. However, the tile might be removed by a player using a cheat so there is no 100% guarantee that the tile will always be a road tile.
Rubidium wrote:All coast tile are of the 'water' class by design. Otherwise you'd have different types for coast tiles where one can run ship on and coast tiles one can't run ships on. Furthermore building on coast tiles is way more expensive than not building on coast tiles.
The town's location is by default a road tile. However, the tile might be removed by a player using a cheat so there is no 100% guarantee that the tile will always be a road tile.
Really? This is hugely useful information!
A) I can do [IsWater() && GetSlope() > 0] to detect shore tiles, for bridge construction. Ive been wondering how I would figure this out!
B) My current method for urban road planning is to find a "seed" road tile in a radius around a town's location, but 1% of the time that fails totally! Knowing this, I can drop that flaky operation altogether!
Not being an OpenTTD developer, there must be something that I don't know about that would seem obvious to you guys. Are there any other neat tricks you can tell us?
Zutty wrote:
Not being an OpenTTD developer, there must be something that I don't know about that would seem obvious to you guys. Are there any other neat tricks you can tell us?
Wikify the ones you find
The only thing necessary for the triumph of evil is for good men to do nothing.
I was going to post a separate thread for this, but it doesn't seem worth it!
--
I'm stuck in a bit of a conundrum at the moment. I'm making efforts to make my AI not only optimal but also globally effective, i.e. it should make the best use of ALL resources on the map. I'm not saying it IS optimal yet... my implementation is FAR from perfect, and the global construction idea is still in its infancy and a bit naive yet, but still. I am striving for the optimum, to the best of my abilities!!
The problem with this though is that if two instances of the AI were started they would BOTH try to build a road network that spans the whole map, i.e. everything on the map could possibly be connected to everything else TWICE! (I haven't actually tried this yet, but its a worry) More to the point though they would both do EXACTLY the same things at the same times in the same places. If they started at the same time they would just try to build roads on top of each other! This would lead either to a horrific mess of roads that wind around each other, or worse yet deadlock if they started trying to build identical roads at precisely the same moment ('who can build this road tile first' would become a race condition). I know that a bit of randomness in the decision making process would alleviate this, but eventually two instances of the same AI are BOUND to collide like this. Having the same strategies, they would never be far from one another.
But then this got me thinking. If two hypothetical AIs written by two different developers were both PERFECTLY optimal, would they ALSO try to do the exact same things all the time and collide constantly in this way? My point here this... Is that is there much point in creating an AI that is completely optimal? If ALL our AIs choose coal or valuables first then those resources are going to run out very quickly! If they all start in the largest city then there's going to be an awful lot of traffic there! If they all choose the area with the highest density of industries then its going to get rather overcrowded.
Obviously you still want the AI to make sensible decisions, but there must be some means to inject a bit of variety in order to combat this problem. Possible means that I can think of include...
- Random seeds
- Sensitivity to competition and an excess of service in any area
- Specialisation (e.g. only transport one type of cargo, only use one type of vehicle, only work within a certain area of the map)
It seems likely that the idiosyncrasies in our AIs will make them do different things anyway, but I think there are strong possibilities of strategic collisions. I suppose this is probably thinking too far ahead, but I want to try to make sure my AI will be robust in all situations.
Hehe
Okay, it is not in the place you might expect, but still
