Simutrans-Experimental 10.0 - pre-release testing

[jamespetts]

Ahh, it's not that simple: if the loading takes place after reversing, then passengers/goods who/that have arrived after the convoy has started to reverse will be loaded, which will have waited less than the reversing time. Also, to simulate the fact that, in real life, people have timetables, and thus do not turn up at the station five minutes after the train to their destination has departed as often as they turn up to the station five minutes before their train is due to leave, waiting times are halved relative to travelling times, so the distinction between travelling and waiting is important (and not least because waiting time is for all convoys from one stop to a particular destination, whereas travelling time is specific to the one particular line/convoy, and is used for determining which is the best line/convoy to take from that stop).

[inkelyad]

I still think it is unnecessary.

Also, to simulate the fact that, in real life, people have timetables, and thus do not turn up at the station five minutes after the train to their destination has departed as often as they turn up to the station five minutes before their train is due to leave

Hmm. we have  haltestelle_t::loading_here
You can use this in passenger generations.

[jamespetts]

What do you mean?

[inkelyad]

It contains list of loaded convoys. We can generate more passengers when station is not empty. Or even (but it will be processor-heavy) look into connexion table for current convoy.

[jamespetts]

I think that I have found a sensible workaround to the reversing/travelling/loading time issues - have a look at the latest 10.x branch. Note that the saved game format has changed, so games previously saved with 10.x will not load with this new version unless first saved with Experimental version 9 or lower. Further testing would be much appreciated!

Edit: I have now updated this to take Inkelyad's most recent suggestion relating to the loading_here list, such that convoys now continue to load whilst they are reversing.

[jamespetts]

Might I ask those who had problems with the initial run to re-test with a version compiled from the latest 10.x branch?

[dustNbone]

Bit of weirdness here with convoys not following their schedules, seemingly at random.  It seems to happen with trains and ships, that's all I've tested.  They leave their terminal station, seem to stutter on the map and in their window it shows them as "reversing", even though they are travelling, they cycle through stops in their schedule and then seem to stop on one much further down the roster, and head directly there.  Savegame: http://dl.dropbox.com/u/38204997/simutrans/June1898.sve

There are 3 ship routes on the map, and it's prominent in all of them, I can't seem to pin down the cause.  I'm building the map to test some of the new features so I've "cheated" a little and many of the stations have huge coverage areas, so I don't need to worry about local transport to generate passenger volume.  Any insight would be great, thanks in advance.  Good work on 10.x

Dustin

[Carl]

I'm getting some similar weirdness. When a train is ready to reverse, it displays "Reversing. left" before teleporting two squares along the track, displaying "Reversing. left" again, teleporting again...and this is repeated three or four times before the train eventually heads off.

Also, as dustNbone reports, trains don't always appear to be following their assigned schedules.

Edit: A further observation on the previously reported bug where passengers would display an initial destination which was not on their vehicle's schedule. This still occurs, but seems only to happen when a game is loaded into 10.0. That is, nobody will board a convoy headed for the wrong destination; this is a problem related to mistaken categorisation of passengers who are already on vehicles at the time the game is loaded.

Edit 2: Can I ask -- what is the '[R]' flag on stations in the Schedule window? Does it concern reversing? On many lines, every stop has this flag -- and on almost all lines, many stations have it which are not reversing points.

[dustNbone]

The [R] does signify a stop at which reversing is (supposed) to take place.  Behaviour you describe is identical, reversing,left caption, jumping a couple squares, etc.  I did have the same thing on a train schedule as well, but I withdrew the train service temporarily so that I could try to isolate the problem.  It's not all convoys on the line either, some (maybe even most) leave normally and head to the next station on the schedule, but some just don't behave.

Dustin

[Carl]

It's not all convoys on the line either, some (maybe even most) leave normally and head to the next station on the schedule, but some just don't behave.

Yep, that's the same as what I've witnessed.

[jamespetts]

Thank you for the report. I'm looking into this, but it's rather elusive so far. I have fixed another bug in the process (which might have resulted in stations/stops being marked as "[R]" (a stop at which the convoy reverses)) incorrectly.

Any help in tracking down the main issue would be appreciated!

Edit: One thing that would be very helpful in tracking down the problem is if somebody could manufacture a saved game in which there is one single convoy that reliably misbehaves in the way described.

[Carl]

Edit: One thing that would be very helpful in tracking down the problem is if somebody could manufacture a saved game in which there is one single convoy that reliably misbehaves in the way described.

I'll upload such a save-game later on today.

[jamespetts]

Thank you; that's very kind.

[Carl]

Here's a savegame: http://dl.dropbox.com/u/61716/balkansreversing.sve (uses previously uploaded addons set: http://dl.dropbox.com/u/61716/carladdons3.rar)

The trains leaving 'Cegled sidings' will reliably display this behaviour. That is: every other train will display this behaviour. Each time it 'reverses'/teleports it skips a stop on its route, meaning that when it gets out of the siding it's headed for the wrong station. You can see this behaviour repeated by a number of other lines which terminate in the vicinity (e.g. at Kecskemet, slightly to the south).

Edit: Why does this only happen with alternate trains at Cegled sidings? My only guess is that it's explained by the fact that trains alternate platforms at Cegled sidings because of the choose-signals at the entrance to those sidings. So only trains leaving from one of these platforms is subject to the problems. The plot thickens...

I haven't yet compiled the very latest updates to the 10.x branch -- I'll do that now and report any changes in behaviour.
Edit 2: I've compiled the latest sources and the above behaviour is unchanged. Also, some lines still have an '[R]' flag at every stop -- for example, the 'R Szeged - Kecskemet - Szolnok' line.

[dustNbone]

Yeah i'm getting the same behavior in my latest build too.  This happens with ships as well, so it's not isolated to platforms with choose signals.  I noticed that if I don't set any convoy spacing or any waiting conditions at all, it doesn't seem to occur but I haven't had enough testing time to say for sure that this is the case. 

Dustin

[jamespetts]

I think that I have managed to confirm the hypothesis suggested by dustNbone that this does not happen with convoy spacing/waiting: I took Carl's saved game and, on the line where the problem occurs reproducibly, removed all of the waiting time (etc.) settings. This caused the convoys to behave normally. Another thing that I noticed in testing was that, when this problem occurs, the convoy will try to reserve its entire path to its next destination, not just to the next signal, which is odd.

However, in order to be able to fix this, I need to be able to isolate the behaviour in a debugger, which means running a map where there is only one convoy, and that reproducibly causes the problem. It needs to be one convoy because I need to be able to set a breakpoint in the debugger in the code relating to advancing through the schedule and be sure that it is set for the right convoy. My attempts to produce such a saved game have not so far met with success. Is anyone able to assist with producing such a saved game?

[Bernd Gabriel]

@james: can you set a conditional breakpoint? If yes, give the convoy a unique name, if it hasn't one yet and break only, if the convoy with this name is processed.

[Carl]

Another thing that I noticed in testing was that, when this problem occurs, the convoy will try to reserve its entire path to its next destination, not just to the next signal, which is odd.

Is this because it's waiting at a choose-signal (which ordinarily will try to reserve a path all the way to the next station)? In my experience this is in line with the normal behaviour of choose-signals.

[chs]

I would like to test it.. if anyone could provide windows binaries, that would be appreciated.

[jamespetts]

I think that I might well have fixed the erratic behaviour issue - can people re-test?

[dustNbone]

It seems that you did Good work James.

Dustin

[jamespetts]

Do people think that 10.0 is ready for release yet?

[Carl]

It seems that the most recent bug has been fixed -- thanks James!

The one main lingering trouble is journey times and their relation to distances/average speeds. The question of release-readiness depends on how important fixing these bugs is perceived to be.

I've uncovered some new data on this problem which is very interesting. When playing with a 400m distance-per-tile setting (that is, a value of 40 in simuconf), the game still displays impossibly short journey times for all routes. For instance: a 20km journey in a 60kph-average vehicle apparently takes only 13 minutes. All things being equal, we should expect the journey to take around 20 minutes. However, when playing with a 250m distance-per-tile setting (that is, a value of 25 in simuconf.tab), the journey time calculations appear to be sensible.  

What's more, I've an idea of how the incorrect journey times at 400m distance-per-tile is being reached. The 13-minute journey time quoted above is wrong -- but it *would* be correct if the game were instead being played under a 250m distance-per-tile setting rather than a 400m setting. At a value of 400m-per-tile, 20.8km (the exact distance in question) is equivalent to 52 squares. 52 squares at 250-per-tile is 13 kilometres. Since our vehicle averages 60kph, we would expect it to travel 13 kilometres in 13 minutes. And, lo and behold, 13 minutes is the value given for journey-time!

What appears to be happening is the following. At 400m distance-per-tile, the game displays the correct km value for journey distances but uses an incorrect km value for its journey time calculations. In the journey time calculations it seems to be assuming that distance-per-tile is 250m, even though it is set at 400m by simuconf.tab (and even though the game's displayed km distances are measured by 400m-per-tile).

Does this make sense? I've run this against a couple of test maps and the hypothesis seems to check out. The erroneous journey times all seem to be entirely sensible if we assume that the game is mistakenly taking a 250m per tile rather than 400m per tile value in journey-time calculation.

Edit: I've just tested this on an 800m-per-tile map (i.e. with a value of 80 for distance-per-tile in simuconf.tab), and my hypothesis has been further confirmed. The game says that a 92kph vehicle can travel 44km in 9 minutes, which is absurd. Now 44km is equivalent to 52 tiles at 800m-per-tile, and 52 tiles at 250m-per-tile is 13km. And 92kph vehicle should take around 9 minutes to travel 13km -- and 9 minutes is the journey time given by the game. At some point the game is mistakenly assuming that distance-per-tile is 250m rather than 800m.

[inkelyad]

What appears to be happening is the following. At 400m distance-per-tile, the game displays the correct km value for journey distances but uses an incorrect km value for its journey time calculations. In the journey time calculations it seems to be assuming that distance-per-tile is 250m, even though it is set at 400m by simuconf.tab (and even though the game's displayed km distances are measured by 400m-per-tile).

I thought we no longer use speed and distance in journey time calculations?

I slowly (it is hot here, and it is not healthy for my computer and me) do cleaning in related code so I will look into it. Again.

[Carl]

I thought we no longer use speed and distance in journey time calculations?

I'm afraid I'm completely ignorant of how it works in the code -- but the point is that whatever measure the code uses to calculate journey times isn't sensitive to changes in distance-per-tile value. So the higher the value the bigger the error in journey times.

I slowly (it is hot here, and it is not healthy for my computer and me) do cleaning in related code so I will look into it. Again.

Thanks for looking into this, inkelyad. Sorry to keep going on about it -- I hope that the new data I've mentioned helps in the search for a solution.

[inkelyad]

I'm afraid I'm completely ignorant of how it works in the code -- but the point is that whatever measure the code uses to calculate journey times isn't sensitive to changes in distance-per-tile value. So the higher the value the bigger the error in journey times.

It is supposed to be that way. Printing/output functions should care about all conversions.
But it is very unclear when you read code.

[jamespetts]

Journey times must still be adjusted for distance per tile, because neither speed nor distance are so adjusted (or ought be).

Edit: I have now pushed what I hope is a fix for the journey times/distance per tile issue, along with some code cleanup to standardise conversions from ticks to minutes to use the distance per tile setting properly. Further, I have changed the time displayed in the tool-tip for reversing/loading, and in the depot display, to use the same time scale as journey and waiting times, which is more useful than using the scale of time used for passing months/years.

I should be grateful if people could check my mathematics and test whether this works and successfully fixes the reported bugs. Thank you all for testing!

[Carl]

Many thanks for this James! I've done some "straight-line testing" -- that is, simple toy lines with only a couple of stops, to abstract from the effects that complex networks can have on journey times -- and the initial results suggest that the bug is still present. Here's some data paired with simple savegames:

Distance-per-tile (dpt): 25
Journey distance=23.5km
Avg speed=88kph
Expected journey time (calculated manually from distance and speed)=16 mins
Game's actual displayed journey time=16 mins
Comments: As ever, correct result given at 25 dpt.

Dpt=40
Journey=33.6km
Avg speed=63kph
Expected=32 mins
Actual=21 mins
Savegame: http://dl.dropbox.com/u/61716/dpt40.sve
Comments: Out by a factor which is close to 40/25.*

Dpt=50
Journey=32km
Avg speed=50kph
Expected = 38.5mins
Actual = 20 mins
Savegame: http://dl.dropbox.com/u/61716/dpt50.sve
Comments: Out by a factor of approximately 50/25 (i.e. a factor of 2)

Dpt=75
Journey = 67.5km
Avg speed = 36kph
Expected = 112 mins
Actual = 38 mins
Savegame: http://dl.dropbox.com/u/61716/dpt75.sve
Comments: Out by a factor of approximately 75/25 (i.e. a factor of 3)


Thanks for making the change regarding time displayed for loading/reversing/etc. I have one question about this. When the game displays (for example) "Loading 1:00", does this denote one minute or one hour? If it denotes one minute then (if my previous calculations are correct) then these displayed times seem right. If "1:00" denotes an hour then I think they are out by a factor of around 60 -- convoys  load for around "2:00" before leaving each station, which would be absurd if "2:00" denotes 2 hours.




* Confusingly, I've found much more ambiguous results on the Balkans test map that I uploaded previously -- on that map, where dpt=40, the journey times seem far more plausible and certainly don't seem to be out by a factor of 40/25. I'll have to play around with this map to verify this.

[jamespetts]

Carl,

thank you for the tests - I am not sure what the problem is, but shall look into those as soon as possible. Are those all saved in pak.ee (the same as the Balkans setup)? As for the loading times, they are indeed intended to be mm:ss rather than hh:mm, as a loading time of several hours is quite implausible.

[Carl]

Are those all saved in pak.ee (the same as the Balkans setup)?

Yes, they are -- sorry, I forgot to mention that in the previous post.

As for the loading times, they are indeed intended to be mm:ss rather than hh:mm, as a loading time of several hours is quite implausible.

Great -- thanks for the clarification.

[jamespetts]

I think that I have found the trouble - the average speed was calculated without taking into account the distance scale. I have pushed a fix - I should be grateful if people could re-test.

[Carl]

James,

Initial testing suggests that the bug has been fixed. Many thanks for your work on this!

[jamespetts]

Thank you for testing!

[wlindley]

I built a new Fedora system and have done this to create a build environment:

Code Select Expand

sudo yum install git gcc gcc-c++ libzip-devel bzip2-devel libpng-devel allegro-devel SDL-devel SDL_mixer-devel
git clone https://github.com/jamespetts/simutrans-experimental

edited the config file appropriately (BACKEND=sdl, COLOUR_DEPTH=16, OSTYPE=linux) but compile fails with this error:

Code Select Expand

simhalt.cc: In member function 'uint16 haltestelle_t::get_average_waiting_time(halthandle_t, uint8) const':
simhalt.cc:1378:55: error: taking address of temporary [-fpermissive]

Suggestions?  And... am I actually compiling 10.0 this way -- or where exactly do I find 10.0 if not?  I looked at the github page but there's nothing there about different versions. Nor does the Git tutorial linked off the wiki even mention how the "git clone" command or explain how to access different versions. 

p.s., I have been writing C programs since 1981 but there are so many unknowns with a new project; I edited the wiki with the actual, exact names of the compilers and libraries requried, after spending half an hour trying to find them.

[jamespetts]

This compiler "error" is actually a warning treated as an error by default, which can be disabled by using the -fpermissive switch. However, I am confused by the line number references: line 1378 of simhalt.cc is:

Code Select Expand


void haltestelle_t::add_pax_too_slow(int n)


That does not appear, however, to be the line to which the compiler is referring. Can I ask - are you using the master branch from Github? If so, that is the latest release version (9.12). You will need to switch to the 10.x branch to compile the pre-release 10.0.