Passenger Script-AI from koa

[Andarix]

Download

The original astar.nut should be replaced with the attached file.

Another problem is that, apparently, only one road depot is built at the start. This means that all buses have to travel a very long distance from there to reach their destination city.

A significant amount of capital is lost because stations are made public—even when no other player is active.

The expansion is very rapid. As a result, the AI quickly goes bankrupt.

Tested with pak64 and Simutrans 124.4.1. A brief test was also conducted with pak64.german.

[koa]

Thanks for the review.

The original astar.nut should be replaced with the one from sqai_rail, as the original apparently cannot build bridges in version 124.4.x.

I'll try merging the new astar.nut.

Another problem is that, apparently, only one road depot is built at the start.

This is just my playstyle.
In pak128.japan, I don't want to build many depots.

A significant amount of capital is lost because stations are made public

This is to check if multiple AI players will use public stations when I run them.
So it's pointless if there's only one AI player.

The expansion is very rapid. As a result, the AI quickly goes bankrupt.

I don't think this is due to the pace of business expansion. I believe the real problem is that it's not connected to cities with high demand. I haven't found a solution yet.

[prissi]

It is good to have another try at an AI.

Yesterday it performed quite well, but today, on a more hilly map, it went backrupt very quickly due to very complicated landscaping. Maybe the newer astar merging helps with it.

Also, does it constrcut trains at a point? I have never seen anything but bus lines?

And, what license it is? Can it be included as another AI with Simutrans?

[koa]

does it constrcut trains at a point? I have never seen anything but bus lines?

It has the source code for the railway construction, but since it has even more bugs than the bus system, it will only run if the effort to alleviate congestion on bus routes fails.

And, what license it is? Can it be included as another AI with Simutrans?

This license complies with the sqai_rail's license (since it is based on sqai_rail).

[Andarix]

I haven't used pak128.japan in ages.

My test map for pak64 is 320x320, and the passenger AI went bankrupt every single time after just three months.

And within a single month, it had taken over the entire map.

[prissi]

One of the most critical points in the test was 10 times trying to connect to a city wasting lost of money of terraforming. (Actually, I am not sure why not using the built-in road building tool for busses and only resort to the astar.nut when that fails.)

[Andarix]

One of the most critical points in the test was 10 times trying to connect to a city wasting lost of money of terraforming. (Actually, I am not sure why not using the built-in road building tool for busses and only resort to the astar.nut when that fails.)

The pathfinding logic in `astar.nut` does not perform terraforming. I don't know why this is different in sqai_koa's original astar.nut or why so much terraforming takes place there.

This was one of the reasons why so many unnecessary bridges were built. Consequently, I have implemented a check for the underlying terrain specifically for short bridges (up to 5 tiles, I believe). In simple cases, the terrain is then adjusted to avoid the need for a bridge.
During route optimization at later stages, attempts are then made to adapt the terrain in order to improve the route alignment.

However, while reviewing the code, I came across functions that appear to be derived from functions within the `astar.nut` file. At this moment, I am unable to determine which parts of the code are actually being utilized and which are not. I also do not yet fully understand the logic behind the construction sequence.

From my perspective, the primary issue lies in the gameplay style, which relies on a single central depot, as well as the absence of a profitability check. Further expansion should only be undertaken once the operation is generating an operating profit. In this regard, I believe it is preferable to construct subnetworks each with its own dedicated depot and to connect these subnetworks only at a later stage.

Furthermore, the initial selection of cities should be weighted more heavily based on size, as larger cities tend to generate a potentially higher volume of local traffic.

I don't know how high the starting capital is in pak128.japan. However, in pak64 and pak64.german, it is very limited.

It is certainly possible to configure the AI's behavior based on the pakset being used.

code function

Differing weightings for rail and road between pak128 (road-heavy) and pak128.german. code

[koa]

The pathfinding logic in `astar.nut` does not perform terraforming. I don't know why this is different in sqai_koa's original astar.nut or why so much terraforming takes place there.

I did this because I wanted to incorporate the behavior of non-scripted AI players—who terraforming while building roads and tracks—into the scripted AI (since this feature didn't seem to exist in the past).
The reason for all the terrain adjustments is that I want to minimize curves as much as possible when laying railroad tracks.
Ideally, it would be great if we could lay the tracks to fit the terrain initially and then improve the alignment later...

Furthermore, the initial selection of cities should be weighted more heavily based on size, as larger cities tend to generate a potentially higher volume of local traffic.

If I try to make the management too conservative, I think that when running multiple AI players, they'll all end up basing themselves in the same town and using the same economical cars, which won't make for a very exciting visual experience.
I'd like the management strategies to vary depending on the slot selected.

[Andarix]

...
If I try to make the management too conservative, I think that when running multiple AI players, they'll all end up basing themselves in the same town and using the same economical cars, which won't make for a very exciting visual experience.
I'd like the management strategies to vary depending on the slot selected.

Before building in a city, you can check whether there are already stops there that belong to other players.

pak64.german includes a script tool for this purpose, which I have attached here. This performs the query for the active player when a city area is clicked. It would then need to be invoked for all active players associated with the respective city.

I also encountered the problem of multiple AIs building simultaneously. That is why sqai_rail employs various strategies—not based on the slot occupied, but rather through alternating activation.

Additionally, there is a construction delay.

Code

This construction delay occurs even after a line has been successfully built. This serves to prevent construction from proceeding too rapidly a particularly important consideration given that a human player is significantly slower than an AI when attempting to establish a connection.

code

Furthermore, the distribution of goods poses problems when parallel routes exist between the same origin and destination points. One player is prioritized while the other typically comes away empty-handed, a situation that ultimately results in "dead" routes.

I can't find it in the code right now, but `sqai_rail` shouldn't create tracks running parallel to those of human players.


EDIT

pak64.german

It's a bit suspicious. On this map, after just three cities, sqai_koa claims that all cities have been settled.

[Andarix]

Added fixed astar.nut for build rail to first post.