Transport Tycoon Forums

And what is the problem? Build the first way if you want slopes, or the second way if you want turns.

griffin71 wrote:Hello everyone,

I have 2 questions:

* Does anybody know what the return values of AITile::GetSlope mean? The API is rather terse here...

* There seems to be a bug with the 'allow building on slopes and coasts' option. Where should I post it? (see pictures below; default way of building conflicts with situation, because banks have been built in a different manner than would be done by default for the current roadpiece)

GetSlope returns 0 if the tile is flat, or non-zero if it isn't. In the last case, it returns the internal value of the slope, which currently isn't really meaningful. There will be wrappers that makes it easier to handle those return values.

Slopes are and will be a painful thing for AI road building. As it depends very much in OpenTTD how you build a piece of road (as your screens show clearly), it is also important for an AI to build in a specific way. Currently there are some ideas to make this easier for AIs, but right now you just have to be careful how you build things Or make sure build-on-slopes is disabled (for now, that really is the easiest way out for AIs, just disable build-on-slopes )

Thank you for your comments.

DaleStan, in the second picture, the land has become level. So why can I not build a road on the marked tiles?

TrueLight, thanks for your comments. I'm still reworking the flatland pathfinder (which will be the main object of my AI), but work is progressing well now. That's why I took a sneakshot at the possibilities for land not level. When I saw the function that checks whether land is flat, I hoped it might return me details about that.
I would suggest to return a 4 element array containing the absolute heights of the corners of the tile, ordered by tile index. That's a really basis function, but it'll do, I guess.

griffin71 wrote:DaleStan, in the second picture, the land has become level. So why can I not build a road on the marked tiles?

Because a human player couldn't either. More specifically, the game engine can't guarantee that you won't change the tiles in the second case so that one is sloped and the other is not. (Eg, the road runs off the edge of the foundation, and restarts at the bottom.)

griffin71 wrote:(..)
I would suggest to return a 4 element array containing the absolute heights of the corners of the tile, ordered by tile index. That's a really basis function, but it'll do, I guess.

It is what the wrappers most likely will return. It is just that we can't really return an array (or rather: not yet), so we are looking into the possibilities.

Well, at least at this point, the number you're returning only ever ranges 0..15(dec), so you can easily pack all four corner heights into a single uint32.

DaleStan wrote:Well, at least at this point, the number you're returning only ever ranges 0..15(dec), so you can easily pack all four corner heights into a single uint32.

I don't know, but I think the problem here is the limits of the current squirrel implementation.

kaan wrote:

DaleStan wrote:Well, at least at this point, the number you're returning only ever ranges 0..15(dec), so you can easily pack all four corner heights into a single uint32.

I don't know, but I think the problem here is the limits of the current squirrel implementation.

Nah, the problem is more that we want a clean framework, so we need to think a bit how to give the information in a nice way, that everyone can work with it. For sure this won't be bit magic.

TrueLight wrote:Nah, the problem is more that we want a clean framework, so we need to think a bit how to give the information in a nice way, that everyone can work with it. For sure this won't be bit magic.

Too bad -- I like a bit of magic now and then

But seriously, also when it comes to other contributors' plans of increasing the possibilities for slopes (e.g. various levels of steepness), it really is a wise plan to think twice about a way to pass that information to SQ.

DaleStan wrote:

griffin71 wrote:DaleStan, in the second picture, the land has become level. So why can I not build a road on the marked tiles?

Because a human player couldn't either. More specifically, the game engine can't guarantee that you won't change the tiles in the second case so that one is sloped and the other is not. (Eg, the road runs off the edge of the foundation, and restarts at the bottom.)

Thanks for clearing this up, DaleStan. I be in favour of changing this, as the situation shown is counter intuitive IMO, but I'm into pathfinding right now, so I'll stick to that.

Hi TrueLight

There is a bug in the OTTD-win32-noai-r9915-noai version. If you activate the fastforward button, then it keeps flashing on and off, and you cannot stop flashforward anymore, at least not on the windows version. I could not reproduce it in the 9788 build.

A suggestion: later it would be useful to query the vehicles/stations/etc owned by the other companies too. For eg to avoid connecting already connected industries. Or in a small map, if almost everything is connected, to check where are running the most profitable vehicles. The AI could go there too and make some concurency.

Dear all,

I'm proud to announce that I will soon release a pathfinder that finds any forward roadpath on flat land.

A forward path is defined as:
1. select 2 locations on the same continent, A and B
2. if A is our starting point, then the forward direction from A to B will be MAX(dx(A,B), dy(A,B)), where dx is the 'x' component of the difference in co-ordinates of A and B on the map, and similar for dy.
3. a forward path goes in the direction from A to B and possibly to the left/right. It never goes (temporarily) in the direction from B to A, which limitation will be solved later on. This means that from A to B, an S-shaped path will be found, but a ~-shaped path won't.

In practise, the majority of paths on flat land are already found.

The system is designed to be extendible to
* find non-forward paths also
* find paths on landscapes that are not flat
* find paths for railroads
* work with bridges and tunnels
* find the path with the shortest Manhattan length, and return the badness of the path actually found (badness is the extra distance travelled as compared to the Manhattan length from A to B)

I estimate that in about a week, I will post a version 1.0, that finds any forward roadpath on flat land.

griffin71 wrote:Dear all,

I'm proud to announce that I will soon release a pathfinder that finds any forward roadpath on flat land.

A forward path is defined as:
1. select 2 locations on the same continent, A and B
2. if A is our starting point, then the forward direction from A to B will be MAX(dx(A,B), dy(A,B)), where dx is the 'x' component of the difference in co-ordinates of A and B on the map, and similar for dy.
3. a forward path goes in the direction from A to B and possibly to the left/right. It never goes (temporarily) in the direction from B to A, which limitation will be solved later on. This means that from A to B, an S-shaped path will be found, but a ~-shaped path won't.

In practise, the majority of paths on flat land are already found.

The system is designed to be extendible to
* find non-forward paths also
* find paths on landscapes that are not flat
* find paths for railroads
* work with bridges and tunnels
* find the path with the shortest Manhattan length, and return the badness of the path actually found (badness is the extra distance travelled as compared to the Manhattan length from A to B)

I estimate that in about a week, I will post a version 1.0, that finds any forward roadpath on flat land.

Nice work, I can't wait to see some screenshots

As an impression only, take a look a the following 3 routes that were built by the AI.
Please note that because the landscape is not flat, road on some tiles could not be built (see my post on page 8 for an explanation of what problem the AI encounters). Height difference is currently not accounted for whatsoever.

Also, unsuccessfully built parts of the road are not yet removed, but this requires only a minor change.

Hmm why not use ctrl-s ?

Hi

I am trying to extends the AITown class by:
Then I get the error (where line 32 is "class City extends AITown"): Are there any classes you cannot extends???

rrm wrote:Hi

I am trying to extends the AITown class by:

Code: Select all

class City extends AITown
{

}

Then I get the error (where line 32 is "class City extends AITown"):

Code: Select all

dbg: [misc] Your script made an error: the index 'AITown' does not exist

CALLSTACK
*FUNCTION [main()] ai\RRMAi\main.nut line [32]

LOCALS
[this] TABLE
dbg: [misc] [squirrel] Failed to compile 'ai\RRMAi\main.nut'

Are there any classes you cannot extends???

This has to do with how the system works. First time your script is loaded, no classes exists besides the AIFactory class. You have to register your AI there. The second time your script is loaded, things like AITown exist. The only way to get what you want to work, is to use require in the constructor of your AI, where the file you include can extend AITown.

Hello,

I'm sorry to announce that I need to delay presenting the pathfinder. The reason is that when I started to program that always the best path possible would be found, it became imperative to almost redesign the main pathfinding algorithm. The advantage that it has, however, is that it will now "natively" be no longer restricted to finding forward paths only. I have tested this and it seems to work well.
My new estimate is that I will be able to finish the code for testing by the end of next week.

I'm sorry for the delay.

Well, I've downloaded the noai branch. Seems the AI do nothing, but when I viewed its source, I see why - the sample AI is not finished

But I have few ideas: The AI is written in some sort of script (Squirrel), but what if I have some libraries (for example for neural networks) in C/C++ that I want to plug in?

Will there be some feature to use AI partly or fully programmed in C++?
(so you'll end up with some .dll/.so when you compile your ai and stuff that somewhere in openttd directory, maybe in place of the .nut file
Still there will be need for the library to use AI helper functions in openttd which have loaded it, while usually it is inverse (program load some library and use functions within it). But that is solvable, pass few pointers to factories for ceating these objects to library initialization functions or something alike.

Alternatively there may be communication over pipe (program recive something on stdin, respond with commands on stdout) or tcp connection (same as pipe, but AI can run on another computer). With pipe you may be able to run even some sort of scripts (perl, bash ... ) as AI

Also, what may be nice is to enable switching the AI in game or turn on some AI for human player (this will allow developing some "guarding AI" that will do some minimal upkeep (rebuilding tracks after UFO, adding more trains if too much cargo appears in station ...) which player can switch on when he is AFK. Or alternatively, enabling "cyborg mode" - AI will build something, human will either build in cooperation something else or improve the AI creations. Or AI can optimize human work. Or ... well, the limits are endless ...)

Also, on win32 the results of "print" functions seems to be printed nowhere .... probably it is printed to console which is ehm ... absent ... for win32 gui programs