Open erik-vos opened 6 months ago
The new <Score>
and <Count>
tags have been implemented in 18VA and now work fine.
Until all games have been adapted, the old style configuration will keep working; there is a new (and temporary) game parameter HasNewStyleReachAndScoreAttributes
that controls which style is used.
For future game development, the following aspects should be taken into account:
NetworkVertex
instances, after applying all factors that determine these values. Game-specific details should be added in a subclass (see StopValueCalculator_18VA
). The values can depend on all three of stop type, count type (major/minor/no) and train type. NetworkVertex
instances now get there final values per train type already at instantiation time. The reason for this change was, that in some cases route finding was terminated prematurely, delivering a sub-optimal income. However, it may prove necessary to reconsider this change, as I have already seen a case in an end game with two trains, where optimal route finding was rather slow. So far, only 18VA has been converted. I'm currently testing other games for correct processing of the old style configuration details. The regression test now runs perfectly.
For quite some time I have been working on an issue with 18VA, that basically is caused by the overloading of the stop type 'minor' for giving certain train stops different properties than others.
It is currently used for at least three purposes:
In most games that overloading does not generate problems, but in 18VA it does. In 18VA, neither of the following two 'minor' stop types is counted, but
In the code, the variable
ignoreMinors
is used for both purposes 2 and 3. I could fix this in a dynamic modifier, but that isn't neat, and I decided to try a new approach in which that 'minor' overloading will be reduced or even eliminated.In any case, the contents of the
<Score>
tag per train type will change. So far we have<Score towns="yes"|"no" cities="single"|"double" />
. This will be replaced by defining score factors per stop and train type. For 18VA this would give:<Score city="1" town="1" mine="1" port="1" offmap="1"/>
( where 'town' refers to 18VA mines, and 'mine' to CMDs);<Score city="1" town="0" mine="0" port="1" offmap="1" />
<Score city="2" town="0" mine="0" port="2" offmap="2" />
, but I'm not yet sure about that, as not only the simple revenue but also the port and offmap bonuses are doubled.The value "0" implies ignoring a stop, as is currently the case with
towns="no"
. As "1" will be the default, attributes with that value may be omitted.In addition I may need a new tag
<Count>
with a similar structure (and a default "yes" for all):<Count city="yes" town="yes" mine="yes" port="yes" offmap="yes"/>
<Count city="yes" town="no" mine="no" port="no" offmap="yes"/>
This way counting and scoring would be separated completely. An alternative approach could be to keep using stop type="minor" to define counting (as 18VA has no '+'-trains).This all is still in the works. Success isn't guaranteed, as the infamous
ignoreMinors
permeates much of the route finding and revenue calculating algorithms, which I still do not completely understand.