Block rail section based on train condition

[ikarikeiji]

TL;DR:
Allow clicking a rail entity (or segment) to bring up a GUI where conditions can be set; then whenever a train does pathfinding and sees that rail entity (or segment), if the conditions are met for that train, the pathfinding acts as if that entity (or segment) doesn't exist (and thus goes a different way or produces "no path").

What:
The conditions depend on the approaching train.
These could be things like:
* Is a player in the train?
* How long is the train? (total engines + wagons)
* How many forward-facing engines are in the train? (or what is the ratio of such engines to train length)
* How much cargo is in the train? (and potentially, what kind of items)
* How much fuel is in the forward-facing engines in the train? (total fuel value in MJ)
* Does the train have a certain station in its order list?

Why:
This can allow for efficient routing/prioritising of trains without needing to use circuit network control or "waypoint" stations.
Also, it has an extra advantage over using "waypoints", because the conditions can be set on the track, rather than needing to be copied into every train that uses them.

The most obvious use case I saw was for the first condition (is a player in the train).
In my (single player) builds I have 3 lines on main railways; the central line goes both ways and is reserved for me, i.e. I set my junctions and signals so that cargo trains can never enter the central line, and manually put or drive my train onto that central line to pass any other trains. (Especially useful when I need to solve a blockage as I can get there much more quickly on a train on an empty line than walking past a bunch of jammed trains.)
However, that means I need to take special care when going from 3 lines to a 2 line or 1 line section; I can't allow cargo trains to enter the reserved line, so the signals must not allow it; but that means I can't use automatic pathfinding on my train and have to manually drive the wrong way past the signal.

If there was a settable condition on "is a player in the train", I could set a segment of the "cargo line" to say "Block this segment if player is in the train", similarly I could set a segment of the "passenger line" to say "Block this segment if player is not in the train".

After thinking of a sensible way to tell the pathfinder that certain segments should not be used in certain conditions, the other conditions followed simply with their own use cases:

* How long is the train - could be used to block lines from long trains if they should only be used for short trains (optimised signal spacing for example)
* How many forward-facing engines (or the ratio) - this will affect the train's acceleration, so slower trains can be put on lines designed for them
* How much cargo (and potentially what cargo) is in the train - trains with more cargo (or more important cargo) could be put on a priority line for the unloading station; similarly trains with less cargo could be put on a priority line for the loading station
* How much fuel - could send the train to a station with fuel to refuel (though this would only work if we're talking about separate stations with the same name, some with fuel and some without)
* Is there a certain station in the order list - going back to the "is player in the train" condition, this could be used to allow a passenger train onto the passenger line even without a player in it, if that train had a passenger-only station somewhere in its order list.

I'm sure there are other conditions that would be useful, but these are what I have thought of so far; more importantly if the condition system was set up in the first place, it would work for any condition that might be thought of in future.

Also note, this is rather different than using a circuit-connected signal; circuit-connected signals can't tell any information about the train that is doing the pathfinding; also a red signal still allows the train to path that way (it will just be stopped) whereas acting like the segment does not exist at all means such a train will never path that way, even if it causes a no path error (which would be a good thing, as it means the player knows something is wrong with their network or conditions and needs to fix it, rather than just causing a jam or delay).

[hanyuwei70]

+1

[eradicator]

I like that idea...but, it sounds like it would make train pathfinding at least an order of magnitude slower than it is now.

As a funcionally reduced but possibly more feasible alternative solution...how about being able to assign groups to trains and have certain rails that can be disallow passing on a per-group basis? As changes to groups can only be done manually this should be resonably cheap computationally (one graph per group).

[mrvn]

Or it could make it faster because paths get blocked and don't need to be searched.

I would like to add a use case for using train length to block paths. The path might be impassable for trains above a certain length. E.g. a turnabout with a 270° turn can only be used by trains that are short enough not to hit them self. Currently trains just crash if they for some reason path through there.

[<NO_NAME>]

Or it could make it faster because paths get blocked and don't need to be searched.

I think that it would be faster if many trains would have set conditions that block some paths and slower if most of trains can go everywhere. Anyway, checking that conditions doesn't seem to be computable heavy so the worst-case slowdown would be pretty small anyway.

I would like to add a use case for using train length to block paths. The path might be impassable for trains above a certain length. E.g. a turnabout with a 270° turn can only be used by trains that are short enough not to hit them self. Currently trains just crash if they for some reason path through there.

Yeah, I also have a lot of small loops for trains that I use for traveling but they are often cause deadlocks with big trains which are not supposed to go there anyway. They just choose that path because all others are temporally occupied. It would be amazing to block that.

I would be nice to be able to also block trains from entering rails leading to station if they don't go to that station, although it seem to be harder to implement so maybe I shouldn't stretch it so far.

[mrvn]

I would be nice to be able to also block trains from entering rails leading to station if they don't go to that station, although it seem to be harder to implement so maybe I shouldn't stretch it so far.

If you build stations without stacker than use only chain signals in the station. That way they can only go to the station when it is empty and can't get stuck.

With a stacker you can do the same if you add a way back to the main line between the stacker and the station.

A good way to prevent trains entering stations is have them be a backwards loop. Have the exit before the entry. Any train considering that path would just add the loop to the cost and it will never be cheaper.

[Tekky]

I really like the suggestion of routing restrictions. In fact, I had the same idea 12 years ago for the game OpenTTD and, meanwhile, it has been implemented in OpenTTD 3 years ago as an optional patch.

Instead of only being able to forbid a route completely, it may also be useful to additonally be able to add a pathfinder penalty. This is also how it is implemented in OpenTTD.

It would also be useful if trains had some user-defined information that could be read. In the following thread, it has been suggested that every train (or individual engine) should have a constant combinator:

viewtopic.php?f=6&t=46969 Constant Combinator for Locomotive

Also, regarding players on trains, in the following thread it has been suggested that the number of players on a train should count as train contents (which is signalled to the circuit network):

viewtopic.php?f=6&t=54203 train stop circuit network 'contents' should include player

Unfortunately, the routing restriction suggestion cannot be implemented with Factorio's circuit network, because the circuit network is only evaluated once per tick and can require several ticks to compute a result, whereas it must be possible for the route restriction conditions to be evaluated separarely for every train, possibly even several times in one tick. However, in the following thread, it has been suggested that it should be possible to pack combinators into a circuit box.

viewtopic.php?f=6&t=57067 Add a space saving "circuit box" for combinator setups

If the contents of the circuit box didn't behave as a standard circuit network that was evaluated once per tick, but instead was only evaluated whenever a train's pathfinder tries to pathfind past a certain track piece, then the combinators of the circuit box could be used as a program that determines the route restriction, similar to the one in OpenTTD. This circuit box could then also accept external input from the "standard" circuit network, so that the circuit box routing restriction program could take certain external variables into account.

EDIT: On second thought, I'm afraid that it would be too complicated to develop a completely new circuit network system that can be evaluted several times per tick. Instead, I guess it would be best if the routing restrictions used conditions similar to the train station conditions. For example, IF TrainID != 20 OR circuit signal A > 5 THEN Deny.

[McDuff]

Could you do this with circuit entities and signals?

EG, a combinator type thing which reads the properties of the train in a given signal block - train name/id, composition, contents, fuel level etc. Link that to signals and/or stations ahead in order to set them to on/off.

That might even be moddable. In fact there might even already be a mod that does it, or something similar.

[Tekky]

Could you do this with circuit entities and signals?

EG, a combinator type thing which reads the properties of the train in a given signal block - train name/id, composition, contents, fuel level etc.

Currently not, at least not in vanilla, but in the following thread I suggested that it should be possible for signals to send the contents of moving trains to the circuit network:

viewtopic.php?f=6&t=47541 track signals should send Train-ID to circuit network

Unfortunately, even if it were possible for the circuit network to read the contents of moving trains, all the circuit network can currently do is force a signal to red. Although red signals can have a limited influence on the pathfinder, they cannot completely forbid certain routes. A train may still attempt to take a route whose signal is currently red. Therefore, I believe that the suggestion of the OP, that it should be possible to have a direct influence on the train pathfinder and completely forbid certain routes, is meaningful.

[mrvn]

Further more a red signal stops all trains.

The case where this would be useful would have a 1 car train and a 4 car train going the same way. The 4 car train needs to be blocked because it's too long to take the roundabout. Using signals any approaching 4 car train would block all the 1 car trains too.

You would also quickly get into situations where a 4 car train will approach a roundabout, gets blocked, turns around, approaches a different roundabout, get blocked again, turns around and approaches the first roundabout again, ... over and over.

This feature must happen when planning the path, which might be arbitrarily far away from the signal where you would block the train.

[eradicator]

Thought about enforcing train length with signals. But since trains can't block themselfs anymore i had no success.

noselfblock.jpg (595.81 KiB) Viewed 5841 times

[mrvn]

Thought about enforcing train length with signals. But since trains can't block themselfs anymore i had no success.

noselfblock.jpg

So a train coming from the right that is too long will block itself and therefore must re-path to go south?

Problem is that the train will allocate the chain signals when the breaking point hits the first one, at which point it is still a long way away from blocking itself.

Try this: A fork with a chain signal before it and full signals after. The top signal is circuit controlled and disabled when "red > X". Before the fork you have a LOOOOOOOOONG track with full signals much denser than the train length and all connected by wire to read the signal state. The track needs to be longer than the breaking distances of a train at full speed. Set X to the number of trains a short train will block. A long train will block more segments so the fork to the top gets blocked. When the breaking point hits the chain signal it will already be blue.

[eradicator]

So a train coming from the right that is too long will block itself and therefore must re-path to go south?

That was the idea. But it doesn't work as i said. Even if i replace the second chain signal (red on picture) with a normal one and circuit control it and start the train right in front of the first (blue) chain signal. It will run straight over the red signal becaues it's causing the signal to be red itself. Thinking about it again...how can the train possibly know that it caused a circuit condition. Weird. I guess someone will have to do more testing.

[mrvn]

So a train coming from the right that is too long will block itself and therefore must re-path to go south?

That was the idea. But it doesn't work as i said. Even if i replace the second chain signal (red on picture) with a normal one and circuit control it and start the train right in front of the first (blue) chain signal. It will run straight over the red signal becaues it's causing the signal to be red itself. Thinking about it again...how can the train possibly know that it caused a circuit condition. Weird. I guess someone will have to do more testing.

That doesn't make sense. If you start a train it should never ignore a red signal. That only happens when the train is already moving and has the signal already reserved (i.e. when it can't possibly stop before the signal anyway).

Maybe make a new design with e.g. a station with the train in it leaving after 10s of inactivity. If the train still ignored the red signal send it in as a bug.

[mp0011]

I am using dummy stations to force trains to take another way, but all trains are treated identically.

If penalty for passing such station was calculated based on train status/length/conditions, it could be different for different trains, and that's something within modders reach...

Train does pathfinding, finds a station on it's way. Instead of adding 2000 tiles, it "negotiate" with it, and based on some values, gets lower or higher penalty...

Such station ofc do not need to be in trains schedule.

[mrvn]

I am using dummy stations to force trains to take another way, but all trains are treated identically.

If penalty for passing such station was calculated based on train status/length/conditions, it could be different for different trains, and that's something within modders reach...

Train does pathfinding, finds a station on it's way. Instead of adding 2000 tiles, it "negotiate" with it, and based on some values, gets lower or higher penalty...

Such station ofc do not need to be in trains schedule.

I wouldn't make those stations. You don't want them to show up on the map or be selectable in the schedule at all. Make them a new entity with their own GUI and circuit control terminal.

Someone mentioned that circuit controlled checks would be problematic because the circuit network on propagates one combinator per tick and train pathing needs instant results. So I would make the new "path controller" entities support a number of conditions similar to the train schedule with additional settings for train composition. Circuit control would then be limited to enable/disable, setting the penalty score or supplying values for the circuit conditions used internally.

[mp0011]

You need something distinctive to handle all conditions, station (modded version of regular Train Stop) is a good object. Different graphic, invisible in schedule menu etc.

Conditions interface similar to Locomotive, each condition can be true or false.
Default penalty = 0
If condition is true, add 0 to penalty.
If condition is false, add 100.
Condition values comes from wires (constant, live update, apply for each train equally)
If You need to make some conditions more important, just duplicate it.

How I see it is working (simplest solution, I have no idea what can be modded and what not):
Tick #1: Train writes somewhere (to some virtual network/chest) all its properties, including length, content fuel etc.
Tick #2: Train does pathfinding. All Station already received and processed wired data and virtual network/chest content. Penalty points for all such stations are now updated and readed by train.
Tick #3: Train deletes it's content from virtual network/chest and proceed "shortest" path (with less penalty points and length).

Problems:
- there should be only 1 simultaneous train pathfinding.
- train still would go through station if it's only way.

[eradicator]

So a train coming from the right that is too long will block itself and therefore must re-path to go south?

That was the idea. But it doesn't work as i said. Even if i replace the second chain signal (red on picture) with a normal one and circuit control it and start the train right in front of the first (blue) chain signal. It will run straight over the red signal becaues it's causing the signal to be red itself. Thinking about it again...how can the train possibly know that it caused a circuit condition. Weird. I guess someone will have to do more testing.

That doesn't make sense. If you start a train it should never ignore a red signal. That only happens when the train is already moving and has the signal already reserved (i.e. when it can't possibly stop before the signal anyway).

Maybe make a new design with e.g. a station with the train in it leaving after 10s of inactivity. If the train still ignored the red signal send it in as a bug.

Whelp. Fiddle some more. Got nothing. The signal in my new test is actually yellow when the train passes, though imho that is becaues it somehow delays becoming red because of the incoming train. Seems like you can only do that kind of "filter by length" thing if you force all trains to stop before the fork. And also it doesn't work if the alternative for the long train is significantly longer (i.e. station penalty +2000) than the other route, because in that case the long train just waits indefinetly at the signal that it's blocking itself.

BP

0eNrlm1tu6kgURedSvw1XrpcfSD2L/mtFyIG6oSSwkW2ijiIG0LPosfVIuszDBKec7B3dr/TPzTXgxeGc2vU4G17F4/bg9o2vOrF4FX5VV61Y/PkqWv9Uldv+se5l78RC+M7txExU5a6/akq/FceZ8NXa/SUW8vgwE67qfOfd+f7TxcuyOuweXRNeMNy5c2t/2M3d1q26xq/m+3rrAndft+HmuurfMQDnyQ87Ey/hP1L/sOGNQmBVuMOf4nsVsv+nceu37+XDlTrO7q6L0bVMjg/H45sHrwEqMsD8a/HJUTx6IhxNhiOzX5MvE+70zergu8vT8fDMEF7Z+G6zc12IbFXvHn1VdnXzPj6V3EW39s05OLFIT7F2Tb1dPrpN+ezD7eGeG3cZnl774ZP89E3bLd8Nz2ffdIfwyBDY+RVzV642/UBtXY/pWW1X9oM9BFTvXVOeoxC/hTvrQ7c/0Owjnm0b0jkTauLZqbFgybGg7NfGwqj246GaToSXkuFp87Xw7FjKdiKg7G6Wml/K+X6K0ekQiByPShXh5iBXZRy3QOP9ABsX0bWcq23dumFcd83B3UrduHI9PPWz3LZvnhuU9wXh9RU8F/cmuDBD7MvmNEMsxL9//yOOX585s6nyywTMZ/I/z+dE+uR9+lab0leTSSSHulRYbYrvVZrfqcJMrQNSY8nrc/ZLsjdK0V36zpmtm7J6ckt24TwljMjI1DZEGiwjWpHD1IJc880yPbXGyxRMCLmkyttavTo0z249Px0s3s/VRp+xxWjzGGPe1um2C7inTTdF1fkl2AQItQBD1fFQdezQkeChpnioSuJYQ2AVjlUEVuPYhMAaGKuIYaAsjmVKluJYpmQZjmVKhktMMSUrYKwkSqZxlUmiZBpXmSRKpnGVSaJkGleZJEqmcZUxFcNFxhQM1xhTL0JiBDXHVht8WdSwuIjyG1haxGc3sLCIMhlYVsSIMrCoiMFvYEkxQjWwpJhZxcCSYqZAA0uKma8NvGgxi4uBZcWshBbXFVEtCwuL2WNYWFnMhsjC0mJ2bxbWFrPVtLC2mH2xhbXFbOItrC3mxGFhbTFHLgseuQx+4krR5qAZOlvZ+CArY1x8M2gueU3vqVmMqtCW89Awy8fRRrPAH7lSIAeG3GEgGYClNZHWaKAp2nUozkwNMDP6uDmK1Mao4DZwrmw00mhK0UZGHBkTapYwPeObkWERaWWS3WCnnysgU+DUMoyAGOQmo2vv90MT9GR4XXhxGxTp0WVmyve66a/PUyhAV+8/ODYayIi99iRdVT5u3XLt2/7vtS3Zumq97Orl6Q2HPubpatm//d6t8WblH0yrMju1yUME3dXCFbGcgJ3ceT5ZmW9vOBRT4ymluzwKmCsyusmDUHO6x4NQC7rFA1DzhO7wIFRJN3gQKroDsVfTKQn6iYE0t+aORGhiSEPN4fbz5Ta37C4uB6Ap53FI+fkanmfUzniMjFY6J3da+eerbI5+tcFcfSOZjKff2McvEtbikcBYLyTrxkBUxZoxEFWzXgxENey5AKJadmsMUVPWiIGoGevDQNSctWEgasGuzwhVJgm7QGNYya7QGFaxSzSG1ewajWENu0hjWEu6MBg1JV0YjJqRLgxGzclDIkYlPRMIKknPBIOSngkGJT0TDEp6JhiU9UwwKuuZYFTWM8GorGeCUVnPBKOynglEVaxnglFZzwSjsp4JRmU9E4zKeiYYlfVMMGpKuhsYNSPdDYyas99Tj/x4IgpGT11Kc2CNmicyIcGS/Mo2ylXkN2ZRroY6rdcZwbxrKH7ctJQa6+Re5waeD3ZFh18yxPLyMDv/Jmzx5idkM/Hsmvb8gjxTobAyM+nx+B8ZQ/Vb

whelp.jpg (523.23 KiB) Viewed 5816 times

I think i've wasted enough time with that. If someone else wants to try be my guest.

[Tekky]

Tick #1: Train writes somewhere (to some virtual network/chest) all its properties, including length, content fuel etc.

As I have stated in one of my previous posts, I think that the following suggestion would be best to allow the properties of a train to be defined:

viewtopic.php?f=6&t=46969 Constant Combinator for Locomotive

That way, the player could have certain signals specify certain properties of the train. For example, he could set the constant combinator of the train to the following:

Signal A specifies a user-defined unique ID of the train (the currently implemented train ID cannot be user-defined)
Signal B specifies the type of train, 1 for iron ore, 2 for copper ore, 3 for diverse supplies
Signal C specifies the length of the train
Signal D specifies the type of fuel that the train should be loaded with, 1 = wood, 2 = coal, 3 = solid fuel, 4 = rocket fuel

The meaning of the individual signals are determined by the player, the above is just an example of how the player could do it.

As I have also already stated in my first post, all of these properties should be readable by both the circuit network and by the train routing conditions.

However, this would only allow the player to define constant properties of the train. Variable properties, such as the cargo or fuel contents of the train, would have to be readable by the built-in condition mechanism, which is also used for train waiting conditions.