Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
Discussions Rules and Guidelines
Report this post
Every time even a single thing is changed in the orders/timetable, the trains turn stale.
This can be due to:
- a change that you made in the line
- a change that you made in the orders
- a change that the developer makes in the beta which causes all orders to be recalculated
I totally agree it's very frustrating. I am hoping for a solution.
My workaround right now is this:
I save all my games around 23:30; if they turn stale, this will mess up service before they go to depot at 2am, but not many passengers are affected. By the time they go to depot they will have the new orders in place, so next morning service is normal.
This does limit me; I can't let trains go to depot earlier in the evening for example, cause that would mess things up. And also any changes I make to lines and orders, I usually do around 23:30 (stopping time there). Still even with this workaround it happens now and then that I need to issue an intervention, but it minimizes the problem.
I really hope a solution will come. I understand that Carlos may not have anticipated this problem and that is might be a complex thing to solve.
But implementing timetables means that there must be ways to change them without messing up the entire service. Otherwise it's hard for us to play.
An alternative would be to pick the *next* run, basically the first run which does not make the train late. This implies a long station wait somewhere, potentially for the duration of an entire run. I think it's preferable to have a very late train but still servicing a run than to have it sit for multiple hours just so its next run is perfectly on time.
The next step beyond this would be to just auto teleport trains (and this would still strand pax inside). A "reset" without teleport is useless since it just leaves trains very far from their destination and ensues a mad dash of paths to try to make it there ASAP. Not to mention the total signaling failures from trains changing their paths outside of a signal stop.
That being said, if you can reproduce trains getting stale by themselves without any kind of interaction (add to Yonsef86 list: track edits, adding or selling trains) and without any new version release, then I would like to look into the save, thanks!
This I understand. But if "from the start" means with nearly a full run delay it disrupts service in extremely unreasonable ways. Especially if more than one line is involved, it literally wreaks havoc. The next run would probably work better, but still some trains would probably block tracks then with all due consequences.
I know that the point is to prevent pax getting stuck or lost, but I prefer one or a few loads of pax getting lost, over having all trains running a full run late all day long, which impacts satisfaction severely.
Wouldn't it be possible for trains to keep running their "old runs" for a while after a change in orders? Maybe there could be a possibility to set the time manually for when the order change would have to take place; followed by an 'abrupt' order reset at that time?
Or maybe it could automatically make the reset during the first upcoming 'technical manouvers run'?
With a manual time setting, all responsibility for would lie with the player.
With an automatic technical manouvers setting this would not even be important. Empty trains finding their path to the new depot or a new starting point is not so weird.
1. Minor route or train editing. In my experience although these create a stale run, it's not much different from the original run, and a major disruption will not result. A train will simply reach the end station and continue with the next run. I think it is probably helpful to have some "reserve time" (i.e. set custom line duration to be longer than the minimal line duration) to ensure any increases in the latter do not affect the number of runs.
I think new beta releases likely also should fit into this category, unless there is a major operational change. For example, replacing depots with straight tracks may have done this to some lines if they were using the track or connected tracks.
I think it would however be very helpful if the game could alert us to events when the timetable is recalculated and the number of runs for any order changes. This could potentially be a good way to monitor for changes and then be able to take action before a major disruption happens.
2. Intentional line and timetable changes. These are on players. However, I think we are all struggling in a way because there is no convenient protocol to do changes. My thought is perhaps there could be "Effective time" functionality added to the Append order/Edit order interfaces. This could be as simple as a choice of several basic options: "Next run", "Next identical order", "Set time (cancel run)", perhaps some other.
Next run: current behavior. The current run is not affected but the next run may be cancelled and replaced with a new one, if it is being affected.
Next identical order: the change does not affect any runs on the current order, but any runs on the same order on another day will be affected.
Set time (cancel run): the change take effect at a specified time, and any order running at that time will be cancelled if it is being affected, and replaced with the run from the new order. The specified time could be right away, too (e.g. in a minute). This may sound crazy, but it's super convenient when the train is sitting in a depot already assigned to the next run. That next run will then be cancelled. But you can also do this on a running train, just understand the consequences.
3. Interruptions have moved from an occasional nuisance arising mostly from your own error, to something of a regular occurrence driven by how the game processes changes. For those of us running with money, $500,000 does not make sense. I am honestly just deleting the track under the stuck train (which resets it) and then restoring the track, typically costs $1-5 thousand and a minute or two to restore signals and junctions. I think something like $1,000 per interruption would be a lot more reasonable and closer to real life too. Or perhaps something like 0.1% of the train value.
Thanks a lot! I have already tested it and it works much much better than before.
Small changes go effortless now.
One thing for players still to keep in mind is that a train in depot during a change will still do its first morning run stale, after which it respawns into the new timetable. Especially for bigger changes and longer runs this is something to take into account.
Nonetheless this is a great improvement, which makes the game much more 'playable'. :)
Doing the "save before getting into depot" trick means I will just push the trouble from trains exiting the depot to trains entering it, because both need to be checked. So I nevertheless end up saving the game at night with trains in depots.
I still think being alerted to unintended timetable changes (i.e. changes in the number of runs triggered by any factors other than edits to orders) would be very helpful. These are very difficult to think of sometimes and can have huge adverse consequences.
Or just fast forward at least a full run and all will be normal again, right? in 1.5.28
The problem before was that trains often repeated a late run after the stale run, which resulted in trains getting stuck behind each other in the wrong order, which could last hours or even a full day. That's why the "save before getting into depot" trick was useful.
In 1.5.28 this problem is no longer there.
That was the purpose of my suggestion to be able to cancel the existing run and replace with a new one right away. The current protocol is that the current stale run is preserved. But if this run is no longer needed - which is the case with sitting in a depot when the current run is already the first morning run - there should be no issue cancelling it. Ultimately if it's a run carrying passengers and the user cancels it, that may be something for the user to deal with and take consequences for.