[0.11.22] Train still but not "stopped"

[Dev-iL]

Description:
Inserters cannot interact with a train standing in a station, when said train has a non-existing stop as its next destination.

How to reproduce:
1. Build a circular rail with two stops (say "stop1" and "stop2").
2. In stop1, place a crate with some fuel and an inserter which should refuel the locomotive when stopped.
3. Set a path where the train goes to both stations and spends 0 time in each, and let it run.
4. After the train leaves stop2, pick up ("mine") stop2.
5. The train then reaches stop1 and becomes "still but not stopped", and the inserter cannot place fuel in it.
6. If the missing station is removed from the drive-plan, the inserter can now place the fuel in the locomotive.

Here's a savefile which reproduces this:
http://s000.tinyupload.com/?file_id=306 ... 8850226509
(mods: WaiTex 0.5.0 + test-mode 0.11.7)

In my opinion, a good fix is such where inserters could simply interact with moving trains.
(I think that the current behavior/bug is caused exactly because this was something the devs didn't want).

[sillyfly]

I believe this is by design. I personally wouldn't want inserters to take out of train/insert into train if it simply stopped near a station because of a signal.

[OBAMA MCLAMA]

I believe this is by design. I personally wouldn't want inserters to take out of train/insert into train if it simply stopped near a station because of a signal.

Stop1 is part of the trains schedule he is saying, but the next stop (the previous stop) he "mined" so the next stop no longer existed.

This does strike me as a bug. have you tried it with 3 stops?

[sillyfly]

But the train already 'left' the station, it is merely paused because the next one is unavailable.
I think it comes down to this question - do you want the train to go to the next station as soon as it is re-added to the network, or start counting again in the current stop when the next one is re-added?

[Dev-iL]

This does strike me as a bug. have you tried it with 3 stops?

Just tested this - there's no problem with 3 stops. I think this bug only happens when:

• There's more than 1 stop in the list, and
• Only a single stop in the list is valid.

I saw the same behavior when having >=2 copies of stop1, with nothing else on the list.

[kovarex]

Hello, this is fixed for 0.12.3