[2.0.20] Rail network stuck after "fix"

[Wackerstamfer]

bugfix in question: Fixed stations getting skipped when using the 'Destination full' condition for interrupts.

as reported in detail by TrooperTony viewtopic.php?p=642560#p642560

Trains at depot are now stuck waiting for next station in list to become available, forcing equal visits along all stations. This limits the use of the smart depot interrupt.

Please revert or add the following logic:

Interrupt:

if at station : "depot"
AND destination is full

Target,
go to next in list

previously working setup:

[robot256]

Stations that should always be visited go in the main schedule.

Stations that might need to be skipped go in the interrupts.

You need to revise your system to account for this.

[ejg]

That is not as described in the FFF I think?

[Tobias1595]

The main argument brought up in TrooperTony's post is that the new behaviour is in conflict with what FFF-389 and FFF-395 show. I believe that the setup in these FFFs has been misunderstood.

The setup that Wacker presented has separate station names for each individual item's loading station, and therefore has a main schedule with multiple entries. The FFF posts both show schedules where all "pickup" stations use one and the same name, "Item Input", creating main schedules with only a single entry each.
This setup in these FFFs is a deliberate choice, not just a shortcut to make the images more presentable. A common name for item pickup stations allows all cargo trains to approach any of these stations in any order. The interrupts are used to afterwards direct trains to the correct dropoff point for whatever items they happen to have picked up.

Another form of interrupt usage is the setup from "The Depot Problem" of FFF-389, with an interrupt that sends empty trains to a depot if their destination is full. The intent behind this depot is not to make the train skip the full stations. Trains in the depot are still supposed to wait for their original destination to open up again. Instead, as the FFF describes, the intent is to have empty trains leave the unloading stations quickly, so other trains can start unloading sooner.

The original bug didn't become apparent in the FFF setups, because skipping the only entry in a single-entry-schedule changes nothing. A duplicate of the original bug report (116850) shows a realistic setup with two regular stations and a depot interrupt, and rightfully complained about stations getting skipped if the interrupt was triggered.

In FFF-395 there is also a small FAQ with two questions, the answers to which imply that skipping stations is not intended any more. The new, general 2.0 logic is that stations in the main part of the schedule will always be visited in order. The whole system is easier to understand and work with if there are no exceptions to this rule.

In summary, skipping stations from the main schedule is not intended any more at this point. Interrupts are additions to the schedule, not replacements. That is the new norm for 2.0. Therefore...
"Forcing equal visits along all stations" of the main schedule is not a bug, it is intended behaviour.
Skipping stations by using a "Destination full" interrupt was a bug, so it got fixed.
Adding an option to explicitly skip main schedule stations is not a bug, it is a feature request.

[Wackerstamfer]

Thank you for the concise reply and clarifying intended behavior.

I agree that in that reasoning this report is indeed not a bug.

Intended behavior was however not clear before and the fix was game-breaking in my case hence the report. The reasoning on my part for stations with distinct naming instead of one general pick-up is that you retain the option to send trains to a specific pick-up location. Feature request go to : Ideas and Suggestions ?

[sanctus2099]

The fix is game-breaking for me as well. The whole setup was based on this behaviour. At the moment I'm not updating past 2.0.15.

I get that it was maybe an incorrect behaviour but forcing all pickups to rely on something generic is more limiting than the previous behaviour.

[TrooperTony]

My main argument for my post is the regression caused by a change of behavior. The references to the FFF are to explain how I ended up with my set up (which I indeed misunderstood at second glance).

In 2.0.15 I had a functional base, in 2.0.20 I do not. I am unable to load my save in an older version directly. I can see how updated behavior is the intended simpler design but this behavior was not part of the 2.0 release. I am disappointed my set up in an existing game of 50+ hrs broke by a minor (automatic) update.

As an aside, the old behavior gave me two benefits. Firstly, it allowed me to convey information in the station name. Instead of having an identical name for all provider stations. Secondly, I could have dedicated train groups for ores. Next to this I have a train group for generic items. This group could also pick up ores. The majority of the time the dedicated ore trains manage all ore, but if throughput becomes demanding the generic trains will be drawn to help out.

[mathSq]

I am glad the fix was made, and would also support, as an added feature, an option to have the behavior TrooperTony relied on, where an interrupt causes the train to skip the stop from which the interrupt arose.

I think interrupts should by default act like they do in 2.0.20, because that makes all the interrupts consistent. Before 2.0.20, I tried to design a train schedule, which did not work as I expected because the "Destination full" interrupt didn't act like the others do. I agree with TrooperTony that there's a use case for the prior behavior; in fact, I might use it in my next train system so that I can have generic trains while naming pickup stops by resource. But it should be an option, not the default. The default should be for all interrupts to act the same, as they do in 2.0.20.

[Chindraba]

As an aside, the old behavior gave me two benefits. Firstly, it allowed me to convey information in the station name. Instead of having an identical name for all provider stations. Secondly, I could have dedicated train groups for ores. Next to this I have a train group for generic items. This group could also pick up ores. The majority of the time the dedicated ore trains manage all ore, but if throughput becomes demanding the generic trains will be drawn to help out.

The first point is one I am still unsure I'm willing to give up. My station names convey loads of information and some "generic" name kills that like a nuclear missile.

The second point, however, I have an (untested) thought about. The non-ore trains presumably would only help the ore trains when they we otherwise under utilised. To make them do that in the new system you could include an interrupt which detects their available-to-help status, and the ore system's under performance, and inserts an ore-train's schedule into the generic item train's schedule. The spare trains would then, as available and needed, make a single ore trip as per the interrupt, and then continue their normal duties as if nothing happened.

[Tallinu]

You don't have to give all item pickup stations the same name. In fact I think it's better not to.

For example, I have separate train groups for iron, copper, coal, stone, and uranium. Each group's schedule has a pickup station and a dropoff station, such as "Copper Pickup" and "Copper Dropoff". This guarantees that a certain number of trains will be transporting each resource.

Having all trains use the exact same "item pickup" station name could potentially result in the factory being starved for, say, iron just because my copper mines are closer and/or produce faster, for example, leading to all trains filling themselves up with a load of copper and then sitting in my depot waiting for the copper dropoff station to have room for more, and meanwhile the iron buffer has emptied out so the copper isn't being consumed because both are needed for most things, potentially deadlocking the overall system.

Before this fix, an interrupt which allows the train to go somewhere specific to wait for its next stop to open up had to be created using "(specified) station is full" and "(specified) station is not full" conditions, which meant you needed a different interrupt for every different station name. For my setup that meant two interrupts for each train group, ten in total.

After this fix, one interrupt is all that is required for all trains, because you don't have to use conditions that require selecting a specific station.

If you want your train to optionally visit certain stations if they are not full and skip them if they are, you can set this up by creating an interrupt for each of those stations instead of putting them in the fixed schedule: "Has cargo" or "item count > x", and "(specified) station not full" conditions. Put one entry in the fixed schedule for where the train should pick up its cargo, or you could probably use an interrupt for that too, using "cargo empty".

If you're trying to do it the other way around, with a train picking up cargo from several uniquely named locations and bringing it to one fixed dropoff point, just flip the "has cargo" and "empty cargo" conditions around. Heck, you could probably have one train picking up from multiple places and dropping off at multiple places by creating an interrupt for each of those stations, although if you're doing something like that I don't know why you wouldn't just give them all the same name so you only have to create one entry for pickup and one for dropoff...

It does seem like there needs to be a wait condition to match the "Destination full or no path" trigger, just like there is for the "(specified) station full" trigger and wait conditions. Right now, trains waiting at the depot on a "Destination full or no path" interrupt are constantly flickering their lights as they go in and out of the interrupt constantly. They're a lot more chill about the situation when using the "(specified) station full" trigger with the "(specified) station not full" wait condition. We need a "Next station full/not full" wait condition that just checks whatever the next station in the schedule happens to be.

[custodia]

Personally I’m glad this got fixed but I feel the pain for everyone who’s bases got messed up by this.

But I do agree with the poster above that you don’t have to name all the pickup stations the same. I personally named all my stations ”x pickup” or ”x dropoff” and I’m using a wire signal to send all possible resources with train stops to the train paired with a parametrisized interrupt schedule. With this setup I always have to have my trains go back to a train depot after dropofff but they automatically go from there to deliver any resource that has a free pickup and a free dropoff station available.

[JustBlue]

In summary, skipping stations from the main schedule is not intended any more at this point. Interrupts are additions to the schedule, not replacements.

"Forcing equal visits along all stations" of the main schedule is not a bug, it is intended behaviour.

I don't understand why removing the ability to skip stops in the main schedule was a goal in the first place. Skipping main stations has a use case that interrupts just don't provide. Deactivating a station now completely blocks any train with that stop in its route. This is a regression from old functionality that removes flexibility from the rail network. Why force players in this direction when it was previously optional? This intended behavior makes it impossible to do on demand delivery in a reasonable way.

What do I mean by this?

Previously, deactivating a station allowed a train to ignore a destination it did not need to travel to. You could set up a circuit network that observed the contents of the chests at an unloading station, and logic would enable or disable that stop. When a stop was disabled, trains in that route would skip it and go to the next, or if all stops were disabled, it would wait until one became available and go straight there. Thus, the train would only run when it needed to run and it would consume the minimum amount of fuel by not wasting time on traversing to unneeded destinations.

For example, in one of my saves I have eight defensive walls built at choke points around the map, each with their own train stop. I have a train which I want to use to deliver ammo and supplies to the walls, but only when a resupply is needed. I want this train to wait until an unloading station at one of these walls has less than 1k bullets in its chests (the buffer) before leaving. I want the train to go to only the stations where the bullet count dips below the 1k buffer, and avoid the stations that are above this buffer. This behavior was possible when disabled stations were skipped, and it was easy and simple to understand and set up. It is not possible anymore.

The only solution currently is to send the train to every unloading station anytime one needs a resupply. While this works, the walls are dozens of chunks away and with 7 to 8 stops it becomes ridiculous for this train to traverse the entire map simply to resupply the final stop in the route. With previous behavior, disabled stops would allow it to skip straight to the last station and then back to the loading station. Or, to stop at two stations along the route instead of all eight, etc.

An alternative is for me to make a separate train for every wall, and create an 8 lane parking yard for them, but this is equally inefficient and ridiculous. I need a new train for every new wall. I also now need 8 trains when the volume I am consuming across all walls could be handled by one.

I tried looking at a way to implement this with interrupts, but the only way I could think to do so was to have each wall represented as a separate symbol on the logic network, and trigger the interrupt on that specific wall's symbol being > 0. At the pickup station, the train would interrupt to the wall it needs to visit upon receiving that symbol. However I need an interrupt for every station now, and using interrupts in this way is replacing the main stops, which according to what you are saying is not what interrupts are meant for. I agree, because this solution is ugly and isn't very scalable, especially if I want to implement similar behavior with other stations connected to the same logic network. I would need to assign a symbol to every train stop I create unless I physically separate the logic networks between each route, with separate lines of power poles running across the map.

How am I supposed to do the above in a reasonable way, with current functionality?

Also, a more generic and simple example:
I would like to be able to prevent my trains from driving to a station unless it can fully unload. I can calculate this by taking the total amount of a resource that all of the station's chests can hold, and subtracting how much a wagon can hold. If the value dips below this, a train can fully unload there. Previously, I would watch the chests with logic and keep the station disabled until I had enough space to unload a full train car into the chests. I cannot do this anymore in a rail network that has more than one unloading point. Schedule logic only allows you to check if the station is not full, not if there is enough space to unload X amount of a resource.

There are also situations where you might be transporting one wagon half full with item A and half full with item B. Or 1/4th item A and 3/4th item B. With reserved item slots in a wagon, there's many possibilities that "station full or not" doesn't cover. How are you supposed to know if that train can fully unload? Logic used to provide an elegant solution, but now you'd have to pipe logic across your base to get it to the train itself, to fire an interrupt. Each interrupt would use up one or more logic symbols no longer usable in a base-wide network. You'd also need to send this logic to every station that applicable trains may be sitting at. Previously, calculations could simply be done locally, and the station could just be enabled or disabled...

Stops in a main schedule should be skippable. If someone wants their train to equally visit all stations they can still set up the rail line to do this, by not disabling stops. It makes no sense to force uniform train stop visits upon players, and this is why people were upset with the bug fix. I've looked over the FFF articles you linked and it doesn't not make mention of the change to train stop enable/disable state. Interrupts should be used for the ability to include an additional, infrequent station in the schedule. A refueling depot trains can go to when their fuel gets low is perfect for this. Interrupts do not and should not replace skippable stations.

[Nemoricus]

Stops in a main schedule should be skippable. If someone wants their train to equally visit all stations they can still set up the rail line to do this, by not disabling stops. It makes no sense to force uniform train stop visits upon players, and this is why people were upset with the bug fix. I've looked over the FFF articles you linked and it doesn't not make mention of the change to train stop enable/disable state.[/u]

https://factorio.com/blog/post/fff-395

Heading: Does it still skip if I disable a stop with circuit network?