Build this blueprint, make a 1-loco train with rocket or nuc fuel and the "Croebh" destination and send it on its way. The train stops at the chain signal, as it should. The problem is what happens with the rail and circuit signals, the downstream block stays reserved in error, congesting the merge in error for many ticks. You can send the train around the track to see it again by toggling the constant combinator from on to off, depending on the phase of the moon your first attempt might not show the symptom, even though the train stops.
The rail signal below the pulse converter in the picture is wired no-read, close if H>0. The entry signal on the circuit is wired no-close, read red or yellow as H. So when a train reserves the entry block, the signal reads H and the exit signal should close in one or two ticks, stopping the train before it can reserve the merge block. Sending a -1 H pulse opens the signal for that pulse, any waiting train reserves the block and everything continues as it should.
But when a fast train is approaching, even though the train does stop and at first glance everything might to have worked, the easiest way to see that something's screwy is by turning on braking point display (that won't need any explanation, it's just _weird_), or you can hover over the power pole and watch the signals on the wire, or you can watch the rail signal guarding the other entrance to the merge: at nuc-fuel speed, the approaching train reserves the merge block for nearly a full second before the signal closes. When I trace it, on tick 166 the H signal lights, on tick 167 the yellow (from the chain signal) lights (and H is still lit), but it's not until tick 227 that the chain signal goes red and the merge block is released.
Seems to me, you should be able to tell whether the block is reserved or it's not. If the chain signal reads yellow the blocks should really be reserved and the train should be permitted to pass; if it's not reserved, the signal shouldn't read yellow and other trains should be allowed in. But here the signal's lying: it reads yellow, but then changes its mind a second later and retroactively stops the train.
edit: okay, I think I get it: the entry block is less than two ticks long at nuc/rf speeds, so the arriving train sometimes reserves the chain signal before the circuit readout has time to propagate, and so the exit signal honors the committment the chain signal made. Then, when the train's braking point reserves the (pre-0.17-style-)waypoint entry block, the waypoint disables itself, and the train does a full repath - - which releases the reservation before trying to re-reserve its new path, which just by coincidence the same as the old path up through its braking point. But the merge entry signal's wired closed, and the reservation was already abandoned, the new reservation is refused and here's where trains are allowed to do magic stops, if they repath through a previously-reserved-for-them-but-closed-after-being-reserved path. If I extend the chain entry block so it's 5m long (3×1.39 is 4.17m so 4 won't always be enough)
Are the magic stops something people are wedded to like mining robots? I get the robot mining part, you get to choose between honorable frustration and just getting on with your business, but that's at least something that requires affirmative action, a conscious choice to cheese. Seems to me when repathing a train should be allowed to re-up any reservation it already had, especially since repaths can happen so very far ahead for long trains, and for so many reasons that wind up not altering the previously-reserved part of the path.
Post your bugs and problems so we can fix them.
1 post • Page 1 of 1
- Filter Inserter
- Posts: 646
- Joined: Sun May 08, 2016 9:01 am