Simutrans-Experimental 10.0 - pre-release testing

[Carl]

The new 'show_month=8' option allows for verification of the journey times displayed in the Stop Details window. After quite a lot of testing, I've found some reasons to think that these journey times are not always quite accurate.

Here's a toy map for demonstration: http://dl.dropbox.com/u/61716/journeytimes.sve (requires addons folder http://dl.dropbox.com/u/61716/carladdons4.rar, as ever).

The headline findings from this map are as follows: point to point lines with only two stops give accurate journey times, but more complex lines of several stops give journey times which are too short by a factor of between 10% and 35%. A more detailed analysis follows:

There are two lines on this map. Line (2) has only two stations. The GUI displays a journey time of around 12-13 minutes. If we set show_month to 8 and follow the convoy, we will see that it does indeed take around 12 minutes from end to end.

Line (1) has several stations. The GUI displays a total journey time of around 30-31 minutes. However, if we follow the convoy, we see that it reliably takes around 38-39 minutes to get from end to end. (Note that the "avg trip time" displayed in the vehicle window for Line (1) appears to be accurate, since it displays a value of 1h 24m.)

I can confirm that this effect occurs on a larger scale. On my larger map, this effect seems to occur on more or less all lines. For instance: there are cases where a journey advertised as being 2.5 hours long reliably takes 3 hours.

[sdog]

I did some superficial testing, it compiled and ran without crash on my system (ubuntu 64bit). Didn't look deeply enough to check things like journey times etc.

[inkelyad]

Here's a toy map for demonstration: http://dl.dropbox.com/u/61716/journeytimes.sve (requires addons folder http://dl.dropbox.com/u/61716/carladdons4.rar, as ever).
Line (1) has several stations. The GUI displays a total journey time of around 30-31 minutes. However, if we follow the convoy, we see that it reliably takes around 38-39 minutes to get from end to end. (Note that the "avg trip time" displayed in the vehicle window for Line (1) appears to be accurate, since it displays a value of 1h 24m.)

Simutrans don't use real waiting time to compute total journey time.
from haltestelle_t::get_waiting_minutes:

Code Select Expand


// Waiting time is reduced (2* ...) instead of (3 * ...) because, in real life, people
// can organise their journies according to timetables, so waiting is more efficient.


[Carl]

Yes -- sorry, the times I was referring to are the travelling times rather than the complete journey times. I take it that travelling times don't make any reference to waiting times.

[jamespetts]

I've found the problem with this, which is that, currently, the only actual journey times booked are journey times between consecutive halts: otherwise, timings are based on the fallback average speed system. This was a mistaken omission from the original design of point to point average timings, which I am currently working to correct: however, this will require a hashtable of departure halts | times for each convoy, which will increase memory consumption somewhat.

[dustNbone]

I don't think memory consumption is really a huge issue as long as it's within reason.  Considering the complexity of the game and in comparison to other modern games, Simutrans has a very small footprint.  CPU usage gets a bit tight sometimes but memory is the one thing that I think most of us have in ample supply.  I can't speak for everyone however.

Dustin

[jamespetts]

I have now pushed a fix for this to Github - can people test?

[Carl]

1. The problem appears to persist, as demonstrated by the following savegame which was created and saved in the newest version: http://dl.dropbox.com/u/61716/journeytimes1.sve

There are two lines with multiple stops in this savegame.  Line (1) has nine stops, and line (2) has four. The error in the line (1)'s travelling time is much larger -- it's displayed as 14 mins when it is in fact 28 mins. Line (2)'s times are much closer to the truth; 12 minutes when they are in fact 15 mins. I've no idea whether this will be helpful but I thought I should mention it!


2. The new version is unable to open any savegames from previous 10.x versions. The following error is given:

Code Select Expand


FATAL ERROR:
loadsave_t::rdwr_str()
string longer (2820) than
allowed size (128)


Is this an unavoidable consequence of the changes made?

Even a 10.x game set to save in the 9.x save-format via the settings menu cannot be opened in the new version -- although this yields a standard Windows crash, not the error quoted above.

[jamespetts]

Carl,

thank you very much for testing this. Taking the second point first, I needed to update the saved game format in order to accommodate the new data. This will inevitably break previous saves with the same version number but a different format. I have checked, and it loads without difficulty games saved in 9.12 (and other 9.x versions), so I am a little confused that it is having trouble loading games saved as 9.x with previous pre-release 10.x builds - have you tried loading those builds in 9.12?

As to the main issue, I shall have to look into this further. Do you notice any change in behaviour between the latest build and the previous situation?

[Carl]

I have checked, and it loads without difficulty games saved in 9.12 (and other 9.x versions), so I am a little confused that it is having trouble loading games saved as 9.x with previous pre-release 10.x builds - have you tried loading those builds in 9.12?

Loading the savegames in 9.12 is generally successful. On further testing, I have been able to create a file in a previous 10.x build, save it as a 9.x file, and load it in the latest 10.x build. However, not all such games are so lucky. The following file cannot be opened in the latest build, despite having been saved as a 9.x file:  http://dl.dropbox.com/u/61716/canisavein9.sve. Have you any idea why this might be? (Edit: Note that this file appears to load fine in 9.12.)

Do you notice any change in behaviour between the latest build and the previous situation?

Since I can't use the same savegame it's difficult to make a perfect comparison. But I've just set up a new savegame in the previous build which is similar in format to "journeytimes1.sve". In this savegame, the line with 9 stops has a more accurate travelling time than in the latest build -- displayed as 21 mins when it is in fact 29. So there might be reason to think that the latest build is less accurate than the previous situation.

[jamespetts]

Hmm - this is odd. The game that you still can't get to work - does it open in 9.12, but fail to open in 10.x even though saved in 9.12; or does it fail to open in 9.12?

[Carl]

It can be opened in 9.12, and once opened in 9.12 and saved with 9.12 it can be opened with the latest 10.x build. So it seems that 10.x is failing to save "properly" in 9.x format, somehow. (Although that doesn't explain why 9.12 can open it but the latest build can't.)

[Milko]

Hello

I built a simutrans-exp for windows. Updated 29/08.

I publish the file if someone wants to try and not be able to compile it. http://simutrans-germany.com/files/upload/simutrans-experimental_2908.zip

Giuseppe

[jamespetts]

I think that I have fixed the issue with the journey times: would anyone care to re-test? Note that the correct journey times will only appear after the path explorer has refreshed the connexions data once at least one convoy in the line has recorded average journey times for the route in question. The problem with incorrect reverse markers has also been fixed.

[Carl]

Something odd has happened to the journey times in this version. See attached savegame: http://dl.dropbox.com/u/61716/journeytimes2.sve

In this save all of the "travelling times" lists read like multiplication tables. For instance:

From Station A:

to Station B, 6:06 mins
to Station C, 12:12 mins
to Station D, 18:18 mins
to Station E, 24:24 mins
to Station F, 30:30 mins
to Station G, 36:36 mins
to Station H, 42:42 mins



I can confirm that this happens in both newly-created maps and older maps. It's a different multiplier each time, but the journey times on each line take this times-table structure. The stations in question are not equally far apart, so this couldn't be right even with the average speed-based system.

Note that this "multiples" phenomenon seems to occur even before the path-to-path average speeds could have been calculated -- i.e. when a line has just been built.

[jamespetts]

Carl,

thank you. This suggests that there might be a problem with the fallback system for calculating journey times. Can you run the game fast-forward for about two months and see whether the problem persists? If not, the problem will be only with the fallback system. If it does persist, the problem may be more serious.

[Carl]

Hi James,

This pattern of times occurs both before and after the two-month point. The uploaded game has been run for almost a year and nevertheless displays this behaviour.

[jamespetts]

Carl,

thank you for that report. The problem was indeed with the fallback mechanism. I have uploaded a fix; can you re-test? (Note that I have added a new simuconf.tab setting, which is saved: your saved games will not work unless you save them as 9.x first, or use a debugger and skip line 1257 of einstellungen.cc when loading).

[Carl]

Carl,

thank you for that report. The problem was indeed with the fallback mechanism. I have uploaded a fix; can you re-test? (Note that I have added a new simuconf.tab setting, which is saved: your saved games will not work unless you save them as 9.x first, or use a debugger and skip line 1257 of einstellungen.cc when loading).

Hi James,

Thanks for this. At the moment I can't get this version to run at all -- I get the following error:

loadsave_t::rdwr_str() expected "<i16>", got "</ei>"

This error occurs when trying to run the program.

Do I need to change/add something to simuconf.tab in order to get it to work?

[jamespetts]

Carl,

yes - you need to delete settings-experimental.xml (or settings-experimental-debug.xml if you're running without -DNDEBUG defined), as the settings format has been incremented without incrementing the version number.

Giuseppe,

I have split your post into a new topic so that we can keep this topic devoted to testing 10.x.

[Carl]

James,

Thanks -- I should have thought to try that!

The point-to-point average speeds system still doesn't seem to be kicking in -- I think all travelling times are being given by the fallback system. Here's another map: http://dl.dropbox.com/u/61716/journeytimes3.sve

This map has been run for almost a year, so I guess that point-to-point speeds should have kicked in by now. But line (2) demonstrates that they can't have. Half of its route is on track with a low speed limit, so we'd expect that half of the route to take longer. But the travelling times given don't reflect this -- rather, it's clear they have both been calculated using the same average speed. That is, the behaviour here resembles that found in 9.12 and previous versions.

[jamespetts]

Carl,

thank you for that testing. The problem was, I think, that the data were being over-written because they were reset on being read, but for some reason were read twice, and had been reset by the second time. I think that I have fixed this now - can you re-test?

[Carl]

I'm afraid that there doesn't seem to be any change in this version -- the situation I described in my previous post is still present, even after the game has been run for a further in-game year.

[jamespetts]

Hmm, I can't reproduce this. After running through two path refreshes, the debugger confirms that the fall-back code is not accessed by the second run. The timing from Frankenthal branch station to St. Johann branch station (fast line, no intermediate stops, 12km) is 9:00 minutes. The timing from Frankenthal land 1 station to Mönchengladbach branch station (slow line, two intermediate stops, 13.25km) is 22:18 minutes. This seems correct to me.

Are these timings consistent with your results?

[Carl]

Those timings seem exactly right. However, I can't get the game to display that pattern in the Stop Details window, which is very strange. :-\ I've recompiled the sources and I still can't get this to work.

How long does a path refresh take? I'm guessing it can't be longer than a couple of months.

Edit: I've been compiling a release version rather than a debug version -- could that make any difference?

[jamespetts]

Hmm - that is very odd. It shouldn't make a difference if you're using a release build, but can you test with a debug build just to be sure? As to the path explorer , you can see when it refreshes in the "display" menu: look at the very bottom indicator, which shows "Status:" - it usually says "stand-by", but will very quickly go through a series of categories every so often. If you keep that window open and fast forward, you will be able to see when it refreshes by looking carefully at the "status" indicator.

May I ask - what operating system are you using?

[Carl]

I've compiled a Debug version, and intriguingly the point-to-point journey times are working perfectly in this version! However, the Release version compiled from the same sources appears only to use the fallback system. Very strange!

I'm using Windows 7 64-bit.

An aside: the Debug version itself runs into a crash with 9.x games:

minivec_tpl<T>:resize()
new size 256 too large
(>255).

I can't reproduce this in the Release version, so I daresay it isn't too serious. But I thought it worth mentioning anyway!

[jamespetts]

Hmm, this is very odd indeed. Are you using MinGW or MSVC++? Problems present only in the release version indicate undefined behaviour somewhere, but are extraordinarily difficult to track down because it's not possible to use a debugger with the release version (which is a large part of the reason why the debug version exists in the first place).

The minivec problem, however, can easily be solved by replacing the minivec with a full vector.

I shall have to think about how to deal with this when I know whether you are using MinGW or MSVC++.

[Carl]

I'm using MSVC++ 2010 Express.

[jamespetts]

Hmm, same as me. Are you using the project files from the Github repository?

Incidentally, I have pushed a fix for the minivec crash.

[Carl]

Yes, each time I've been downloading the source files from the 10.x branch on github. When I compile, I usually select "Release" from the Configuration menu, and "Release" in the Configuration Manager window. Is this right? I see that there's also a "Release (SDL)" option, and I don't know what the difference between these two is.

Thanks for the minivec fix -- I'll check that out now.

[Milko]

Hello

A reflection: the average speed is calculated by dividing the distance between the two stations (note, the distance is calculated as the crow flies) and the time it takes to travel the convoy route. The convoy, however, use a path that will in most cases longer than the crow flies. This difference can cause the problem?
Consider these four stations:

A-B
  I
D-C

The distance between "A" and "B", "B" and "C", "C" and "D" is one tile.
The distance between "A" and "D" is for the convoy of three tiles (A-B-C-D), but the crow flies is one tile.
It may be that in some cases simutrans not using the correct values ​​of the distance?

Giuseppe

[jamespetts]

The SDL version is now deprecated, so don't worry about that.

May I ask - what timings are you getting exactly with the release version and your test map? There have been changes to the calculation of distances in 10.x - we now use the "shortest_distance" method written by Knightly, which calculates the shortest possible distance using only the 8 directions available in Simutrans (the previous Experimental method was to use the Euclidian distance, which is the shortest physical distance which may be shorter than the shortest distance achievable in Simutrans, and the Standard method is to use the Manhattan distance, which is the shortest distance using only 4 directions). However, I don't think that this is likely, since the distance method is the same for the GUI and for the calculation of the speed, and unless you're seeing a different distance display in the GUI between debug and release, it won't be that.

[Carl]

Here's a complete account of the timings I get in the Release version on the test map.

From St Johann branch station (line 2):

Frankenthal branch (12km)
12:30 mins

<slow line kicks in here>

Frankenthal external (19km)
19:30 mins

Bezau branch (28km)
29:00 mins



From Monchengladbach branch (line 1):

Monchengladbach external (2.75km)
4:12 mins

Frankenthal land (5.75km)
8:06 mins

Frankenthal outer station (9.50km)
12:54 mins

Frankenthal land 1 (13.25km)
17:42 mins

<slow line ends here>

Frankenthal land 2 (17km)
22:30 mins

Frankenthal land 3 (21km)
27:42 mins

Frankenthal land 4 (23.5km)
30:54 mins


These vary a small amount from month to month depending on the average speed of the vehicle.


I can confirm that the distances are the same in the debug version.

[jamespetts]

And you get the same timings as I do in debug...?