placing rail signals create stuttering and low FPS

[Spad889]

Hello guys, i need some help.

I have created a very large base (classic train grid, ~3000 spm) and now, only when placing rail signals, the game stutters and goes to 3-4 FPS/UPS.
Rest of the time the game goes normally up to 30-40 FPS/UPS (as i said the base i quite Huge)

Does someone know why?

i really enjoy the base but this problem is incredibly frustrating

(my PC have win 10, ryzen 3600 e GTX1660)

Thanks, best regards.

[Koub]

The "classical train grid" is probably not optimal in terms of UPS. It's easy to use, but there are tons of unnecessary crossings, rails, and signals, which must add a significant workload on the train pathfinder.

Adding your save, mod list if you use some could also help.

[Spad889]

Thanks Koub,

yes probably not optimal at all, but still fun and easy to use
i attached my file save and mod list.

Thank you, have a nice day

mod2.png (1.6 MiB) Viewed 3644 times

mod1.png (925.48 KiB) Viewed 3644 times

UNOPUNTOZERO.zip

(76.66 MiB) Downloaded 140 times

[Koub]

I'm not an expert into this, but from what I see, if I add a "cell" of your train network, train path finder goes from a couple ms to spikes of 30-ish ms (on my computer).
Knowing that one needs the full update cycle not to exceed 16ms to maintain 60 UPS, the maximum UPS I can achieve on your map during those spikes is 30 (ignoring all the rest, so it's an upper bound). The entity update is also quite high, but that's to be expected on a big factory (a tad bit below 15 ms).

I'd say that both the size of your factory and the suboptimal design choices you did with your train network bring your factory to the maximum your hardware can do. No matter the hardware, you'll always have a upper limit of what it can cope with.

If you want better performance, your best option is probably to make UPS friendly design refactoring. For that, I'll let specialists in here give you the right pieces of advice.

[Loewchen]

Have not looked at the save but performance drops when placing rail suggests you have a lot of trains that cannot path and all try again when the track changes. If you are deactivating train stations, use train limits instead.

[mrvn]

You could reduce the path finding overhead a lot by switching to a tree or at least a more sparse grid. I'm playing the nullius mod at the moment and using a H-Tree instead of the conventional grid. There is exactly one path from every city block to every other city block. At some point that will cause congestion if too many trains have to pass from one half of the base to the other. But then I can always add some cross connects. I could also add another chunk spacing between higher levels as I grow so the cross connects can use 2 or 4 lanes per direction. And a more efficient T junction for that.

rail-h-tree.png (415.9 KiB) Viewed 3586 times

https://en.wikipedia.org/wiki/H_tree

[boskid]

Rail network being a grid itself it not a direct cause of the low FPS when placing signals.

When a signal is placed, there are certain cases which may create new paths and this forces trains in NO_PATH state to repath. The problem is that running trains pathfinder in the rail network with huge amount of rail segments (this is not specific to grid, any network with way too many rail signals will do) when there is still no path to the train's destination will cause train pathfinder to visit literally every rail segment accessible from train's original position.

In certain cases due to trains pathfinder heuristic, grids may be slightly better than other structures because the heuristic will most likely guide the correct way from start reducing amount of visited rail segments which is good for UPS.

I loaded this save file to run some simple commands to look if there are any NO_PATH trains:

Code: Select all

/c counters={} for k,t in pairs(game.player.force.get_trains()) do if t.state == defines.train_state.no_path then local dest=t.schedule.records[t.schedule.current].station counters[dest]=(counters[dest] or 0)+1 end end game.print(serpent.line(counters))

And sure, there are NO_PATH trains: copper ore IN, copper plate IN, plastic IN, green chips IN.

Quick search using the Trains gui to find which train stops are not full (if a train is in NO_PATH, full train stops are not interesting as they are not a candidate destination, it must be something else).
For Copper ore IN, sure there are disconnected train stops near [464,-949]:

100066-copper.png (428.21 KiB) Viewed 3554 times

There is also cell that produces red chips near [52,984] that has unreachable train stops:

100066-redchip.png (379.54 KiB) Viewed 3554 times

There may be more unreachable train stops, i just found some of them.

Conclusion is that the drops in FPS here are due to missing rails causing certain trains in NO_PATH to recalculate path which fails (the most expensive case for trains pathfinder). Also looking at the sequence of rail signals at the rail that goes out of train stops and into the main rails: those signals will split rails into many many rail segments and every one of those short blocks has to be touched causing those failing searches to be even more expensive.

After adding missing rails in places pointed above, there were no more NO_PATH trains and when placing rail signals there were no spikes in cpu time usage.

-- edit:

Just for fun i made this slightly larger command:

Code: Select all

/c
  local counters={}
  for k,train in pairs(game.player.force.get_trains()) do
    if train.state == defines.train_state.no_path then
      local dest=train.schedule.records[train.schedule.current].station
      counters[dest]=(counters[dest] or 0)+1
    end
  end
  for k,trainstop in pairs(game.player.surface.find_entities_filtered{type="train-stop"}) do
    if counters[trainstop.backer_name] and trainstop.trains_count < trainstop.trains_limit then
      game.print("UNREACHABLE TRAIN STOP AT [gps="..trainstop.position.x..","..trainstop.position.y.."]")
    end
  end

which does basically what i did manually: finds to which stations those no_path trains are trying to go and using that it finds train stops under given station name that are not full and prints a ping to the output console. Those pings would immediately pinpoint which train stops are faulty because some trains cannot get to them.

[Spad889]

Vey nice, thanks you all.

I disconnected the station that i need to work on, but if this is the cause of the problem (as boskid suggested),i will stop doing that.

Anyway the game is amazing and even with FPS drop is still playable

[mrvn]

Try setting the train limit == 0 for the stations. Then the station would be full and not a candidate. So trains should go to "Destination full" instead of "No path".

[ptx0]

you can also set a standard rail signal to red using a combinator! then nothing will travel past that point. it's a silly solution, but it's mine.

[Spad889]

Nothing is silly if it works!

I've had my share of good advice.

Thank you awesome players

[mrvn]

you can also set a standard rail signal to red using a combinator! then nothing will travel past that point. it's a silly solution, but it's mine.

Wouldn't that have trains driving towards the station till they hit the red signal and then block traffic? Unless you do it between a stacker and the station that seems like a bad idea.

[ptx0]

you can also set a standard rail signal to red using a combinator! then nothing will travel past that point. it's a silly solution, but it's mine.

Wouldn't that have trains driving towards the station till they hit the red signal and then block traffic? Unless you do it between a stacker and the station that seems like a bad idea.

yeah it's not going to be pretty, but it works! blocking traffic isn't going to stutter UPS like No Path will.

[jodokus31]

-- edit:

Just for fun i made this slightly larger command:

Code: Select all

/c
  local counters={}
  for k,train in pairs(game.player.force.get_trains()) do
    if train.state == defines.train_state.no_path then
      local dest=train.schedule.records[train.schedule.current].station
      counters[dest]=(counters[dest] or 0)+1
    end
  end
  for k,trainstop in pairs(game.player.surface.find_entities_filtered{type="train-stop"}) do
    if counters[trainstop.backer_name] and trainstop.trains_count < trainstop.trains_limit then
      game.print("UNREACHABLE TRAIN STOP AT [gps="..trainstop.position.x..","..trainstop.position.y.."]")
    end
  end

which does basically what i did manually: finds to which stations those no_path trains are trying to go and using that it finds train stops under given station name that are not full and prints a ping to the output console. Those pings would immediately pinpoint which train stops are faulty because some trains cannot get to them.

Nice! This could be made into a mod: "Detect unreachable train stop causing performance issues" or such