Ciubix8513 wrote: ↑
Thu Sep 22, 2022 8:42 pm
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.
boskid wrote: ↑
Fri Sep 23, 2022 3:54 am
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.