AWay to totally lock a track path.

[zOldBulldog]

Although I don't think this is what the OP meant, it is what I instantly understood from the title and might be relevant.

- A disabled train stop effectively stops being considered by the Pathfinder.
- A red signal (regular or chain) only blocks passage, but what is behind the stop still gets considered in pathfinding and thus a train can end up stopped behind the red signal instead of going to an alternate destination.

- What does not exist (as far as I know) is a way to make a signal have a similar effect of a disabled stop... to remove what is behind it from consideration *completely*, to "totally lock a track path". In other words, if you have an enabled stop behind the red signal and the only way through is through the red signal... then the stop is considered disabled and the train moves on to the next item in its route.

So,

1) Would that solve the OP's issue? I suspect yes but I'm not sure.

2) Would such a feature be of interest to anyone other than me and worth creating a separate suggestion thread?

[eradicator]

What you just described is simply wiring all stops after that signal to the signal and disable them on the same circuit condition. Sure, that requires some wires. And maybe some combinators if you want it to override other stuff. But it is there to be used.

[ikarikeiji]

A chain signal acts exactly the same as a regular signal, except that it also prevents a train passing if the next signal that that train would encounter (based on that train's current path) cannot be passed by that train.

That seems kind of pointless. They're supposed to be based on Pre signals and PBS signals from OpenTTD, where special logic applies.
in this case, they're supposed to allow the train to bypass blocked paths, such as trains stopped at a station.

OpenTTD needs pre-signals to have special logic because OpenTTD trains do their pathfinding at the approach to every junction and they do not pathfind all the way to the destination. Before PBS, there was no concept of a reserved path for a train. Factorio trains are significantly different, they pathfind the full way at once, save this until they next re-path, and reserve part of the path when they turn a signal orange. By the time a chain signal decides whether to let a train through, the train already knows which signal it wants to go through next so the chain signal uses that information. In OpenTTD, the pre-signal has no idea where the train wants to go, so it simply goes green when any exit signal is green, thus the train needs to check the signal type in its pathfinding to avoid stopping at a red exit signal.

Although I don't think this is what the OP meant, it is what I instantly understood from the title and might be relevant.

- A disabled train stop effectively stops being considered by the Pathfinder.
- A red signal (regular or chain) only blocks passage, but what is behind the stop still gets considered in pathfinding and thus a train can end up stopped behind the red signal instead of going to an alternate destination.

- What does not exist (as far as I know) is a way to make a signal have a similar effect of a disabled stop... to remove what is behind it from consideration *completely*, to "totally lock a track path". In other words, if you have an enabled stop behind the red signal and the only way through is through the red signal... then the stop is considered disabled and the train moves on to the next item in its route.

So,

1) Would that solve the OP's issue? I suspect yes but I'm not sure.

2) Would such a feature be of interest to anyone other than me and worth creating a separate suggestion thread?

I would say there is an important difference between skipping a stop if it is disabled, and halting the train with a no path message if the stop is disabled. I previously made a similar thread about disabling rail sections (which someone has already linked here) and the use cases I outlined required halting not skipping, so I would say both need to be covered.

[eradicator]

A chain signal acts exactly the same as a regular signal, except that it also prevents a train passing if the next signal that that train would encounter (based on that train's current path) cannot be passed by that train.

That seems kind of pointless. They're supposed to be based on Pre signals and PBS signals from OpenTTD, where special logic applies.
in this case, they're supposed to allow the train to bypass blocked paths, such as trains stopped at a station.

OpenTTD needs pre-signals to have special logic because OpenTTD trains do their pathfinding at the approach to every junction and they do not pathfind all the way to the destination. Before PBS, there was no concept of a reserved path for a train. Factorio trains are significantly different, they pathfind the full way at once, save this until they next re-path, and reserve part of the path when they turn a signal orange. By the time a chain signal decides whether to let a train through, the train already knows which signal it wants to go through next so the chain signal uses that information.[emphasis added] In OpenTTD, the pre-signal has no idea where the train wants to go, so it simply goes green when any exit signal is green, thus the train needs to check the signal type in its pathfinding to avoid stopping at a red exit signal.

No. Just no. Factorio chain signals do not care where the next train "wants to go", their status depends soley on the status of the exit signals. If any exit is green the chain signals is blue, if all exits are green the chain signal is green. It is the train that decides wheater it needs to stop at a blue signal or not depending on its preferred exit at the time of arrival at the chani signal. That preferred exit can and will change when waiting for too long at a blue signal as mentioned above (aka the train will "repath").

[Tekky]

OpenTTD needs pre-signals to have special logic because OpenTTD trains do their pathfinding at the approach to every junction and they do not pathfind all the way to the destination.

That is not quite correct. In OpenTTD, trains do actually pathfind all the way to the destination (assuming you are using the YAPF pathfinder). However, when using path signals (i.e. Path Based Signalling=PBS), they reevaluate their path (i.e. repath) at every signal. When using block signals, they instead repath at every switch. Since OpenTTD pre-signals are block signals, trains never pathfind at pre-signals, but only at the switches after the signal.

The main difference between OpenTTD pre-signals and Factorio chain signals is that, in OpenTTD, block signals work independantly of the train pathfinder, whereas trains in Factorio (and also trains in OpenTTD using path signals) are tied to the pathfinder. When using OpenTTD pre-signals, a train will drive past the pre-signal as soon as one of the exit signals is green, even if that route does not lead the train to its destination; in that case, the train will drive to the red exit signal and wait there. With Factorio chain signals, however, the train will wait in front of the chain signal until the exit signal of its preferred path turns green.

[bobingabout]

A chain signal acts exactly the same as a regular signal, except that it also prevents a train passing if the next signal that that train would encounter (based on that train's current path) cannot be passed by that train.

That seems kind of pointless. They're supposed to be based on Pre signals and PBS signals from OpenTTD, where special logic applies.
in this case, they're supposed to allow the train to bypass blocked paths, such as trains stopped at a station.

OpenTTD needs pre-signals to have special logic because OpenTTD trains do their pathfinding at the approach to every junction and they do not pathfind all the way to the destination. Before PBS, there was no concept of a reserved path for a train. Factorio trains are significantly different, they pathfind the full way at once, save this until they next re-path, and reserve part of the path when they turn a signal orange. By the time a chain signal decides whether to let a train through, the train already knows which signal it wants to go through next so the chain signal uses that information. In OpenTTD, the pre-signal has no idea where the train wants to go, so it simply goes green when any exit signal is green, thus the train needs to check the signal type in its pathfinding to avoid stopping at a red exit signal.

Before you argue with me, just remember how long I've been around.
Fact: Chain signals are based on OpenTTD PBS and Pre signals. I'm not saying they do the same thing as either of these, just that they served as inspiration. Several Factorio Developers have played OpenTTD and at least 1 was an avid player before joining factorio.
Fact: The reason chain signals were created was because of dumb train behaviour in Factorio, where one train would wait behind another at a split junction where the latter train could easily bypass and go around.

However, I am not that knowledgeable about the ins and outs of exactly how chain signals work, and the path finding has been improved since their introduction.
I do agree with your statement about Factorio trains being smarter than OpenTTD trains though, but when it comes to multiple paths in short distances, they're still pretty dumb, hence the chain signals.

[Hyenna]

it would help to simply have control over penalty values a regular signal could show like this:

red(by wirenetwork) - *penalty value*
red(blocked by train) - *penalty value*
yellow
green

those in * a player can enter number for the penalty
there should be two for the red because it makes a diffrence if asignal is red by wire or red by train blocking path
also the signal output could be diffrent to readout if there is a train on track or not.

[ikarikeiji]

eradicator, Tekky, bobingabout: I'm not trying to argue with any of you, you're saying the same things as I tried to, just in different words.

I was trying to point out that the reason chain signals do not need to affect pathfinding differently to regular signals when OpenTTD's pre-signals do is due to the differences between them. Nothing more.

[Tekky]

I do agree with your statement about Factorio trains being smarter than OpenTTD trains though

I strongly disagree with the claim that Factorio trains are smarter than OpenTTD trains.

I fully agree with the statement that Factorio trains are smarter than OpenTTD trains when using OpenTTD block signals.

However, when using OpenTTD path signals, OpenTTD is, in my opinion, far superior (and also more realistic) compared to current Factorio signalling. That's why I am in favor of Path Based Signalling (PBS) being introduced in Factorio.

Especially when using OpenTTD with the optional routing restrictions patch, OpenTTD is far superior to Factorio. That's why I am in favor of the suggestion of implementing all of this in Factorio.

[bobingabout]

I do agree with your statement about Factorio trains being smarter than OpenTTD trains though

However, when using OpenTTD path signals, OpenTTD is, in my opinion, far superior (and also more realistic) compared to current Factorio signalling. That's why I am in favor of Path Based Signalling (PBS) being introduced in Factorio.

Especially when using OpenTTD with the optional routing restrictions patch, OpenTTD is far superior to Factorio. That's why I am in favor of the suggestion of implementing all of this in Factorio.

Well, it has been quite a few years since I was involved with OpenTTD, it sounds like they've improved things since last I played, but my trains used to get lost on long routes in OpenTTD all the time.

[Hyenna]

- A disabled train stop effectively stops being considered by the Pathfinder.
- A red signal (regular or chain) only blocks passage, but what is behind the stop still gets considered in pathfinding and thus a train can end up stopped behind the red signal instead of going to an alternate destination.

Yes thats what it is about and yes it would solve the problem if a red signal can be set to not being considered to be passed for a relevant track.
If it isnt the only way to go it would consider another path to move on.

[zOldBulldog]

- A disabled train stop effectively stops being considered by the Pathfinder.
- A red signal (regular or chain) only blocks passage, but what is behind the stop still gets considered in pathfinding and thus a train can end up stopped behind the red signal instead of going to an alternate destination.

Yes thats what it is about and yes it would solve the problem if a red signal can be set to not being considered to be passed for a relevant track.
If it isnt the only way to go it would consider another path to move on.

Yeah, I always wished for a signal/state to disable every stop that can only be reached via a particular signal.

But it does not exist. The only way I know to work around the problem is to disable the stop itself with circuits.

It is a pain and cumbersome, but what else have we got? And yet, I fear that the response will be that "since there is a way, no matter how cumbersome, this is not going on the to-do list". So you might as well start designing some complex circuitry to disable your stops. And if you don't have a stop where you need this functionality... to add one that can be disabled. Or... look for a mod that does the trick.

[tobsimon]

it would help to simply have control over penalty values a regular signal could show

The specific penalties can now be found in the utility constants, which allows mods to change them. (Undocumented)

So this says, that it is possible to alter the penalties. Maybe you can mod values, that suit you? The wiki also contains a link to the train pathfinder code.

[eradicator]

it would help to simply have control over penalty values a regular signal could show

The specific penalties can now be found in the utility constants, which allows mods to change them. (Undocumented)

So this says, that it is possible to alter the penalties. Maybe you can mod values, that suit you? The wiki also contains a link to the train pathfinder code.

OP wants dynamic values that can differ for each signal. You can only mod a single fixed value for all signals.

[Hyenna]

it would help to simply have control over penalty values a regular signal could show

The specific penalties can now be found in the utility constants, which allows mods to change them. (Undocumented)

So this says, that it is possible to alter the penalties. Maybe you can mod values, that suit you? The wiki also contains a link to the train pathfinder code.

When it changes all signal the same penalty im not sure if it would solve the problem because it would only need a high penalty (higher then the waiting trains penalties) on the stacker entrance each line when the signal is red by wire network.

[Hyenna]

Possibly it is the increasing penalty from waiting trains causing this problem. I think it would solve the problem if the increasing penalty wasnt there and give a fix penalty to each waggon instead.
Its because any waiting train penalty will overrule any placed red signal sooner or later due to increasing value.

[eradicator]

Possibly it is the increasing penalty from waiting trains causing this problem. I think it would solve the problem if the increasing penalty wasnt there and give a fix penalty to each waggon instead.
Its because any waiting train penalty will overrule any placed red signal sooner or later due to increasing value.

You could try

Code: Select all

data.raw['utility-constants'].train_path_finding.train_waiting_at_signal_tick_multiplier_penalty = 0

It's the only dynamic penalty as far as i know. But i think googling for the threads of people who have already solved your problem with circuits instead of mods would be a better solution. (Also no guaranteed that setting it to 0 doesn't cause other problems when you actually want that behavior and just don't know yet...)

[Hyenna]

Im not a modder nor do i know what to do with that code.
When its a multiplier what it seems to may shouldnt be zero the one would keep the current number not increasing while zero would completely remove penalty from it?

[Optera]

I do agree with your statement about Factorio trains being smarter than OpenTTD trains though

However, when using OpenTTD path signals, OpenTTD is, in my opinion, far superior (and also more realistic) compared to current Factorio signalling. That's why I am in favor of Path Based Signalling (PBS) being introduced in Factorio.

Especially when using OpenTTD with the optional routing restrictions patch, OpenTTD is far superior to Factorio. That's why I am in favor of the suggestion of implementing all of this in Factorio.

I fully agree that PBS is much more realistic and on small scale smarter with how OTTD only checks one segment ahead. OTTD trains still get lost easily if you build junctions where you have to turn left to go right.

Factorio trains on the other hand always calculate their whole path. They can't get lost unless you remove tracks, but in turn don't check for paths at every junction.

If chain signals always forced path recalculation that could solve the problem of trains waiting in front of half empty stackers.

I'll write a small mod hooked into train states, forcing repath whenever a train breaks or stops at a signal. Though it'd be odd if they didn't do that already.

Update:

Train_Repath_0.1.0.zip

(989 Bytes) Downloaded 136 times

Here's the mod i tested, it seems the pathfinder is too smart to properly stack trains OTTD style and this mod only makes things worse.

2018-10-13-08-48-33-1905917.png (678.23 KiB) Viewed 6491 times

This station design shows the shortcomings most clearly.
When a train stops at the chain signal leading into the stacked stop it prefers to go to a track where a train just leaves at the front over an open slot at the back of the stacker. It often even repaths between tracks making the wait time a lot longer than if it stuck with the original path.

When setting the penatly for trains waiting in stops down from 500 to 100 with Pathological or similar the stacker works a lot better.

[eradicator]

Im not a modder nor do i know what to do with that code.
When its a multiplier what it seems to may shouldnt be zero the one would keep the current number not increasing while zero would completely remove penalty from it?

The default value is 0.1, so 0 should be correct to remove only the tick-based penalty (if that is indeed what you're asking, the grammar in that sentence is hard to understand). @Optera linked a mod called "pathological" that apparently lets you adjust all the penalties, so you don't even need to mod it yourself.