Factorio Forums

was moved from bugs to suggestions by boskid — ssilk

Factorio version: 1.1.57
Mods: None

You cannot close yellow train signals with the circuit network. (They "lock" as yellow until the train which reserved them has passed).

This is the intended behavior. However, it is inconsistent with how other signal logic works, and somewhat counter-intuitive.
(I've filed this under "bugs" because it feels more like a "fix" than an "enhancement." Feel 100% free to move it if you want.)

Example setup:
1. Construct attached blueprint
2. Set trains to automatic
3. Enable combinator at start

Argument:
The reasoning I have mostly seen around the forum is that yellow signals are locked because the train has "committed" to that path; it is locked-in and cannot change course. However, this is not the case in-game. I can un-commit any train I feel like by closing a signal right after the yellow signal. This forces a repath; if the train finds an alternate path it will un-commit and go on the alternate path. (This is what happens on the top track). This is inconsistent; I can't close the yellow signal because the train is commited, but I can un-commit it with a single signal right next to this one? Why not just let me close the yellow signal?

This behavior is inconsistent with green signals. When I close a green signal, any trains coming along will redirect around the closed block if possible. If not, they will come to a stop at the closed signal. When I close a yellow signal, I expect the incoming train to redirect around the closed block if possible. If not, it will continue (there's nothing else to be done in this case).

Instead, when I close a yellow signal it does not close. This is very unexpected.

This is demonstrated on the middle and bottom tracks. On the middle track, we close a signal while it is green; the train diverts and goes around. On the bottom track, we close the signal while it is yellow. The train does not divert, despite having the opportunity to do so.

Proposed behavior in detail:
When a yellow signal is closed:
1. Attempt to path as though the block was closed.
2. If 1 succeeds, attempt to reserve the necessary blocks for the new path.
3. If 2 succeeds, un-reserve blocks from the old path and close the signal.
4. If 1 or 2 fails, then maintain old path and lock the signal as yellow (current behavior).

The proposed behavior maintains all necessary reserved blocks at all times, and therefore does not permit collisions.

Copy blueprint

(Longtime lurker, first-time poster. Am I doing this right?)

Very early versions (pre 0.17 some time), trains would drive past red signals if it did not have enough stopping distance when a circuit closed the signal, because they were completely governed by physics.

IIRC, The next fix was to allow instantaneous deceleration to stop at circuit-closed signals. This stopped trains from violating the circuit conditions, but was was unrealistic and inconsistent behavior.

I assume this was reverted in 1.0/1.1, and now it is assumed that the circuitry will check if a rail signal is yellow before it tries to close it. The train will keep the signal yellow to indicate what it will do, will pass the signal without breaking the physics rules, and subsequent trains will stop for the red signal.

If I understand your post correctly, your case is a nuance of these: When the train does not have space to stop before the circuit-closed, but does have a diverging route it could repath to and avoid the closed signal without stopping. That's an interesting case and I've run into it myself as well. Hopefully it can be implemented in an efficient manner.

Current implementation is that when a circuit network wants to reserve a signal but a signal is already reserved by a train (either by the braking point being past this signal or because of train being inside of the guarded rail block), circuit network close request becomes pending and it will be acquired as soon as the signal becomes green. There are many safeguards here that will make sure a train repathing (which internally releases current path, releases all reservations, repaths and reacquires signals up to braking point) will be able to reacquire a reservation of a signal that a train already had acquired before a repath. I am not seeing anything broken in the behavior described as current. There are for example safe crossing setups working nicely with current behavior where a gate read causes a rail signal request to be closed and once a rail signal is really closed by circuit network it stops sending any signals which opens a gate for a player to pass. This solution prevents making trains to immediately crash if they already have signal reserved. I will think about this more after waking up but honestly at first glance it is a not a bug.

Thank you for your response! That was really fast.

The desired behavior is only different from the existing behavior when there is a potential alternate path for the train. Train crossings would not be affected unless the incoming train has another path around it. In that case they would be improved; nearing the crossing would cause trains to path around the crossing by some other route, and let the player walk through without delay.

Neither the existing nor proposed behavior allow any train crashes to occur. I don't think that's an issue?

A lot of my reasoning for filing this under "bug" is that it's unexpected for most players, and doesn't match with how the other signals work (as above). I thought about calling it a "suggestion" but it doesn't really *add* stuff so much as adjust the current behavior to be consistent with the rest of the game. On the other hand, that's a pretty subjective thing.

I think any issue around allowing you to close a yellow signal would then being this signal first sending a signal to the train that reserved it to repath and, if the train successfully repaths, then closes. But if it doesn't repath, then it shouldn't be allowed to close as this would be misleading and could cause other issues beyond (because, yeah, it's less about the train being "committed" to this path and more about if the train needs to brake, this signal is already inside the stopping distance).

Edit: Just to clarify, I would think this would add extra overhead to these situations which may be complex to handle. When a train repaths, as boskid mentioned, the train first releases everything. This means that now the signal must show itself as closed while the train is attempting to repath (otherwise it will logically repath back the same way in many cases), but if no other path is actually available, then make itself open and available again.

To me, the logic of not being able to close a yellow signal is sound.

Yeah, if the train has no other option than to continue - then it should definitely continue, and the signal shouldn't close. It's rerouting if it can that's important.

There's a bunch of cool stuff you can only do if you can close yellow signals. Like multi-step train crossings, where traffic is diverted around the player as they cross multiple lanes of train traffic. Or train accelerators, where you loop a train around until it reaches full speed before sending it off into ... wherever. Biter territory, a high-speed "freeway" track, etc. Without the ability to reroute a train by closing a yellow signal, both of those are either outright impossible, or very unwieldy/unreliable.

Edit: Does the train pathing still use Dijkstra? If so, it shouldn't be too big a change to filter out certain nodes in the process, just check if your new node is <node to exclude> when adding it to the queue, and skip it if so. Otoh, implementations vary, and "should" is rarely so simple.

Imho, as already explained above, the current behavior when closing a signal is fine. Thus I'd argue for intended behavior / not a bug.

The feature request of having the train repath when one of it's reserved signals gets closed and attempting to avoid that signal seems reasonable. It would mimic the behavior when repathing while the target stop has exceeded its train limit: Try to go elsewhere, but keep the original target if there is no other option.

ravenwolf397 wrote: ↑Sun Apr 24, 2022 2:44 am Or train accelerators, where you loop a train around until it reaches full speed before sending it off into ... wherever. Biter territory, a high-speed "freeway" track, etc. Without the ability to reroute a train by closing a yellow signal, both of those are either outright impossible, or very unwieldy/unreliable.

I'd love to see or make one of those train accelerators once the requested behavior is released. Sounds awesome and fairly practical. You could make trains on the main line never have to slow down for joining trains, and also wait in top speed in a loop before a crossing instead of stopping.

i was thinking about this and i am not considering existing behavior to be broken. Moving to "ideas and suggestions"

Qon wrote: ↑Sun Apr 24, 2022 8:40 am

ravenwolf397 wrote: ↑Sun Apr 24, 2022 2:44 am Or train accelerators, where you loop a train around until it reaches full speed before sending it off into ... wherever. Biter territory, a high-speed "freeway" track, etc. Without the ability to reroute a train by closing a yellow signal, both of those are either outright impossible, or very unwieldy/unreliable.

I'd love to see or make one of those train accelerators once the requested behavior is released. Sounds awesome and fairly practical. You could make trains on the main line never have to slow down for joining trains, and also wait in top speed in a loop before a crossing instead of stopping.

Already possible.

quyxkh wrote: ↑Mon Apr 25, 2022 7:37 am

Qon wrote: ↑Sun Apr 24, 2022 8:40 am

ravenwolf397 wrote: ↑Sun Apr 24, 2022 2:44 am Or train accelerators, where you loop a train around until it reaches full speed before sending it off into ... wherever. Biter territory, a high-speed "freeway" track, etc. Without the ability to reroute a train by closing a yellow signal, both of those are either outright impossible, or very unwieldy/unreliable.

I'd love to see or make one of those train accelerators once the requested behavior is released. Sounds awesome and fairly practical. You could make trains on the main line never have to slow down for joining trains, and also wait in top speed in a loop before a crossing instead of stopping.

Already possible.

That's really cool! The only accelerators I had seen before this had to use stations. And is that a spedometer too?

(Making an accelerator is actually the project that led me to post. Apologies for the following word salad.)

However, that design does have a few limitations that make it less than ideal:
1. It is very large (>200 tiles long). It has to be, for reasons I'll explain
2. With some trains, it only accelerates them to low speeds
3. It fails with heavy trains

These all stem from the same root cause.

The linked design (if I understand it right), reads a yellow signal and starts counting each time a train approaches an exit. After 10 ticks it closes off the exit of the accelerator. If the train has reserved the exit before the timer elapses then the closing fails, and the train leaves. Otherwise, the exit closes and the train repaths to the other exit.

This fails if the train's braking distance is long enough to cover the distance between the two exits. For example, suppose we adjust the signal condition to close an exit to "yellow >= 3", to get our trains going faster. This works fine for very short trains. However, if you put a 1-4 artillery train into it then you see some weird stuff happen: the train speeds up, slows down, speeds up, slows down, and eventually exits at low speed when the stars happen to align.

What is happening is that i) the train approaches the first exit. It is going too slowly, so the exit closes. ii) the train's braking distance approaches the second exit - while the train is still behind the first exit (the braking distance is large because the train is heavy - it's artillery). The train is still going too slowly, so the second exit closes. iii) the train sees there is no path out, and quits. iv) the train drifts past the first exit, which opens and v) the train sees a path out, and starts moving again.

The train does eventually escape - at only 100kmh, after having accelerated well past that and slowed down again several times. This is the same issue I've seen in my own attempts.

This issue is more apparent if you try to build the accelerator smaller, or try to accelerate to larger speeds. For example, suppose I wanted to use your design to send a 1-0 locomotive in a small loop - to its max speed, and just never let it out. Instead of measuring the speed of the locomotive and closing the exit only if it's slow, I will just close each exit whenever the locomotive's braking point gets close. (This is equivalent to setting the condition to "yellow >=1").

This doesn't work, unfortunately. The train stutters and escapes like before.

Like in your design, the train's braking distance will eventually extend across both exits. The first exit will close, so the train repaths to the second exit. Either i) the train's braking distance is long and its braking point is *past* the second exit, in which case it will instantly reserve the exit and escape (like it shouldn't), or ii) the train's braking point is in the middle of the second exit, and the exit will close. This leaves the train with no viable exits, so it drifts and slows down. Then the braking distance shortens enough that an exit can open, and the cycle starts again. It will repeat until the train escapes.

Copy blueprint

(The above blueprint is somewhat sensitive to the starting point of the train - if it doesn't do anything interesting the first time, try moving the initial location of the locomotive. It should circle around once or twice, accelerating and slowing down, before eventually picking an exit and leaving.)

The only ways I've found around this problem are either i) don't accelerate the train very fast, so its braking distance can't get very long. This is missing the point of a train accelerator. ii) Build an accelerator at least twice as large as the braking distance of your heaviest train at its maximum speed. Given that 200 tiles isn't big enough for just a 1-4 arty train at half speed, this would be enormous and only really useful in a megabase or as a toy. Or iii) let us close yellow signals.

(Sorry to rag on your design - it works well for non-arty trains, and even low-to-medium speeds with artillery trains. (Wait - 2016? Did they even exist when you made this? Damn you're a veteran.) And that's a cool spedometer design too, mind if I use that?)

tldr; The limitations of this design all come from the fact that once a train reserves a block, there's nothing we can do. But if there is something we can do (ie. close yellow signals), then all the problems I listed are now possible to solve. Basically, if we can't close yellow signals then we have to work around the braking distance of our heaviest train, which is often very large (much longer than the train itself), which means we have to build even larger designs to accomodate them. This is impractically large for some common train sizes.

boskid wrote:There are many safeguards here that will make sure a train repathing (which internally releases current path, releases all reservations, repaths and reacquires signals up to braking point) will be able to reacquire a reservation of a signal that a train already had acquired before a repath.

When a train repaths, it has to release all of its current path so that the same segments can be incorporated into the new path. The existing path segments are given special treatment and always allowed to be used in the new path, even if a signal has a request to close. Therefore, implementing the proposed behavior would add a number of operations:

1. Trigger a repath when a yellow signal is requested to close. This should be able to target only the train that has reserved the signal.

When this happens, and during any other repath, additional operations would be required:

2. Check if the current path contains a yellow signal that is requested to close
3. If yes, then perform an initial path search with the requested signal treated as unavailable.
4. If no, or if the initial search fails, perform a final path search with the existing path treated as available, per the existing behavior.

That would mean every repath has to check for circuit-controlled signals within their braking distance, and trains that path through such signals could trigger double the number of path searches.

Trains pathfinder already checks if a signal is requested to be closed by a circuit network because those signals are giving a pathfinder penalty. When a train is repathing, those signals within braking distance are released from trains reservation but they are not given to the circuit network reservation (they will be given to circuit network reservation only when train chooses other path that goes through other signals or fails to find a path during a repath). Only part that would be to be implemented is the repath event which would be relatively easy because signal points at exactly one train for which the rail block is reserved for.

robot256 wrote: ↑Mon Apr 25, 2022 12:57 pm 4. If no, or if the initial search fails, perform a final path search with the existing path treated as available, per the existing behavior.

That would mean every repath has to check for circuit-controlled signals within their braking distance, and trains that path through such signals could trigger double the number of path searches.

Why would we have to repath in step 4? If we hit step 4 we know there is no path other than our original one (edit: I am wrong here in one case but I'm not sure it matters, see edit below). So wouldn't it be

1. Trigger a repath when a yellow signal is requested to close. This should be able to target only the train that has reserved the signal.
2. Check if the current path contains a yellow signal that is requested to close
3. If yes, then store the old path, then perform an initial path search with the requested signal treated as unavailable.
4. If no, then do nothing (return)
5. If the initial search (#3) fails, then use the old path without changes.

Or something like that?

EDIT: Actually my program here acts differently in some cases. In the event that the tracks after the yellow signal have changed and there is no route around the yellow signal, your program would repath the train through the yellow signal and then (potentially) change its path after that based on the new state of the tracks. With my program, the train will not change its path if the yellow signal fails to close.

ravenwolf397 wrote: ↑Mon Apr 25, 2022 11:24 am that's a cool speedometer design too, mind if I use that?

Please do. I always thought the idea of posting designs on forums was to share them, always happy to see others like the stuff I like too.

The only ways I've found around this problem are either i) don't accelerate the train very fast, so its braking distance can't get very long. This is missing the point of a train accelerator. ii) Build an accelerator at least twice as large as the braking distance of your heaviest train at its maximum speed. Given that 200 tiles isn't big enough for just a 1-4 arty train at half speed, this would be enormous and only really useful in a megabase or as a toy. Or iii) let us close yellow signals.

I think you're missing iv) add a locomotive to make your train accelerate better. Just plopped that bp down and made a 2-4 arty train, it works fine on that layout which was tuned for 1-3, 1-10 and 1-16 normal trains.
Adding an extra locomotive to get a pleasingly-short cyclotron loop seems like a bread-n-butter design tradeoff, it's what the game's about. If you want a really long loop you could use one of those gorgeous compact spiral designs.

boskid wrote: ↑Mon Apr 25, 2022 3:26 pm Only part that would be to be implemented is the repath event which would be relatively easy because signal points at exactly one train for which the rail block is reserved for.

Thanks for explaining. So, if this simple change were made, you would still have to make sure the closed-signal penalty was enough to redirect the train (maybe by putting several closed signals in series).

I admit don’t understand completely this discussion nor have enough time to try it all out by myself.

But what I just want to mention to make afterwards discussion simpler (sorry for repeating knowing things):

A train-signal shows the state of the block behind it.

So — logically — if I turn on a yellow signal, the block behind it gets reserved for this train-lane. Which means nothing else than all other signals into that block needs to turn red automatically. Otherwise the yellow signal doesn’t make any sense (to me).

This is completely different behavior as if I turn on a signal to red. In that case the block is not reserved nor occupied. It’s just “don’t drive over this signal”. The block behind it isn’t touched! Don’t needs to be touched as with the yellow signal.

The logical conclusion is this: a yellow signal is nothing else as if I turn all other signals into that block to red. Which already can be done with circuits.

ssilk wrote: ↑Tue Apr 26, 2022 6:22 am

I think what the issue/request here is, is that a signal that is yellow from a train reserving it cannot then be given a control signal to turn red (thus forcing the train to repath). This is what they are requesting the ability to do.