Re: [Rails-devel] revenue library

[Stefan F. (web.de) <ste...@we...>]

Erik:
yes you are right:

The city location vertex set rule does not cover cases below. 
And you are right again that (any of) your suggested rule(s) would cover the 
Berlin tile as well. 

However there is some reason why I was reluctant to implement your rule:
The main issue is that is difficult to define the rule first and then to 
transfer it to the vertex graph. 

To cut that short:
1) Is the rule "only one city on a hex can be visited" (and does this mean 
city or any kind of station?) or "if a train has left any hex,it may not 
reenter that same hex".

2) Especially the implementation of the latter defintion is particularly hard 
to convert into the vertex structure: If I define all side vertexes as a 
vertex set, a train will never be able to leave the hex again. Most likely 
this requires the addition of additional vertices for entry/departure of the 
hex to control for that (where all of the entry vertices are defined as a 
joint set).

Thus I will live with the simple definition for now and leave the more complex 
cases for later.

Stefan


On Wednesday 19 May 2010 20:57:38 Erik Vos wrote:
> Stefan,
>
> I have no major problem with your solution, but I doubt if it will prove to
> be "sustainable" in the long term.
>
> How would you address:
>
> - 1825, where the restriction that only one city on a hex can be visited
> applies to all OO-style hexes? There are quite some of these hexes on all
> the units and regional kits, and the tiles are standard OO tiles.
>
> - 1860, where a similar rule applies to *all* tiles, including such plain
> track tiles as green 16-22, as well as some special tiles. Here the rule
> simply is: if a train has left any hex, it may not reenter that same hex.
> Here it is not a city/station property, not even a hex property but a game
> property.
>
> I'd go for some way to assign that last rule ("if a train has left any hex,
> it may not reenter that same hex") to either selected hexes, or all hexes,
> or (in cases where off-board areas span multiple hexes), sets of hexes.
> Such an approach would cover all cases known to me.
>
> Erik.
>
> -----Original Message-----
> From: Stefan Frey (web.de) [mailto:ste...@we...]
> Sent: Sunday 16 May 2010 23:49
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] revenue library
>
> Erik:
> see below.
>
> On Saturday 15 May 2010 22:04:15 Erik Vos wrote:
> > -> Berlin tile still has to be added to the hand-made tiles (city names
> > to block double runs to yellow Berlin).
> >
> > [EV] Does this mean that the one and only function of Station city names
>
> in
>
> > the Tile definitions is to block multiple runs?
> > That does not sound very logical to me. Cannot this blocking feature
>
> (much)
>
> > better be made a (single) MapHex property? Or, if it's colour-dependent,
>
> in
>
> > TileSet?  Like <NoMultipleAccess/> or such?
>
> I found it logical, but I came up with that solution, so that does not mean
> too much. And all solutions have reasonable pro/cons. My reasons were:
>
> A) Choosing the city attribute mirrors the solution for the offboard
> locations/stations. The only difference is that for offboard locations the
> city name (like the revenue value) is defined on the MapHex instead of
> creating different tiles for each off-board area. Allows easy
> implementation.
>
> I only hope that no one ever comes up with two different off-map locations
> combined on one hex, but that would cause headaches for the revenue value
> as
>
> well.
>
> B) Why not in TileSet? Stations are defined in Tile.xml, I did not want to
> split that information over various  files.
>
> C) Why not one property per MapHex/Tile? It allows easily to have
> restrictions
> that combine several hexes/tiles into one vertex set (as I call them). And
> think about a tile with three stations, where only belong to one city.
> I admit that all that is not required for the games currently implemented.
>
> Stefan
>
> ---------------------------------------------------------------------------
>- --
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ---------------------------------------------------------------------------
>---
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel