Bugs on -devel branch

[Bernd Gabriel]

In my branch "devel" at https://github.com/BerndGabriel/simutrans-experimental the following fixes and changes are present:

Fixed:

   
• Rolling resistance issue: Was: the longer the convoy the lesser the rolling resistance. Now: Calculate median rolling resistance of the vehicles.
• Avoid division by zero in Carl's "new formula" in simhalt.cc (happened in a standard savegame I loaded).

Changed:

   
• unit of get_effective_power_index() and geared_power from kW to W.
• unit of get_effective_force_index() and geared_force from kN to N.
• geared_power and geared_force become arrays. Array index is speed in m/s, array index range is 0..max_speed. Allows arbitrary power resp. force characteristic curves (e. g. respecting efficiency).

[Carl]

Avoid division by zero in Carl's "new formula" in simhalt.cc (happened in a standard savegame I loaded).

Thanks for catching that one Bernd!

[jamespetts]

Bernd has recently pushed a fix, which I have now merged into the -devel branch, relating to an uninitialised variable when reading the rolling resistance value. Can anyone re-test to see whether this fixes the Windows XP problem?

[HeinBloed]

It's looking very good indeed, the bugged max speeds are gone! However, I -think- there's now a different smaller problem: some of the trams are showing an extraordinary acceleration. It's not like they reach max speed within zero time, but certainly within a very short time span and much faster than others. Two of those are the Double Deck Open-top Tram and the Double Deck Closed-top Tram.

Edit: Oh, and loading a savegame created with one of the previous devel executables (a debug build) leads to this:

I presume that might be because the rolling resistance variables aren't set in those savegames ...

[jamespetts]

Hein,

thank you for testing that. I'm afraid that I can't reproduce the trams issue (although haven't tried on the XP virtual machine). Can you test to see whether you still get the problem if you re-compile the pakset with the makeobj from -devel?

As to the saved games, there are a few places in the -devel branch when I change the saved game file format - there are usually warnings when I do this, so this is not unexpected behaviour.

Thank you again for testing!

[jamespetts]

Hein,

if you don't want to build Pak128.Britain-Ex yourself, I have now uploaded a binary version of a testing release to use with -devel here.

[MCollett]

Schedule Minimum load:

• Tooltip says 'enter a value between 0 and 400', but the actual maximum is 255.  Only really noticeable for stagecoaches, where a full load is 300%; almost nothing else can be over 150%.
• Clicking the arrows does not cycle between typical useful values, including 100%, but around a strange sequence, different in the two directions.  Going up gives 0, 4, 28, 52, 132, 8, 28, ... . Going back gives 0, 144, 132, 52, 28, 4, 0, ... .

Commit 6be2b59 (30/6/2012), compiled on Mac OS X 10.6.8.

[jamespetts]

Thank you for the report! Found and fixed. The issue was that the variable was a uint8 rather than uint16. Unfortunately, replacing it with a uin16 requires a different save game format, which means that any games saved with previous self-compiles from -devel or the RC binary will not load with the latest -devel build or any subsequent release. This does not affect official release versions.

[jamespetts]

The latest release candidate (see here) no longer seems to display the trams issue according to my tests with the Windows XP virtual machine. Does anyone care to re-test to verify?

[MCollett]

More scheduling issues.  In this savegame, there are three empty Telford-Daventry trains waiting at Telford Station.  There are two distinct errors here:

• The trains should leave when 100% full, and there are enough passengers waiting at the station to completely fill two trains.
• Non-full trains are scheduled to leave 10 times per 'month', but two of the waiting ones have been allocated the same departure slot.

I have seen similar behaviour earlier in the same game.

Commit d2dbf1d (15/7/2012), compiled on Mac OS X 10.6.8, plus Pak128.Britain-Ex-0.8.4.

[Carl]

Error (2) occurs pretty rarely, but it's been present since the advent of convoy spacing.

As for error (1) -- this is intended behaviour. Convoys will only load passengers 10 minutes before their scheduled departure. (If you accrue more than 100% load worth of passengers before this point, you probably need to increase the frequency of service!) The reason for this feature is that, otherwise, passengers could potentially board a convoy which still has (e.g.) 1 hour to wait before departure, and in the process miss several other services which would leave before that.



If you want a convoy to leave whenever its full load is present, I recommend you turn off convoy spacing and just use "minimum load = 100%".

[MCollett]

Error (2) occurs pretty rarely, but it's been present since the advent of convoy spacing.

It wasn't the only time it occurred at this station.

As for error (1) -- this is intended behaviour. Convoys will only load passengers 10 minutes before their scheduled departure. (If you accrue more than 100% load worth of passengers before this point, you probably need to increase the frequency of service!)

Hmm.  OK.  I had noticed the new 'don't load until shortly before departure' behaviour, but it hadn't occurred to me that it might be intended to apply even when there were enough passengers for an early departure.   

I understand the motive for it, and clearly it is a good thing when spacing is entirely determined by the schedule, but it does rather break the combination that I had been using in the previous released version of primarily scheduled services with occasional early departure 'specials'.   The motive for this was mainly to allow for a little sloppiness in time-keeping; if an incoming convoy just missed the scheduled time, and demand was heavy, it would leave soon anyway, rather than making the whole line slip a slot.   This was good for road services, where congestion always makes strict timetables iffy; more relevantly to the present case, it also helped smooth transitions from one schedule to another, when the frequency of services was changed.  This was exactly how the mess in this savegame arose: because there was a backlog of passengers, I had just increased the frequency of services, which meant that successive incoming trains just missed the new scheduled departure times, which (thanks to this 'ten minute' rule) further increased the backlog ... 

Best wishes,
Matthew

[Carl]

I'm a big fan of options that allow everyone to tailor functionality to their needs. As such I'd be in favour of an option in the settings menu which disables the "wait until 10 minutes before departure before boarding" -- though I think it should be enabled by default. This should be fairly easy to code, I'd have thought. What do you think, James?

It wasn't the only time it occurred at this station.

There are certain patterns that can set it off. If a convoy arrives at a spacing station at around the same time as another has been timed to leave, then that convoy can often be placed into the "wrong" slot, leading to more than one convoy being timed to leave in a single slot. I'm not sure we've managed to pin down the cause of this, yet.

[jamespetts]

Thank you both for your feedback on this - this is a most useful discussion. It is a good idea, I think, to make the waiting until ten minutes before departure time optional, but I think that this might well be done better on a per schedule basis than applied generally to the game as a whole. This would allow greater flexibility. Do you think that you could manage to code it in that way, Carl? I can provide assistance as far as modifying the loading/saving element of things if necessary (I can't remember whether you are familiar with this aspect of things or not - it can be slightly tricky to code if you're not familiar with it). It would need to be a variable of the schedule_t (formerly fahrplan_t) class, and load and save with schedules.

[Carl]

I've not yet had any successful experience with coding loadsave stuff -- modifying equations and departure conditions has been about my limit so far. I think I could just about figure out how to code this as a universal setting, but I doubt I could do it on a per-line basis. I never even managed to figure out how to convert the "max wait for load" into an integer :(

Actually: it may be beneficial to have both a universal setting and a line-specific setting for this. The universal setting would specify the default status of a line (i.e. wait until 10 minutes before departure, or don't) and the line-specific setting could be designed for exceptions to this rule. My thought here is that if we make it purely a per-line setting, then one of two groups -- either players like me or players like mcollet -- are going to have a lot of tedious work in switching this setting to either on or off on all their lines (depending on the default setting). If the default status of the setting can be altered, along with per-line alterations, we'll avoid this. 

[jamespetts]

If you are able to code a value into the schedule class, and you let me know that it will need loading/saving, I shall be able to code the loading/saving routine for it. The way to do it on a per line basis would be to have an option in the schedule dialogue box entitled something like, "always load immediately" and a tooltip stating something like, "If this option is selected, this convoy will always load immediately on arriving at a stop, even if its scheduled departure time is more than 10 minutes in the future". There could be a bool load_immediately member in the schedule_t class recording the status of this option.

As for the default setting, this can work, and can be saved locally only (in umgebung_t rather than settings_t), as the per line settings are the only things that will need to be loaded/saved over the network.

[Carl]

That sounds do-able. I'll take a look at this in the next few days, then. Thanks for the pointers, James!

[jamespetts]

One thing of which you ought to take note, however: when you are implementing the UI for changing schedules, make sure that it is network safe (in other words, that, in a network game, the instruction to change the schedule (in this case, the always load immedaitely option) should be trasmitted from the client to the server, and from the server to all the clients). This means using the tool interface from simwerkz.cc. What I recommend is looking at the way in which other boolean items in the schedules are changed and copy that, modifying the identifiers for the particular tool as necessary.

I hope that that is clear.

[MCollett]

There are certain patterns that can set it off. If a convoy arrives at a spacing station at around the same time as another has been timed to leave, then that convoy can often be placed into the "wrong" slot, leading to more than one convoy being timed to leave in a single slot.

Yes, that might be the culprit in this case -  odd things seemed to happen more often when one convoy arrived while another was in the process of reversing to leave. 

It is a good idea, I think, to make the waiting until ten minutes before departure time optional, but I think that this might well be done better on a per schedule basis than applied generally to the game as a whole.

If an explicit option is introduced, then per schedule, please: even though I have pointed out some drawbacks of the ten-minute rule, I still agree that is is desirable for stably running rail timetables, and would not want to disable it globally.   But even better than 'yet another option' would be automatic determination:  if the route has an impossibly large early departure target (i.e. is running strictly to schedule), the ten-minute rule should apply; if it has an achievable one (i.e. is at least partly demand-driven) it should not.

Best wishes,
Matthew

[Carl]

Here's a small puzzling thing I just noticed. In the latest version, the Class 170 turbostar in Pak128.BritainEx, in 3-car formation, reports only being able to max out at 133km/h with an empty load. In fact, such a convoy should be able to reach 160kph. All of the vehicle's stats seem to be correct in the dat file (verified via TheRailwayCentre etc), so I presume something is up on the game's side of things.

I note that this is in fact unchanged since 10.11, so whatever's wrong here has not been introduced by recent changes.

[jamespetts]

Thank you for the report - I have asked Bernd to look into this.

[Carl]

Thanks. I should note that this is not isolated to that vehicle, but occurs with several of the sprinters in pak128.BritainEx. 2 and 3 car formations of these will often display max speeds much lower than they presumably should be.

[jamespetts]

Yes, I noticed that, too. I am wondering whether it is related to air resistance, as longer trains do not exhibit this problem.