[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.