Re: [Rails-devel] Implementation details for revenue calculation

[Phil D. <de...@gm...>]

On 27 April 2010 23:37, Stefan Frey (web.de) <ste...@we...> wrote:
> Hamburg: I have to admit that I do not like the Hamburg offboard tile: The
> graphical representation does not define exactly, where the value vertex is,
> as it does not contain any type of station.
> I assume the most natural interpretation is to assume a non-tokenable station
> in the middle of the hex (similar to tile 12, only that the slot cannot be
> filled). To work with the offboard bonuses, an additional vertex is connected
> to the station vertex, which acts as a sink (has no neighbors defined, thus
> similar to a tokened out station). All of the bonus combinations for Hamburg
> use that vertex to enforce the restriction that the bonus runs have to stop
> in Hamburg. (D)

Note that 1856 has the Goderich tile which is the same as Hamburg, I
see no reason why this logic should hold up for that as well but it's
worth bearing in mind.  EU of course has the added complication that
if Hamburg starts or ends a run it can be part of the red-red bonus
but again I don't think that causes too many issues

> Pullman: If I understand the 18EU rules correctly, the Pullman is an exception
> to the second sentence under 4.4.3: "... must calculate the maximum possible
> earnings". 4.4.9., second paragraph defines that "... doubles the value of
> any City or Off-Map Location of the President's choice".
> To capture the spirit of the rules and to simplify things the Pullman will not
> be part of the maximization process, but the President will be prompted to
> select one the city values of the runs.

Hmm, not sure I agree, I think this is a case of slightly misleading
rules text.  I think that the 3: "... must calculate the maximum
possible earnings" is always in force and Pullmans must take account
of it.  David Hecht is pretty vocal on the 18XX yahoo list so it's
always worth posting the question if we aren't in agreement on this.
To make the 'must maximise' work for route calculation I would think
that your D approach should work here (I'm beginning to think that
with all these virtual vertices, route bonuses etc. that the EU
revenue calc might take a little while!)

Phil