As far as I can tell all the things that are needed, and can be blueprinted, are included in the blueprints for each example? The reason they are not included in the first example is that they are not needed to get the system to work, they should be in the second blueprint though.gyro2death wrote:Okay figured it out. I think your base BP string should contain the 3 rail signals and the wire needed to start the thing (with the spawning stop conditioned only to enable when the signal is green).
Second the key here lies in how to name the stops and assign stops between the trains.
IMO you have 3 stops and two trains.
First stop is the "train" stop, which is where your train to be used for testing stops at, the condition for leaving must also never be met. It's second stop is the place you want it to go on the main track network after i spawns at the...
Second stop, which is the "starting" stop. This is where trains will spawn from, and where you'll want to assign your second train without fuel to go to. It only needs to be sent to this starting stop and nothing else needs to be set.
The third and final stop is the end goal. Pretty simple.
I got hung up on figuring out the stop mechanics of which train I was to assign to where. And setting up the rail signals and configuring the stop to be 'enable disabled'. I thought I was missing a setting on the train selection stop.
Yeah, that signal is already included when testing. I usually don't add it to the blueprint as, depending on network layout and train sizes, it may not always be safe to add.gyro2death wrote:Side note, your testing map works great and I can now see why you thought adding a rail signal at the start wouldn't help, however, most train networks don't have rail signals every wagon length so it does help in that case. I created my own slight train testing map before I started using your save and found out that different intersections have a 'lane bias' which allows for traffic to flow out through certain lanes more often, which resulted in a network of 24 trains being nearly completely stuck behind 2 of the 4 intersections after nearly 12 minutes. This is something yours doesn't simulate as trains don't have to try to reenter the intersection. This ended up slowing the throughput in my own test down due to trains not coming from the other intersections as frequently since they ended up being empty. Overall though I find your testing map amazingly flexible for different trains of any length and setup as well as RHD and LHD all in one. Marvelous design work.
The problem of lane bias is the same as what Miravlix discusses on page 5. And I believe you are correct in saying that it will be much more noticeable in a more "lifelike" situation, it still happens in the new test system but it does not have nearly as much of an impact as the trains will not run out. I do believe it is mitigated further by the fact that, in the new tester, after a while the stuck train will have the lowest train ID, which I believe is used to decide which train gets access first to a block two trains are waiting for.
It is an interesting problem, and I'd like to try to add some kind of details on it in the tests, but currently I don't think enough is known about it that I'd be confident doing so. It may be possible to estimate which lanes will have problems by counting how many other lines they need to cross to progress to the next buffer, and how many of those lines can overlap traffic. For example: If you manage to build an intersection that can buffer a train after every crossing I don't think this would ever be a problem, but I don't know for sure. I also currently don't know of a good way to prove that theory, maybe comparing the number of trains that are able to enter the intersection from each lane? It may also be the case that some designs can be fixed by adding circuit controlled traffic lights, though I'm not sure how these would need to be designed to make sure it will work.
)
