[kovarex] [0.17.3] Train leaves disabled station

[Barnum]

I wasn't sure whether it is a feature or a bug, but after reading through, the decision is to revert it to the 0.16 behaviour:

- Disabling station with train waiting in it doesn't force the train to departure anymore so it works as it worked in 0.16.
It looked like a useful change for 0.17, but we can control train conditions by circuit network and there are some
nice and simple usecases were ruined by trains being forced to departure when the stop is disabled. (65109)

So fixed for 0.17.9

I'm a bit sad that this bug/feature had to go. It was the only way to make a train leave without moving forward through the schedule. This allowed for trains to unload partially at several 'unload' stations and then move on to a load station. However, I understand the decision to go back to the old behavior.

I don't know how much more attention this will get now that it's already officially resolved, but as someone who is happy to see the .16 behavior made the default again I also see a lot of fun and interesting possibilities for the original .17 behavior. Maybe it would be possible for stations that have enable/disable conditions to also get a "Train departs when disabled" checkbox so the original .17 behavior could be used where desired?

[wolletd]

I wasn't sure whether it is a feature or a bug, but after reading through, the decision is to revert it to the 0.16 behaviour

I don't know how much more attention this will get now that it's already officially resolved, but as someone who is happy to see the .16 behavior made the default again I also see a lot of fun and interesting possibilities for the original .17 behavior. Maybe it would be possible for stations that have enable/disable conditions to also get a "Train departs when disabled" checkbox so the original .17 behavior could be used where desired?

If in doubt about "feature or bug", make it an option

[gridstop]

Couldn't you easy support both schemes if when using a signal to enable/disable the stop you also send it to the wagon for conditions (just OR your wait condition with the inverse of the stop disable condition)? Or automatically generate a new 'this stop disabled' and/or 'this stop enabled' signal you just always send to the train that always tells it the current state of the stop. Or even add a 'stop disabled' wait condition (wait until cargo full OR stop disabled).

[Kermitz]

Fix didn't work for me, just tested with Version 0.17.9 (build43513, linux64, alpha)
encountered the same train misbehavior than the previous 0.17 Versions

[Barnum]

Couldn't you easy support both schemes if when using a signal to enable/disable the stop you also send it to the wagon for conditions (just OR your wait condition with the inverse of the stop disable condition)? Or automatically generate a new 'this stop disabled' and/or 'this stop enabled' signal you just always send to the train that always tells it the current state of the stop. Or even add a 'stop disabled' wait condition (wait until cargo full OR stop disabled).

What you're proposing is just another way to fulfill the conditions of the stop so the train moves to the next stop on its schedule; what was actually so interesting about the original .17 functionality is that the train wouldn't go to the *next* stop on it's schedule if the station was disabled, it would look for another station with the same name as the current one and go there.

[knightelite]

Fix didn't work for me, just tested with Version 0.17.9 (build43513, linux64, alpha)
encountered the same train misbehavior than the previous 0.17 Versions

Did you do a clean install? It did work correctly for me (at least the reproduction scenario I posted on the first page of the thread no longer functions incorrectly). Using steam version on Windows 10.

[5thHorseman]

I wasn't sure whether it is a feature or a bug, but after reading through, the decision is to revert it to the 0.16 behaviour:

- Disabling station with train waiting in it doesn't force the train to departure anymore so it works as it worked in 0.16.
It looked like a useful change for 0.17, but we can control train conditions by circuit network and there are some
nice and simple usecases were ruined by trains being forced to departure when the stop is disabled. (65109)

So fixed for 0.17.9

I'm a bit sad that this bug/feature had to go. It was the only way to make a train leave without moving forward through the schedule. This allowed for trains to unload partially at several 'unload' stations and then move on to a load station. However, I understand the decision to go back to the old behavior.

I'll simply leave this here;
https://xkcd.com/1172/

Amusingly they could have posted this in response to the original bug report.

[Kermitz]

Fix didn't work for me, just tested with Version 0.17.9 (build43513, linux64, alpha)
encountered the same train misbehavior than the previous 0.17 Versions

Did you do a clean install? It did work correctly for me (at least the reproduction scenario I posted on the first page of the thread no longer functions incorrectly). Using steam version on Windows 10.

A clean install didn't change anything, but when i updated my map from version 16.51 instead of 17.06 to 17.9 it worked.

worked for about 10 minutes than they began to leave their stations again.
I don't really understand why they behave like this, they all left their station at about the same time,
~500 Trains with completely different schedules, stations and circuits...

[adblockplus]

I'll simply leave this here;
https://xkcd.com/1172/

Which could as well be said for the original bug report

[Khaylain]

I'll simply leave this here;
https://xkcd.com/1172/

Amusingly they could have posted this in response to the original bug report.

-------------

Which could as well be said for the original bug report

Which was the whole point; see relevant xkcd.

[5thHorseman]

Which was the whole point; see relevant xkcd.

*checks to make sure it's the one he's seen 1000 times before. Yup. It is.*

In that cartoon there is a clear correct side and incorrect side. The correct side wants to not overheat the cpu. The incorrect side wants to.

In this case, there are arguments for both sides. Neither is wrong.