4-way intersections: Throughput and deadlocks [image heavy]

Smart setups of railway stations, intelligent routing, solutions to complex train-routing problems.
Please provide - only if it makes sense of course - a blueprint of your creation.
User avatar
TRUEpicness
Long Handed Inserter
Long Handed Inserter
Posts: 74
Joined: Wed Aug 09, 2017 8:21 pm
Contact:

Re: 4-way intersections: Throughput and deadlocks [image heavy]

Post by TRUEpicness »

in my map i have an omnistation that gets all ore except uranium
what i want to do is give the iron trains priority over the others using circuit networks (which i want to start experimenting after never using it because its complex depending on what you want to do)
i have a stacker going into the omnistation and the 2 stacker 'lanes' that are the closest to the omnistation have a trainstop where only and all iron trains go to make them prioritized
they immediately leave that station and go through a signal and then waits at the signal after that (which is in the usual place in a stacker)
the first signal has wire on it that connects to the other signals is the stacker which turn red if an iron train is in the priority part of the stacker
is there any ways i can improve it? (im sure there are lots of ways.)
1 more YouTube vid before bed *starts 24hr long vid*
aaargha
Filter Inserter
Filter Inserter
Posts: 333
Joined: Wed Dec 07, 2016 8:35 am
Contact:

Re: 4-way intersections: Throughput and deadlocks [image heavy]

Post by aaargha »

Zijkhal wrote:Allright, I've completed the automated setup, and run some tests on the Windcross version. Six tests to be precise, all the same (set 1), each averaged over the course of 5 minutes.
My numbers: 57.6, 57.6, 60, 61.6, 58.8 and 56.6
There is a difference of 5 trains a minute between the highest and lowest measurements, which imo is pretty big.

Then I did a 30 minute test, and got 57 trains a minute...
Could it be that all these variations are caused by the randomness of train destinations, so a lucky set will have better use of the buffers, and trains will arrive in a pattern so they can always make use of the maximum number of available turns? This may be made even worse by the seemingly random way trains get priority? I know it is deterministic, but I think it is so sensitive to small details, and has very little consideration of giving priority in a way that allows for maximal throughput, it is virtually random.
The random destination selection is probably the biggest cause of the variations and it seems like the 5min test is too short for useful comparisons in many cases. At 15min the variation seems to be about +-1, I probably won't increase the duration of the tests beyond that to increase the accuracy, the large 8-lane ones take long enough as it is (I can only maintain about 90-100 UPS for them).

I'd really love to know the rules that control which trains get access to a certain block, it could probably be exploited for some neat designs. I've done a bit of testing on that but while some of my theories work for my test setups they do not hold up in the throughput tester. It's probably dependant on the train update order which may involve anything from which chunk the trains are in to the build order of the trains.
Zijkhal wrote:So this made me curious. I set out to eliminate the random factor from the tests. There are two setups I came up with, one where I seperated the input buffers, each having its own train generator and a single destinaction. The throughput bottleneck this way is pretty much how many trains a single line (the output line) can carry. This way it achieved around 93 trains a minute.
Then I hooked up the three train generators to merge into a single line, and controlled which one is released via circuits, I set them into a repeating pattern of left -> straight -> right, so at any time, four trains arrived at the junction, each doing the same turn (all left / straight / right). I only did one such test, as I dont think the throughput will be any different due to the highly controlled nature of this test and that the intesection never backed up. The throughput was 91.2 trains a minute.
That seems perfectly reasonable, a large part of why I implemented the random destinations was that I felt that controlling it like that would make the results too "artificial". It's fun to see the big numbers, but the conditions are a bit far from reality to make the results all that useful :)
Zijkhal wrote:Watching the trains in this second test reassured my suspicion that this intersection actually likes left turns over trains going straight, as it can let four left turns happen in parralel, while only two trains can go straight at any time. Most probably that is why this intersection (and some other) report a higher score in set1 than in set2. The take from this is that the general assumption that left turns (in RHD systems, or, right turns in LHD systems) are bad for throughput is false. It seems, it mostly depends on the type of intersection used.
I agree that the intersection type, mainly buffer placement, will heavily influence this. Still, for the vast majority of the intersections tested set 2 performs better than set 1. For most of the designs where set 1 performs better than set 2 the "bad" turn actually has better buffering than the straight path, best example are probably the multi-cross designs.
Zijkhal wrote:Armed with this knowledge I started building intersections... The entire day passed, and I did not even get to benchmarking the 8-car Windcross which was the whole point, but at least I got three designs, each sort of iterating on the other. A day wasted well spent.
Here is the BP book: https://pastebin.com/e46k2Ncn
And the pics: https://imgur.com/a/qxpaT

The first one I call Braid, because that is what the lines going straight remind me in the middle, also, that one has pretty bad performance (I dont think its worth benchmarking in its current form), it is more of a proof of concept. I may try improving on it tomorrow.

The second one kinda reminds me of a boat prop... :D I have not tested it, but it ought to be better than the Braid ;) Mostly due to more buffers. But I'm curious wether the left turning lane cutting straight across two other lanes will work out or not.

Speaking of more buffers, the third one is full of them. The only thing that is not fully buffered is the left turning lane, but that worked out pretty well for the Windcross. On the straight lines, there are two buffer zones where two 2-4 trains can fit... Although, it would be a real pain to extend the buffers that need extending... I have high hopes for this one. And the best thing is, all those buffers barely increased its size.

Ps.: feel free to change the names
Added as Braid, Propeller and Pasta :) I did muck about with the signals a bit, there was some misplaced signal in one of them, but mostly to enforce 6-car output blocks. Over all, they're three solid designs.

The output block size is something that I probably should have mentioned, and been a bit better with myself (redid the tests for Inscribed square without the train size optimized output blocks), but I think the designs will probably be more useful if they're not locked to one train length. I'll instead add a section with some links to general optimizations that can be applied to most intersections. I'm currently looking to include optimizing output blocks (once I get around to making that posts), the merge-o-matic that tallinu made, and probably something on circuit controlled traffic-lights (once someone manages to design a easer to use system that is not a deadlock waiting to happen).
TRUEpicness wrote:in my map i have an omnistation that gets all ore except uranium
what i want to do is give the iron trains priority over the others using circuit networks (which i want to start experimenting after never using it because its complex depending on what you want to do)
i have a stacker going into the omnistation and the 2 stacker 'lanes' that are the closest to the omnistation have a trainstop where only and all iron trains go to make them prioritized
they immediately leave that station and go through a signal and then waits at the signal after that (which is in the usual place in a stacker)
the first signal has wire on it that connects to the other signals is the stacker which turn red if an iron train is in the priority part of the stacker
is there any ways i can improve it? (im sure there are lots of ways.)
That sounds like it should work so I'm not sure what you're looking for? The only think I can think of is doing the same thing with a regular priority merge instead of circuits, how that is achieved is mentioned a few times in this thread.

You'll probably get better results by making a topic in the "gameplay help" subforum, especially if you include some pictures of you current setup. In this thread it's a bit off-topic.
Zijkhal
Inserter
Inserter
Posts: 25
Joined: Thu Sep 07, 2017 4:32 pm
Contact:

Re: 4-way intersections: Throughput and deadlocks [image heavy]

Post by Zijkhal »

Pasta :D

I'm kinda surprised by the Braid's performance, in the controlled test it got backed up.
And yes, the controlled test is not really representative of a "real-life" scenario.

As for the buffer signalling, what governs where you put the extra signals?

Oh, and I think the Braid should not be A rated, if a train wants to go straight or left, but does a repath, after the first split but before the second, there could be a scenario where they can not fit, and block the output trains. If, for example, two straight lanes going the opposite direction block each other, they could cause a deadlock requiring player intervention.

For left turning vs strainght, true, but both cross four other train tracks, so in a way they are exactly as bad.
aaargha
Filter Inserter
Filter Inserter
Posts: 333
Joined: Wed Dec 07, 2016 8:35 am
Contact:

Re: 4-way intersections: Throughput and deadlocks [image heavy]

Post by aaargha »

Zijkhal wrote:Pasta :D

I'm kinda surprised by the Braid's performance, in the controlled test it got backed up.
And yes, the controlled test is not really representative of a "real-life" scenario.

As for the buffer signalling, what governs where you put the extra signals?
It's mostly that the block after a crossing needs to be as long as the longest train that will use the intersection, at least if it's going to be used by trains of different lengths. Once we've passed that distance signals can safely be placed anywhere. If we'd design for a fixed train length then we can cheat a bit on that as long as we're aware where the trains will stop.
Zijkhal wrote:Oh, and I think the Braid should not be A rated, if a train wants to go straight or left, but does a repath, after the first split but before the second, there could be a scenario where they can not fit, and block the output trains. If, for example, two straight lanes going the opposite direction block each other, they could cause a deadlock requiring player intervention.
Heh, I didn't actually even look for that, most with that kind of performance tend to be A rated, so thanks for pointing that out. From what I can see it would require 8 trains going straight on opposing lanes, to fill the buffers, and another from each direction that switches from left to straight while on the crossing. I've got to say that is one of the less likely ones :) Oh well, it is by far the leading B rated 2-lane intersection at least.
Zijkhal wrote:For left turning vs strainght, true, but both cross four other train tracks, so in a way they are exactly as bad.
And if the intersection is input- and output-dependant the left turn should even be better as it allows for some trains to turn right at the same time. I think that the reason why this is not too visible in the results may be that it is not the left turn in itself that is problematic, what becomes an issue is when you mix trains going left with trains going straight. A train turning left will block all other paths if the other trains want to go straight (the other way around is also true). It does not seem too far fetched that doing a set that is 50% left, 15% straight, and 35% right would perform better for many intersections, at least as long as the left turns do not intersect.

I wonder if the reason the left turn got labelled as bad is that in most "real" scenarios it's mainly trains going straight through with only a few turning left/right to get to certain offshoots.
User avatar
Tallinu
Fast Inserter
Fast Inserter
Posts: 143
Joined: Sun Jun 14, 2015 8:14 am
Contact:

Re: 4-way intersections: Throughput and deadlocks [image heavy]

Post by Tallinu »

Zijkhal wrote: ... A day wasted well spent.
I hear you there! Some interesting looking designs, too. Some of those remind me of a cross between Aaargha's "inscribed square" and the MultiCross layout.
TRUEpicness wrote:is it ok that i have changed the 4 lane multicross intersection into a 2 lane (by removing the outer rail) or should have kept it 4 lane (as in prep for 4 lane system)?
just wondering
I had actually been working on optimized versions of both the 4 lane and 2 lane MultiCross but I got busy with life and distracted by other things before actually posting them (I kept wanting to finish creating rescaled versions for longer trains first). I think I'll go ahead and do that now, since people are active here again.

It's okay to do whatever you want with them, of course, but you'll get better performance with an intersection specifically designed for the number of lanes you're using. Leaving enough room for a future upgrade to four lanes may be a smart move, or you can just build a full 4 lane junction and only use the inner two lanes at first but that's a bit wasteful of track, unless you're absolutely certain you'll be upgrading and don't want to bother with setting up a two lane junction and then just tearing it down and replacing it later. But if materials or maximum efficiency for the current system are the main concern, definitely stick with one designed for two lanes until you're ready to upgrade.

I'll edit them in or make a new post here once I have blueprint books published for the optimized two lane MultiCross variants I have finished. It's a really interesting design, I think, because there are several versions each with different length and performance. And with the way I've set up the blueprints, each holding just one of the four arms of the junction which you rotate and assemble, you can actually have different parts of the same junction use different versions of it, so that the entrance/exit tracks with the most traffic use a longer, high-performance layout while the tracks with lower traffic use smaller layouts with less buffers (or even a universal piece with no buffers -- for example, if you know the station(s) down that track are only ever going to have one train assigned to each).
aaargha wrote:I wonder if the reason the left turn got labelled as bad is that in most "real" scenarios it's mainly trains going straight through with only a few turning left/right to get to certain offshoots.
You're almost certainly on the money there. Except for a situation where most traffic is turning toward or coming back from a direction at a right-angle, and the "branches" are going straight and turning the other direction, but I doubt that happens too often. I suspect four-ways are most often used where most of the traffic is going straight through to reach destinations further down a continuing main line.

---

Here are the two-lane MultiCross blueprint strings I'd been working on. There are versions for both LHD and RHD in 6, 8, 10, and 14 car scaling, although not all versions are included at the longer scales. Partly because beyond a certain length the expanded versions just don't make a lot of sense, and partly because the TurboCross's merge manager takes a lot of tweaking to get it to handle a new train length reliably.

https://drive.google.com/drive/folders/ ... mJ0NDdVMjQ

Let me know if there are any problems accessing those.
User avatar
TRUEpicness
Long Handed Inserter
Long Handed Inserter
Posts: 74
Joined: Wed Aug 09, 2017 8:21 pm
Contact:

Re: 4-way intersections: Throughput and deadlocks [image heavy]

Post by TRUEpicness »

i can access them just fine
i have saved the lhd versions of them into a blueprint book called 'keep for future bases'. i do really like how you have just a quarter of the whole thing and you then put it together though.
i went on xterminators website and got his 4 lane blueprint book which doesnt include a 4 way intersection for some reason
1 more YouTube vid before bed *starts 24hr long vid*
noodlebox
Manual Inserter
Manual Inserter
Posts: 2
Joined: Mon Oct 09, 2017 3:01 am
Contact:

Re: 4-way intersections: Throughput and deadlocks [image heavy]

Post by noodlebox »

I've been working on a new BP book for a different rail gauge, and that meant making some new intersections. Then I found your benchmarking map and got lost in that for a while, until I finally decided to post here with my results. :D

Here's a set of "Celtic Knot"-style intersections for 2-, 4-, and 8-lane RHD, but signaled a little differently for improved throughput. Trains are much more optimistic about entering the junction to move as far forward as they can without risking a deadlock, and often don't end up needing to stop. The 4- and 8-lane versions perform very well, considering their size. These should be deadlock safe regardless of train length or repathing, though there could be something I've missed. At worst, a perfect storm of repathing events could lead to trains ending up in a slow-to-resolve jumble, but an automatically resolvable one at least., [edit] but I've found some cases where they can deadlock if multiple trains repath. I eliminated a C-level deadlock possible in the original version if two trains repath by chain signaling a few more blocks (throughput numbers below should drop by around 5-10%), but the 4- and 8-lane versions are still at least vulnerable to a B-level deadlock if four trains repath inconveniently. I also have some buffered versions that I can post after I work out a couple small bugs if everything else is alright with these.

Potential B-level deadlock setup in 4- or 8-lane version:
- Train A enters on outer lane from South, intending to exit North, recalculates path after first chain signal and stops because Train B has reserved a block ahead of it.
- Train B enters on outer lane from East, intending to exit West, recalculates path after first chain signal and stops because Train C has reserved a block ahead of it.
- Train C enters on outer lane from North, intending to exit South, recalculates path after first chain signal and stops because Train D has reserved a block ahead of it.
- Train D enters on outer lane from West, intending to exit North, repaths to exit East after first chain signal and stops because Train A is inside a block ahead of it.
- Deadlock resolves if any of these trains repaths again to exit to its own left.

I don't think the deadlock rating can be improved to A simply by adjusting signals. So, I think that would be an "A" rating for the 2-lane version, and a "B" for the 4- and 8- lane versions.

"Greedy" Celtic Knot Junctions
BP Book (2017.10.09) (revised, with A/B-level deadlock ratings)
BP Book (2017.10.08) (original, with C-level deadlock ratings)
Images: https://imgur.com/a/Fmstv

I did some testing and these are the trains per minute I got for profiles 1 and 2:
Dual Celtic Knot - 42/48
Quad Celtic Knot - 72/78
Octo Celtic Knot - 110/110

Edit: found some repathing deadlocks
Last edited by noodlebox on Wed Oct 11, 2017 1:55 am, edited 2 times in total.
sillyfly
Smart Inserter
Smart Inserter
Posts: 1101
Joined: Sun May 04, 2014 11:29 am
Contact:

Re: 4-way intersections: Throughput and deadlocks [image heavy]

Post by sillyfly »

Very interesting thread and ideas, I'm surprised I have only just now come across it (maybe its because I've taken a break from Factorio :D )

If I might suggest a more "systematic" categorizing scheme. Sometimes it is more important to have lower probability of deadlock (if 100% safe / Cat A is not possible for some reason), while other times you may decide an occasional deadlock is fine, so long as it can be resolved automatically - so the straight linear order is not always accurate for all cases.

I suggest a three-metric categorization scheme, because well - we all like to play Factorio, so I assume we all like things that are neat and concise. Namely, I suggest labeling intersections "STE", where
  • S stands for Safety, and can be one of:
    • S for Safe, meaning no deadlocks possible
    • P for Problematic/Potential-deadlock, meaning deadlocks are possible in rare cases where two or more trains re-path inside the intersection
    • D for Dangerous, meaning deadlocks are possible in cases where even just one train re-pathes inside the intersection
    • U for Unsafe, meaning deadlocks may occur even with no re-pathing occuring
  • T stands for Troubleshooting, and can be one of:
    • A for Automatic, meaning all possible deadlocks may be automatically resolved if a block clears.
    • M for Manual, meaning deadlocks which require manual intervention for solving may occur.
  • E stands for Efficiency, and is a number between 0 and 100 signifying the percentage of the maximum theoretical efficiency. In practice, since a single lane can support almost exactly 30 trains per minute, a 4-way n-lane intersection has a maximum theoretical throughput of

    Code: Select all

     30 * 4 * n / 2 = 60 * n 

    trains per minute (half of the lanes are incoming, half outgoing). This is very convenient, as it means 100% efficiency is exactly 1 train per lane per second. So to convert from TPS to Efficiency you simply divide by the number of lanes and multiply by 100.
As an example, here is the conversion from the original categories to this scheme (with efficiency omitted):

A -> SA
B -> PA
C -> PM
D -> DA
E -> DM
F -> UM

Note that SM and UA are not possible categorizations, as a Safe intersection will never require player intervention by definition, and an Unsafe intersection (presumably) always fails in a way that requires player intervention.

As for the efficiency, I think it can be extremely interesting to see the law of diminishing returns, and how it applies to intersection - presumably, the higher-lane version of an intersection will have a lower efficiency, but does it scale the same way for all types?


(Note: I may have been over-thinking and over-complicating this... )
ERJHolton
Burner Inserter
Burner Inserter
Posts: 9
Joined: Mon Oct 09, 2017 4:36 am
Contact:

Re: 4-way intersections: Throughput and deadlocks [image heavy]

Post by ERJHolton »

Thank you for this thread! Excellent information, and the test-bench map is lots of fun for experimentation. I have one quick question about the test methodology. Do you reset the counters as soon as you start the trains, or do you let the trains run for a few minutes first to let it settle into a steady flow before starting the counter?

Finally, I'd like to offer my own small contribution to the 2-lane four-way canon. On a whim I decided to try to design a junction loosely based on the magic roundabout; that is, a series of roundabouts feeding into a central contradirectional roundabout. It took a few iterations and refinements, but eventually I came up with a layout that seems quite stable under the three provided major profiles (equal, planned RHD, planned LHD), and has reasonable throughput. There are potential deadlock scenarios, but I think actual deadlocks would be quite rare.

Blueprint string:
Magic Roundabout v4r4
Picture
User avatar
TRUEpicness
Long Handed Inserter
Long Handed Inserter
Posts: 74
Joined: Wed Aug 09, 2017 8:21 pm
Contact:

Re: 4-way intersections: Throughput and deadlocks [image heavy]

Post by TRUEpicness »

thats the biggest roundabout ive ever seen
1 more YouTube vid before bed *starts 24hr long vid*
mrvn
Smart Inserter
Smart Inserter
Posts: 5865
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: 4-way intersections: Throughput and deadlocks [image heavy]

Post by mrvn »

At the start there was the simple round about and crossing and then things got bigger and bigger. With buffers before, after and even inside the constructs all to imporve throughput. The designs allow multiple trains to take a left (or right) or multiple trains to go straight at the same time and the buffers are there so hopefully the game will pick the right trains to move at the same time.

Now I wonder if that choice should be left to the game at all. Why not build a real traffic light? Split each track into left turn, right turn and straight and then have buffers. Use circuits to enable combinations of trains to pass through the junction, e.g. all left turns at the same time, for a while. Buffers that threaten to overflow should be allowed to drain first or most often but also no train should be held back forever. For advanced circuit use: Try to control the signals leaving the buffer zones to interleave the trains. Give them enough tracks to get up to speed so they race across the actual junction. Start the next set of trains so that it arives at the junction as it clears.
Jap2.0
Smart Inserter
Smart Inserter
Posts: 2378
Joined: Tue Jun 20, 2017 12:02 am
Contact:

Re: 4-way intersections: Throughput and deadlocks [image heavy]

Post by Jap2.0 »

mrvn wrote:At the start there was the simple round about and crossing and then things got bigger and bigger. With buffers before, after and even inside the constructs all to imporve throughput. The designs allow multiple trains to take a left (or right) or multiple trains to go straight at the same time and the buffers are there so hopefully the game will pick the right trains to move at the same time.

Now I wonder if that choice should be left to the game at all. Why not build a real traffic light? Split each track into left turn, right turn and straight and then have buffers. Use circuits to enable combinations of trains to pass through the junction, e.g. all left turns at the same time, for a while. Buffers that threaten to overflow should be allowed to drain first or most often but also no train should be held back forever. For advanced circuit use: Try to control the signals leaving the buffer zones to interleave the trains. Give them enough tracks to get up to speed so they race across the actual junction. Start the next set of trains so that it arives at the junction as it clears.
I've been thinking about making something like that with a lot of buffer and circuits esssentially being traffic lights for some time now, but I haven't gotten around to it yet. Maybe this weekend.
There are 10 types of people: those who get this joke and those who don't.
ERJHolton
Burner Inserter
Burner Inserter
Posts: 9
Joined: Mon Oct 09, 2017 4:36 am
Contact:

Re: 4-way intersections: Throughput and deadlocks [image heavy]

Post by ERJHolton »

When it comes to roundabouts, at least, circuits would be needed to force respect for the offside priority rule (ie, traffic within the roundabout has priority over traffic waiting to enter it). If I get time this evening I might test a simple roundabout with quadrants of a full train length that has signalling for such implemented, and see how it behaves.

Edit: Done. It's a bit bigger than I said above, but it flows quite well. If it can deadlock with fewer than 12 trains in the circle I'd be surprised, and that's a scenario that seems unlikely at best.

String below, plus a picture, and a close-up of the combinator setup.
Offside priority roundabout v1r4, RHD
Overview picture
Combinator setup
mrvn
Smart Inserter
Smart Inserter
Posts: 5865
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: 4-way intersections: Throughput and deadlocks [image heavy]

Post by mrvn »

ERJHolton wrote:The rail at the bottom is part of the roundabout, while the rail coming in from the top is one of the entrance legs.The rail signal on the right is read and the signals input into the right-hand arithmetic combinator. It adds the red and yellow signals together and outputs that as cyan. The other combinator adds together the value of the cyan signal and the value of the red signal from the rail signal at the exit of the junction, and outputs the result on the pink signal. Finally, the rail signal that controls the top rail's access to the junction is set to be closed if the pink signal is greater than zero.

The upshot is that if a train on the roundabout is either within three wagon lengths of the junction or is moving fast enough that it reserves the block, it stops trains from entering the roundabout. Even if it is clear for a train to enter, it won't unless it can move through the junction. This setup is replicated at all four entrance junctions.
I would like to take this a step further. Move the buffers further away from the roundabout so they can accelerate before entering it and then time the signals in such a way that the entering train will slot right between trains already on the roundabout. Same on the output side. There should be enough tracks for the train to slow down if the output is congested. Trains should also only be allowed to enter when their destinations output buffer has space for them. The idea would be that trains inside the roundabout are always at (near) full speed.
ERJHolton
Burner Inserter
Burner Inserter
Posts: 9
Joined: Mon Oct 09, 2017 4:36 am
Contact:

Re: 4-way intersections: Throughput and deadlocks [image heavy]

Post by ERJHolton »

I like the idea, but there are some challenges to implementation. Firstly, you want trains moving swiftly through junctions, but not so fast they speed-reserve blocks too far ahead. Secondly, if a train's path has multiple branches, it becomes problematic to detect their overall path through the junction. Finally, if you have different train types on your network (eg bulk trains are 2-4, with some 1-2 legacy/small volume item trains, and 1-1 fluid wagon trains; perhaps some trains are fuelled with coal rather than solid fuel or rocket fuel), you'll have trains with different acceleration rates.

There is a mod with a potential answer to the first challenge, called Train Speed Limit. The second challenge is one I currently do not have the know-how to solve, and the third would have to be solved by completely standardizing on one train type (including having to barrel / unbarrel fluids rather than using the heavier fluid wagons).
Jap2.0
Smart Inserter
Smart Inserter
Posts: 2378
Joined: Tue Jun 20, 2017 12:02 am
Contact:

Re: 4-way intersections: Throughput and deadlocks [image heavy]

Post by Jap2.0 »

Sorry everyone. I tried to make an intersection using the traffic light principle and combinators, but I've never been much good at them, so I don't really have anything to show for it. Someone else feel free to try - I still think it would be a really cool intersection, if it was done by someone more adept at circuits than me.
There are 10 types of people: those who get this joke and those who don't.
User avatar
hansjoachim
Filter Inserter
Filter Inserter
Posts: 252
Joined: Wed Apr 26, 2017 7:03 pm
Contact:

Re: 4-way intersections: Throughput and deadlocks [image heavy]

Post by hansjoachim »

Jap2.0 i am working on one. And it works pretty well, but I have to fix a couple things before posting it. You can se an earlier version from me if you want.
There is a save file attached to that older post
viewtopic.php?f=194&t=46855&start=240
mrvn
Smart Inserter
Smart Inserter
Posts: 5865
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: 4-way intersections: Throughput and deadlocks [image heavy]

Post by mrvn »

ERJHolton wrote:I like the idea, but there are some challenges to implementation. Firstly, you want trains moving swiftly through junctions, but not so fast they speed-reserve blocks too far ahead. Secondly, if a train's path has multiple branches, it becomes problematic to detect their overall path through the junction. Finally, if you have different train types on your network (eg bulk trains are 2-4, with some 1-2 legacy/small volume item trains, and 1-1 fluid wagon trains; perhaps some trains are fuelled with coal rather than solid fuel or rocket fuel), you'll have trains with different acceleration rates.

There is a mod with a potential answer to the first challenge, called Train Speed Limit. The second challenge is one I currently do not have the know-how to solve, and the third would have to be solved by completely standardizing on one train type (including having to barrel / unbarrel fluids rather than using the heavier fluid wagons).
I think you do want the trains at full speed for maximum throughput. Make the junction large enough that their reservation stays inside it. I'm talking humongous.

I don't get your comment about multiple branches. In my suggestion each input would split right at the start into as many branches as there are outputs. Then you have buffer area for each. So the trains path gets decided before it enters the input buffer.

Your comment about different speeds is a problem. I have no problem standardizing on one kind of fuel and one type of train length. But fluid wagons are just so damn useful. I wouldn't want to do without them. On the other hand, at least in vanilla, you probably won't have many liquid trains. So maybe they can just be ignored.
User avatar
Tallinu
Fast Inserter
Fast Inserter
Posts: 143
Joined: Sun Jun 14, 2015 8:14 am
Contact:

Re: 4-way intersections: Throughput and deadlocks [image heavy]

Post by Tallinu »

mrvn wrote:I don't get your comment about multiple branches. In my suggestion each input would split right at the start into as many branches as there are outputs. Then you have buffer area for each. So the trains path gets decided before it enters the input buffer.
This is exactly what's done in most of the really high throughput junction designs. That concept was present even my old "Cross" design from before I had access to these great testing tools, and by now it's been pretty well refined, although there's certainly room for more innovation! :D

I'm not sure how well that idea would work in regards to a roundabout though, considering that they tend to put all traffic on the same circular path regardless of which exit a train is heading for. Having multiple paths onto the roundabout per entrance would be functionally equivalent to a stacker, as in an input buffer with multiple parking slots side by side, and all trains waiting at that entrance would be trying to use, or at least start out using, the same path through the roundabout. There's no way to know which train is heading for which exit unless there's a one to one correspondence between input buffers and accessible output buffers, and if all of a given set of input buffers merge onto the same roundabout track, then that's not the case. I don't think it's possible to make something for which that's true and which also qualifies as a roundabout (and not just something that resembles a roundabout visually, but can't actually be traversed in a full circle).

On the other hand, the idea of having a really huge roundabout with circuitry to help a train merge into the gaps might work, although detecting a gap large enough for an entire train and its track reservation to fit in might be difficult, and I can tell you from experience that it's also difficult to get trains to travel at a consistent speed and reliably do what you want them to do, even with some serious circuitry. But if you want to, you're welcome to have a look at the merge managers on a few of the MultiCross blueprints I posted recently for some circuitry that you might be able to modify to always prioritize one lane (the main roundabout path) over another (the entrance), or at least for an example idea of how I handled some of that detection and lane control.
ERJHolton
Burner Inserter
Burner Inserter
Posts: 9
Joined: Mon Oct 09, 2017 4:36 am
Contact:

Re: 4-way intersections: Throughput and deadlocks [image heavy]

Post by ERJHolton »

I've been messing around a bit with the offside priority roundabout I posted earlier, trying to work out ways to where when train A exits a roundabout, train B can enter the roundabout without forcing train C to stop at the chain signal. Ideally, train C would be forced to slow down for just long enough for train B to clear the merge. The mod I linked to earlier, Train Speed Limits, would probably be the easiest way to set the speeds, but I expect some creative flashing of red signals ahead of train C would do something similar.
Locked

Return to “Railway Setups”