3 and 4 way intersections

[ichaleynbin]

First off, a big thanks to everyone for the tweaks in v4.4, I think it's great! There was some weird behavior in one of my intersections that this patch impacted greatly.

Second, I have a weird observation to throw out there, and a couple ideas on how it could be handled. Intersection relevant. The core concept is, I don't know how "realistic" having trains coming in as fast as they are, is. Packing trains that tightly is honestly not so bad to do in a factory, it's the little loops that get two trains packing the rails. I'm 100% sure they could be used more effectively than I did here, I just got proof of concept with this. So it is possible to have the test conditions, in a real factory. It's effort but not that much effort.

I also observed some weird behavior regarding braking distance, where trains who could split (as these can) will accelerate past the tail of the train in front of them to block the intersection. In s2, if you add in enough rail signals just prior to the first split so they aren't getting that little speed check, "tap the brakes" or speed bump, I call it, they'll actually block three other lanes most of the time! I'll have a video about this soon, and I feel like this is kindof an extraordinary datapoint, because adding three extra rail signals to just one entrance, turns an s113 intersection into an s80, absolutely tanking the s2 score to the 40's. It does not similarly tank s1 or s3!

So, is the test scenario realistic? Yes. Did this intersection (with the extra signals) totally bomb to those testing conditions, testing conditions which it can create itself? Yes. However, I learned something, and maybe it'll be of use to y'all some way, maybe just slap a warning sticker on the hood or something. The testing conditions, if you have a branched input path as shown, could allow some inputs to block others because of braking distance and their speed. The braking distance of the second train gets through the intersection, before the tail of the first train clears. Because the trains are launched and packed as they are, attempting to branch and then cross is what triggers this behavior it seems.

It's hard for me to actually recommend any kind of change, except possibly a toggle for "Packed rail" versus "0 speed packed rail accelerating behind an unblock." Maybe a rate change in the advanced settings? It might be possible to adjust the rate of incoming trains based on the measured rate of train output, see how the intersection responds to its own traffic. The problem is that it's so much easier to say "if you see this, the easy fix is to give them a speed bump." It's not really an intersection problem, the intersection is s113, and by that same token it's not even really a rate problem. It was a speed problem, which only happened because they were packed close enough to accelerate beyond the next train when they could, and this is already an edge case and a half.

It's possible for 4 lane intersections to see this behavior rectified with speed bumps too, I haven't done any testing but if you see intersections where fast trains will blow through a crossing rather than letting a bunch of stopped trains cross, speed bumps seem to be a way to fix the core issue I had without affecting throughput too badly. Particularly because they're coming in too fast and their braking distance is too long, in cases where they split for parallel crossing, a speed bump has a markedly positive effect by slowing the trains down, decreasing braking distance just enough so cross traffic can go. This seems like it could be a useful concept maybe somehow to someone?

Michigan Left, Single Buffer per Crossing, Single Split per Lane
Score: 113
RHD, Size: 499x535, spacing: Weird/adjustable?, Train length: 6 cars

Set1: 127, Set2: 114, Set3: 97
Designed by ichaleynbin

picture

[Kano96]

First off, a big thanks to everyone for the tweaks in v4.4, I think it's great! There was some weird behavior in one of my intersections that this patch impacted greatly.
...

Those are indeed some interesting observations. I agree that the rate of incoming trains isn't particularly realistic, that just wasn't a big issue until now. As for using train compression in a real factory, I don't think that's a good idea. When the trains are running that closely together they constantly have to brake a little to avoid running into each other, which also means they constantly have to recalculate their path, leading to massive ups problems. For this reason, we have decided to ban train compression from the normal ranking as we can't recommend anyone to actually use it. If you still want to submit your design, we can put it into the "Others" category, where you can already find my own attempt at train compression. Congrats on the high score nevertheless!

About your issues with the Set2 test, I don't really understand your explanation. Can you maybe post two blueprints showcasing the issue? One working normally, one edited to tank the s2 score.

I always upload my blueprints to factoriobin.com and then just read out the size displayed there. Also I think your blueprint link isn't working.

[ichaleynbin]

Thanks Kano, fixed! Yeah the compressed incoming rails thing, that's easy enough to fix from a user standpoint if you don't want it. Compressed outgoing, eh I'm not actually in contention but might as well throw it up there But if I can't compress the rails out, and the rails are compressed coming in, how useful is that test? Obviously still very, I'm just wondering if there's more relevant data when it comes to using these intersections IRF (in real factorio, like iRL), such as how it handles its own traffic.

I put together this vid to explain the difference. At about 3:20 I point out the three signals that got added to the blueprint to trigger the behavior, which is one input of lanes coming in fast enough to block the other three. It's not completely stable in that pattern in s2, but it's mostly stable. The braking distance of each train passes the end of train in front of it, because they have ONE choice to go a different way. The initial branch is L-S-R so it isn't a choice, they have two lanes to choose from in the direction they're going.

[Avona]

I've made some 4 lane intersections, based on the cross and multicross, parallelized of course!

Parallel Cross 4 Lane
RHD
Score 131
S1: 150
S2: 133
S3: 110

LHD
Score 130
S1: 145
S2: 134
S3: 110

6 car trains, 250x250, 4 lane, 6 tile spacing



Parallel Multicross 4 Lane
RHD
Score 175
S1: 197
S2: 172
S3: 156

LHD
Score 175
S1: 200
S2: 168
S3: 158

6 car trains, 350x350, 4 lane, 6 tile spacing

[Avona]

I've expanded the Symmetrical Cross to 8 tile spacing! Additionally, while I was doing that, it occurred to me that the 6 tile LHD could be 4 tiles smaller with slightly higher throughput!

Symmetrical Cross 8 Tile
RHD
Score 43
S1: 49
S2: 39
S3: 42

40x40, 2 lane, 8 tile spacing

LHD
Score 44
S1: 48
S2: 40
S3: 44

36x36, 2 lane, 8 tile spacing

Symmetrical Cross 6 Tile
LHD
Score 45
S1: 50
S2: 41
S3: 44

30x30, 2 lane, 6 tile spacing

[coppercoil]

I just thought, we need new metric: throughput/chunk. Some crosses have outstanding throughput, but hell, they are HUGE

[DaveMcW]

Simply dividing throughput by chunk count will always make the smallest intersection win.

Anyone who cares about size will use an unbuffered intersection. The buffered intersections are all about throughput at any cost.

[coppercoil]

Of course, small and large intersections are not comparable. I would like to compare small vs small, large vs large, buffered vs buffered and so on.

[Kano96]

I just thought, we need new metric: throughput/chunk. Some crosses have outstanding throughput, but hell, they are HUGE

That is an interesting idea. I like compact builds, so I'm inclined to include something like this, but I don't think it's possible to do it in a meaningful way. Like when you look at the compressed multicross compared to the Stack interchange, they both have the same size, but a wildly different footprint. If we include a size based score, all the square shaped junctions would rank at the top, even though the second shape can often be more "space efficient" as it only uses low value space along the straights.

The real deal breaker is simply that we can't sort the list by this new scoring tho. The only way I see to do this would be to print the whole thing twice, which would already be too big to fit into a single post. It would of course be possible to just keep the old sorting and only display the size score together with the other characteristics, but if we go that far then what is the point in the first place? The people who care enough to actually read and compare the data tables are probably capable of reading out the size and doing a better analysis on their own.

It would provide a new challenge for people to compete for the best score per size, however I don't think it would be that exciting considering the problems mentioned.

[mmmPI]

I just thought, we need new metric: throughput/chunk. Some crosses have outstanding throughput, but hell, they are HUGE

That is an interesting idea. I like compact builds, so I'm inclined to include something like this, but I don't think it's possible to do it in a meaningful way. Like when you look at the compressed multicross compared to the Stack interchange, they both have the same size, but a wildly different footprint.

jumping on the idea, in this particular case, size is not only equivalent to footprint, but also ressources/ amount of rails/rail density.

Those other types of ranking, for example thoughput per iron ore, could be meaningful in some cases where ressources are scarce, or when you want to go fast. Same as rail density could become interesting if you are expanding on water, or planning to fill in the space with solar pannel and accumulator.

I don't think it's possible to include all relevant parameter into 1 single metric and from that create a unified ranking system of the "best" junction in a meaningful way either.

However the speadsheet from the first post could be used to produce charts listing all junctions in 1 picture accordng to whatever metric made possible/considered relevant if there was some of the information contained in the bluestring such as number of rails and signals available on this spreadsheet. It's too bad i have no idea how to do that because that sounds something that could be automated to some degree. ( although for the case of rail density calculation it seems more challenging ).

[sparr]

they both have the same size, but a wildly different footprint. If we include a size based score, all the square shaped junctions would rank at the top, even though the second shape can often be more "space efficient" as it only uses low value space along the straights.

Bounding rectangle would not be a very useful metric, you're right. Convex hull would be slightly more useful (so cross and diamond score the same, but square counts as twice as big). An exact bounded footprint, counting only tiles on or between the rails, would be closer to what I'm interested in.

The real deal breaker is simply that we can't sort the list by this new scoring tho. The only way I see to do this would be to print the whole thing twice

Just put the data in the spreadsheet so we can sort/filter it there. The forum post is almost never the best way to pick an intersection these days.

[coppercoil]

Should the relative throughput consider train size? Longer trains -> larger footprint -> less value, on the other hand, longer trains -> more cargo wagons -> more items moved -> larger value, do they compensate each other?

[Kano96]

jumping on the idea, in this particular case, size is not only equivalent to footprint, but also ressources/ amount of rails/rail density.

Those other types of ranking, for example thoughput per iron ore, could be meaningful in some cases where ressources are scarce, or when you want to go fast. Same as rail density could become interesting if you are expanding on water, or planning to fill in the space with solar pannel and accumulator.

I don't think it's possible to include all relevant parameter into 1 single metric and from that create a unified ranking system of the "best" junction in a meaningful way either.

However the speadsheet from the first post could be used to produce charts listing all junctions in 1 picture accordng to whatever metric made possible/considered relevant if there was some of the information contained in the bluestring such as number of rails and signals available on this spreadsheet. It's too bad i have no idea how to do that because that sounds something that could be automated to some degree. ( although for the case of rail density calculation it seems more challenging ).

I dunno about throughput/iron, that seems like a stretch lol. Maybe for seablock it's relevant.
Making some sort of charts is an interesting idea, although gathering the required data from the blueprints will be somewhat difficult to implement the first time.

Bounding rectangle would not be a very useful metric, you're right. Convex hull would be slightly more useful (so cross and diamond score the same, but square counts as twice as big). An exact bounded footprint, counting only tiles on or between the rails, would be closer to what I'm interested in.

Just put the data in the spreadsheet so we can sort/filter it there. The forum post is almost never the best way to pick an intersection these days.

The bounded footprint sounds much more interesting. Right now we just read out the size manually from factoriobin, but when we decide to automate this we could go for something more complicated. There are already python libraries to interact with blueprints out there, so this wouldn't be impossible to implement.

We already have a spreadsheet. I like the idea to just recommend people to use it when they want to search/filter/sort for a specific design. Google sheets is still pretty new for me, but I just discovered the filter views which do exactly what we need and you can use them without editing power (data->filter sheet->create new temporary filter sheet).

[mmmPI]

I dunno about throughput/iron, that seems like a stretch lol. Maybe for seablock it's relevant.
gathering the required data from the blueprints will be somewhat difficult to implement the first time.
The bounded footprint sounds much more interesting.
Right now we just read out the size manually from factoriobin, but when we decide to automate this we could go for something more complicated. There are already python libraries to interact with blueprints out there, so this wouldn't be impossible to implement.

For seablock it's the case where 2 junctions with the same amount of rail and size may occupy a very different amount of tiles depending on the numbers of rails overlapping or not. ( more generally, everytime you build a grid-like map accross forest lakes and cliffs you reduce the tedium ).

A slightly different case would be between two junction with 5% or 10% difference in throughput, it is possible that one uses 50% more rails to achieve the gain, in this case throughput per iron ore ( +/- == throughput/rail used ) could help evaluate the cost-benefit more accuratly, if you want to expand fast, you may choose the lighter version at first, then replace it with a heavier one where required because of congestion.

Factoriobin also list the individual entity and their quantities Thanks for mentionning the python libraries, now i have an idea on how to do it, but i'm unable to make it happen due to lack of knowledge, still learning

[hansjoachim]

The intersections are now up to date with 4.5.1!

[Zentay]

I suspect that these tests may not be measuring what you think they are measuring.

Much of the performance of an intersection may be simply due to its size, rather than due to good design.

The smaller intersections also tend to be used with a denser grid of city blocks which is better at decentralizing traffic and this can compensate for the poorer individual performance of the smaller intersections. This advantage is not visible on tests that measure the performance of a single intersection.

[Avona]

I suspect that these tests may not be measuring what you think they are measuring.

We are measuring the throughput through each intersection. We are not measuring the throughput through a grid.

[Zentay]

If you have a certain amount of trains and in a certainsection of the network a small intersection is no longer sufficient, is it better to replace small intersections with big ones, or to decentralize traffic by adding alternative routes and avoiding base designs with chokepoints that need huge intersections?

[Avona]

avoiding base designs with chokepoints that need huge intersections?

I just tested the symmetrical cross 6 tile spaced LHD with 100x100 grids:
Score: 54
S1: 77
S2: 43
S3: 42
Note that one of the central blocks deadlocked.

Symmetrical Cross 100x100

Symmetrical Cross 100x100 Design:


One of the blocks deadlocked:

Since the 100x100 design deadlocked, I tested a 200x200 design:
Score: 76
S1: 81
S2: 71
S3: 77

Symmetrical Cross 200x200

Symmetrical Cross 200x200 Design:

You say that by providing alternate routes, you prevent having a very large intersection, however these intersections taken as a whole are very, very large and get worse performance than a purpose built buffered intersection. There is more that goes into building a good intersection than "more space".

In reality of course, inputs into the grid would also be spread out, reducing traffic to any particular intersection.

I've also noted that most trains tend to take a main route regardless or that they cycle between a couple of different routes, filling up one until the pathfinding penalty is too high and then filling up the secondary until it becomes overwhelmed.

While you make a point, it is beyond the scope of our testing. There is no single grid to test intersections on nor is there an easy way to test grids consistently. Rather, we test the intersections and people make the decisions as to what type of factory they want to build and what intersections to use.

Additionally, there are legitimate reasons to use large intersections, such as in non-grid bases.

Do you have something practical to add for our testing? What would you have us do differently?

[Kano96]

If you have a certain amount of trains and in a certainsection of the network a small intersection is no longer sufficient, is it better to replace small intersections with big ones, or to decentralize traffic by adding alternative routes and avoiding base designs with chokepoints that need huge intersections?

I think both are valid approaches. If you have enough space for the bigger intersection anyways, then that's usually the simpler solution. This really depends on the situation tho, like I often find myself building more alternative routes just because I want to capture more ground with my rail network and I need new space for more subfactories anyways. Also nothing speaks against just combining both methods.

Everyone can build bypass routes to improve traffic, but having some good junctions just gives you another option. You can get away with building a lot more compact than usual, which in turn means you need to capture less territory from the biters and you can build closer to your main base, which usually results in easier and faster construction.