[2.0.20] Train skips temporary train stop if new temporary stop is added

[Halosos]

Pre 2.0/space age behaviour:

Place stop 1, train begins moving to stop 1.
Place stop 2 before train has reached stop 1.
Train continues to stop 1, then proceeds to stop 2.
You can queue up temporary stops

Current behaviour:

Place stop 1, train begins moving to stop 1.
Place stop 2, train skips to stop 2.
Train will move to stop 2, it will then go to the next station in its schedule, never going to the temporary stop 1 until it gets back to that spot on the schedule.

Trains will skip what ever temporary stop it was going to when you place another. You can no longer intuitively queue stops, such as que stop 1 for the player to enter and stop 2 for the player to exit without going through more steps.

[robot256]

Confirmed that this still happens in 2.0.20. To be clear, the manually-created, rail-entity temporary stop is still added before any permanent station in the schedule the train is currently at or pathing toward. But subsequent manual temporary stops are added after the previous one, without even deleting the first temporary stop, and the train only drives to the most recent temporary stop before going to the next permanent stop in the schedule. So the schedule becomes cluttered with temporary stops that were never travelled to that it will visit after the schedule loops to the beginning again.

[boskid]

Good that it is still happening since it is was an intentional change.

[robot256]

Good that it is still happening since it is was an intentional change.

Hey boskid, thanks for the reply and Happy New Year!

Since this is the intended behavior, is there somewhere I can read about the intended use of it? It still feels like it breaks the only practical use for manually-created temporary stops: hijacking a train for personal transport, after which the train returns to its original schedule at the point it was interrupted.

If the intention is to simplify usage in this case, it might make more sense for manual interrupts to behave like schedule interrupts with "interrupt other interrupts" enabled. This way it would delete all other temporary stops before the next permanent stop, including previous manual and schedule interrupts, before creating the newest manual interrupt. This would actually be more convenient for PAX trains based on my experience, though it still would result in skipping the previously-added schedule interrupt stop for a normal delivery train and could mess up a delivery that way.

[wiggleshark]

I gotta agree, the new behavior is confusing and useless. If I create four temporary stops, it should go to them in order. If I want to go to stops A B C D, I have to select stop B, then C (and my train maybe changes direction) then D (changes direction again) then A (again)? What's the rationale?

If there is no temporary stop, insert it before the current stop and go to that stop. If in-transit to a temporary stop, append the new stop to the end of my temporary-stop sequence.

edit Here's another way it's broken. I leave my personal train nearby but out of the way while I do some maintenance. I bring the train over to where I am, I hop in, and I set a destination over by my mall. My train takes off immediately, leaving the old stop in the schedule that's no longer a queue. It bring me to my mall, then it leaves. Hopefully I remember where that was.

[robot256]

This behavior now also affects the new LuaSchedule API, resulting in more required "drag" operations if you don't use the "index" parameter of "add_record". viewtopic.php?t=127178

[wiggleshark]

I completely ignore the interrupt mechanic, but it seems it may be at play. I think temporary stops now interrupt temporary stops. It's good for them to interrupt the regular schedule, and possibly any defined interrupts. But not temporary stops.

[robot256]

The problem described in this bug report hinges on the fact that new temporary stops are added after the current destination if it is a temporary or interrupt stop and the train is immediately sent to the newest/last temporary stop, skipping the interrupt stop completely.. This is not how non-interrupt schedules are treated, for good reason, and only certain types of interrupt systems will be able to recover from it.

Note that internally, the game does know the difference between an interrupt stop and a non-interrupt temporary stop.

[wiggleshark]

Okay?

I see no reason why a change in behavior from 1.1 is needed. My current stop is temporary, my added stop is temporary... don't change the active destination.

I'm just speculating that temporary stops are being treated the same as any old interrupt stop when they shouldn't be.

[boskid]

Temporary stops are due to their nature temporary and are intended to go away once fulfilled. Reason why i made temporary records to also activate immediately is that this feature is often used when hijacking a running train and in that case if a temporary record added by player would not be activated, the train would have to first fulfill current schedule record driving not where i wanted it to go before i would finally start executing the request. Also there was often a frustrating point when changing destination as the train would keep going to the old destination instead of transitioning to the new one. Changing active record is more useful in a time sensitive order of actions when jumping into a train and trying to steer using temporary stops. If the current record change was not intended it is always possible to open locomotive and set the train to go to other record. If there is a reasonable explanation why this behavior is wrong i could change this behavior (for me thats just a 1 line of code), but i think current behavior is better than the original one.