Trains get removed from request schedule due to bug

There is a difference between the first 2.
In the first one the train is interacting with the station,
but in second one the train just paths through it &
doesn't interact with the station.
They can't be implemented at the same time,
without adding some form of behaviour selection.

nope the previous fixes of finding a station with a non-integer request didnt' fix the bug

you know

it's quite strange how it ALWAYS and ONLY happens to this station. now that I think about not a single other station which is configured to supply rock with >3 train requests does this. I wonder if demolishing and rebuilding the station would be suitable here

galdo145 [discord] wrote:

if there is no station able to accept them, what are they supposed to do? in F they will skip that train stop, and go to the next one on the list...

why would they even be dispatched if there is no station to accecpt them

and any train which is dispatched should go to the station it was dispatched to, rather than halting on the main line

you guys did arrive at similar conclusions as part of the other discussion

slopth [discord] wrote:

why would they even be dispatched if there is no station to accecpt them

That can happen due to arrival conditions being fulfilled by other trains,
while this train is traveling to it.

The train should still arrive at the station

The train does not just randomly stop

I run like 12 lines that work this way

They all work

Except this one station

eryk500 [discord] wrote:

That can happen due to arrival conditions being fulfilled by other trains,

Hitting this now too.
Does it mean that any station with request condition of "All modules empty" or "Any modules empty" need yo have a train limit one to prevent this ?

Yeah, otherwise this will trigger the highly undesirable behaviour mentioned in this thread multiple times.

The perfectly safe value in every situation is 1
(especially if your train station is shorter than your train);
if the station matches the length of trains then you could potentially put it to 2
(because the capacity of a module is always 2x the capacity of a cargo wagon);
and extrapoliting this, you can put the train limit higher for even longer train stations.

I really hope they change CoI to only stop and wait for a station to start moving to happen at stations. Its ok to change station if a higher priority one comes up in route, but should not just stop while on the tracks. I would much prefer that destination station ONLY get chosen at the prior stop.

IMHO, only if the station become unreachable should the train change destination or stop on tracks.

Changing routes is what makes CoI great. that allows to deal with traffic situations.

I have worked around this bug by having single train lines for low use materials or two trains on lines where the station modules match the car count.

hreintke [discord] wrote:

Hitting this now too.

limit of 2 works fine

I have not tested with office train capacity buff

you run into throughput issues when you have lots of trains and\or long distance and want to increase throughput of a station, as the loading throughput of a station is faster than what 2 arriving trains can saturate

many of my stops from the big mines can have 4, 5 incoming trains

and doing it this way means you don't need to build large stackers at these stations and can run a slightly tigther logistic network due to not having stale stations requesting a ton of trains that aren't needed if you were to configure with "unrestricted"

I also haven't tested with pull-through behavior either, where a single train could potentially empty a station

so I suppose the more better answer is as long as incoming capacity is less than station capacity you're fine

if incoming capacity is more than station capacity, the bug seems like it will appear

I'm surprised the megabase guys moving 10 bazillion rock aren't encountering this issue

unless they're just running unrestricted supply and demand stations

I wouldn't classify this as "good design". That is just asking for train pile-ups.
That being said, if you think that you can get away with this, then you do you.

All that I say to this is that one shouldn't use their "mainlines" as storage for trains.

That's not what I'm saying though

Any system sufficiently designed doesn't need to worry about backups

You only need space for (x-2) trains, and that can be shared among the stations. If there is enough throughput there isn't any fear about it backing up

And you only need stackers at the other end of the line where the trains do wait for the next job

I've considered this further, and experimented, and I think you're both describing real issues, but talking past each other a bit.
eryk - Your solution works, and is what I do as well; but I cant help but admit it's more treating the symptom. Why should a train that was validly dispatched suddenly lose its destination just because other trains got there first? That's not a configuration issue beyond the fact is produces this result, that's the scheduler making questionable decisions mid-route. Its obvious to me now, that we need an alternative, that isn't currently possible.
lowstrife's network design seems actually quite efficient for high-throughput scenarios, its only flaw is it isn't possible. The problem isn't the setup - it's that the game is cancelling valid assignments instead of honoring them through to completion for whatever reason, right or wrong. Its not like they are losing their assignment while in parking - that is possible - but it is that they are losing it while on main lines.
Real question: What's the design intent here? Should trains complete dispatched journeys, or should the scheduler be allowed to strand them mid-network? And if so what are the argument for why? why not continue? and why not proceed home or on the route. Because right now it's doing the latter, and that seems... suboptimal and prone for Users to get frustrated/confused.

I've been experimenting too.
Not clear yet in what circumstances the re-evaluation is done.
I have a rather long line, uranium ore -> nuclear, that has now 4 trains, train limit 3, request when all modules empty.
As far as I see now, that runs OK, but (regularly) has a train stopped.

Checking in the code when/how that happens.

I have noticed that most times the second train does not get stopped. Normally had second train show up and processed even though the first train filled the request and everything works.. Its just every so often the second train is stopped on the tracks and gets the "Conditiona are not met" message and clogs up traffic. I now watch my Steel count as it seems to be the first to show a train bottleneck happened from a random train going senile and forget what to do.

Yes, that's the same behaviour as I see.

Today I had one get "Conditions not Met" and stop halfway into the station it was delivering.

Does anyone have a save I can load which reproduces this issue if I don't press any buttons?

ie. when you notice it happening, go back to the last autosave, leave the game running with no interaction, and if it happens again, I can use that autosave to reproduce it easily!

It seems to be a fairly rare issue, so to fix it it'd really help to have something where we can just load, run forward, see the issue appear.

Next time it happens i will make a save. It only happens every hour or so

To be clear: a save before it happens would be most useful

In other words, when you notice it, going back to the last autosave and checking that that reproduces the issue without any further inputs from you.

Will do