[Bug] Waiting times not recorded on popular route

[Carl]

Here's a bug with waiting times which is independent of the patch on the other topic (that is: it occurs in 10.10 and persists with the patch applied).

Savegame: http://dl.dropbox.com/u/61716/balkans-waitingtimesbug.sve
Addons folder: http://dl.dropbox.com/u/61716/requiredpak.rar

Take a look at the halt-detail for Paks station (which is in the frame on loading). There are a whole bunch of stations which have no waiting times recorded. These include Kiskorös, which -- as you'll notice -- is the most popular destination for passengers from Paks, with around 70 pax leaving on each (hourly) train. But no matter how long you run the map, this set of stops will always display "waiting times unknown". This set corresponds perfectly with the stops on the line Budapest-Kalocsa-Paks. Waiting times for these stations are never displayed(/registered?), even though waiting times to stops on other line serving the stop are registered and displayed.

Note that even if you delete the station and build another in its place (which resets all this data), the same situation will be in place within a couple of months.

I'm hoping that this bug (whatever it turns out to be) is at the root of some of the residual problems with waiting times.

[omikron]

If that game is confusing, with all those strange names and the big map and addons, my testgame displays the same behaviour: At Peachwich (on opening screen), the waiting times remain unknown regardless for how long you play, while at all other stops, they are recorded normally.

normal Pak128 Britain (exp)

http://simutrans-germany.com/files/upload/testmap.sve

However, this only works when you click on the Info window of the stop before the first month is past. If you wait until February, it's all normal.....

omikron

[Carl]

I think waiting times are only updated during the path refresh at the beginning of the month, so that might be normal behaviour.

Sorry for the large map / addons / Hungarian!

[omikron]

No - if you click on the info window while in January, the waiting times will remain unknown forever, but once you wait a month before clicking, normal waiting times are displayed...

omikron

[Carl]

Oh, I see -- sorry for misunderstanding. That is strange!

[Carl]

I've tracked the bug I reported above to the following part of simconvoi.cc (line 1260), regarding reversing. (The bug goes away if you make the convoy reverse in a siding rather than in the platform, so it's definitely reversing-related.)

Code Select Expand



case REVERSING:
         if(wait_lock == 0)
         {
            state = CAN_START;
            if(fahr[0]->last_stop_pos == fahr[0]->get_pos().get_2d())
            {
               book_waiting_times();
            }
         }


                      break;


If you remove the if-condition here ("if (fahr[0]..." etc), then the bug is fixed -- all waiting times at Paks will be displayed as normal. So perhaps this condition is interfering somehow.

Two odd things, though:

1. I don't really know what work that condition is doing generally, so am not sure if removing it will have side effects (though I didn't observe any ill effects in testing).

2. The bug doesn't occur at other places where convoys reverse, so it isn't a problem with reversing generally. But I can't work out what is special about the Paks case.

[omikron]

You've pinned it down, I think. In my test game, the reversing trains are only occasionally calling 'book_waiting_times, de3pending on whether thw mentioned condition is met. However, it is not clear what the condition actually is, since I have not yet figured out a pattern when  it is being met and when not. Funnily, the position on the platform at which the convoy's stop is registered is important, though, since sometimes this varies, and then book_waiting_times is called, sometimes....

I agree with you, Carl, that the easiest way would be to remove the lines 1264-5 and 1267. There is no need checking whether the train just stopped where it is currently situated, in my mind. If anybody has any clearer idea about this if-condition, please tell us!

omikron

[omikron]

I suddenly understood the logic of the if-clause: In case the convoy reverses at some point outside of a station, the waiting times for the last visited station should not be updated. However, it obviously does not work the way it was intended.

omikron

[Carl]

Ah, that makes sense. So the if-clause is doing some work. But it's also excluding some legitimate waiting times, so I guess it needs some kind of modification...

[omikron]

The same if-clause function spotlessly in simconvoi.cc at line 2479, i.e. before reversing changes the convoy position. If one could set a boolean variable to true at this point, then line 1265 could just bool? That's beyond my C++ abilities, however.

omikron

[jamespetts]

Thank you for tracking this down! Apologies for not having responded earlier - I have been a little preoccupied with other things this week, and am still trying to clear the backlog of iterator troubles from merging the latest code. omikron correctly identified the reason for the code's presence - I am not sure why it is not working properly at that position. I shall have to look into this further when I have fixed the iterator issues.

[jamespetts]

Can anyone confirm whether this issue is still present in 10.13?

[Carl]

Yes, this one is fixed. Many thanks!