Implement priority signals for trains

Post your ideas and suggestions how to improve the game.

Moderator: ickputzdirwech

User avatar
Optera
Smart Inserter
Smart Inserter
Posts: 2915
Joined: Sat Jun 11, 2016 6:41 am
Contact:

Re: Implement priority signals for trains

Post by Optera »

ssilk wrote:
Sat Aug 17, 2019 9:10 am
Most effective solution: use short trains. I use LCC only and only 1 track in each direction, on a map with about 200 trains and most times they are up and running. No problems as described here. There are points that need more attention. But my main problem are deadlocks, that cannot be prevented, cause LTN mod is sometimes too stupid. :) 8-)
While LTN optimizes train utilization, it is no fix against bad junction designs allowing deadlocks. :P
Speaking of junctions, I'm still sad variable rail collision boxes where removed. Working train bridges where fun to play with.

I've seen priority merging done with circuit controlled signals. It was buried somewhere in the huge post about efficient junction designs.

Edit:
Here's Tallinu describing his merge-o-matic: viewtopic.php?f=194&t=46855&p=388894#p388908
and one blueprint using it: viewtopic.php?f=194&t=46855&p=299868#p299868

User avatar
ssilk
Global Moderator
Global Moderator
Posts: 12888
Joined: Tue Apr 16, 2013 10:35 pm
Contact:

Re: Implement priority signals for trains

Post by ssilk »

Optera wrote:
Sat Aug 17, 2019 9:26 am
ssilk wrote:
Sat Aug 17, 2019 9:10 am
Most effective solution: use short trains. I use LCC only and only 1 track in each direction, on a map with about 200 trains and most times they are up and running. No problems as described here. There are points that need more attention. But my main problem are deadlocks, that cannot be prevented, cause LTN mod is sometimes too stupid. :) 8-)
While LTN optimizes train utilization, it is no fix against bad junction designs allowing deadlocks. :P
Speaking of junctions, I'm still sad variable rail collision boxes where removed. Working train bridges where fun to play with.
No, what I meant is that LTN is not safe useable, if you build your provider stations so, that it limits the items exactly to the needed number of items. :lol: 8-)



Off topic:
In my case I build a gigantic outpost producing level 3 modules. But it produces only 5 per second or so, and that leads to a situation, where trains requested for example 10 modules, cause 400 where in storage. But I forgot the inserter bonus: each grab of the inverters was 12 (bonus) * 24 (number of inverters) items was 284 items. After 2 trains the storage was empty and the remaining 10 trains run in timeout. LTN will reorder the request, which will add another 10 trains to the station, and 3 minutes later the whole block goes into a big train deadlock, cause now other stations cannot be delivered. Which results in a big jam of over 100 trains. I solved the problem by reducing the inserter bonus for now.

BTW That was the reason, why I suggested some month ago to have a check when a train arrives at the provider (and requester): is there still enough available (wanted)? When not the train should return to the depot and a warning message should be printed. Cause what usage has the best plan when the reality changes meanwhile?

Besides that: I find it really hard to build stations, that fix all problems involved with using LTN. Not that I don’t like that (yeah in my deepest thought I think that’s the best with LTN) but I play now over 3 years with it and still find edge cases, where some design breaks. It should be a bit simpler. I hoped the LTN combinator mod would output signals, which inserter to move, and much more...
Cool suggestion: Eatable MOUSE-pointers.
Have you used the Advanced Search today?
Need help, question? FAQ - Wiki - Forum help
I still like small signatures...

User avatar
Lubricus
Filter Inserter
Filter Inserter
Posts: 294
Joined: Sun Jun 04, 2017 12:13 pm
Contact:

Re: Implement priority signals for trains

Post by Lubricus »

slippycheeze wrote:
Fri Aug 16, 2019 8:23 pm
Lubricus wrote:
Fri Aug 16, 2019 4:01 pm
I think it rarely will help anything. You can't solve to little throughput with priorities. Timing trains at intersections could help throughput, I don't see how priorities can?
I assumed it was to make a "fast long distance" pair of lines in the center of a 4-line track, and then dedicate the outer two to "turning off the line" trains which have to slow down to reach their station, etc. This is a technique that is used, with good effect, to improve throughput. Also, can be used in Factorio, not just real world traffic management. ;)

...but seriously, you absolutely can improve throughput by moving through traffic and local / turning traffic into separate lanes, and it works just as well in Factorio as it does on the local freeway / highway system you have driven on. You normally make it happen in Factorio by placing something -- a station named " " (yes, one space character) on the outer lanes, and never scheduling anything to it. That'll make them undesirable compared to the inner lanes, so only trains that have to enter them, will, and even then, only when they are forced to in order to hit their turnout to the station or whatever.
I made a design that should work as you wan't. The trainstations is dummy stations just there for detere the pathing algoritm using the outer lanes.
Image

PS. trains on diagonal train tracks use more UPS so try not use diagonal tracks in big megabases

User avatar
BlueTemplar
Smart Inserter
Smart Inserter
Posts: 2420
Joined: Fri Jun 08, 2018 2:16 pm
Contact:

Re: Implement priority signals for trains

Post by BlueTemplar »

ssilk wrote:
Sat Aug 17, 2019 9:10 am
Most effective solution: use short trains. I use LCC only and only 1 track in each direction, on a map with about 200 trains and most times they are up and running. No problems as described here. There are points that need more attention. But my main problem are deadlocks, that cannot be prevented, cause LTN mod is sometimes too stupid. :) 8-)
Yeah, I've recently started using multiple trains per rail network (in fact, just one single, merged network), and even multiple trains per ore (Marathon !), and I like how well the LCC trains fit with LCL ones...
Diagonal Rails Offtopic
BobDiggity (mod-scenario-pack)

Adamo
Filter Inserter
Filter Inserter
Posts: 479
Joined: Sat May 24, 2014 7:00 am
Contact:

Re: Implement priority signals for trains

Post by Adamo »

Diagonal Rails Offtopic

slippycheeze
Filter Inserter
Filter Inserter
Posts: 587
Joined: Sun Jun 09, 2019 10:40 pm
Contact:

Re: Implement priority signals for trains

Post by slippycheeze »

Lubricus wrote:
Sat Aug 17, 2019 10:26 am
slippycheeze wrote:
Fri Aug 16, 2019 8:23 pm
Lubricus wrote:
Fri Aug 16, 2019 4:01 pm
I think it rarely will help anything. You can't solve to little throughput with priorities. Timing trains at intersections could help throughput, I don't see how priorities can?
I assumed it was to make a "fast long distance" pair of lines in the center of a 4-line track, and then dedicate the outer two to "turning off the line" trains which have to slow down to reach their station, etc. This is a technique that is used, with good effect, to improve throughput. Also, can be used in Factorio, not just real world traffic management. ;)

...but seriously, you absolutely can improve throughput by moving through traffic and local / turning traffic into separate lanes, and it works just as well in Factorio as it does on the local freeway / highway system you have driven on. You normally make it happen in Factorio by placing something -- a station named " " (yes, one space character) on the outer lanes, and never scheduling anything to it. That'll make them undesirable compared to the inner lanes, so only trains that have to enter them, will, and even then, only when they are forced to in order to hit their turnout to the station or whatever.
I made a design that should work as you wan't. The trainstations is dummy stations just there for detere the pathing algoritm using the outer lanes.
Image

PS. trains on diagonal train tracks use more UPS so try not use diagonal tracks in big megabases
I wouldn't use that design, myself: it'll work just fine, but you have turns across the fast lanes in the center, which means the potential for a train to be slowed down to give way to a turning train. A better strategy for maximum throughput is only permit trains to exit from the same side, fast to slow, or slow to fast, and never cross on the central line.

The Bulldog Main Line is an example of a design that supports this strategy, from which you might draw inspiration if not an exact design. I used a different, but not radically so, design to build my own version when I tried this. That one just happens to be the one I recall first -- they chose a good name.

Also, I see that I didn't actually say it, but the "one space" name trick is valuable: those stations are valid, and blueprintable, but they will not show up in the list of available stations when building a schedule. I'm not sure it will last forever, since it isn't any sort of formal feature, rather somewhere between a bug, and an unexpected combination of features, but until then it'll keep your dummy stations weighting the track nicely out of the way.

The alternative, which is definitely supported, is that a circuit-disabled signal will significantly discourage trains. Link it to the incoming signal when a train enters the track and use that being reserved to set the "discouragement" signal open. In this case you will get slowdown unless you have sufficient space between the trigger signal and the discouragement signal that the train doesn't want to brake for the red stop. That is ... hard, at speed, but the good news is that it matters less than otherwise because the train only entered that side-line to turn off to a station anyhow, so .... that'll be good enough for government work, at least.

Anyway, we are way, way off-topic here, and I'll take anything further over to the railway design forums with y'all, if we want. Not that I think there is much further to be added here, really.

mrvn
Smart Inserter
Smart Inserter
Posts: 5681
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Implement priority signals for trains

Post by mrvn »

slippycheeze wrote:
Mon Aug 19, 2019 3:35 am
The alternative, which is definitely supported, is that a circuit-disabled signal will significantly discourage trains. Link it to the incoming signal when a train enters the track and use that being reserved to set the "discouragement" signal open. In this case you will get slowdown unless you have sufficient space between the trigger signal and the discouragement signal that the train doesn't want to brake for the red stop. That is ... hard, at speed, but the good news is that it matters less than otherwise because the train only entered that side-line to turn off to a station anyhow, so .... that'll be good enough for government work, at least.

Anyway, we are way, way off-topic here, and I'll take anything further over to the railway design forums with y'all, if we want. Not that I think there is much further to be added here, really.
It tried circuit controlled signal. The problem is that they only increase the cost while the signal is circuit controlled red. For the train not to slow down you have to turn the signal green when a train reserves the block before it. Or, if slowdown is OK, you still have to turn it green when the train has to pass it. At that point it no longer deters other trains and you get stupid paths.

With a station on the other hand the cost is always there. And you can name all "increase cost" stations the same. Even if they show up in the station list in the future it will only be one entry among many.

mrvn
Smart Inserter
Smart Inserter
Posts: 5681
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Implement priority signals for trains

Post by mrvn »

ssilk wrote:
Sat Aug 17, 2019 10:04 am
Optera wrote:
Sat Aug 17, 2019 9:26 am
ssilk wrote:
Sat Aug 17, 2019 9:10 am
Most effective solution: use short trains. I use LCC only and only 1 track in each direction, on a map with about 200 trains and most times they are up and running. No problems as described here. There are points that need more attention. But my main problem are deadlocks, that cannot be prevented, cause LTN mod is sometimes too stupid. :) 8-)
While LTN optimizes train utilization, it is no fix against bad junction designs allowing deadlocks. :P
Speaking of junctions, I'm still sad variable rail collision boxes where removed. Working train bridges where fun to play with.
No, what I meant is that LTN is not safe useable, if you build your provider stations so, that it limits the items exactly to the needed number of items. :lol: 8-)



Off topic:
In my case I build a gigantic outpost producing level 3 modules. But it produces only 5 per second or so, and that leads to a situation, where trains requested for example 10 modules, cause 400 where in storage. But I forgot the inserter bonus: each grab of the inverters was 12 (bonus) * 24 (number of inverters) items was 284 items. After 2 trains the storage was empty and the remaining 10 trains run in timeout. LTN will reorder the request, which will add another 10 trains to the station, and 3 minutes later the whole block goes into a big train deadlock, cause now other stations cannot be delivered. Which results in a big jam of over 100 trains. I solved the problem by reducing the inserter bonus for now.
There are two kinds of stations and you need different designs for them:

1) Mass producers

If you produce full belts worth of iron plates then it takes little time to fill a train and you probably want to ship full train cars all the time. So put down lots if inserters to improve loading speed and don't care about overloading smaller requests. The refill will quickly make up the difference.

2) Costly / Low count items / Multi produc providers

A station providing entities (assemblers, oil refineries, ...) or items that are costly or slow to produce doesn't need 24 stack inserters to load the train. You never want 284 oil refineries. Actually why use LCC trains for that at all? If the station provides a mix of good going from oil refineries, where you want single digit counts, to rails or belts, where 3 digit counts are the rule, can use a mix of stack filter inserters and filter inserters with circuit logic enabling the stack filter inserters only if the count is high enough. It's not hard to make them load count perfect (see provided blueprints for some examples).
ssilk wrote:
Sat Aug 17, 2019 10:04 am
BTW That was the reason, why I suggested some month ago to have a check when a train arrives at the provider (and requester): is there still enough available (wanted)? When not the train should return to the depot and a warning message should be printed. Cause what usage has the best plan when the reality changes meanwhile?

Besides that: I find it really hard to build stations, that fix all problems involved with using LTN. Not that I don’t like that (yeah in my deepest thought I think that’s the best with LTN) but I play now over 3 years with it and still find edge cases, where some design breaks. It should be a bit simpler. I hoped the LTN combinator mod would output signals, which inserter to move, and much more...
LTN isn't a magic bullet solving all the problems. You have to use the right station design for the right job. That said I've come to the conclusion that the timeouts as they are are completely broken and have turned them off. It's far easier to fix trains stuck at a station trying to load non-existent goods than the system wide chaos the extra trains or left over goods cause when a timeout hits.

One thing I don't get in your description of the problem though. You say you produce 5 modules a second and the train wants to load 10. That means 2s of waiting should produce enough to load the train even if the previous train cleaned out the station. So I assume the factory run out of material and stopped producing. But then it shouldn't provide any modules and no new trains should be scheduled.

Only thing I can imagine is that the initial 10 trains already cause a traffic jam, which means you forgot to set the train limit on the provider to the number of trains it can buffer. In that case the 10 trains would cause other stations to time out and down the system goes. See "magic bullet" above. If your station doesn't have a stacker for 9 trains + 1 train loading then it should limit the number of trains below 10. I usually have it set to 2 and give each station enough lead for 1 train loading and 1 train waiting. LTN then never sends more than 2 trains to the station UNLESS you run into a timeout (see timeouts are broken above :).

slippycheeze
Filter Inserter
Filter Inserter
Posts: 587
Joined: Sun Jun 09, 2019 10:40 pm
Contact:

Re: Implement priority signals for trains

Post by slippycheeze »

mrvn wrote:
Mon Aug 19, 2019 9:56 am
slippycheeze wrote:
Mon Aug 19, 2019 3:35 am
The alternative, which is definitely supported, is that a circuit-disabled signal will significantly discourage trains. Link it to the incoming signal when a train enters the track and use that being reserved to set the "discouragement" signal open. In this case you will get slowdown unless you have sufficient space between the trigger signal and the discouragement signal that the train doesn't want to brake for the red stop. That is ... hard, at speed, but the good news is that it matters less than otherwise because the train only entered that side-line to turn off to a station anyhow, so .... that'll be good enough for government work, at least.

Anyway, we are way, way off-topic here, and I'll take anything further over to the railway design forums with y'all, if we want. Not that I think there is much further to be added here, really.
It tried circuit controlled signal. The problem is that they only increase the cost while the signal is circuit controlled red. For the train not to slow down you have to turn the signal green when a train reserves the block before it. Or, if slowdown is OK, you still have to turn it green when the train has to pass it. At that point it no longer deters other trains and you get stupid paths.

With a station on the other hand the cost is always there. And you can name all "increase cost" stations the same. Even if they show up in the station list in the future it will only be one entry among many.
Assuming you only use the turnout for getting off the main line, or emergency bypasses of a broken center, you only need to turn the circuit signal green when a train has entered the block, not as it approaches. In theory. ...and in theory, theory and practice are the same. In practice, they tend not to be. :)

The main other difference between the two is that a station has a 2000 unit penalty, while a circuit-red signal is 1000. When calculating out the path a train also weights distance at the number of tiles -- I *think* normal grid tiles, not the double-size rail tiles -- on the path. That makes a station worth either 1,000, or 2,000 rail segments, and a circuit-signal worth 500 or 1,000 of them. A far enough path will beat out that penalty. You can enhance the effect with more dummy stations or circuit-signals, if you want, and that can help on long enough runs.

mrvn
Smart Inserter
Smart Inserter
Posts: 5681
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Implement priority signals for trains

Post by mrvn »

slippycheeze wrote:
Mon Aug 19, 2019 5:42 pm
mrvn wrote:
Mon Aug 19, 2019 9:56 am
slippycheeze wrote:
Mon Aug 19, 2019 3:35 am
The alternative, which is definitely supported, is that a circuit-disabled signal will significantly discourage trains. Link it to the incoming signal when a train enters the track and use that being reserved to set the "discouragement" signal open. In this case you will get slowdown unless you have sufficient space between the trigger signal and the discouragement signal that the train doesn't want to brake for the red stop. That is ... hard, at speed, but the good news is that it matters less than otherwise because the train only entered that side-line to turn off to a station anyhow, so .... that'll be good enough for government work, at least.

Anyway, we are way, way off-topic here, and I'll take anything further over to the railway design forums with y'all, if we want. Not that I think there is much further to be added here, really.
It tried circuit controlled signal. The problem is that they only increase the cost while the signal is circuit controlled red. For the train not to slow down you have to turn the signal green when a train reserves the block before it. Or, if slowdown is OK, you still have to turn it green when the train has to pass it. At that point it no longer deters other trains and you get stupid paths.

With a station on the other hand the cost is always there. And you can name all "increase cost" stations the same. Even if they show up in the station list in the future it will only be one entry among many.
Assuming you only use the turnout for getting off the main line, or emergency bypasses of a broken center, you only need to turn the circuit signal green when a train has entered the block, not as it approaches. In theory. ...and in theory, theory and practice are the same. In practice, they tend not to be. :)

The main other difference between the two is that a station has a 2000 unit penalty, while a circuit-red signal is 1000. When calculating out the path a train also weights distance at the number of tiles -- I *think* normal grid tiles, not the double-size rail tiles -- on the path. That makes a station worth either 1,000, or 2,000 rail segments, and a circuit-signal worth 500 or 1,000 of them. A far enough path will beat out that penalty. You can enhance the effect with more dummy stations or circuit-signals, if you want, and that can help on long enough runs.
No. If you only turn the signal green when a train has entered the block then it has to slow down. Unless your block is large enough to contain all of the breaking distance (which is insane for full speed Angels+Bobs trains). But that's beside the point.

At some point in time a train will use the path. (Otherwise why would you build it at all?) When the train reserves the block it will take that path and you have to turn the signal green (then or later). The moment you do that the extra cost from the circuit controlled signal goes away. And then trains will randomly path through there from all over the map near there because it is no longer more expensive. The first train leaves and the signal goes red again and no more trains path through it. But any train already on the path will stick to it unless it gets blocked somewhere. Which makes more trains pick that path. It's self amplifying.

In summary: Circuit controlled signals only work when no train passes them. Train stops always work.

User avatar
Optera
Smart Inserter
Smart Inserter
Posts: 2915
Joined: Sat Jun 11, 2016 6:41 am
Contact:

Re: Implement priority signals for trains

Post by Optera »

mrvn wrote:
Thu Aug 22, 2019 9:18 am
No. If you only turn the signal green when a train has entered the block then it has to slow down. Unless your block is large enough to contain all of the breaking distance (which is insane for full speed Angels+Bobs trains). But that's beside the point.

At some point in time a train will use the path. (Otherwise why would you build it at all?) When the train reserves the block it will take that path and you have to turn the signal green (then or later). The moment you do that the extra cost from the circuit controlled signal goes away. And then trains will randomly path through there from all over the map near there because it is no longer more expensive. The first train leaves and the signal goes red again and no more trains path through it. But any train already on the path will stick to it unless it gets blocked somewhere. Which makes more trains pick that path. It's self amplifying.

In summary: Circuit controlled signals only work when no train passes them. Train stops always work.
Correct for a single circuit controlled signal.

Theoretically it could work when 2 signals are circuit controlled like an airlock, one of them always has to be red.
default state, signal 1 = green, signal 2= red
when signal 1 becomes red or yellow then signal 2 goes green and signal 1 is locked red until signal 2 is green again.

The question is if the pathfinder will see signal 1 as red from a train in its block or red from circuit.
If it's the former the whole design will need to be even bigger with a detecting signal in the middle.

mrvn
Smart Inserter
Smart Inserter
Posts: 5681
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Implement priority signals for trains

Post by mrvn »

Optera wrote:
Thu Aug 22, 2019 9:49 am
mrvn wrote:
Thu Aug 22, 2019 9:18 am
No. If you only turn the signal green when a train has entered the block then it has to slow down. Unless your block is large enough to contain all of the breaking distance (which is insane for full speed Angels+Bobs trains). But that's beside the point.

At some point in time a train will use the path. (Otherwise why would you build it at all?) When the train reserves the block it will take that path and you have to turn the signal green (then or later). The moment you do that the extra cost from the circuit controlled signal goes away. And then trains will randomly path through there from all over the map near there because it is no longer more expensive. The first train leaves and the signal goes red again and no more trains path through it. But any train already on the path will stick to it unless it gets blocked somewhere. Which makes more trains pick that path. It's self amplifying.

In summary: Circuit controlled signals only work when no train passes them. Train stops always work.
Correct for a single circuit controlled signal.

Theoretically it could work when 2 signals are circuit controlled like an airlock, one of them always has to be red.
default state, signal 1 = green, signal 2= red
when signal 1 becomes red or yellow then signal 2 goes green and signal 1 is locked red until signal 2 is green again.

The question is if the pathfinder will see signal 1 as red from a train in its block or red from circuit.
If it's the former the whole design will need to be even bigger with a detecting signal in the middle.
You want to only flicker the signal green just long enough for the train to enter the next block? I'm not sure what the cost of a signal is that is both red from a train and a circuit signal. Could reduce the window of vulnerability to the setup.

But unless you build your airlock large enough to contain the breaking distance the train will slow down. And that distance gets rather large. Like hundreds of meters large. And you are talking about at 4-6 signals and a lot of extra rails to replace one train stop. Not worth it imho.

Note: You need breaking distance before the first signal and the last signal. So twice the breaking distance for the airlock.

csduff
Fast Inserter
Fast Inserter
Posts: 110
Joined: Thu Nov 22, 2018 3:42 pm
Contact:

Re: Implement priority signals for trains

Post by csduff »

mrvn wrote:
Thu Aug 22, 2019 10:43 am
Optera wrote:
Thu Aug 22, 2019 9:49 am
mrvn wrote:
Thu Aug 22, 2019 9:18 am
No. If you only turn the signal green when a train has entered the block then it has to slow down. Unless your block is large enough to contain all of the breaking distance (which is insane for full speed Angels+Bobs trains). But that's beside the point.

At some point in time a train will use the path. (Otherwise why would you build it at all?) When the train reserves the block it will take that path and you have to turn the signal green (then or later). The moment you do that the extra cost from the circuit controlled signal goes away. And then trains will randomly path through there from all over the map near there because it is no longer more expensive. The first train leaves and the signal goes red again and no more trains path through it. But any train already on the path will stick to it unless it gets blocked somewhere. Which makes more trains pick that path. It's self amplifying.

In summary: Circuit controlled signals only work when no train passes them. Train stops always work.
Correct for a single circuit controlled signal.

Theoretically it could work when 2 signals are circuit controlled like an airlock, one of them always has to be red.
default state, signal 1 = green, signal 2= red
when signal 1 becomes red or yellow then signal 2 goes green and signal 1 is locked red until signal 2 is green again.

The question is if the pathfinder will see signal 1 as red from a train in its block or red from circuit.
If it's the former the whole design will need to be even bigger with a detecting signal in the middle.
You want to only flicker the signal green just long enough for the train to enter the next block? I'm not sure what the cost of a signal is that is both red from a train and a circuit signal. Could reduce the window of vulnerability to the setup.

But unless you build your airlock large enough to contain the breaking distance the train will slow down. And that distance gets rather large. Like hundreds of meters large. And you are talking about at 4-6 signals and a lot of extra rails to replace one train stop. Not worth it imho.

Note: You need breaking distance before the first signal and the last signal. So twice the breaking distance for the airlock.
If I'm envisioning this correctly, there would not be a problem. Signal 1 is set to read signal. Signal 2 is set to go red when signal 1 is green. As soon as an approaching train reserves the block between signal 1 and 2, signal 1 should switch to yellow, disabling the red lock on signal 2, thus allowing the block past signal 2 to be reserved, and the train to continue at speed. The system would be also function that if a train did enter the block and stop, signal 1 would be red, still allowing signal 2 to toggle to yellow/green, as appropriate.

It is actually a fairly elegant system that I may have to use at some point to control traffic on my main lines.

mrvn
Smart Inserter
Smart Inserter
Posts: 5681
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Implement priority signals for trains

Post by mrvn »

csduff wrote:
Thu Aug 22, 2019 12:44 pm
If I'm envisioning this correctly, there would not be a problem. Signal 1 is set to read signal. Signal 2 is set to go red when signal 1 is green. As soon as an approaching train reserves the block between signal 1 and 2, signal 1 should switch to yellow, disabling the red lock on signal 2, thus allowing the block past signal 2 to be reserved, and the train to continue at speed. The system would be also function that if a train did enter the block and stop, signal 1 would be red, still allowing signal 2 to toggle to yellow/green, as appropriate.

It is actually a fairly elegant system that I may have to use at some point to control traffic on my main lines.
That's the initial setup I was talking about. That is not an airlock. In that setup the signal turns green as soon as the 2m block before the 2nd signal is reserved and stays green until the train left that 2m block. All that time the extra cost of the circuit controlled signal disappears.

An airlock would be more like this: At the entry there are 2 signals. Then a long stretch the size of a train + breaking distances followed by another signal.

Like above signal 1 is set to read signal. Signal 2 is set to go red when signal 1 is green. Signal 3 is set to go red when signal 1 is not green.
At all times either signal 2 or signal 3 is red so the extra cost for a circuit controlled signal remains.

What I don't like about this is the size. The inside of the airlock has to be big enough for a train + breaking distance. A L4C12 train with locomotive III at 500+km/h makes that rather large.

slippycheeze
Filter Inserter
Filter Inserter
Posts: 587
Joined: Sun Jun 09, 2019 10:40 pm
Contact:

Re: Implement priority signals for trains

Post by slippycheeze »

mrvn wrote:
Thu Aug 22, 2019 9:18 am
No. If you only turn the signal green when a train has entered the block then it has to slow down. Unless your block is large enough to contain all of the breaking distance (which is insane for full speed Angels+Bobs trains). But that's beside the point.

At some point in time a train will use the path. (Otherwise why would you build it at all?) When the train reserves the block it will take that path and you have to turn the signal green (then or later). The moment you do that the extra cost from the circuit controlled signal goes away. And then trains will randomly path through there from all over the map near there because it is no longer more expensive. The first train leaves and the signal goes red again and no more trains path through it. But any train already on the path will stick to it unless it gets blocked somewhere. Which makes more trains pick that path. It's self amplifying.

In summary: Circuit controlled signals only work when no train passes them. Train stops always work.
Not quite the right summary, I'm afraid: you seem to have forgotten that trains can change their path, for example, in response to a red signal in front of them. To quote the wiki on railway pathfinding:
The train is braking for a signal (chain or regular) it cant reserve and the train is not inside a chain signal block. The train is forced to recalculate its path.
So, the situation where a train uses the slow lane rather than the fast lane preferentially requires that the circuit-signal is open (a) when it calculates the path, and also (b) when it reserves the signal(s) to pass through the slow lane. Otherwise it will repath on the fast lane to avoid the red signal it doesn't need to wait at since it is going on past. While a train turning off will accept the one-and-only path that has a red signal on it to reach the turnoff it has to take. It won't like it, but it'll do it. :)

Anyway, regardless of the technical details that mean the circuit controlled signal model works, dummy train stations do work more trivially, requiring no particular logic, and can be duplicated to provide the same degree of penalty to a rail branch that circuit-set signals can. Plus they currently have the nice "space character only" name hack to make them work even more smoothly.

mrvn
Smart Inserter
Smart Inserter
Posts: 5681
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Implement priority signals for trains

Post by mrvn »

slippycheeze wrote:
Thu Aug 22, 2019 1:39 pm
mrvn wrote:
Thu Aug 22, 2019 9:18 am
No. If you only turn the signal green when a train has entered the block then it has to slow down. Unless your block is large enough to contain all of the breaking distance (which is insane for full speed Angels+Bobs trains). But that's beside the point.

At some point in time a train will use the path. (Otherwise why would you build it at all?) When the train reserves the block it will take that path and you have to turn the signal green (then or later). The moment you do that the extra cost from the circuit controlled signal goes away. And then trains will randomly path through there from all over the map near there because it is no longer more expensive. The first train leaves and the signal goes red again and no more trains path through it. But any train already on the path will stick to it unless it gets blocked somewhere. Which makes more trains pick that path. It's self amplifying.

In summary: Circuit controlled signals only work when no train passes them. Train stops always work.
Not quite the right summary, I'm afraid: you seem to have forgotten that trains can change their path, for example, in response to a red signal in front of them. To quote the wiki on railway pathfinding:
The train is braking for a signal (chain or regular) it cant reserve and the train is not inside a chain signal block. The train is forced to recalculate its path.
So, the situation where a train uses the slow lane rather than the fast lane preferentially requires that the circuit-signal is open (a) when it calculates the path, and also (b) when it reserves the signal(s) to pass through the slow lane. Otherwise it will repath on the fast lane to avoid the red signal it doesn't need to wait at since it is going on past. While a train turning off will accept the one-and-only path that has a red signal on it to reach the turnoff it has to take. It won't like it, but it'll do it. :)

Anyway, regardless of the technical details that mean the circuit controlled signal model works, dummy train stations do work more trivially, requiring no particular logic, and can be duplicated to provide the same degree of penalty to a rail branch that circuit-set signals can. Plus they currently have the nice "space character only" name hack to make them work even more smoothly.
I mentioned re-pathing indirectly. Did you overlook the "unless it gets blocked somewhere" part?

But I think I see what you mean. In my test design both the signals for the circuit controlled extra cost where on the track between the slow and fast lane and set to close on "green < 1". So simply by reserving the block leading to the red signal the circuit controlled signal turns green. The train never sees a red signal. So any train getting pathed to the wrong lane and not otherwise blocked would take the branch to the other lane, hit the trigger signal and the extra cost signal turns green. It doesn't get forced to repath.

I think in your design you must have the circuit controlled signal set to close on "red = 1" or set with a delay. So a train reserving the block before the signal will still see a red for the circuit control signal at least for a few ticks. It then either re-paths or starts to break. If it can't re-path then the circuit controlled signal will turn green eventually.

I can't see how that Idea can work without having the train break at least partially. Something I want to avoid. It also doesn't work for cases where you want to get trains onto the right track early on. As in the decision which track to use has to be made far in advance of the signal that adds the cost.

slippycheeze
Filter Inserter
Filter Inserter
Posts: 587
Joined: Sun Jun 09, 2019 10:40 pm
Contact:

Re: Implement priority signals for trains

Post by slippycheeze »

mrvn wrote:
Thu Aug 22, 2019 3:20 pm
I mentioned re-pathing indirectly. Did you overlook the "unless it gets blocked somewhere" part?
I did.
mrvn wrote:
Thu Aug 22, 2019 3:20 pm
But I think I see what you mean. In my test design both the signals for the circuit controlled extra cost where on the track between the slow and fast lane and set to close on "green < 1". So simply by reserving the block leading to the red signal the circuit controlled signal turns green. The train never sees a red signal. So any train getting pathed to the wrong lane and not otherwise blocked would take the branch to the other lane, hit the trigger signal and the extra cost signal turns green. It doesn't get forced to repath.

I think in your design you must have the circuit controlled signal set to close on "red = 1" or set with a delay. So a train reserving the block before the signal will still see a red for the circuit control signal at least for a few ticks. It then either re-paths or starts to break. If it can't re-path then the circuit controlled signal will turn green eventually.

I can't see how that Idea can work without having the train break at least partially. Something I want to avoid. It also doesn't work for cases where you want to get trains onto the right track early on. As in the decision which track to use has to be made far in advance of the signal that adds the cost.
Yeah, it either has partial braking, or some train sized buffers involved, and either path also includes a possibility of being overtaken by a train behind.

Stations are definitely better. We are, I think, in violent agreement, overall, and the nuance isn't much worth it beyond this point. We flogged that horse well past death. :)

mrvn
Smart Inserter
Smart Inserter
Posts: 5681
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Implement priority signals for trains

Post by mrvn »

slippycheeze wrote:
Thu Aug 22, 2019 4:05 pm
mrvn wrote:
Thu Aug 22, 2019 3:20 pm
I mentioned re-pathing indirectly. Did you overlook the "unless it gets blocked somewhere" part?
I did.
mrvn wrote:
Thu Aug 22, 2019 3:20 pm
But I think I see what you mean. In my test design both the signals for the circuit controlled extra cost where on the track between the slow and fast lane and set to close on "green < 1". So simply by reserving the block leading to the red signal the circuit controlled signal turns green. The train never sees a red signal. So any train getting pathed to the wrong lane and not otherwise blocked would take the branch to the other lane, hit the trigger signal and the extra cost signal turns green. It doesn't get forced to repath.

I think in your design you must have the circuit controlled signal set to close on "red = 1" or set with a delay. So a train reserving the block before the signal will still see a red for the circuit control signal at least for a few ticks. It then either re-paths or starts to break. If it can't re-path then the circuit controlled signal will turn green eventually.

I can't see how that Idea can work without having the train break at least partially. Something I want to avoid. It also doesn't work for cases where you want to get trains onto the right track early on. As in the decision which track to use has to be made far in advance of the signal that adds the cost.
Yeah, it either has partial braking, or some train sized buffers involved, and either path also includes a possibility of being overtaken by a train behind.

Stations are definitely better. We are, I think, in violent agreement, overall, and the nuance isn't much worth it beyond this point. We flogged that horse well past death. :)
Still some things to explore there. I like the idea of forcing trains to re-path and only allowing them in when they truly need to.

But for that the signal has to remain red until the train hits it. Then, if it is still going through the signal it has to turn green. Which means the train will be breaking. Best case would be breaking for only 1 tick. But how do you get that timing right so it works for trains at any speed?

I'm thinking this would need 3 signals: A, B and C. A and B just read status while C is set to red. When A becomes not green you start a clock. When B becomes not green you reverse the clock. When the clock is less than 0 set C to green. You reset the clock to 0 if A is green.

With A, B and C equidistant this should set C to green one tick after the train needs to reserve C if it is at constant speed. More ticks if it is still accelerating. The timing might be slightly off and you need to set C to green when the clock is less than -5 or something. But I hope you get the idea. The time difference between A and B becoming not green is used to get the trains speed to estimate when C will be reserved.

slippycheeze
Filter Inserter
Filter Inserter
Posts: 587
Joined: Sun Jun 09, 2019 10:40 pm
Contact:

Re: Implement priority signals for trains

Post by slippycheeze »

mrvn wrote:
Mon Aug 26, 2019 11:11 am
But for that the signal has to remain red until the train hits it. Then, if it is still going through the signal it has to turn green. Which means the train will be breaking. Best case would be breaking for only 1 tick. But how do you get that timing right so it works for trains at any speed?

I'm thinking this would need 3 signals: A, B and C. A and B just read status while C is set to red. When A becomes not green you start a clock. When B becomes not green you reverse the clock. When the clock is less than 0 set C to green. You reset the clock to 0 if A is green.

With A, B and C equidistant this should set C to green one tick after the train needs to reserve C if it is at constant speed. More ticks if it is still accelerating. The timing might be slightly off and you need to set C to green when the clock is less than -5 or something. But I hope you get the idea. The time difference between A and B becoming not green is used to get the trains speed to estimate when C will be reserved.
[/quote]

I'd have to experiment to verify that, but I don't see anything wrong with your logic. I don't think I'm enthused enough to actually do that, so please let us know the results if you do try. I just use dummy stations, like you said. :)

Post Reply

Return to “Ideas and Suggestions”