Re: [Rails-devel] Vertex visit sets (was: 1837 Revenue Calculation)

[Stefan F. <ste...@we...>]

Erik:
most likely it is my mistake in explaining the concept, but the "vertex 
(visit) set" is in fact a simple idea:

It simply defines that from  a set two or more vertices no more than one 
can be included in a train run ("the train can only visit one of them").

For the revenue calculation the rail network is translated into a graph 
(see http://en.wikipedia.org/wiki/Graph_%28mathematics%29).

A vertex/node of the revenue graph corresponds to objects on the 18xx 
map/tiles: E.g. each station is mapped into one vertex.

A simple example:
Canadian West in 1830 is a multi-hex offboard location (A9, A11).
However there are two vertices (one for A9, one for A11).

As they are separately modeled it would be possible for a train to run 
from A9 to A11: To avoid this a vertex set with two elements (A9 and 
A11) is defined and so the algorithm knows that only one of them can be 
included into a train run.

Currently the vertex set is created at the preparation stage of the 
revenue calculation automatically because the two hexes have identical 
city labels.

My proposal was to add the possibility for an explicit definition of 
such a vertex set: This would allow e.g. to add a vertex set that 
includes all mines of 1837 and thus the algorithm would know that a 
train can only run to one of those.

Hope that helps a little bit in understanding.

For the other issue: Sorry I did not realize that the HandmadeTiles was 
a deadend.  So your proposal is to use another id that defines the 
internal structure of Berlin and the two 18EU (B/V Paris) tiles?

Stefan



On 05/19/2012 03:42 PM, Erik Vos wrote:
>
>
>> -----Original Message-----
>> From: Stefan Frey [mailto:ste...@we...]
>> Sent: Saturday, May 19, 2012 1:46 PM
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] 1837 Revenue Calculation
>>
>> Erik:
>> if I remember correctly we only agreed to disagree on this issue. I cannot
>> prevent you from you creating new attributes for the xml-files, but I
> cannot
>> guarantee to write the supporting code for the revenue algorithm.
>>
>> A VertexVisitSet is a base element of the revenue calculation algorithm:
>> It covers all cases in which from a set of nodes/vertices only one member
> can
>> be path of a single train run. It covers not only visiting the stations
> from the
>> same hex twice, but also prevents running into multi-hex offboard hexes
>> several times and is used in conjunction with some of the bonus mechanisms
>> where only one bonus can be scored by a single train.
>>
>> If you have a better name for that I can use it throughout the program.
>> However I am reluctant to introduce a different terminology in the XML
> files
>> than in the program code for same mechanism.
>
> I can't provide a better name because I have no clue what the range of
> values and their meaning would be.
> But wouldn't we mix up functional and technical specification by mentioning
> such technical stuff into the XML?
> I probably wouldn't understand much of it, and would even less be able to
> explain it to others, so we would have to involve you anyway each time a new
> game gets set up.
>
> Terms like "runThrough", "loop" etc. I can understand and explain, but your
> route/revenue algorithms are beyond my horizon.
>
>> I understand that is good approach to limit t those cases where we have to
>> define handmade tile.xml definitions, but I do doubt that this will be
> possible
>> for all of them: There will be still Goderich and other tiles remaining,
> that
>> require that. It seems that taking HandMadeTiles.xml into account during
> the
>> creation of Tiles.xml is unavoidable. In fact I wonder if that is the main
> reason
>> why the Goderich bug creeps in again and again.
>
> I think there is a simple solution for each of the existing uses of
> HandmadeTiles.xml.
>
> 1. Goderich: as I said, this has already been persistently fixed in another
> way, i.e. by using different internal and external tile IDs.
> Goderich and Hamburg now have tile ID=-903 (i.e. a normal 3-way offboard
> tile) with<Access runThrough="yes"/>.
> Tile ID -939 is now used as an image only; it no longer exists in the
> Tiles.xml files of these games.
> As far as I have been able to test, this works.
>
> 2. The per-station 'city' attribute: can equally well be moved to
> TileSet.xml, provided that the attribute name is changed, e.g. to just
> 'name', although that would be an equally bad description of the purpose of
> this attribute.
> For the existing uses, I think 'mutexID' would be more descriptive, but that
> would not well cover your proposed usage in the 1837 ZKB tile.
> In any case, it would still be returned by station.getCityName(), so you
> would not be affected.
>
> Indeed another approach, perhaps to be implemented later, could be to
> replace it by vertexWhatever, if that and its values can be named so to be
> understandable to mortals like me.
>
> 3. The per-tile 'name' attribute (used for the 1825 water tiles and
> half-tiles to tweak the TD-provided name for use in some labels): any
> overrides can as well be added to TileSet.xml.
>
> With these fairly simple measures, there is no more need for
> HandmadeTIles.xml.
>
>> * Replace the implicit name convention for creating VertexVisitSets by an
>> explicit mechanism. Details have to be discussed and agreed on.
>
> Well, for now I can't provide any input to such a discussion, except by
> stating that both name and values should be either easily understandable or
> well documented.
>
> Erik.
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel