[9.4] New acceleration/deceleration behaviour

[Carl]

I wanted to report some troubling experiences I'm having with trains on the new deceleration behaviour in 9.4.

The (9.3-created) map which exhibits the following behaviour has a 25% distance-per-tile value. I mention this because I've done some brief testing, and I think this makes a difference to the behaviour.* My suspicion is that the problems with the new behaviour become more evident with smaller values for this parameter.

I observe the following behaviour with trains:

1. On approaching each signal, the train decelerates to around 66% of its top speed. This happens regardless of whether the signal is clear. What's more, it seems to happen around 6-8 squares before the signal (so 1.5-2km at 25% dpt). This is perhaps the most puzzling behaviour, and precludes any sustained running at top speed. (This appears not to occur at all when distance-per-tile is 100%.)

2. Deceleration before stations seems to be over the top in many cases. Some trains crawl into each station at only 15kph -- and in some cases they travel around four squares (1km) at this speed before stopping at the station. Some trains manage 34kph into the station, but this seems to be as good as it gets. In reality, trains are often still travelling at a significant velocity when they arrive in the station -- especially on (for example) the Tube.

3. Trains also seem far more sensitive to shallow corners which should have no impact on speed. (It's unclear why this should be a consequence of the deceleration changes, but it seems to be correlated.)

The effect on my existing map is that the average speed for all train lines decreases by 30-50%. This makes it impossible to run services frequently enough to transport all passengers, even though the passenger-factor on the game in question is only 19. I can upload the relevant files if you'd like to see this all for yourself.

My worry is that this new behaviour makes certain kinds of high-detail maps impossible to simulate -- that is, maps with low distance-per-tile values where stations are nevertheless still very close together. For example, it's very difficult to run a good simulation of a tube-style line where stations occur every 1km or so.

I suspect that this feature would work much more smoothly for higher distance-per-tile values, and the brief testing I've done suggests that many of the quirks I've noted above matter far less under these circumstances.. This makes me think that the feature should be optional, and that those using lower distance-per-tile values should be advised to switch it off.



*I recognise that distance-per-tile *should* make a difference to how this feature works -- my concern is that, at smaller distance-per-tile values, the effects are not desirable.

[jamespetts]

Thank you for the report. I should be most grateful if you could upload a saved game, as initial testing on another saved game that I used did not disclose these difficulties.

Edit: Looking more closely, I can reproduce the slowing for signals on my existing saved game, but not the crash, so I should be grateful if you could upload.

[Carl]

Hi jamespetts,

Thanks for looking at this. Here's the savegame, along with my pak-folder:

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

http://simutrans-germany.com/files/upload/jha4cebpak.rar

On further examination, the behaviour is uniform across all trains, and not -- as I implied in the earlier post -- variable. You'll see in this game how, especially on the tube lines where stations are close together, this behaviour does not allow for a proper service.

[Carl]

Hi jamespetts,

Since I've uploaded that file, there's actually one more oddity/possible bug that I wanted to ask about if that's okay with you. It's an oddity which I thought was related to the (now fixed) bug regarding return journeys and private cars, but since it persists in 9.4 I guess it must be something else.

On the UK map, there are several cities on the fringes of London whose arrival/departure statistics vary wildly from the norm -- as far as I can work out, by a factor of 10. Specifically, they have vastly more passengers arriving and departing than one would expect for cities of their (relatively small) size. In 9.3, they also had vastly more passengers arriving than departing. In 9.4, the arrival numbers remain unchanged, but they also have immense amounts of passengers departing.

Good examples of this behaviour can be found at Loughton, Chigwell, Grays, and Caterham. Caterham, for example, has a population of only 1500 yet seems to manage around 2600 arrivals/departures per month. Its neighbour Oxted, which has a population of 1160, manages only around 300 arrivals/departures per month.

My best guess is that this is an unfortunate side effect of the fact that all of the cities in question are on the edge of a huge city (London). However, this doesn't make sense of the discrepancy between, for example, Caterham and its neighbours. I'd be grateful for any insight you have on this matter in addition to the acceleration behaviour!

[jamespetts]

The original problem should be fixed in the new 9.5 release; I have not, however, been able to identify any cause of the second issue at this juncture. I should be grateful if you could test the new 9.5 release and report your findings. Thank you very much for reporting this issue.

[Carl]

Hi jamespetts,

Thanks for this: the 'signals' issue appears to be fully fixed in 9.5.

However, some of the other issues I reported originally are still present: specifically, the deceleration still seems far too aggressive and far too early when playing at a the low 25% distance-per-tile value. In stark terms: it is impossible, under this new feature, to realistically create lines which have stations every 1 or 2 kilometres. This is because, under the new behaviour, trains travel at less than 50kph (and in some cases less than 40kph) for an entire kilometre (4 squares) before they stop at a station. What's more, they travel at 15kph for the final 500 metres (2 squares) before stopping at a station.

But especially for high-density urban lines, this is very unrealistic. The tube manages high speeds between stations which are close to one another, and certainly does not trundle into stations in the way that trains do in 9.5. Perhaps the behaviour is more realistic for mainline and rural lines--but even in those cases, travelling sub-50kph for an entire kilometre and at 15kph for 500 metres before stopping seems way over the top.

I've done some testing on a an older save with a higher distance-per-tile value - 50% - and at this level, the new feature seems to work much better: and certainly much better than the pre-9.4 deceleration behaviour. So perhaps your response will be that ST-Exp is not designed to model realistic behaviour at such low distance-per-tile values as 25%. This would be disappointing, however, since levels this low are necessary if one wants to simulate real high-density transport networks. What's more, since varying the distance-per-tile is one of the nice features of Experimental, it would be a shame to limit its usefulness in this way.

In sum -- I wonder whether the new behaviour needs to be more sensitive to the varying requirements of different distance-per-tile values.

[Carl]

I've just noticed that 25% appears to be the default distance-per-tile value for many versions of Experimental -- including the 'Complete' version -- and I feel that this adds force to my above concerns.

[Carl]

Edit: The post that this was a reply to seems to have disappeared!   

[jamespetts]

Sorry - I didn't see your first post until after replying. I shall have to look into this and revert yo you. The feature is intended to be realistic at all distance per tile settings.

[Carl]

No worries. I look forward to hearing your findings!

[jamespetts]

I think that I have fixed this on my 9.x branch now: there was, I think, an arithmetical error that caused vehicles to slow down too soon.

As to the corners, nothing has changed in respect of that since 9.3, and all that changed in 9.3 was a fix of a bug to ensure that the cornering settings were read from simuconf.tab properly, so the solution if you do not like the cornering behaviour is to change the simuconf.tab values.

[Carl]

Thanks for looking at this.

I think that I misidentified the cornering behaviour an extra problem, whereas in fact it was just an instance of the (now-fixed) problems with braking before signals.

[Brambo]

I have always thought that in simutrans train decelration was unrealistic, but I agree that it is overdone in 9.5, so I'm looking forward to 9.6
I do have one other point on this subject: when approaching a (not clear) choose-signal, trains decelerate to almost 0 kmh due to this feature, this clogs up stations immensely and makes the choose signals somewhat useless. Is there a way to make the choose signals show "clear to non-scheduled platform" a few tiles earlier? This way, no slowdown would be needed.

[jamespetts]

The fixes to the issues identified in 9.5 are now available in 9.6, which has just been released.