Factorio Forums

mrvn wrote: Wed Mar 20, 2024 9:27 am I think the earlier a chain signal is in a series is the better. The game will reserve a stretch of chain signals in it's entirety so for reserving it doesn't matter where the middle chain signals are. But when the train crosses it frees segments as it leaves them. So the earlier the chain signal the earlier the previous segment gets freed for a crossing train, right?

Yes, you want to put the chain signals as early as possible unless they're the entry chains. Since chains through blocks with no crossing rails will not release a crossing train sooner, the later chains are effectively doing nothing.

Avona wrote: Tue Dec 05, 2023 12:04 am

datarza wrote: Mon Dec 04, 2023 11:47 pm Sorry, can not understand the problem, please explain. I can confirm, that turning to the right (from top) blocks the train, which turns to left (from bottom), it is expected behaviour for unbuferred intersections (and for buffered probably as well).

Why not just use the Wide instead? The only advantage I can see for your intersection is that it's slightly smaller, but space isn't a big deal in Factorio.

When I see an intersection like this my brain is always twitching. When a train arrives at the intersection it will have a path already picked to cross it and it will go past the first signal. At that point the path is locked in, there is no way the train can repath when there is congestion to drive around a blockage.

All the entry signals should be chain signals so a blocked train can still decide to take another path. Except that will cost a bit of time when trains don't re-path because they wait earlier. Has anyone compared the effect of that?

mrvn wrote: Wed Mar 20, 2024 9:04 pm When a train arrives at the intersection it will have a path already picked to cross it and it will go past the first signal. At that point the path is locked in, there is no way the train can repath when there is congestion to drive around a blockage.

Like I previously said, when a train's braking distance touches a red signal on its path, it will repath at that point. If an alternate path has a lower pathing penalty, it will take that path instead. If the alternate path's pathing penalty is too high, the train will not take that path anyway. The only penalty that changes over time is the penalty that increases as a train sits at a red signal. This penalty usually takes an extremely long time to change the train's path, on the order of minutes. If your traffic is sitting there for minutes, then you have bigger problems.

Since the train repaths when it brakes, if a train would repath with a chain signal, then it would repath without a chain signal. The chain signal would only prevent a train from stopping immediately after the split. Since the train has already repathed by that point, it's already determined that it's going to wait there.

You can check the Factorio wiki page on pathing penalties. Also, I've checked this in the game myself and it works. If your train traffic is at a standstill in your base, you should fix that problem instead of adding chains to the entrances of intersections. Chains reduce tpm, increasing congestion.

Thanks a lot for your thorough analysis and suggestions!

Avona wrote: Wed Mar 20, 2024 7:47 am The main way I saw to increase the tpm was by adding more space to the central diagonal crossing rails. Your design had nearly exactly 6 train cars of length, which means that trains will be braking in the way of other trains as they cross paths.

Oh, that is a great point! I was indeed trying to leave just enough space to fit a train, without thinking about the speed at which it would be able to pass through. Leaving a bit extra to make sure the train clears the intersection before breaking is a great tip, thanks!

Avona wrote: Wed Mar 20, 2024 7:47 am I also noticed that you have a lot of signals in general. Hans already pointed out the excess rail signals. I'll just point out the useless chain signals.

I think one of the chain signals is actually just left over from me fiddling with the design and shouldn't be there at all. oops.

My placement of signal was pretty much based on these rules:
- chain signal just before crossing
- signal just after crossing, normal if there's a safe buffer behind it, chain if not
- signal before and immediately after each split/merge, chain signal before splits that go to the same destination.
- normal signal every 2 car lengths, except inside a safe buffer

Thinking more about chain signals, I agree with what you're saying - having a chain signal before a crossing is completely unnecessary if the previous signal was a chain signal.

Comparing the two designs, I see you're using signals generally every 3 car lengths instead, which might explain a lot of the difference. Is there a less-is-more rule hidden here? or is that just about minimizing resources rather than improving throughput?

FWIW I started using the 2-car spacing when I was using a mix of 1-2-1 and 1-4-1 trains (on my first train-heavy factory), and then just stuck with it.

Avona wrote: Wed Mar 20, 2024 7:47 am Contrary to popular belief, chain signals before splits do nearly nothing. As trains brake, they repath, so the effect of chains that they force the train to choose an empty path isn't so useful in an intersection.

Interesting.
I've had issues in the past when trying to experiment with complicated intersections where a train would often (visually noticeable on the benchmark timelapse) block the split even if one branch was free, hence I started adding chain signals before all splits on equivalent paths. It's entirely possible I misunderstood why that was the happening originally, and just made the wrong association.

Avona wrote: Wed Mar 20, 2024 7:47 am As far as the curvy rails, I didn't have any issues getting the rails to cross. They're offset from the other rails a bit, but that's alright.

The primary reason for the curvy bit is that I needed a 2 space offset, which can't be done directly (in 1.1 anyways). As a side effect it saved some horizontal space when used as a buffer, but as you pointed out I had unused space on that section anyways.

I was trying to avoid crossings where I couldn't fit signals immediately adjacent to the rail, which pushed me to have more spacing in some places. I see you're using this pattern without any issues though, so I was probably over-optimizing something that doesn't really matter.
I think the big lesson for me is that train speed might matter more than length of the intersecting segments.

Avona wrote: Wed Mar 20, 2024 7:47 am My version: https://factoriobin.com/post/MO4eAHP9

Thanks! Added it to my blueprint library.

Avona wrote: Wed Mar 20, 2024 7:47 am I tested my modified version, which got a score of 139.43, set 1 of 151.93, and a set 2 of 126.93.

That's an awesome result!

In fact, one of the things that was bothering me was that taking 'Parallel Multicross 4 lane' and chopping one arm off yielded a slightly better score than my intersection (151/113, total 132), but yours actually beat it.



Thanks again for all your suggestions, this is a great learning experience!

PavelH wrote: Wed Mar 20, 2024 10:24 pm Thanks a lot for your thorough analysis and suggestions!

Your intersection was well made and deserved a thorough analysis.

Comparing the two designs, I see you're using signals generally every 3 car lengths instead, which might explain a lot of the difference. Is there a less-is-more rule hidden here? or is that just about minimizing resources rather than improving throughput?

So, it's actually a bit subtle. Sometimes certain block lengths produce certain rhythms in an intersection. Because of this, it's not always better to have smaller blocks. Now, I didn't optimize for that effect (I was already working on it for 2 hours lol); however, my set 2 did synchronize. The block spacing I use is just a habit that I built up over the years that seems to have benefits. It makes sense that you used 2 train car spacing for your smaller trains from before. Also, using fewer signals does save on resources lol...

Edit: I forgot to mention that there're small UPS savings when using fewer signals. It's not a lot, but it's helpful. (Signals don't add UPS normally. They will add tiny amounts when trains trigger repath events.)
Edit edit: Of course using parallelization is bad for UPS as it increases the number of paths that need to be calculated. shrug Oh wells...

I've had issues in the past when trying to experiment with complicated intersections where a train would often (visually noticeable on the benchmark timelapse) block the split even if one branch was free, hence I started adding chain signals before all splits on equivalent paths. It's entirely possible I misunderstood why that was the happening originally, and just made the wrong association.

I can't really speak about your experience. There are a lot of possibilities that could explain what happened.

I was trying to avoid crossings where I couldn't fit signals immediately adjacent to the rail, which pushed me to have more spacing in some places. I see you're using this pattern without any issues though, so I was probably over-optimizing something that doesn't really matter.

You're not wrong that generally smaller crossing blocks are better, but it's only a tiny tpm boost. I made the choice of aesthetics over tpm here, yes... may the Factorio gods have mercy upon me lol

If you use discord, I'd suggest joining the Factorio server. They have a channel called train-help which has a lot of experienced train gurus. It's quite nice.

3-way LHD junction, 4-lane with 2-rail (4-tile) gaps.
Based on Kano96's SuperCompact 4-way design, optimized for footprint, then re-signaled.
Set 1: 58
Set 2: 47
Score: 53
Size: 48x34 https://factoriobin.com/post/3XS3qene

Avona wrote: Wed Mar 20, 2024 10:13 pm

mrvn wrote: Wed Mar 20, 2024 9:04 pm When a train arrives at the intersection it will have a path already picked to cross it and it will go past the first signal. At that point the path is locked in, there is no way the train can repath when there is congestion to drive around a blockage.

Like I previously said, when a train's braking distance touches a red signal on its path, it will repath at that point. If an alternate path has a lower pathing penalty, it will take that path instead. If the alternate path's pathing penalty is too high, the train will not take that path anyway. The only penalty that changes over time is the penalty that increases as a train sits at a red signal. This penalty usually takes an extremely long time to change the train's path, on the order of minutes. If your traffic is sitting there for minutes, then you have bigger problems.

Since the train repaths when it brakes, if a train would repath with a chain signal, then it would repath without a chain signal. The chain signal would only prevent a train from stopping immediately after the split. Since the train has already repathed by that point, it's already determined that it's going to wait there.

You can check the Factorio wiki page on pathing penalties. Also, I've checked this in the game myself and it works. If your train traffic is at a standstill in your base, you should fix that problem instead of adding chains to the entrances of intersections. Chains reduce tpm, increasing congestion.

But a paths cost rises the longer a segment is blocked by a train, as you say. So if a train is sitting at a red (chain) signal the cost of individual path changes with time and the cheapest path can change.

So what happens is that the train arrives at the signal with a path where the next chain signal is red. That is still the best path so it breaks and comes to rest in front of the chain signal. At that point it's path is fixed.

If instead the intersection starts with a chain signal the train will come to rest before the intersection and over time an alternative path can become cheaper and then it switches and takes that path and can leave the intersection.

Or maybe you add a new rail and new paths open up going around a part of the network where you have a gridlock. Or just look at the gridlock. Since trains will be sitting inside the intersection (just past the first signal) none of them can change direction so the gridlock can't resolve itself.

mrvn wrote: Thu Mar 21, 2024 9:16 am If instead the intersection starts with a chain signal the train will come to rest before the intersection and over time an alternative path can become cheaper and then it switches and takes that path and can leave the intersection.

In my base long ago, I watched trains sit at chain signals for minutes before they finally pathed around the congestion. I haven't had traffic problems where the trains came to a standstill in years. Don't allow your rail system to be mediocre. You shouldn't use chains before splits. Fix the actual problem: the traffic. Fix the congestion instead of making suboptimal intersections.

Avona wrote: Thu Mar 21, 2024 10:12 pm You shouldn't use chains before splits.

Can you back that up with any test data? How much throughput does it cost to have chain signals before the splits?

mrvn wrote: Thu Mar 21, 2024 11:54 pm Can you back that up with any test data? How much throughput does it cost to have chain signals before the splits?

I've tested it before but didn't keep the data. I finally had some free time today so I tested the wide you showed in your earlier post as it comes normally and with the entry rail signals swapped to chains (and nothing else changed). Btw, you could easily test the tpm cost with the testbenchcontrols mod yourself.

Rail entry signals:
Score: 42.72
S1: 47.92
S2: 39.07
S3: 41.16

Chain entry signals:
Score: 38.90
S1: 43.85
S2: 35.40
S3: 37.46

So, just under a 10% increase to the score. I would consider it significant.

Thank you for your time testings and sharing the results

For the fun of it i decided to do a test for a 16 lane multicross (buffers between crossings could probably be better optimized)
very good even split distribution, not great all crossing (tbf, a train trying to turn right[on lhd] has to cross 60 tracks on its way through the 1100x1100 intersection) had to expand the tester abit

TBTerra2 wrote: Sat Mar 30, 2024 8:25 am For the fun of it i decided to do a test for a 16 lane multicross (buffers between crossings could probably be better optimized)
very good even split distribution, not great all crossing (tbf, a train trying to turn right[on lhd] has to cross 60 tracks on its way through the 1100x1100 intersection)
multicrossS16.png
had to expand the tester abit
multicrossS16img.png

That is really cool:) insane numbers:)
I like that you could just adjust the testing map, did you find any issues when doing so? I see that the mod fails in counting number of lanes, that is fixable.
Also how is performance? I remember in the old testbench something like this would barely run.

hansjoachim wrote: Sat Mar 30, 2024 11:26 am That is really cool:) insane numbers:)
I like that you could just adjust the testing map, did you find any issues when doing so? I see that the mod fails in counting number of lanes, that is fixable.
Also how is performance? I remember in the old testbench something like this would barely run.

it runs at 90ups, the 4hour test had to be done overnight.
as for modifying the test map. main issues was running out of space, i painted some extra map tiles, but for some reason they (and the spawning stations on them) don't show up on the map

TBTerra2 wrote: Sat Mar 30, 2024 11:55 am

hansjoachim wrote: Sat Mar 30, 2024 11:26 am That is really cool:) insane numbers:)
I like that you could just adjust the testing map, did you find any issues when doing so? I see that the mod fails in counting number of lanes, that is fixable.
Also how is performance? I remember in the old testbench something like this would barely run.

it runs at 90ups, the 4hour test had to be done overnight.
as for modifying the test map. main issues was running out of space, i painted some extra map tiles, but for some reason they (and the spawning stations on them) don't show up on the map

90 is pretty good.
Yeah, the issue with making it larger is probably because the size I put in when making the map. So everything outside of that is out of the map limit. Idk if that is adjustable with the editor.

as i had already extended the testbed decided to see what sort of numbers an unbuffered would get. so heres a 16lane christmas design. couldn't work out how to do it on 6 spacing, so its 8 spacing with adapters
for context, this is worse than a compacted 4lane multicross (the multicross is twice the length, but each leg is only a third as wide)

Actually, i just realized that you don't have the compact multicross 4lane on the main list.
its not much lower score than the full multicross (150 vs 163), while being considerably smaller (350tiles long vs 434), and still easy to build around (only 62 title wide legs)
BP string(LHT): https://factoriobin.com/post/6aNtrQUo
test results (done on normal testbed for consistency): Full image:

Made a pretty cool intersection(s) if i saw so myself: https://factoriobin.com/post/wiXu42ig
It's better then any standard roundabout already, and should be much better on set 4 too (which is no longer a thing tho).
Second intersection is pretty ugly but a bit faster.
Inner Roundabout intersection: Test results for it: Test results for bypass version: Would love for these intersections to be added to the main post.

P¡ІІow wrote: Sat Apr 20, 2024 6:17 pm Test results for it: Inner Roundabout Test.png
Test results for bypass version: Inner Roundabout Bypass Test.png
Would love for these intersections to be added to the main post.

Make sure to include safe exit blocks. All of the intersections have been scored with safe exit blocks, so your results are not comparable.

My test results for your Inner Roundabout intersection with safe exit blocks:
Score: 39.59
Set 1: 45.37
Set 2: 36.18
Set 3: 37.23

My test results for your Inner Roundabout Bypass intersection with safe exit blocks:
Score: 39.91
Set 1: 45.87
Set 2: 36.70
Set 3: 37.18

Your intersections are similar to a symmetrical cross except that the straight paths have been replaced with a roundabout and they're significantly larger. The symmetrical cross has a score of 45. Also, the chunkaligned crossabout includes the u-turn but is significantly smaller and has a similar score of 40. While your intersections may have aesthetic merit, there are significantly better options depending on the desired throughput goal.

Avona wrote: Sun Apr 21, 2024 5:42 am

P¡ІІow wrote: Sat Apr 20, 2024 6:17 pm Test results for it: Inner Roundabout Test.png
Test results for bypass version: Inner Roundabout Bypass Test.png
Would love for these intersections to be added to the main post.

Make sure to include safe exit blocks. All of the intersections have been scored with safe exit blocks, so your results are not comparable.

My test results for your Inner Roundabout intersection with safe exit blocks:
Score: 39.59
Set 1: 45.37
Set 2: 36.18
Set 3: 37.23

My test results for your Inner Roundabout Bypass intersection with safe exit blocks:
Score: 39.91
Set 1: 45.87
Set 2: 36.70
Set 3: 37.18

Your intersections are similar to a symmetrical cross except that the straight paths have been replaced with a roundabout and they're significantly larger. The symmetrical cross has a score of 45. Also, the chunkaligned crossabout includes the u-turn but is significantly smaller and has a similar score of 40. While your intersections may have aesthetic merit, there are significantly better options depending on the desired throughput goal.

Hm, i indeed didn't do safe exits. Also it should be much better in using that u-turn then crossabout, but sadly there is no set to try for it anymore.