Simutrans-Experimental 10.0 - pre-release testing

[jamespetts]

Simutrans-Experimental 10.0 is nearly ready for release. New features, which come under the approximate theme of routing enhancements, include point-to-point average speeds, Inkelyad's spacing as loading and round trip time patches and the ability of passengers to walk between nearby halts (where one halt is in the catchment area of another) en route. It will also contain fixes for a number of reported bugs as well as optimisations and the removal of redundant code (10.0's Windows executable is 147Kb smaller than 9.12's; the first time in a very long time indeed that a subsequent version has had a smaller executable than a previous version).

There is a new 10.x branch on my Github repository; I should be very grateful indeed if anyone with the ability to compile code could test to see whether it is ready for release. I should be very grateful for any pre-release feedback.

[inkelyad]

There is a new 10.x branch on my Github repository

I don't see it. Did you mean 'devel' branch?

[dustNbone]

Yes that is where you will find it.

Linux x86 SDL and server builds:

http://www.megaupload.com/?d=FK9W2XQ6

[jamespetts]

Ahh, apologies, I had forgot to push the 10.x branch. It is nearly identical to the devel branch, but I have just pushed one minor fix to it that is not on devel.

Edit: Note that the 10.x branch is now getting all of the bug fixes, rather than devel.

[Carl]

I'm just about to have a proper play around with the pre-release version, but here's a graphical error I've noticed right away:



The new "avg trip time" line has displaced the line-identifying section, and means that you can't follow the shortcut to the "list of lines" window.

[jamespetts]

Ahh - this appears to be a problem only in Pak64 or similar sized sets. Inkelyad - do you think that you could look into fixing this, as it arose in your code?

[dustNbone]

Ooops my bad on jumping the gun and making assumptions   I built new binaries a few minutes ago, 8PMish GMT.  Seems to still be a quickly moving target but here we go.

Linux x86 binaries, client and server packed together:

http://www.megaupload.com/?d=CX50WXRA

Dustin

[Carl]

I've found some pretty serious trouble with the new point-to-point average speed system, and more specifically with its impact on journey times. In short, the game is throwing up absurd combinations of journey times and passenger routing becomes very problematic as a result.

As far as I can see, there are three main problems.


1. Asymmetry of journey times

-- Journey times are severely asymmetric: there can be large differences between the A-to-B journey time and the B-to-A journey time. In theory these should not differ by more than a few minutes on a normal route, but in practice I've seen examples where A to B takes 25 mins and B to A takes 40 mins.

-- As a result of the above, journey times are not transitive. If a route takes 10 minutes to get from A to B and a further 10 minutes to get from B to C, then the A to C journey time should be approx 20 mins. But here's an example from my test map: A to C takes 125 mins, but B to A takes 54 mins and B to C takes 91 mins -- a total of 143 mins. Multiply this between lines (and interchange stations) and it  causes havoc for routing on a network of even moderate complexity.


2. End-to-end journey times are too short

-- Some journey times seem far too short. Here are two examples from my test map:

70kph vehicle can apparently travel 190km in 120 mins
45kph vehicle can apparently travel 55km in 54 mins

These are both absurd results. This problem is reminiscent of something that came up in a recent version -- 9.7/9.8?

In general, the end-to-end journey times are wildly different from those found in 9.12. In 9.12, the journey time calculations from one end of a route to the other were almost completely accurate -- the problems only came with intermediate stations. The fact that these are very different (and, in general, shorter), suggests that error has been introduced.


3. Penultimate station to terminus station journey times are too long

-- The journey time from the penultimate station on the line to the terminus station is usually excessively long. An examples: 44 mins for a 3km journey on a route with 55kph average speed. Could this be related to the fact that convoys on this line use "convoy spacing" and so spend a long time loading at the terminus station? That is -- could the game be counting the time between a convoy's leaving the penultimate station and its *leaving* the terminus station, rather than its *arriving* at the terminus?



I'll post more problems as and when I find them. The good news is that "walking connexions" appears to be working perfectly and the new system has no significant performance hit.

[Carl]

Sorry for double-posting -- I've just found another serious problem which is unrelated to the above problems with journey times.

In short: on the "Via (amount)" display, vehicles are trying to take passengers to stops which they do not serve.

Here's a visual example:



The trouble is that this train never visits "Budapest Ferenc Liszt Airport"! In order to get there, passengers would have to change. But the "Via (amount)" screen only shows the immediate destination for passengers, not final destinations. The upshot is that those Airport passengers will never leave the train.

[jamespetts]

Carl,

thank you for the testing and feedback - much appreciated. Looking into these issues, I have not been able to reproduce your fourth problem (in the second post), but can reproduce no. 1 in so far as it applies to trains in the stop before the terminus, as you originally indicated. It is not confined to routes in which the spacing time is set, and I am looking into whether the reversing time is incorrectly taken into account. I have not been able to reproduce problem no. 1 other than in that situation as yet (and my results are far less extreme than yours - an extra few minutes, not 44 minutes for a 3km journey - might your termini be congested such as to lead to delays before the trains enter them?)

As to no. 2, I have not seen this effect. Perhaps you could upload a saved game? Also, have you been able to reproduce this with Pak128.Britain-Ex, or only with Pak64? I wonder whether the difficulties occur more with some distance per tile (or other) settings than others.

[Carl]

might your termini be congested such as to lead to delays before the trains enter them?

This occurred to me, but it seems to happen even on clear termini so I don't think it can be entirely explained this way.

I've only tested using pak64, I'm afraid, but I have tested on both 250m and 400m distance-per-tile settings.

Here are the two games I've used for checking for easy demonstration of these bugs.


Game 1 - (400m distance-per-tile)
Savegame: http://dl.dropbox.com/u/61716/Balkans10testing.sve
Addons folder: http://dl.dropbox.com/u/61716/carladdonsbalkans.rar

The train in the frame when the game loads -- vehicle (106) -- is carrying pax for a destination which it does not serve. 7 passengers wish to go to the Airport, which is not on the route of that train.

The "penultimate stations" bug is well demonstrated at Gyöngyöshalász (25 mins to terminus at Gyöngyös, 3 mins to equivalent-distance station in other direction) and Andornaktálya (62 mins to terminus at Eger, 4 mins to equivalent-distance station in other direction).

If you let the game run for a month (to "iron out" its journey times), you can find a good example of the "journey times are too short" worry by observing the Miskolc to Szeged journey. This is a 190km journey -- but apparently it only takes 130 mins, even on a train which averages just 62kph and takes a far-from-direct route.


Game 2 - (250m distance-per-tile)
Savegame: http://dl.dropbox.com/u/61716/UK10testing.sve
Addons folder: http://dl.dropbox.com/u/61716/carladdons2.rar

This map has been run for a month in 10.0 to update journey times. It does not seem to suffer from the "journey times are too short" worry, signalling a difference between 250m and 400m distance-per-tile values. I'm also unable to find any trains carrying passengers to the "wrong" destinations, like the airport passengers above.

However, the "penultimate stations" worry is definitely still present. See the 17-minute journey from Patterton to Neilston (compared to the 4-minute journey to the next station in the other direction) and the 13-minute journey from Chatelherault to Larkhall (compared to the 4-minute journey to Hamilton Central, the next station in the other direction).

[inkelyad]

Ahh - this appears to be a problem only in Pak64 or similar sized sets. Inkelyad - do you think that you could look into fixing this, as it arose in your code?

I will look itho this.

2. End-to-end journey times are too short

-- Some journey times seem far too short. Here are two examples from my test map:
70kph vehicle can apparently travel 190km in 120 mins
45kph vehicle can apparently travel 55km in 54 mins

3. Penultimate station to terminus station journey times are too long

-- The journey time from the penultimate station on the line to the terminus station is usually excessively long. An examples: 44 mins for a 3km journey on a route with 55kph average speed.

Here are we again. Where said minutes come from?
Are you using new Avg time? Or numbers from "line details" dialog?

EDIT:
@james: Do I understand correctly that
1) tiles/month speed does not depends on km/tile value?
2) journey_distance inside convoi_t::laden() does not depends on it too.
3) journey_time inside convoi_t::laden() does not depends on bits_per_month

1 -> it is useless for player to do any calculation using distance (in km) and speed (km/h)?
2 & 3 -> what is stored inside  average_speed table?

[dustNbone]

Brief summary of my findings so far:

There are some errors in the journey times listed in the station details, mainly with my ships.  In one example the average speed in the line details is correctly shown as 20, but the journey times for 44.5km and 55.75km are 6 and 12 minutes respectively. It's a dogleg route serving three stops, and the 55.75km stop is actually quite alot more distant time wise than then 44.5km one.  This is a pretty extreme example, mainly seems to be the ships.  The only thing special about that line is that it's serviced quite frequently, 24 convoys a month leaving each stop. 

One other thing that is different, when I assemble a train at a depot and send it out to it's first stop, it sits at the station loading until I manually set its schedule to the next stop on the line, then it leaves, and next time it comes back to the end of the line reverses and carries on normally.  This isn't necessarily a problem, it's actually kind of handy for spacing trains out once you realize that it's doing that, but it's different behaviour from 9.12.

I'm going to spend some time today testing, it's a holiday Monday here.  Also, I couldn't compile the last commit on the github, the one described "FIX: Passengers would route to their final stop with a walk, but would not actually walk the final leg." It croaked on simhalt.cc, forgot to save the compiler output.  I'll run it again and post the exact build error.

Dustin

[Carl]

I will look itho this.
Here are we again. Where said minutes come from? Are you using new Avg time? Or numbers from "line details" dialog?

Journey time and distance (km) come from the station details dialog. The average speed comes from the line details dialog.


Journey time from one end of a line to the other -- from terminus to terminus -- should always be at least approximately measurable by dividing total distance by total average speed. If it's not anywhere near this value then surely something's gone wrong.

[jamespetts]

A brief reply, as my time is currently limited. Firstly, Inkelyad, to answer your questions:

(1) yes;
(2) yes;
(3) yes.

However, it is not useless for players to undertake any calculation in km and km/h, as the average speeds, the distances and the times shown in the stations are all calculated on a commensurate basis (that is, taking into account distance per tile but not bits per month). One thing about which I do wonder is whether it would be better for your round trip time and loading time displays to be expressed in minutes (i.e., the same minutes as used for journey times) rather than the internal measure currently used, so that players could also use those times for calculation purposes and compare them against other things (as presently, it might be considered somewhat confusing).

Dustin - I have not noticed in my testing the problem that you describe with trains waiting at their first stop, and this is not intended, nor have I changed any part of the code that I can think might account for this. As to the compiling - can you see if you can post a compiler output? What platform/compiler are you using?

[Carl]

One thing about which I do wonder is whether it would be better for your round trip time and loading time displays to be expressed in minutes (i.e., the same minutes as used for journey times) rather than the internal measure currently used, so that players could also use those times for calculation purposes and compare them against other things (as presently, it might be considered somewhat confusing).

I'll second this -- that would be extremely useful.

Dustin - I have not noticed in my testing the problem that you describe with trains waiting at their first stop, and this is not intended, nor have I changed any part of the code that I can think might account for this. As to the compiling - can you see if you can post a compiler output? What platform/compiler are you using?

I came across this problem on a brief test of Pak.Britain-Ex last night. A new convoy was apparently "scheduled" to wait at its first station for 320 hours before departing -- even though its line was not subject to any spacing settings. I'll see if I can recreate this later and upload an example.

[inkelyad]

However, it is not useless for players to undertake any calculation in km and km/h, as the average speeds, the distances and the times shown in the stations are all calculated on a commensurate basis (that is, taking into account distance per tile but not bits per month).

Are you sure about average speed information? At first glance I can't find where tiles/km is used.

EDIT: but still..
Vehicle speed is 100 tiles/month.
tiles/km == 1 => vehicle speed is 100km/month.
tiles/km == 3 => vehicle speed is 25km/month.

Do speed from pakfile scaled to tiles/km when printed?

One thing about which I do wonder is whether it would be better for your round trip time and loading time displays to be expressed in minutes (i.e., the same minutes as used for journey times) rather than the internal measure currently used, so that players could also use those times for calculation purposes and compare them against other things (as presently, it might be considered somewhat confusing).

It is goal of my next patch -- it wil create new date/time printing mode, where journey minutes are used.
It will make month of weird length, but it can't be helped.

[dustNbone]

Here is the compiler output for my build attempt of f92927f (Latest Git):

===> CXX simhalt.cc
simhalt.cc: In member function 'uint16 haltestelle_t::get_average_waiting_time(halthandle_t, uint8) const':
simhalt.cc:1170: warning: taking address of temporary
simhalt.cc: In member function 'ware_t haltestelle_t::hole_ab(const ware_besch_t*, uint32, const schedule_t*, const spieler_t*, convoi_t*, bool)':
simhalt.cc:1504: warning: comparison between signed and unsigned integer expressions
simhalt.cc: In member function 'uint32 haltestelle_t::liefere_an(ware_t)':
simhalt.cc:1936: error: 'class ware_t' has no member named 'get_zeil'
simhalt.cc:1936: error: 'class ware_t' has no member named 'get_zeil'
simhalt.cc:1936: error: 'class ware_t' has no member named 'get_zeil'
simhalt.cc:1939: error: 'class ware_t' has no member named 'get_zeil'
simhalt.cc: In member function 'void haltestelle_t::rdwr(loadsave_t*)':
simhalt.cc:2580: warning: comparison between signed and unsigned integer expressions
simhalt.cc:2704: warning: comparison between signed and unsigned integer expressions
simhalt.cc:2737: warning: comparison between signed and unsigned integer expressions
make: *** [build/default/simhalt.o] Error 1

Compiler is GCC 4.4.5 on 32 bit Linux.  Maybe it just hates me

[jamespetts]

Inkelyad - see my post in the other thread in answer to your question.

Dustin - I have realised that this problem is because I forgot to push the fix to my typing errors causing this problem with the latest commit - apologies!

Edit: Inkelyad, incidentally, what do you mean when you write that printing loading/waiting times in terms of journey minutes will make the month length weird? The two should not be connected (see the post to which I refer above on the deliberate distinction between the first and second measures of time).

[inkelyad]

The new "avg trip time" line has displaced the line-identifying section, and means that you can't follow the shortcut to the "list of lines" window.

Fixed in my round_trip_time branch.

[jamespetts]

Thank you very much!

[jamespetts]

I have found the cause of the "penultimate station" bug, and also possibly the "passengers for the wrong destination" bug: my alterations to the pathfinding system to accommodate point to point journey times, there was an error that caused the journey times to be recorded backwards: for example, the journey time from A to B would instead be recorded as the journey time from B to A. If convoys did not use linear routes, it is possible that passengers/goods might be loaded for the wrong destination (although I am not sure whether this is the cause of the problem).

The "penultimate station" issue was caused by a reversal (due to the above bug) of a phenomenon which one might expect to result from reversing times: because reversing is counted as part of the journey time for departing convoys (because the convoy arrives at the station, unloads, loads, then tries to depart, and then incurs the reversing delay when, having tried to depart, it realises that it has to go in the opposite direction), the journey time for departing from stations at which reversing occurs to the next stop is higher than the journey time in the opposite direction.

[Carl]

Hi James, many thanks for looking into this.

Given that reversing only takes a few minutes for most vehicles, I don't think that reversal time can fully explain many of the discrepancies -- many seem to be out by about 20 minutes in the first map I uploaded, for example.

However, the "backwards journey times" problem sheds some light on what *could* be causing the problem here. I conjecture that journey times are being counted from the point when a passenger joins a service, rather than from the point when that service departs. Where convoy spacing is in effect, a passenger may join a service (e.g.) half-an-hour before it departs. If it's a five-minute journey to the next stop, then the game will erroneously record a 35-minute journey time to that stop.

If this is right then it marks a change on 9.x versions, where convoy spacing has no effect on journey times. Arguably, what's happening is that time which should be counted as part of waiting time is being counted as part of travelling time. Travelling time should only record how long it takes to get between stations, and waiting time should record the time between arriving at a station and leaving that station on another convoy. So the ideal solution would be for journey times to "start" only when a convoy leaves, and for all loading-time up until that point to be counted as waiting time.

Edit: Some data in favour of my conjecture: the severe instances of the "penultimate stations" bug on the first map occur in all and only the termini where convoy spacing is in effect.

[inkelyad]

So the ideal solution would be for journey times to "start" only when a convoy leaves, and for all loading-time up until that point to be counted as waiting time.

There is logic in current setup:
Waiting time is "how long we wait for bus/train".
Traveling time is "how long we are sitting inside". Eg. "It take (in average) 2 hours from boarding to getting off".

[Carl]

Yes, there is that.

But I still feel that this behaviour creates a strange discrepancy between lines with convoy spacing enabled and lines without it enabled. Even within the same line there are odd discrepancies. In the example I gave before, imagine that A is the terminus and B the next stop along. For journeys from A to B the game will display something like "35 mins travelling, 2 mins waiting", but for journeys from B to A it will display "5 mins travelling, 30 mins waiting". I think it's confusing for the player for these journey times to be so different when visually they take the same amount of time.

However, I recognise that the question here is "routeing-neutral": either the time in question gets counted as waiting time or as travelling time, and either way connections will work out the same -- so passenger behaviour will be the same either way.

[jamespetts]

Carl,

the behaviour of counting spacing time as travelling time is not different to 9.x, but was is less noticeable in 9.x, as it was all merged into the general average speed there. Inkelyad is right about the logic of it, and there is another inescapable problem: if passengers board at stop A intending to go to stop C, and the train/bus/boat/etc. calls in the meantime at stop B, and there is a spacing time in force at stop B, then there is no sense in which the time that the passengers from stop A sitting on the train/bus/etc. at stop B can be said to be waiting time - it must be travelling time; there is no reason for the same not to apply to passengers boarding at stop B.

Just as in real life, one must be very careful with spacing times with passengers or other cargoes that want fast transport, as having to sit a long time waiting at a stop is likely to increase the total journey time considerably.

However, one workaround for this at terminus stations is to specify the terminus twice on the schedule; for example, in the A-B-C route that we postulated above, if A and C are spacing points, the schedule might be A-A-B-C-C, with the mirrored option enabled and the spacing time set on the first A and the last C; passengers will not board at A if the next stop is A, nor at C if the next stop is C, so the convoy will sit empty whilst it waits for its spacing time to be filled. This cannot, however, be used at intermediate halts (such as B), and nor can it accommodate the spacing feature's function of ending the spacing time if the convoy becomes full.

[Carl]

there is another inescapable problem: if passengers board at stop A intending to go to stop C, and the train/bus/boat/etc. calls in the meantime at stop B, and there is a spacing time in force at stop B, then there is no sense in which the time that the passengers from stop A sitting on the train/bus/etc. at stop B can be said to be waiting time - it must be travelling time; there is no reason for the same not to apply to passengers boarding at stop B.

Ah yes, that is a big problem -- I hadn't considered the matter of spacing at intermediate stops at all.

However, one workaround for this at terminus stations is to specify the terminus twice on the schedule; for example, in the A-B-C route that we postulated above, if A and C are spacing points, the schedule might be A-A-B-C-C, with the mirrored option enabled and the spacing time set on the first A and the last C; passengers will not board at A if the next stop is A, nor at C if the next stop is C, so the convoy will sit empty whilst it waits for its spacing time to be filled.

That's a very useful workaround. I think I'll be adopting it! (Another option is to have a vehicle "stable" in a siding and wait out its spacing time there rather than in a platform.)

[jamespetts]

I have been investigating changing the loading sequence from:

arrive > unload > load > reverse > depart

to:

arrive > unload > reverse > load > depart

but this is very difficult, as the reversing is tightly bound up with the departing in the code, which is not much changed from Standard. I am wondering whether it is necessary to go as far as introduce a completely new convoy state called "UNLOADING", but this might require some fairly major code surgery. I'd be interested in any views on the matter.

[inkelyad]

arrive > unload > load > reverse > depart
to:
arrive > unload > reverse > load > depart

I think it is unnecessary. But you can join reversing time with waiting/loading time too.

Now (Reversing time is 30 min):

Code Select Expand


LOADING state          REVERSING state
|--------------------|-------------------------------|
    20 min                        30 min

After:

Code Select Expand


  LOADING            REVERSING
|--------------------|----------|
  20 min                 10min


Should be more or less easy. We have convoi_t::arrival_time now. Tricky part will be not using it when convoy need to reverse between stations(schedule change etc).

[jamespetts]

I think it is unnecessary. But you can join reversing time with waiting/loading time too.

Now (Reversing time is 30 min):

Code Select Expand


LOADING state          REVERSING state
|--------------------|-------------------------------|
    20 min                        30 min

After:

Code Select Expand


  LOADING            REVERSING
|--------------------|----------|
  20 min                 10min


Should be more or less easy. We have convoi_t::arrival_time now. Tricky part will be not using it when convoy need to reverse between stations(schedule change etc).

I must confess, I am not sure that I fully understand, as the only difference between the two diagrams is that, in the second, reversing takes less time; nothing appears to be joined. Also, it is not so much tricky as more or less impossible, I think, to distinguish between this being in intermediate and non-intermediate stations.

[inkelyad]

I must confess, I am not sure that I fully understand, as the only difference between the two diagrams is that, in the second, reversing takes less time; nothing appears to be joined.

Convoy reversing time is 30 min on both pictures. On second picture first 20 minutes are shared between loading and reversing.

[jamespetts]

Ahh, I see - this is a totally different thing, then, to not registering the arrival time until reversing has taken place?

[inkelyad]

Now I don't understand you. You are asking how to implement this?

After recent patches we have convoi_t::arrival_time.
Don't touch anything related to LOADING state, but use it in REVERSING state processing.
"if (now - arrival_time > loading_time) { ... }"

[jamespetts]

Ahh, no, implementing this should be easy: add a flag as to whether the convoy has hopped since its last time in the loading state, and, if it has not, deduct the longest loading time from the reverse time (although, actually, your system seems even better, as it does away with the extra bool flag).

I was more making the point (in the previous post) that this is a different thing to taking the reversing delay (which is often much longer than the loading delay) out of the time computation for passengers/goods who/which are not on the vehicle at the time of reversing.

[inkelyad]

taking the reversing delay (which is often much longer than the loading delay) out of the time computation for passengers/goods who/which are not on the vehicle at the time of reversing.

Then said time will be added to waiting time. I see no difference. Final routing decision is based on total journey time (traveling time + waiting time).

EDIT:

Code Select Expand


const sint64 departure_time = (arrival_time + longest_loading_time) - reversing_time;
...
go_on_ticks_spacing = (wait_from_ticks + spacing * queue_pos) - reversing_time;

I am not sure why you are doing it that way. (Why not take in account loading time inside REVERSING state processing?) But it seems you forget subtract reversing_time here:

Code Select Expand


go_on_ticks_waiting = welt->get_zeit_ms() + (welt->ticks_per_world_month >> (16-fpl->get_current_eintrag().waiting_time_shift));