Open erik-vos opened 1 year ago
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.
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:
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.