1826: Non-optimal runs for 10H-trains

[erik-vos]

During testing using a real game (published by Steve Thomas in his 'zine) I noticed that the revenue calculator sometimes does not find the best run for a company. Examples:

The GC run with a 10H-train should have included M13 (St. Etienne) for an F30 higher income.

The Alsatian run with a 10H-train should have included K17 (Geneva) for an F30 higher income.

Possibly this bug is specific to H-trains, as in my experience most 'normal' train runs are OK.
The bad news is that I have little hope to be able fix this problem - the revenue calculator still is much of a mystery to me.

I have added an advice to the 1826 game notes to enable the revenue spinner, and correct non-optimal runs.

See also issue #483 for an even worse case.

[erik-vos]

It turns out that the lengths of H-trains were not always taken into account in the route finding process for these trains. The whole H-train route calculation process uses the variable maxMajors, which gets a different meaning with H-trains. It seems to me that overriding RevenueCalculatorMulti methods in RevenueCalculatorMultiHex is incomplete, Maybe the former class should get an additional separate maxHexes attribute per train, which is used everywhere where currently maxMajors and maxMinors are used with a H-train. But currently I have no grip on all that stuff.

To the defence of the developer of this code (AFAIK that was Stefan) I would say, that 1826 probably is the first game in Rails that uses H-trains, so I may be the first one who is really seriously testing with that type of train.

I have added a few stopgaps in RevenueAdapter and RevenueCalculator to make it work most of the time, In any case, the two cases shown above are now correct. But there still are cases that go wrong, sometimes even resulting in a zero revenue. So my recommendation to use the revenue spinner still stands.