Trains get stuck if the destination is disabled and other are full

[Ciubix8513]

Trains get stuck if the destination is disabled and other stations with the same name are full. Trains stop wherever they are, ignoring signals, which creates an unfixable deadlock.

2 trains blocking one of the entrances to the station

20220922231616_1.jpg (568.13 KiB) Viewed 9001 times

Disabled stations

20220922231626_1.jpg (475.34 KiB) Viewed 9001 times

Trains should treat full stations like disabled stations when path finding, so in this situation these 2 iron trains should go to the next station in the schedule

[Loewchen]

Trains should treat full stations like disabled stations when path finding

No they should not. The whole point of station limits is to hold the train until a station is available.

[Nosferatu]

When using the station limit you should not disable stations. Instead reduce the station limit to 0.

[boskid]

When i was implementing train stop limits i was aware it will not work nicely with enable/disable exactly because of that case but i kept it because it gives different behavior for controlling trains (allows trains to skip some schedule records instead of waiting). I guess i have enough of those issues, i will just get rid of the enable/disable entirely for 1.2 (it will be replaced with internally forcing limit to 0). There will be no longer "skip schedule record" behavior.

[ColonelSandersLite]

will just get rid of the enable/disable entirely for 1.2 (it will be replaced with internally forcing limit to 0). There will be no longer "skip schedule record" behavior.

Oh god, please don't do that. Especially not without talking to a lot of rail addicts about it first. I use that feature pretty much *all the time*.

[ColonelSandersLite]

When using the station limit you should not disable stations. Instead reduce the station limit to 0.

That's pretty much the answer, though it's noteworthy that there's a useful exception if you're following that rule -

You can disable a station in the situation that it's a station with a single train limit and the station gets disabled when the train does something at the station. In this specific situation, there isn't another train routing to the station anyways. I mainly do this for military outpost supply trains.

[mmmPI]

Trains should treat full stations like disabled stations when path finding, so in this situation these 2 iron trains should go to the next station in the schedule

I think the problem in this case is that the station for iron unload was opened without limit at some point, or as other mentionned that you try to disable it instead of reducing its limit to 0.

If you were to set a limit of 3 to the iron unload station, then you would never have 5 trains trying to path to it.

If you need to have 5 train running to that station to maintain throughput you may need to have room for 5 train to park without causing deadlock before that station.

Or you could do it with reducing the limit from 5 to 4 to 3 only when you read that "incoming trains" is decreasing ( meaning when a train unload, limit is decreased by 1 so that this train is not replaced when it leaves the unload, so that out of the 5 initial incoming train, you make sure only 3 max are parked when the limit reaches 3).

Disabling the station in your case would cause the 3 (or more ) incoming trains to cancel their planned stop, reducing that limit to 0 from 3 would cause all incoming train to park nicely in the stacker. Reducing the limit to 0 from 5 would cause 2 train to get stuck on the main lane but not suddenly, they wouldn't say "destination full" but instead would try to finish the schedule.

Another way to say : in the screenshot case , don't disable a station if there are incoming trains, you can read incoming trains from the train stop.

When i was implementing train stop limits i was aware it will not work nicely with enable/disable exactly because of that case but i kept it because it gives different behavior for controlling trains (allows trains to skip some schedule records instead of waiting). I guess i have enough of those issues, i will just get rid of the enable/disable entirely for 1.2 (it will be replaced with internally forcing limit to 0). There will be no longer "skip schedule record" behavior.

It would remove the possibility to have a train schedule looking like this :

Multi-Unload ( always enabled )
depart condition : [cargo empty]

Iron-load (enabled if iron < 100 ) => output N= 1
depart condition : [iron > 1000]

Copper-load (enabled if copper < 100 ) => output N= 1
depart condition : [copper > 1000]

Coal-load (enable if N >0 )
depart condition : [coal > 60] and [signal N = 1]
or depart condition : [coal > 120] and [signal N = 2]


This with the aim of having a train that picks up iron, AND/OR copper before picking up coal and bringing all the material to the unload. (That would be in the case of a dedicated steel furnaces + green circuit factory so that copper cannot be consumed without iron and cause a train bring too much coal.)

Possible outcome would be :

1) train picks up 1000 iron , then 60 coal
2) train picks up 1000 copper , then 60 coal
3) train picks up 1000 iron then 1000 copper , then 120 coal.

What i want to demonstrate with the example is that there would be no way to make a train "skip" a station with the limit set internally to 0 and then there would be no way to make a train sometimes having 2 sometimes having 3 stops in their schedule even if all loading station were named the same.

One could think of another example where a train goes pick up stone, or uranium, but when picking up uranium the train needs to bring a few barrel of sulfuric acid first and require in this case an extra step in the schedule. Either 1 loading area, or 2 before unload.

I would miss that behavior even though i'm not using it "all the time" , not every cases where i use it can be easily replaced if the limit was set internally to 0, i find it useful to have the choice between the 2 behavior.

[astroshak]

When i was implementing train stop limits i was aware it will not work nicely with enable/disable exactly because of that case but i kept it because it gives different behavior for controlling trains (allows trains to skip some schedule records instead of waiting). I guess i have enough of those issues, i will just get rid of the enable/disable entirely for 1.2 (it will be replaced with internally forcing limit to 0). There will be no longer "skip schedule record" behavior.

I like having both Enable/Disable, and the Train Stop Limit. Removing one or the other would be detrimental IMO.

I have not looked at the train tutorials lately. If it’s not there, then something about not combining limits and enable/disable in the same train schedule should be. Also, when using enable/disable, one station on that route MUST remain ON AT ALL TIMES without limits should also be in the train tutorials somewhere.

The issues that aI use come from people blindly assuming that the two systems work well together, when they honestly do not. However, they work well in parallel, for different trains on the same tracks.

It’s just an issue of informing newer players about the limitations of both systems, more than anything else.

[mrvn]

When i was implementing train stop limits i was aware it will not work nicely with enable/disable exactly because of that case but i kept it because it gives different behavior for controlling trains (allows trains to skip some schedule records instead of waiting). I guess i have enough of those issues, i will just get rid of the enable/disable entirely for 1.2 (it will be replaced with internally forcing limit to 0). There will be no longer "skip schedule record" behavior.

I like having both Enable/Disable, and the Train Stop Limit. Removing one or the other would be detrimental IMO.

I have not looked at the train tutorials lately. If it’s not there, then something about not combining limits and enable/disable in the same train schedule should be. Also, when using enable/disable, one station on that route MUST remain ON AT ALL TIMES without limits should also be in the train tutorials somewhere.

The issues that aI use come from people blindly assuming that the two systems work well together, when they honestly do not. However, they work well in parallel, for different trains on the same tracks.

It’s just an issue of informing newer players about the limitations of both systems, more than anything else.

But they do work well together.

If all stations are disabled then trains will skip the station in their schedule. If all enabled stations have reached their train limit then trains will stop with "destination full".

The problem of trains stopping mid track only arises when you disable a station that has a train coming in, have other stations enabled but they are all at their limit.

You can use enable/disable with limits provided you either
a) always have some station with open slots remaining
b) only disable the station when it's train count is 0 (which needs to first set the limit to 0 and then disable to avoid races)
c) disable all the stations with the same name (which is mostly for when you only have one station with that name)

Note that case (a) does not skip the station while (c) will skip the station. (b) may skip the station if it ends up with all stations disabled. A station with limit 0 will not allow skipping. So there is a real difference between limit 0 and enable/disable.

[Loewchen]

But they do work well together.

Note that case (a) does not skip the station while (c) will skip the station. (b) may skip the station if it ends up with all stations disabled. A station with limit 0 will not allow skipping. So there is a real difference between limit 0 and enable/disable.

That is not what i would call "working well together" :) It's more like it is possible to use both but you need to go out of your way to prevent a blockage of your whole train network when doing so.
I'd love for the Disable feature to be replaced with a general Skip condition in the train schedule.

[mrvn]

But they do work well together.

Note that case (a) does not skip the station while (c) will skip the station. (b) may skip the station if it ends up with all stations disabled. A station with limit 0 will not allow skipping. So there is a real difference between limit 0 and enable/disable.

That is not what i would call "working well together" It's more like it is possible to use both but you need to go out of your way to prevent a blockage of your whole train network when doing so.
I'd love for the Disable feature to be replaced with a general Skip condition in the train schedule.

They work well together in the sense that each alone and in combination they let you produce the exact behavior you desire. You just might have to use few of circuits for the more complex cases. Neither feature overrules the other and their combination offers up new possibilities.

We all would love one of the many skip condition proposals. That's why there are so many of them.

[Tertius]

There will be no longer "skip schedule record" behavior.

Please don't remove this ability to skip a schedule record. It's useful, because trains don't have to drive through a station but can instead skip directly to the next scheduled station. So they can overtake other trains.
Or if you must, please give some replacement functionality. For example, move this to the train schedule. Add a yes/no checkbox in a schedule entry (the station entry, not a wait condition entry) to make a train skip this entry, if its train limit is 0. Or add a skip condition as wait condition that accepts a circuit condition, where the train limit and station id of that station is provided as some virtual signal. Or attach this condition to the station entry, because that skip condition is not really a wait condition - it's only valid if the train is about to leave/repathing.

[robot256]

I agreee with Tertius. Mrvn's explanation of how to use Limits and Stop Disable together simply shows that the Disable logic should be moved to the train instead. Disabling stops is now only a hack to enable conditional schedules.

There are a thousand ways to imagine vanilla schedule branching working. For example, each schedule entry could include an optional "skip count signal" selection, which it will read from the train stop just before departing, telling it how many extra schedule entries to jump ahead by. This would give similar uses, and ensure that destinations remain static while the train is in motion.

[ColonelSandersLite]

I would miss that behavior even though i'm not using it "all the time" , not every cases where i use it can be easily replaced if the limit was set internally to 0, i find it useful to have the choice between the 2 behavior.

I can give 2 very simple and one *slightly* more complex use cases that I'm using in every base besides some of my *really* old ones.

First - My military outpost supply trains

Code: Select all

Military Supply Loading (always enabled)
   Full cargo

Military Outpost (limit 1, enabled only when supplies needed)
  inactivity

Military Outpost (limit 1, enabled only when supplies needed)
  inactivity

Military Outpost (limit 1, enabled only when supplies needed)
  inactivity

Military Outpost (limit 1, enabled only when supplies needed)
  inactivity

Military Outpost (limit 1, enabled only when supplies needed)
  inactivity

This setup means that my supply trains can zip around and provide supplies to up to 5 outposts and then return home to pick up more stuff or idle waiting for another supply request.


Second, I use a nearly identical setup for train fuel deliveries. A special train can zip around the factory delivering train fuel to various production sites and then it comes home to resupply or idle.


Third is a basic system I use to summon and dismiss various construction trains when I want them.

I have several permanently disabled stations to prevent the automatic train schedule altering thing when you rename the last station.

Build Site Main, Build Site Solar, Build Site Mixed Mason, Build Site Bricks, Build Site Concrete, Build Site Garbage Collector.

At the build site, I just change the name of the station to summon all relevant trains which will automatically cycle between the build site and their home. Rename the station to something else and all those trains go home to wait for the next job and the newly ordered trains are summoned. Rename the station to x or disable it to just send everything home.

[mrvn]

Or you use it to prioritize:

Code: Select all

Coal Mine (limit 1, always enabled, train idles here)
  full

Power plant (limit set by free space in chests, enabled only when limit > 0)
  empty

Smelter fuel (limit set by free space in chests, enabled only when limit > 0)
 empty

Now whatever station needs coal gets the train moving. But if there is a coal shortage and everyone needs coal then the power plant gets priority. Actually all coal delivery to smelters is paused while the power plant is short of coal.

[causa-sui]

will just get rid of the enable/disable entirely for 1.2 (it will be replaced with internally forcing limit to 0). There will be no longer "skip schedule record" behavior.

Oh god, please don't do that. Especially not without talking to a lot of rail addicts about it first. I use that feature pretty much *all the time*.

[mmmPI]

fixing_problems.png (15.39 KiB) Viewed 8027 times

If it ain't broken don't fix it.

It is a normal experience to make mistake when using something one is not familiar with, however once you understand how to use the limits then you don't do those mistakes anymore.

Hopefully it is not necessary to get rid of one functionning system because sometimes it is not properly implemented by some players.

[aka13]

When i was implementing train stop limits i was aware it will not work nicely with enable/disable exactly because of that case but i kept it because it gives different behavior for controlling trains (allows trains to skip some schedule records instead of waiting). I guess i have enough of those issues, i will just get rid of the enable/disable entirely for 1.2 (it will be replaced with internally forcing limit to 0). There will be no longer "skip schedule record" behavior.

Will there be another mechanism to skip stations? That was pretty useful in some edge-cases.

[MrGrim]

While it doesn't need to remain in its current form, the ability to skip scheduled stops shouldn't be sacrificed over this. There is an opportunity here, however. A way to solve the weird interaction, the confusion, and keep the functionality we want.

I was discussing on the Discord server the concept of a fuel depot, and the problem of conditionally sending trains to such a thing was part of that discussion. How to send an arbitrary number of trains to a station while having the rest skip it. No combination of limits and disabling can achieve this. The current system allows some specific cases to work, but completely fails to handle others.

Instead, allow the following:

• For each item in the schedule, allow a circuit condition to be set to include that item in the schedule.
• For each station in the world, include the option to send a signal to the schedule of the currently parked train.
• When a train meets its conditions to leave its current station, if the station is sending a signal to the schedule, filter the schedule based on the signal and the conditions.
  • If the schedule item has no condition, it's always included.
  • If the schedule item has a condition and the condition matches the signal sent by the station, include it in the schedule.
  • Otherwise, do not include this item in the schedule.
• If the train meets its conditions to leave its current station, and the station is not sending a signa to the schedule, consider the complete schedule.

Now the train goes to its next stop in the resulting schedule.

I hope you can see how this provides a vast amount of flexibility in a way that doesn't conflict with other trains mechanics, including limits, and keeps everything useful about the enable/disable ability!

Thanks!

[Deadlock989]

I guess i have enough of those issues, i will just get rid of the enable/disable entirely for 1.2 (it will be replaced with internally forcing limit to 0). There will be no longer "skip schedule record" behavior.

Please reconsider.