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...
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.
