Friday Facts #395 - Generic interrupts and Train stop priority

[xlomkn]

Regarding the generic interrupts, I'm not sure I love the showcased implementation, often my trains will be called "[iron-icon] iron drop-off" to have the fanciness of the icon, but the readability / searchability of text. Would it be possible to implement a basic wildcard, for example "[any-item] *drop-off" would match anything starting with the generic interrupt's item and ending with "drop-off"? I don't know if that would hurt performance, probably not for <1000 unique train stop names.

I really upvote that !
I name my stations like "Iron Mine 1". I could live with "[item:iron-ore] Mine 1" but specifying an unique name is helpfull for me to locate the outpost, add it in my personnal train schedule and so on. I like the genericity a common name gives for ressources trains schedules but I would like to have both, like in LTN where names are not taken into account to dispatch trains. Having some kind of wildcard would do the job for me.

[Svip]

Regarding the generic interrupts, I'm not sure I love the showcased implementation, often my trains will be called "[iron-icon] iron drop-off" to have the fanciness of the icon, but the readability / searchability of text. Would it be possible to implement a basic wildcard, for example "[any-item] *drop-off" would match anything starting with the generic interrupt's item and ending with "drop-off"? I don't know if that would hurt performance, probably not for <1000 unique train stop names.

I really upvote that !
I name my stations like "Iron Mine 1". I could live with "[item:iron-ore] Mine 1" but specifying an unique name is helpfull for me to locate the outpost, add it in my personnal train schedule and so on. I like the genericity a common name gives for ressources trains schedules but I would like to have both, like in LTN where names are not taken into account to dispatch trains. Having some kind of wildcard would do the job for me.

Honestly, I feel like the station name thing is a bit hacky, and it's now starting to show its limits. Others have suggested elsewhere the ability to grant stations "tags", which would be a better solution (or at least a nice addition), so instead of trains going to a station name, they go to a station with tag A. (Preferably, you'd still keep the old system, since for most purposes, names are just fine, but tags for when things start to scale.)

EDIT: Thinking further about these tags. Initially, I thought of tags as alternative names (or bynames) for the station, but perhaps instead they should just be signals. So if you had an iron mine, you could add a tag with the iron ore signal. You could add as many tags as you'd please. The reason for using signals would be to allow the user to control the tags with circuits. But wait, you say, if they are just signals, how can I tell my tags apart from provider and requester stations? You'd use the value. You could set your interrupt to go to station with tag with "<generic-item>" signal where value = 1.

[xlomkn]

Regarding the generic interrupts, I'm not sure I love the showcased implementation, often my trains will be called "[iron-icon] iron drop-off" to have the fanciness of the icon, but the readability / searchability of text. Would it be possible to implement a basic wildcard, for example "[any-item] *drop-off" would match anything starting with the generic interrupt's item and ending with "drop-off"? I don't know if that would hurt performance, probably not for <1000 unique train stop names.

I really upvote that !
I name my stations like "Iron Mine 1". I could live with "[item:iron-ore] Mine 1" but specifying an unique name is helpfull for me to locate the outpost, add it in my personnal train schedule and so on. I like the genericity a common name gives for ressources trains schedules but I would like to have both, like in LTN where names are not taken into account to dispatch trains. Having some kind of wildcard would do the job for me.

Honestly, I feel like the station name thing is a bit hacky, and it's now starting to show its limits. Others have suggested elsewhere the ability to grant stations "tags", which would be a better solution (or at least a nice addition), so instead of trains going to a station name, they go to a station with tag A. (Preferably, you'd still keep the old system, since for most purposes, names are just fine, but tags for when things start to scale.)

EDIT: Thinking further about these tags. Initially, I thought of tags as alternative names (or bynames) for the station, but perhaps instead they should just be signals. So if you had an iron mine, you could add a tag with the iron ore signal. You could add as many tags as you'd please. The reason for using signals would be to allow the user to control the tags with circuits. But wait, you say, if they are just signals, how can I tell my tags apart from provider and requester stations? You'd use the value. You could set your interrupt to go to station with tag with "<generic-item>" signal where value = 1.

I agree, I also feel station name exploit is hacky. At least I would like to have a wildcard like feature, but a better solution is... better
Tags (or station signals) open much more possibilities.
Like combinators that are able to choose from which (red or green) wire to read from, station could choose from which wire it should read signals to use as tags and which to send to train.

[Svip]

Like combinators that are able to choose from which (red or green) wire to read from, station could choose from which wire it should read signals to use as tags and which to send to train.

Personally I would prefer two areas for connectors on train stations, one meant for trains and one meant for the station. You can send signals to the train but also to the station through the same wires, and that's a little fiddly. Combinators has two areas for connectors (input and output), and it's 1 × 2, train stations are 2 × 2, some slightly modification of graphics (and code) would allow connections to either the train "combinator" or the station "combinator". Kind of sort of like how LTN does it.

[factoriouzr]

That's great that you can replace the icon in rich text but what if I use the name of the resourse such as "Iron Depot", "Copper Depot" instead of the icons.

Can we have support for replacing any text in the stop names instead of just icons? So you can do "[item] Depot" and replace "[item]" with "Iron" or "copper" or "gear".

[Qon]

That's great that you can replace the icon in rich text but what if I use the name of the resourse such as "Iron Depot", "Copper Depot" instead of the icons.

Can we have support for replacing any text in the stop names instead of just icons? So you can do "[item] Depot" and replace "[item]" with "Iron" or "copper" or "gear".

You want the PE Stringy train stops Redux mod implemented in vanilla? I would love that as well, but it's not going to happen. It is too hardcore for most players.

[kwyntes]

I'm not yet convinced that the new cool interrupt features allow us to completely control trains with circuits. The interrupts and the generic signals are very cool, but with generic signals only being able to take the signal type from inventory and not from combinators we can't tell trains where to go.

We know that interrupts can read signals from the station the interrupted train is parked at, and this FFF mentions an "any signal" signal for the condition. You can totally make a train go to station "[A]" by sending the [A] signal to its train stop. If you run out of signals, you can start naming your stations "[A] 1", "[ B] 1", "[A] 2", etc, with the downside that you'll have to duplicate the interrupt for any number you use (unless they add a replacement for the signal's value).
[/quote]

You're missing the point. If you start naming all your stations differently, you're just moving the problem. Now you're stuck with having to name every station differently and you can't generalise the station blueprint anymore.

[kwyntes]

Priority setting via circuts will finally allow balanced distribution of materials. I love it

From the screenshots it looks like you can't set the priority through signals though...

[boskid]

TrainStopCircuitControlGui was shown couple of times (https://www.factorio.com/blog/post/fff-384) but the priority setting was hidden because it would obviously leak that train stop priorities were added. As this FFF mentioned, there is a way to set a priority by circuit network.

110940.png (40.38 KiB) Viewed 1313 times

[ModernMythos]

My last attempt at a train-supplied mega-base was a mostly functional 60UPS, 2.5k science/per minute base, but the trains would sometimes stop in the path for seemingly no reason. Hopefully, the new logic for 2.0 trains will alleviate this because I ran out of ideas for how to fix it. I controlled the train network by reading the quantity of items in chests at dropoff stops and that value would determine how many trains were allowed at the stop. So I think that these trains must have been routed when the number of trains reduced at the destination stop and they would simply stop in place blocking traffic. It was the most elegant solution for train routing that I had come up with yet, but I haven't found a robust solution to date. The proposed changes should fix this, I am aiming for a train supplied 5k+ mega-base. I think this is very doable but haven't had resounding success yet.

Has anybody here had great success with a train-supplied mega-base? My biggest was 30k+ per minute and it was an unmitigated disaster complete with 150 train traffic jams and UPS dips below 10.

[Trific]

Lowering the train limit (even to 0) doesn't stop trains that were already en route from going to the station. My setup does that all the time. If the train stops with "No path" flashing, then my guess is the stations is getting disabled, not just the train limit being lowered.

[futurmagnussen]

I'm Lost

[Koub]

I'm Lost

You're here .

More seriously, I'm sure it'll all make sense to you once you'll get your hands on the actual feature yourself.

[adam_bise]

Man this is so awesome! Love it!

[crast_b]

In my factory system, trains are created for each demand, trip between two types of stations, so I don't think this update will have a direct impact on me.
However, I would like to suggest two points.


1: A train ghost set signals to red.

There is a risk that an unexpected connection or overwriting may occur if another train is passing at the point where the train ghost is placed at the same time as the train is being placed.
In my factory system, I use grid factory BPs where trains are packaged, additional space is required for separate tracks for train waiting. It's messy, but it worked.
However, with this update, the only way to place Train Ghosts together is to line them up horizontally. Placing trains in the limited spare space of a grid factory becomes difficult.
If a train ghost set signals to red, the risk is banished.


2: Each station can set a function icon in addition to the station name that can be freely written.

There's an argument about skipping the station. But, it's nonsense. because, station priority and same name station will be able to do skipping station with setting the lowest priority same name station. stations will need a little more space, but the design of the railway network itself remains unchanged.

The problem is that players need to master the system of the same name station. It is a certain constraint that the name of the station must be linked to the function of the station in terms of distribution.
If so, it should be possible to set the station's function by specifying an icon, independent of the station name. It should also be possible to set train schedules based on station function icons rather than station names.

It would be interesting to see that the amount of icons that can be set increases depending on the quality of the station.... Or that function icons can be controlled by circuits....

[mrvn]

Disabled train stops not being skipped is very nice, I previously had to add train stations with train limit 0 to get the same behaviour.
Also no need for the automatic trains mod anymore!

It's horrible. Where in 1.1 we have a choice between skipping a train stop and waiting for a slot to open that feature has now gone. This breaks peoples play style for no good reason.

Could a negative limit mean skipping the stop or something? Or does one have to covert all schedules with skips to purely interrupt based?

[FuryoftheStars]

Could a negative limit mean skipping the stop or something? Or does one have to covert all schedules with skips to purely interrupt based?

I think they want us to go the interrupt route. I guess we'll have to see what those conditions are to decide.

[Seraphendipity]

The 'No path' icon flashes to let you know that something is wrong. Destination full is just a solid icon shown in alt-mode. These should make it easier to tell at a glance what a train is up to, without having to do the mental pause to verify there is no flying text notification coming soon.

Problem being, it's still a Flash of ON/OFF, still requiring a mental pause (if shorter one), and a fair bit distracting (even if intentionally so). If I may suggest as small but meaningful changes:

• Flashing Icons (No Path, No Power, etc.) work like Missing Materials Flash (low contrast > high contrast, rather than invisible > visible).
• Options to reduce or turn off the Flashing Nature of all Icons (No Path, No Power, No Materials, possibly Entities taking Damage, etc.)
• Option reduce the size to "upper-right corner" of an entity (moreover for Assemblers).

The ideal solution IMO is the growing use of Status Lights on Objects, being such a great tie-in of in-universe, practical, unobtrusive, but still discernible with a way to translate a lot of vivid information with colors and patterns (blinking, fading, etc.) Second to that, UI icons that are of similar nature -- the main problem being they are annoying at the moment, especially when setting up factories that do not have power yet or depowered via Power Switches or mass blueprinting. The constant flash interrupts good focus.

[mrvn]

The 'No path' icon flashes to let you know that something is wrong. Destination full is just a solid icon shown in alt-mode. These should make it easier to tell at a glance what a train is up to, without having to do the mental pause to verify there is no flying text notification coming soon.

Problem being, it's still a Flash of ON/OFF, still requiring a mental pause (if shorter one), and a fair bit distracting (even if intentionally so). If I may suggest as small but meaningful changes:

• Flashing Icons (No Path, No Power, etc.) work like Missing Materials Flash (low contrast > high contrast, rather than invisible > visible).
• Options to reduce or turn off the Flashing Nature of all Icons (No Path, No Power, No Materials, possibly Entities taking Damage, etc.)
• Option reduce the size to "upper-right corner" of an entity (moreover for Assemblers).

The ideal solution IMO is the growing use of Status Lights on Objects, being such a great tie-in of in-universe, practical, unobtrusive, but still discernible with a way to translate a lot of vivid information with colors and patterns (blinking, fading, etc.) Second to that, UI icons that are of similar nature -- the main problem being they are annoying at the moment, especially when setting up factories that do not have power yet or depowered via Power Switches or mass blueprinting. The constant flash interrupts good focus.

Some way to say that "No Path" or "No Power" is a normal operations mode of the setup would be useful. This could even be automatic I think.

For example: An assembler on a power network with power switch doesn't need to blink "No Power". A far less intrusive power indicator would be preferable for those cases. An assembler without a power pole on the other hand clearly is wrong and should warn loudly.

Similar a train in the middle of the rails with no path is critical. SCREAM. But a train at a station that has no station with space is probably normal. Indicate it quietly (no Path at the station due to disabled stations is going away I believe so we will be spared that in the future).