Author Topic: [r4425] Train somehow passed a red light by a few tiles (Read 4636 times)

Ters · « **on:** May 05, 2011, 03:25:33 PM »

I got a bunch of stuck train messages and found the cause to be a train that had passed a signal by a few tiles while attempting to enter a short single tracked siding to an occupied station. This line had been working flawlessly for many game years and I have not done anything to it recently. I suspect that the train slipped past the signal when the game was loaded given the amount of waiting passengers and goods that had accumulated, but I had already overwritten the savegame by the time I was alerted. The train, or rather its line, has a waypoint on the signal. It did not reserve tiles all the way to the occupied station, just three tiles, which is slightly less than the trains length.

My Simutrans was/is compiled with mingw gcc 4.5.2 and I'm using pak64 r450.

whoami · « **Reply #1 on:** May 18, 2011, 07:51:25 AM »

In the recent weeks, I have seen jumping trains in many occasions, causing network problems and lockups. But their increased occurrence may happen only due to an higher speed and density of trains combined with a much more complex network than before. On the other hand, I remember jumping trains from previous years of ST experience.

Where jumping definitely occurs:
- using "send to depot button" (additionally: if the depot is near enough, the train head jumps into it, but the train remains on the track); modifying the schedule instead causes the convoy to stop anyway, so jumping does not happen there.
- waypoints (sometimes with improper clearance of reservations, which might be caused by non-standard wagon length)
- track layout changes (but this is expectable)
- line schedule changes - it would make sense to stop the trains (of the line) entirely before rerouting

Where jumping may occur as well:
- loading and/or saving
- high CPU load or bad response/refresh times

It is fairly normal that a jumping train resets its reservations and ignores halt signals. Also, most of these cases may lead to recalculation of routes after the route has already been changed temporarily by a choose signal, so the train effectively passes a halt signal and tries to get into an occupied track, causing a deadlock if it is a dead-end station/track.

prissi · « **Reply #2 on:** May 18, 2011, 08:11:41 AM »

Jumping trains during loading may only happen if those (for whatever reasons) are more compressed together than they should. Please provide a savegame of this game to look at.

ercsim · « **Reply #3 on:** May 18, 2011, 09:43:00 AM »

Trains do overshoot but not over a few tiles and they won't get stuck. However, trains DO GET stuck, when you delete signals right before the train passes through it. The solution is to save, and reload the game.

whoami · « **Reply #4 on:** May 18, 2011, 11:59:01 AM »

Savegame (also referred to in my other bugreport in the German forum) with deadlocks at loading:
http://simutrans-germany.com/files/upload/PC184G1_192b_Zug1125-klemmt.sve - look at central stations of Bad Füssing and Karlshuld. At Meinersen, a train (convoy 1079) sits around confused, but this may be the one that was also stuck in a schedule change before saving.
But I can't say if the problems result from loading, saving or some other action.

Ters · « **Reply #5 on:** May 18, 2011, 02:07:05 PM »

I once (sometime this spring) had a train jump half way into a depot and then got completely stuck. It would not continue to move into the depot, and also refused to move back out. Eventually I tried to scrap the train on the spot using the sell button in the trains detail window, but that caused the entire game to crash. Although my memory is very unclear about this now, there may have been a train waiting for clearance to leave the depot at the time. Fortunately, the behaviour there has been changed recently.

prissi · « **Reply #6 on:** May 18, 2011, 10:08:36 PM »

The train 1079 jumps after 30s; but because it was aparently broken or in wrong state. There are some other stucked trains in the game, but those are the clasical cases of changing schedule while in station, which result in going to another platform even though the another was assigned.

I am not sure but maybe the latter could be caused by changing a line while already passed a choose signal!?!

whoami · « **Reply #7 on:** May 19, 2011, 09:46:33 AM »

Re Ters:
Right, now it is sufficient to open+close the convoy schedule. Several revisions ago, I had a crash or two with sending trains to depots, but could not reproduce these.

Quote from: prissi on May 18, 2011, 10:08:36 PM

There are some other stucked trains in the game, but those are the clasical cases of changing schedule while in station, which result in going to another platform even though the another was assigned.

Yes, but (from my observation in several cases) only in the sense that they (after loading of the game) go to the platform that is assigned by the schedule, not the one assigned by the choose signal handling routine (if this signal had been passed before saving). This behaviour, of course, also happens if the (line or convoy) schedule is changed after the train has passed the choose signal. It would be helpful if both cases could be handled more nicely.

Schedule changes could be handled better in related regards: whenever I change the assigned platform (at a certain station), either by stop-moving tool or manually, that stop is skipped by all trains of the line that have this station as next stop, often leading to quite undesirable routes. Jumping and overriding of choose signal decisions comes on top of this. But at least, tile reservations are nowadays handled in a way that it is easy to rectify the resulting situation manually.

Ters · « **Reply #8 on:** May 24, 2011, 03:59:11 PM »

My trains just clogged up again due to this problem. It is at a different station this time where the signal is much closer to the station, so the train jumped straight into the train at the station. However, just like in the previous case, there is a waypoint on the signal. In both cases this is because the trains should enter that track and queue up for a particular platform where they are instructed to wait until fully loaded.

I got a save game this time where the problem appears to have just happened, or will happen upon loading. Although it is possible for trains to get quite tightly packed on these "queue tracks", the train that has passed the red light appears to be alone on the queue track. See http://simutrans-germany.com/files/upload/Ters_4_-_Skip_red.sve where the station in question, Brentham Chemical Plant yard, is just a bit to the left and down from the starting position.

Dwachs · « **Reply #9 on:** June 01, 2011, 11:25:37 AM »

Here is a patch. It fixes the jumping trains in Ters' savegame. These trains reached the end of their route (waypoints) but did not search a new route before the game was saved.

I do not know whether the patch is the right fix or whether it breaks other stuff.

prissi · « **Reply #10 on:** June 01, 2011, 08:13:30 PM »

The set_convoi will break any convoi with a pending signal choose. So this putting it up front is a bad idea. But you are indeed correct, some case of waiting were not handled correctly.

Ters · « **Reply #11 on:** June 02, 2011, 08:54:30 AM »

I tried out r4574 and it (sort of) happened again. This time there were no waypoints on the signals. The schedule (Hillbury Oil 1) only contains the two stations. Two trains were queueing to enter the two occupied platforms at Aschester branch dock. The first train was waiting on the choose signal, while the other was waiting at the signal behind the first. Upon loading the game, both trains begin moving forward (normally, not jumping). Using the B key, I can see that tiles are reserved as they should be. The two rouge trains reserve one tile at a time as they move forward until they bump into the train in front of them.

Dwachs · « **Reply #12 on:** June 02, 2011, 09:25:55 AM »

Also the jumping trains are not cured. For instance train 83 jumps in Ters' savegame. Attached is patch.

The second attachment reproduces the situationTers described: trains ignoring signals after loading.

Edit: patch updated to fix the ignorign of signals. it appears the cnv->next_stop_index was not initialized correctly.

prissi · « **Reply #13 on:** June 02, 2011, 06:36:29 PM »

Why not searching a new route when driving and reached beyond end of route?

Other than that I used the wrong value for checking; but your fix is even better.

Dwachs · « **Reply #14 on:** June 03, 2011, 04:07:49 PM »

Quote from: prissi on June 02, 2011, 06:36:29 PM

Why not searching a new route when driving and reached beyond end of route?

This route search is responsible for the jumping train in Ters savegame, which still happens with trunk. I think the route search will be done later anyway, vehikel-t::set_convoi will set check_for_finish, which then triggers route search.

prissi · « **Reply #15 on:** June 03, 2011, 08:09:42 PM »

Mhh, this may give then problems with the block reserver a few lines later ...

On further checks: train 1079 jumps ahead also without route search on load. Or are we talking of a different train?

Dwachs · « **Reply #16 on:** June 04, 2011, 07:36:01 AM »

I meant train 83 at (644,817) in Ters savegame. There is no train 1079 in this savegame.

Edit: New patch to help the jumping train 1079. The problem was that convoi_t::alte_richtung was not set correctly.

prissi · « **Reply #17 on:** June 04, 2011, 10:32:48 PM »

Oh, I was debugging the wrong savegame ... aparently it works fine with just initializing alte_rcihtung always with get_fahrtrichtung(). ;aybe the saving of this parameter is not needed at all. Anyway, for now it is only reset if the state is not driving or in front of signals.

Thank you.

Ters · « **Reply #18 on:** July 06, 2011, 07:35:03 PM »

There are still some problems with trains passing red signals as of revision 4686.

Once again, the problem appears when loading a game. A train passes a choose signal and tries to enter a platform that is already occupied. The offending train stops short of the platform (or perhaps rather the other train), but blocks the other train from leaving the cul-de-sac station leading to a deadlock.

I have experienced it twice recently, but only had the chance of looking closer at one occurence. The offending train had not yet stopped at the choose signal when the game was saved, but might have just entered the tile. The signal does not change to green. In the case I looked at, the other platform was free, so the train should have gotten a green signal for that platform. (Maybe it had already gotten a green for that platform before the game was saved, but forgot which platform and defaulted to the other one upon loading?)

prissi · « **Reply #19 on:** July 06, 2011, 08:25:37 PM »

Was it saved by autosave? And is the occupying convoi number higher than the empty convoi number? But anyway, a svaegame to debug this is needed as I usually fail to recreate such a situation.

TurfIt · « **Reply #20 on:** July 06, 2011, 09:40:51 PM »

Game manually saved with train 1 tile away from choose signal ->> train ignores signal.
Saved with train >1, or on the choose signal tile ->> train routes to alternate platform.

prissi · « **Reply #21 on:** July 07, 2011, 10:37:19 PM »

It was save as if it has already choosen when it actually still had not done so. Should be fixed with next nigthly.