The reason it takes so long and uses so much ram is that it calculates every possible path between every station, if you have no walls we are talking millions of paths between every station and 819 different station combinations. The solution to your problem is adding walls both around the whole thing and seperating the stations into smaller groups and making sure there are no holes in the walls.

My map is currently under development, so of course there are holes in the walls. The problem is that you can't remove part of the wall. If you connect two walls and then want to remove a small piece, the entire wall will be removed. But that's nothing compared to the time it takes to save, thank you! They need to fix it anyway, it's definitely not okay.

I found a way to combine the walls into a common one but it doesn't matter, because in any case, the game increases your RAM usage very quickly (and also loads the CPU by up to 50%), and there's nothing I can do about it yet. I tried to upgrade to other versions, watch local game files, search for information online, but nothing. I noticed that this counting method wasn't used at all on old versions, but the game can't load my save on them.

Yeah. There are techniques that might be used to optimise the calculations.
But if you do the maths manually. Just work out the combinations the system is going to make given the size of the map and the number of stations and platforms you state, the number of possible interconnections (which varies depending on how many routes you have) but let's just say minimally 4 routes per station, 40 stations and 170 platforms. is astronomical it is 2.8 x 10 to the 14 (280,000,000,000,000) and that's a low end estimate based on an average of 4 routes per node.

The way the exponential growth works (and in this case I'm using the term exponential properly... i.e. mathematically) scales so fast after a certain point that I worked out that if you had 70 stations with 300 platforms and 4 routes per station... which seems not much bigger than the scenario you describe, the exponent scales so much it is (literally) astronomical

That is to say that the number of nodes the CPU would need to calculate is greater than the estimated number of atoms in the in the solar system (10 to the 57 or 100,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000)

A set up as I describe above would take 10 to the 80 calcs to process more or less.

Let's say the game and your CPU could calculate 1 million possible routes between these nodes per second would mean 10 to the 74 seconds

That means that even if the game could calculate 1 million nodes a second... it would take 3.168 x 10 to the 66 years.
(3,168,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 years)

As you can see even optimising to make the game a million times faster really would have no practical impact at that point

By that calculation I reckon your map would take about 7 hours to create. However, coding being coding - and not withstanding your CPU running at full pelt for 7 hours, and the heat and energy required to do that. I doubt it would ever complete. The tables set up to store the routes might cripple your hard drive, a small memory leak that goes unhandled per cycle... lots of things - might mean that a map that big might never complete.

There are likely to be ways the developers could set it up to calculate the routes that are being used on the fly. Only creating the specific routes that are being used for that train on that journey. Maybe storing them in case they are used again - but most likely not. In those cases coding the game that way might be the better option. The game might be a little less responsive in play - but not get bogged down creating very large maps. Dunno if that is possible with this game, and for 99% of users I doubt they would ever need it, but you bring up a really interesting edge case that I enjoyed thinking about for 20 minutes.

Hoshi and Doc Clarke explained a lot.

Just my bit: What the game calculates here is the distance matrix, i.e. it tries to find the shortest possible path between each two stations. More precisely, it tries to find a shortest path from each platform to each other platform and then take the minimum for each station pair.

It should be fast and using modern hardware it usually is.

However, to prevent situations when some narrow corridor is open at the first sight but you can not build a corridor through it because there is not space to turn the rails, the algorithm has to search for the actual connector with respect to rail-building rules (like turning max 45 °). To prove it is not possible it has to enter each grid cell from each direction and exit in each possible direction from it.

Actually it is implemented as a search in 8-layer 3D structure instead of 2D grid. Each layer represents entering the cell from certain direction and is connected only to the layer above (45° turn left) and below (45° turn right).

So the effect is that only the valid connectors are found but the computation time is 8 times longer.

Unfortunately, without simplifications having impacts on the result (some connector possible but not found) we can not speed it up anyhow.

So the map authors have to build walls around stations to isolate the connectivity islands.

Originally posted by Mišo:

Hoshi and Doc Clarke explained a lot.

Just my bit: What the game calculates here is the distance matrix, i.e. it tries to find the shortest possible path between each two stations. More precisely, it tries to find a shortest path from each platform to each other platform and then take the minimum for each station pair.

It should be fast and using modern hardware it usually is.

However, to prevent situations when some narrow corridor is open at the first sight but you can not build a corridor through it because there is not space to turn the rails, the algorithm has to search for the actual connector with respect to rail-building rules (like turning max 45 °). To prove it is not possible it has to enter each grid cell from each direction and exit in each possible direction from it.

Actually it is implemented as a search in 8-layer 3D structure instead of 2D grid. Each layer represents entering the cell from certain direction and is connected only to the layer above (45° turn left) and below (45° turn right).

So the effect is that only the valid connectors are found but the computation time is 8 times longer.

Unfortunately, without simplifications having impacts on the result (some connector possible but not found) we can not speed it up anyhow.

So the map authors have to build walls around stations to isolate the connectivity islands.

In general, everything was fine when I built the walls between the stations (there was still a lot of RAM and CPU usage, and sometimes the game lasted 5. 10, 20 min, but it doesn't matter), and connected them into one common one, without holes. I currently have 140 stations on the map, and when I added the last 10 (the walls are still without holes), the game has been saved for 8 hours, only 62%. In the logs, I saw that the game calculates the processing time of each station, some of them took 4000 seconds. I have almost no signals on the map, does it have any effect?

No, signal presence has no impact.

Inspect one of the worst stations by just starting a track at some platform and trying to build the connector to spot where not intended, e. g. the empty space outside the map. It can be useful for finding the eventual holes.