Game freezes whenever a rail or chain signal is placed or removed

[NJMorf]

Every time I add or remove a signal, or apply a deconstruction planner which acts on signals, the game freezes for about two seconds. This seems to be cumulative, so when use a planner on a large number of signals, the game freezes up for minutes at a time. It's most frustrating when I've got a mass of robots acting out a de/construction job involving a lot of signals as the game freezes over and over again.

I understand that this is because the game has to recalculate all train paths whenever a signal is added or removed. I'm after a little advice on what the best way is to address it.

My factory is fairly large in area, albeit very low density. I've got about a thousand game hours on it and it's changed form many times, so it's a bit of a mess. It's been a city block base with lots of solar panels and nuclear power scattered almost randomly throughout it, so while it was pretty dense, my recent move to consolidate all solar panels into a few major deployments and remove nuclear power entirely (I've heard that all those fluid pipes are bad for UPS, and I'm trying to improve my UPS from about 15-20) has left me with a large base which is mostly empty space. Most of the traffic is via trains (I've also cut back my main logistic network from about 15,000 roboports covering most of the factory to about 400) so there are a lot of fairly long 4-track rail lines, which obviously means a lot of signals.

Another thing I've read is that grid bases tend to run slowly because of the large number of potential paths that each train can take around all of the track. My current aim is to move all my mining to the south and then try to restrict all manufacturing that uses only or mainly raw ores to the south as well. I might try to do this by using entirely separate rail networks for the ores and the more processed goods. Further to that, I was thinking of structuring in horizontal stripes fed by east-west rails, with relatively few north-south interconnects between them. Hopefully I can restrict how far any individual train has to travel so that there is relatively little traffic on those interconnects.

Two questions:

1. Is this plan likely to improve my UPS? I've been able to get back to about 25 UPS when not building stuff, but it's still pretty slow.
2. Is the freezing likely to be alleviated more by having fewer potential paths or should I be trying to user fewer signals instead?

[NotRexButCaesar]

I understand that this is because the game has to recalculate all train paths whenever a signal is added or removed. I'm after a little advice on what the best way is to address it.

I would guess you have trains with no path to their destination: these trains would path all at once when you changed the signals. If you can remove just those it would probably fix the problem.

In questions like these, a save file would probably also be helpful for people to look at.

[MEOWMI]

This may be kind of obvious, but working to reduce the amount of intersections would help. Every cityblock based railway I've seen has like 100x more intersections than needed, I'm not even joking.

As you mentioned, it is true that every extra intersection you add into your massive rail system adds a lot of extra potential paths to the graph. I don't know how the pathfinder works, but you might get good performance just by removing 10% of your intersections.

[mmmPI]

Two questions:

1. Is this plan likely to improve my UPS? I've been able to get back to about 25 UPS when not building stuff, but it's still pretty slow.
2. Is the freezing likely to be alleviated more by having fewer potential paths or should I be trying to user fewer signals instead?

Given the freeze when you add rail, it's pretty obvious that one source of improvement in ups would be changing things about trains. Just to make sure though, you can press F4 in the game to open the debug menu, it allows to tick boxes to select some additionnal visual in the game. One setting in particular is called "show time usage". This one adds lots of text on the left side of the screen detailing how much time different things takes for the game to process. Specifically there are values for "train pathfinding" and "trains" but also "circuit network" or "fluid system". This could allow to get precise value to what are train responsible for, allowing tracking improvement and where you have the more room for it.


The numbers are the time it takes in ms for the game to deal with a task, higher number is bad. And if the total is more than 16 ms then you have less than 60UPS. With 25UPS it should take around 1/25= 0.04, or 40 ms for the game to process each update. But a freeze of 2 second, you could see it in the figures represented by a large number like 200 or even 2000 supposedly in the category "trains" or "trains pathfinding".

https://wiki.factorio.com/Railway/Train_path_finding

Here are the list of the different thing that can trigger a repath. As mentionned ealier by Caesar a new rail only triggers repath for certains trains such as those stuck with "destination full" or "no path". Changing the state of those idle trains is definitly something to consider. ( there must be many of them).

This being the problem would be consistent with the observed linear scaling in time the more rails are involved in the action that triggers a freeze.

But Many repath will still occur in regular situation, ( do you have freeze that are not caused by adding rails but part of normal operation like train stop enabling/disabling ?).

In this case my rule of thumb is to advise for a reduction in the number of junctions, especially in a grid like map as MEOWMI said.

From what i understand of the pathfinding, the game starts looking at potential path from the start AND from the END. Then trying to join those 2 separate half path. So separating the 2 network would still have the effect of forcing the game to scan them both entirely everytime you add a rail for each train that tries to reach a stop in the other network before saying "no path" if that is allowed by your naming convention of train stop.

Otherwise it should definitly reduce the complexity of the network and make it easier/faster for the pathfinding to finish its task if you keep train stop named the same in the same networks.

Having different fuel or speed for trains is also something that should be avoided when possible imo, including train of different size sharing same tracks. This because when a faster (accelerating) train is behind a slower train, the faster train continuously repath, slows a little, accelerate, slows a little, accelerate like some humans do in their car when losing patience. There is a setting in the debug menu called "show train repath" ( i think it's at the bottom) when it's selected it will make a white "repathed" message pop above the loco in place of the red "no path" when such repath happens it can help making visible the rules linked above and isn't invasive on the screen .

This process is made worse when you have many signals close to each others, it increases the frequency of it. While having larger blocks decreases it. If your base is really streched out, you migh consider having blocks way larger than your largest trains in the less dense area, for those long lines depending on traffic density and size of trains.

Obviously the same process occurs much more logically when a train need to let another one go in a junction. It's also an area where reducing the numbers of junctions helps, reducing the complexity of finding a path AND the frequency of repath.

In other word trains repath quite often even outside of player adding rails, especially when they have to slow down due to congestion, junctions, slower trains and so on.

And the frequency of repath and the complexity of each repath have multiplicative effect. I think both are to be considered for best results.

TL DR: Your plans seem likely to improve your ups for train related things, ALL of them, having fewer different path by transforming the grid like network, and having fewer signals most likely to a lesser extend but maybe not if you have placed a signal on every piece of rails

Aside from that you can try to alter the state of the trains that are "idle" as an example: sometimes maybe it's better to only have 2 train waiting full of iron and 10 behind them empty rather than all 12 waiting full of iron and ready to pathfind over the network at the same time. And if you really need those 12 trains of iron to be ready because of very spiky consumption, it would be better to make them wait in line rather than in parralel so that when you add a rail only the front train search for a long path, and the others no because they just want to take the place of the front train.

Another thing to consider if you plan to refactor into separated network of rails and parralel tracks is the possibility to have standardized trains composition and fuel in each network as much as possible in routine operation. ( avoiding the occasionnal truck in your bicycle lane, and the bike on the highway .

[NJMorf]

Thanks for the advice. I do have a fair few trains in "destination full" status, though there should be relatively few in "no path" status - I'd guess that both have the same effect on the pathfinding. I'm using a combination of LTN (for processed goods) and standard (for raw materials) train stations: obviously the LTN trains are frequently sitting in their depots, and I've set up the standard trains so that there's usually one train loading or loaded and at least one waiting to load (and similarly for unloading), with all of the source and destination stations named identically per ore type. That means a fair bit of waiting for the fully loaded raw trains.

I haven't noticed many freezes that aren't directly caused by signal construction. I do have some stations automatically enabling/disabling, but mostly I'm using train limits to control train numbers.

I wouldn't (intentionally) have any duplicated station names between the two networks, assuming I airgap them, and ideally there'd be no reason for a train in one network to need to cross to the other (though that's probably not taking supply and builder trains into account).

All my trains are running on nuclear fuel. Most are 1-4, some are 1-1, and there are a couple of 2-8 artillery wagon trains that only come out to kill stuff when I'm expanding. There are some places where I've got way too many signals in close proximity (I was dumb enough to put lane switchers too close together or too frequently so that none of my 1-4 trains could pass through them without sitting over multiple rail blocks) but I'm slowly getting rid of them. I was considering taking out signals from long sections of straight rail, but I wasn't sure if the effect would be significant enough to bother. Mostly they're set at about the same separation as the trains are long.

I'm not currently planning on using longer trains, but if 95% of them are 1-4, I'm guessing that the 1-1 trains probably don't have much of an effect on traffic.

As for the save file: it's somewhat large, I think (currently about 240MB) so I wouldn't want to impose it on anyone.

[ptx0]

please post a screenshot of this base so we can all have a good time that sounds like an extreme number of signals

when i did city blocks, i had the same problem. so i redesigned the blocks to be MUCH LARGER and therefore have fewer signals and intersections over the same given area.

[NJMorf]

please post a screenshot of this base so we can all have a good time

It's a mess. It's embarrassing. Also, it's no longer as grid-like as you probably think.

Clipboard Image.png (1.38 MiB) Viewed 2344 times

You can see a lot of concrete laid where the grid used to be, and a lot of empty space where the solar panels were before I moved them. Half of my science is done in single (ugly) blocks which take raw materials (and lubricant, cos I find it a pain to produce) and then make everything else themselves. Once I've finished moving all the harvesting to the south I plan to rework the science blocks to use plates instead of ores so as to remove the significant physical area taken over by ore processing, then hopefully start arraying them to the north. I want to get to the point where I only really need to stamp down a new copy and add some harvesting in order to expand more quickly and cleanly.