Train Filter Signs

[ssilk]

TL;DR

This is a “counter suggestion” to Trains: Chain signals should factor in the length of the train.

What?

Introduce signals, that blocks trains with some (measurable) train (!) properties from driving through the block, where the sign is placed.

You can prevent trains crossing such signs.
- trains longer/shorter than x
- trains with/without cargo x
- ... (fuel lower than x? Filter double headed trains? Trains with special equipment?)


Implementation looks relatively simple: I think that could be easy added to the pathfinding. (?) because such signs work just like a broken rail. You cannot place the sign everywhere, for example it makes eventually no sense at crossings. I guess the most effort for this feature goes into the GUI.

No path: if a sign blocks a train from arriving his target it alerts the player. If the signal was changed after the train has been left station (path had been found), and an alternative cannot be found, it ignores the sign.

Nice to have: The sign could also be controlled by circuits. Again: if the sign changes and there is no alternative path, it ignores the sign.

Why?

Give the player a way handle trains with very different length. You cannot build good, fast crossings for any type of train. That makes such crossings inefficient. Instead enable the player to route trains to an optimized version for their length.

Other options can add very much gameplay value with a relatively low effort.

Some ideas:
- avoid crossings that the train with that length is not build for (the origin of this idea)
- route longer trains around the center of your factory
- make “main lines”
- with control by circuits: route around busy crossings
- route low fuel trains to stops with a refuel
- make waiting lines for one item type only

And many things more.

This is also quite related to the suggestions of adding penalty signs/signals to influence the pathfinder.
(Found viewtopic.php?f=80&t=21899
viewtopic.php?f=6&t=85260 )

[Laramy65]

I like this idea. I would also suggest they allow to have configurable pathfinding cost to cross it which can be positive or a negative value, making trains either prioritize some route or avoid it. There is already a clunky way of doing this, you can line a route with empty stations, or set a signal red with circuits which turns green when a train has entered the segment before it. would be epic to have more streamlined way to do this

[Sad_Brother]

- ... (fuel lower than x?

That thing changes over time on the route...

I want to mention usefulness of length filter for stations but this suggestion cover it.

[NotRexButCaesar]

This seems like a more complicated solution to the exact same thing as the chain signal change

[Sad_Brother]

It look complicated? It is simple and controllable!
1.At the moment, pathfinder works, train parameters are known.
2.Some paths become closed for this train (so pathfinder has less ways to measure) and it get own personal way to go.
3.Time to go that way.
Almost as now. Compare with "chain signal change":
1.Pathfinder give train way to go.
2.Train cannot go past chain signal because next signal block too short.
3.Should it repath? Would it repath to the same short block? Will be that block reserved forever?
In my opinion "chain signal change" is more complicated and doubtful.

[ssilk]

This seems like a more complicated solution that the exact same thing as the chain signal change

And combined with adding penalty points (see also Laramy65) this is in my opinion really a game changer for trains.

[Tesse11ation]

My question is, why was that thread locked? I didn't see any message explaining why.

Maybe ssilk did it to stifle the competition, so that his suggestion takes the cake.

[Squelch]

I was just in the process of replying to the other thread, and it got locked.

The point I was going to make, was to highlight a flaw in the argument for allowing longer trains to pass chain signals, and that is track length. We have already seen trains longer than a loop crash into themselves, so having them ignore certain chain signals could only exacerbate the problem.

Having a device that effectively gives us the ability to adjust the pathing cost could be very useful in many situations. My current "hack" is to use multiple circuit controlled waypoint train stops to increase the penalty - ugly, and cumbersome.

[ickputzdirwech]

At the risk that this topic will be locked as well (because it going off topic)

My question is, why was that thread locked? I didn't see any message explaining why.

In his last post ssilk wrote:

(boskid said no)

which doesn't really reflect what boskid actually said:

Currently i am in a "wont implement" state but feel free to discuss.

So he wasn't 100% certain yet and even more importantly he was open to more discussion. Instead of locking the topic at most it could have been moved to "Outdated/Not implemented" imo. And even that would be inappropriate since boskid hadn't, as I said, made a final decision yet and it would be more difficult to discuss since I think people don't read the "Outdated/Not implemented" board that frequently.

[NotRexButCaesar]

In his last post ssilk wrote:

(boskid said no)

which doesn't really reflect what boskid actually said:

Currently i am in a "wont implement" state but feel free to discuss.

I think boskid meant “discuss among yourselves”. He gave a lot of reasons why implementing it didn’t make any sense.

[Squelch]

The discussion continues here, with an alternative suggestion.

I do understand, and agree with all of the reasons not to pursue the original suggestion, but that doesn't take anything away from the premise of having trains of different lengths being more manageable on the same network. Like I said, I also had a need for long long distance bulk trains, and shorter local trains. Either they are kept separate and use transfer stations, or some mechanism is employed to direct these different trains to their respective parts of the network. Controlling pathing costs is one such way. Nasty waypoint stops and complex signal and circuit networks is technically possible, but so unwieldy, that it's not worth bothering.

I still think having the current train ID in the block readable from rail signals would satisfy a lot of wishes, and give players the control that is being requested.

[Sad_Brother]

I still think having the current train ID in the block readable from rail signals would satisfy a lot of wishes, and give players the control that is being requested.

It could work. But in my opinion train id is the worst way to control pathfinder.

This seems like a more complicated solution to the exact same thing as the chain signal change

Sign, able to control allowed train length based on logic signals, would be able to simulate suggested chain signal change.
And much more.

[ssilk]

Why was this locked? I have no idea. I guess someone by accident? Yes, I tend to remember my suggestions better than others - I think this is quite natural - but I guarantee I would never use such tricks to make them stifle out. (Deep Loking at KoblerMan)

In his last post ssilk wrote:

(boskid said no)

which doesn't really reflect what boskid actually said:

Currently i am in a "wont implement" state but feel free to discuss.

I think boskid meant “discuss among yourselves”. He gave a lot of reasons why implementing it didn’t make any sense.

I admit, I shortened that quote a bit too much (I won’t to put much attention in that). But the core of his arguments was “that’s not gonna work well. And discuss to find a better solution.”

I still think having the current train ID in the block readable from rail signals would satisfy a lot of wishes, and give players the control that is being requested.

It could work. But in my opinion train id is the worst way to control pathfinder.

Agreed. You know, trains can be destroyed. And there are some more actions, where trains can change their ID’s.

Using the id of anything in a program to decide, if something should do this or that remembers me to my current project, where my customer made exactly this. Instead of adding new fields into the database to let the program decide what to do on that criteria, they added code like “if ID=123 then do this, otherwise that”. Cold shudders run down my back, when I saw that. And how much code was changed to implement that. Such code is literally dead, it takes more time to figure that mess out and repair it, than to write it new.

And the same is it in Factorio with the train-ID’s. There are programming paradigm, that are known to look fine at first, because they solve a simple problem very fast, but be be known to make everything worse or completely brake, because they are so weak.

And - as said in the suggestion above: the right way to make that, is to have a criteria ON the train. Like the equipment grid, or something like a constant combinator, which enables you to distinct trains. And the filter here can look at the train and see “oh, it has this criteria, so this path is closed” (or “train has not this criteria, path is open”).

[boskid]

Honestly previous topic about chain signals taking into account the train length was easier in terms of possible implementation. This however could have more possible use cases.

Those signs if implemented, would have to affect pathfinder behavior to prevent some paths from being taken due to restrictions. There are certain restrictions about what can add a penalty (or prevent given path from being taken) and it relates to at what points pathfinder processes nodes. For example pathfinder node's are related to rail segments which can be split by junctions (when multiple rails merge) or by rail signals (which force rail segments to split - signals are always at one of the rail segment ends, never inside). If those signs would be required to bind to a rail segment, those segments would have to be able to take multiple signs into account and this would create an issue where a sign that is far behind could still affect a path for a train that is heading away of that signal - just because that sign would behave as it would be at the exit of the rail segment. For that those signs would in general work as rail signals, but here i would have to make them split rail segments as rail signals do, but to ignore the rail signal logic on them so they do not split rail blocks and do not require any reservations (they would immediately turn into rail signals). Quite a lot of weird changes.

Lets assume those signs would be literally a rail signals "with one feature added" for the ease of implementation. Pathfinder has to look into signal state anyway when searching path so adding extra features to rail signals is the least intrusive way to add logic into rails.

Train length restriction is possible to implement as trains never changes length during their travel (and when it changes length, it is now a different train) so this would have a well defined behavior.

Trains with/without cargo condition in theory can change when traveling when player manually puts stuff into the train while riding that train. Because of this when a train would repath for any reason (let it be a signal that cannot be reserved due to another train) during a repath those conditions would have to be still checked and the train could slam the brakes just because the condition is no longer fulfilled. There is no "if no path then ignore sign" because that would mean either train remembers which signs were fulfilled at the repath when leaving train stop (or were fulfilled at the last successful repath) or it ignores all the signs, even those which were not on the path. Second approach would cause the train to possibly breach any condition.

Routing low fuel trains for a refuel would not be solved by this. To fix this the train would have to change its current schedule record it is following. Routing low fuel trains with signs would require weird setups where the refuel train stop would be just another "Iron drop" train stop but without any place to drop iron, just so the train can be refueled without having an extra schedule record for refueling, but then the leave condition would be completly broken as it empty cargo would never trigger. It is far easier to have a dedicated train that brings the fuel to the vicinity of the unloading train stops and provides it directly to the trains that are unloading stuff so the period of unloading can be also reused for loading fuel.

Routing around busy crossings: if a crossing is busy there will be a lot of trains increasing the penalty of such intersection so the trains should already avoid such intersections if another paths are available. For manually forcing to reduce congestion those signs would have to add extra penalty (which is a separate idea by itself). Extra penalty could apply to all the trains and all of them could choose another path that would now become congested.

This idea is not mature enough to be even considered to implement.

[ssilk]

TL;DR

- pointed out exact rules how the train should work with closed path overriding.
- mixing in optional penalty-ideas (I think they are very highly tighted together), namely:
---- when no filter is set it add just penalty to the train
---- with filters you can turn off closing paths and only add penalty
---- you can change amount of penalty (by player or circuits), even negative penalty (prefer paths)
and some details.

Lets assume those signs would be literally a rail signals "with one feature added" for the ease of implementation. Pathfinder has to look into signal state anyway when searching path so adding extra features to rail signals is the least intrusive way to add logic into rails.

Would be completly ok for me: It's might look just a bigger than the normal signals and mybe it can show it's current functionality a bit.

Trains with/without cargo condition in theory can change when traveling when player manually puts stuff into the train while riding that train. Because of this when a train would repath for any reason (let it be a signal that cannot be reserved due to another train) during a repath those conditions would have to be still checked and the train could slam the brakes just because the condition is no longer fulfilled. There is no "if no path then ignore sign" because that would mean either train remembers which signs were fulfilled at the repath when leaving train stop (or were fulfilled at the last successful repath) or it ignores all the signs, even those which were not on the path. Second approach would cause the train to possibly breach any condition.

I had added this rule, to avoid that when you change the sign/signal, so that the train has no allowed path anymore. It would end with a completly mess, because a train then stops with "no path" on your main route. I think this danger is real and should be avoided somehow. But:

Routing low fuel trains for a refuel would not be solved by this.

Ya, Sad_Brother figured that also out. Nothing which can change during the train is running is a good idea.

This suggestion works only well with things, that cannot change during normal automated train routes - and the special case that the player changes the train during traveling can be just a special case; I mean the main issue is the above, that you change something here and you create a complete deadlock somewhere else. So the idea was, that the reachablity of the next target is checked at start of the next schedule-entry and my thought was, that this is checked just once and if such a sign/signal then changes, it should ignore this, if there is no path left then. It might take a second pathfinding for this special case.

But on the other hand I think this will lead also to "interesting game situations", where you forgot, that when you change this so that there is no route left, it will ignore any sign. I don't know, if that is really a good idea. I would like to play with the details in some kind of beta-phase.

So, I tried to make this ideas more detailed:

- When the train is at the begin of the next schedule-entry (normally at a stop or started by the player) we do one special check: Is there a path? When yes: Is there a path, that this train is allowed yet?
---- Subidea: Because this feature can also be used to control, if a train should leave a train stop (there have been some suggestions around that), it is similar to the new max. trains feature and should be displayeed similarly, as when no free destination stop is available. I don't know yet if I need an overview of such kind of trains anywhere to find problems, so I leave that out.
- Then we do the "normal" path scan, this time we just add a ridiculous amount of penalty, every time, when a closed sign/signal is traveled through. This enables the train to avoid this path, but if there is no other path left, it goes that way. Or if there are other signs/signals, the train uses the "shortest" path. This is to avoid that the train gets stuck somewhere during it's travel.
- This double-scan needs to be done only once per schedule-entry. I think this is affordable, but I cannot really know it. I think these scans can be done all in one turn, if clever programmed.
- When the train state is changed by the player, it could just simulate this first scan. If the state changes (path suddenly not longer allowed) we can think about not allowing this player action (not a fan of), or warn the user, that this last operation will stop the train.

Optional stuff, but highly relevant:

- Instead of setting up a filter-condition, the player can just leave it free, so that the penalty is just added to every train.
---- This changes the behavior so, that instead of disallowing a path it adds penalty to every train by the sign/signal. No pre-check is needed anymore, this spares this first check.
- Another option might be, that the player can decide to turn path blocking off, even when the filter is set. This let the train just prefer one path over another, if the condition is met.
- Next option is: The player can choose, how high this penalty is. If the player is allowed to set the added penalty himself:
---- instead of taking a ridiculous amount (dunno, by default one million?), he can set it much lower.
---- To make sense to this feature, we might need some kind of tool to measure the total penalty between two points to balance things out nicely. Would be enough if I could set a locomotive anywhere, give it a destination and when I hover over the schedule, it tells me somewhere the current total penalty.
---- I can also set a negative penalty. Endless possibilies, like prefered paths etc.
- I can set the amount of penalty by circuits. If that changes, the train will only take that into account, if he needs to repath.

Routing around busy crossings: if a crossing is busy there will be a lot of trains increasing the penalty of such intersection so the trains should already avoid such intersections if another paths are available.

I know that, but I had many situations, where I would liked to have a bit more control about that. It also give me a bit more feeling, that I have the control over my trains (which is not really true ) but I really would like it.

This idea is not mature enough to be even considered to implement.

Huh, that sounds dark. Hope that helped a bit to bring more light into it.

[Nidan]

Lets assume those signs would be literally a rail signals "with one feature added" for the ease of implementation. Pathfinder has to look into signal state anyway when searching path so adding extra features to rail signals is the least intrusive way to add logic into rails.

Would be completly ok for me: It's might look just a bigger than the normal signals and mybe it can show it's current functionality a bit.

Reasonable, but something in my head screams "combinatorial explosion". What about chain signal signs?

Trains with/without cargo condition in theory can change when traveling when player manually puts stuff into the train while riding that train. Because of this when a train would repath for any reason (let it be a signal that cannot be reserved due to another train) during a repath those conditions would have to be still checked and the train could slam the brakes just because the condition is no longer fulfilled. There is no "if no path then ignore sign" because that would mean either train remembers which signs were fulfilled at the repath when leaving train stop (or were fulfilled at the last successful repath) or it ignores all the signs, even those which were not on the path. Second approach would cause the train to possibly breach any condition.

I had added this rule, to avoid that when you change the sign/signal, so that the train has no allowed path anymore. It would end with a completly mess, because a train then stops with "no path" on your main route.Because of this when a train would repath for any reason (let it be a signal that cannot be reserved due to another train) during a repath those conditions would have to be still checked and the train could slam the brakes just because the condition is no longer fulfilled.

It would be like removing the only piece of track connecting the train to the destination, "no path" feels appropriate.
Regarding changing the setup of the train:

This suggestion works only well with things, that cannot change during normal automated train routes - and the special case that the player changes the train during traveling can be just a special case; [...]

Changing the train setup will switch the train to manual, so any restrictions become void. Switching the train to another station should behave as it does now, likely just a repath event. Changing signs on the trains route, such that the train is no longer allowed, should trigger a repath, potentially resulting in "no path". Changes for signs already reserved by the train, i.e. within breaking distance or as result of a chain signal section, should be ignored, like closing it signal via circuit network is now.
Speaking of repathing: "slamming the brakes" feels unnatural. If a train repaths and cannot reserve enough track for its current breaking distance, the new path should be discarded. If, as result, there is no viable path towards its new destination, it should break along its previously reserved path and enter "no path" state.

So, I tried to make this ideas more detailed:

- When the train is at the begin of the next schedule-entry (normally at a stop or started by the player) we do one special check: Is there a path? When yes: Is there a path, that this train is allowed yet?
---- Subidea: Because this feature can also be used to control, if a train should leave a train stop (there have been some suggestions around that), it is similar to the new max. trains feature and should be displayeed similarly, as when no free destination stop is available. I don't know yet if I need an overview of such kind of trains anywhere to find problems, so I leave that out.
- Then we do the "normal" path scan, this time we just add a ridiculous amount of penalty, every time, when a closed sign/signal is traveled through. This enables the train to avoid this path, but if there is no other path left, it goes that way. Or if there are other signs/signals, the train uses the "shortest" path. This is to avoid that the train gets stuck somewhere during it's travel.
- This double-scan needs to be done only once per schedule-entry. I think this is affordable, but I cannot really know it. I think these scans can be done all in one turn, if clever programmed.
- When the train state is changed by the player, it could just simulate this first scan. If the state changes (path suddenly not longer allowed) we can think about not allowing this player action (not a fan of), or warn the user, that this last operation will stop the train.

Signs preventing the train from passing it should be treated as absolute, otherwise players will be confused when a train passes a sign it shouldn't be allowed to pass because that's the only route. Going into "No path" mode is more obvious (and easier to implement, as the special case isn't needed). This also gets rid of the double pathing when trying to leave a station.
As I said above, changing the condition should be treated similar to closing the normal signal: If the train has already pathed beyond it, and thus reserved the signal, the signal stays in the reserved state until the train has passed or repathed to another route.

Optional stuff, but highly relevant:

- Instead of setting up a filter-condition, the player can just leave it free, so that the penalty is just added to every train.
---- This changes the behavior so, that instead of disallowing a path it adds penalty to every train by the sign/signal. No pre-check is needed anymore, this spares this first check.
- Another option might be, that the player can decide to turn path blocking off, even when the filter is set. This let the train just prefer one path over another, if the condition is met.
- Next option is: The player can choose, how high this penalty is. If the player is allowed to set the added penalty himself:
---- instead of taking a ridiculous amount (dunno, by default one million?), he can set it much lower.
---- To make sense to this feature, we might need some kind of tool to measure the total penalty between two points to balance things out nicely. Would be enough if I could set a locomotive anywhere, give it a destination and when I hover over the schedule, it tells me somewhere the current total penalty.
---- I can also set a negative penalty. Endless possibilies, like prefered paths etc.
- I can set the amount of penalty by circuits. If that changes, the train will only take that into account, if he needs to repath.

Negative penalties are problematic. They might break Dijkstra, if negative loops exists. And they will break the invariant of the currently used heuristic for A*.

[Ajedi32]

I love this! Such a simple idea but with so many possible applications! Prevent long trains from entering sections designed for smaller ones, discourage trains from taking certain high-traffic paths unless their destination requires it, etc.

[Sad_Brother]

If those signs would be required to bind to a rail segment, those segments would have to be able to take multiple signs into account and this would create an issue where a sign that is far behind could still affect a path for a train that is heading away of that signal - just because that sign would behave as it would be at the exit of the rail segment.

No worse than signal block, which is busy by train far away. In that scheme you can attach several conditions for train to enter that segment. If the train is already on segment all signs are ignored.
Sign should behave as it would be at the entrance of the rail segment. Not at the end.

Lets assume those signs would be literally a rail signals "with one feature added" for the ease of implementation. Pathfinder has to look into signal state anyway when searching path so adding extra features to rail signals is the least intrusive way to add logic into rails.

Such sign (or conditional rail signal, or rail signal with optional condition feature) would forbid to pass it instead of forbidding to enter block. More logical but to add several conditions you need several rail signals. Not a problem imho.
But there are two problems here:
1. if condition changes while train's breaking point pass that sign/signal the train would pass it anyway.
2. if condition changes while train's breaking point is already on the signal block before sign/signal, train would have no way to move suddenly.

This idea is not mature enough to be even considered to implement.

It has enough reasons to mature. I state some above.

So, I tried to make this ideas more detailed:

Too complicated imho.

- Instead of setting up a filter-condition, the player can just leave it free, so that the penalty is just added to every train.

I prefer optional penalty or restriction.
Restriction decrease pathfinder burden. Penalty allow fine tuning.

we might need some kind of tool to measure the total penalty between two points to balance things out nicely. Would be enough if I could set a locomotive anywhere, give it a destination and when I hover over the schedule, it tells me somewhere the current total penalty.

It might work on schedule. But best would be moment when you aim at the map with goto cursor and see that white line. (If I can remember it correctly)

I can also set a negative penalty. Endless possibilies, like prefered paths etc.

Driver: "I like to move near my beloved girl's house so much, I would drive here again and again. In circles."
Or in Scientific words...

Negative penalties are problematic. They might break Dijkstra, if negative loops exists. And they will break the invariant of the currently used heuristic for A*.

What about chain signal signs?

As far as I remember they are not even controllable for some reason...

It would be like removing the only piece of track connecting the train to the destination, "no path" feels appropriate.

Exactly.

[Nidan]

What about chain signal signs?

As far as I remember they are not even controllable for some reason...

"Chain signals have no state" apparently. Which makes me feel like chain signals are implemented as an entirely different thing than signals, instead of signals with an extra feature. If we add that the circuit network also doesn't keep a state since it gets recalculated every tick (see the abstraction thread), then... I'm getting sidetracked

But when combining signs into signals, like boskid suggested, there might be a situation where a player wants a sign but the only place where they can put it is already occupied by a chain signal, thus creating a need for chain signal signs.

[ssilk]

Too complicated: yes. Ok. I already thought that in my last post. And now I see what needs to be changed:

Instead of closing a track like the OP suggest you can only add penalty!

The whole complicated rules with double scan for availability for target stop: gone!
The rules what happens, if the signal changes during a ride: gone!
The player needs not to decide between different operation-modes.

So here is an updated description:

- a sign can be added to a track, by default it works like a normal signal.
- if you open it you can set up - besides the normal signal setup - two more parts:
—— a filter. (*)
—— an amount of penalty.
- if no filter is set, but the penalty, the penalty is added to every train, that passes this signal in the pathfinder algorithm. If filter and penalty is set, the penalty is only added, if filter is true. If no penalty is set, but a filter, a very high penalty is added.
- when a player changes the content of a train while driving, this will recalculate the path for each change.
- only positive penalty can be set.
- the things I don’t mention are still the same, like that we need a tool to measure penalty between two points, that the sign (or signal) should reflect it's internal state, and so on.

(*) the filter looks a bit like circuit logic. But is different. On the left side we can choose parameters from inside the train:
train length, number of locomotives/wagons, bidirectional or one-way, cargo (any item, that can be transported), equipment grid stuff, things, where we can distinct a train-type from others (there are other suggestions, like to put a constant combinator thing on the train) and other parameters on the train, that don’t change during a ride and I currently don’t know and make eventually sense.
The comparator works like in the decider combinator.
The right side is the value, which optionally can be changed from external circuit.

Optional:

- the value, that decides if and how much a filter filters, can be set by circuits.
- Also the penalty-value.

That’s it. With this change this suggestion will still be super useful. The main disadvantage is, that you cannot control, when a train should leave a station. But I already thought that this feels a little bit too complicated. And it feels a bit like misusing the sign for schedule things.