Re: [Rails-devel] 1837 Revenue Calculation

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

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 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.

So my proposal is:
* Keep the handmade tiles so far. As long as there is no alternative it 
should be a supported feature of Rails.

* Replace the implicit name convention for creating VertexVisitSets by 
an explicit mechanism. Details have to be discussed and agreed on.

Hope that this is a compromise you can live with.

Stefan

On 05/19/2012 12:33 PM, Erik Vos wrote:
>> I would still prefer a solution which assigns the mine station of the ZKB
> tile
>> the name "mine" and the town on that tile no name.
>
> IMO that would be unsustainable, and against the direction we have chosen
> not so long ago.
>
>> The scenario that both have the name "mine", but that the "loop"
>> attribute on the map.xml overrides the behavior seems odd to me.
>
> My reference to 'loop' only referred to the rather different 1835 and 18EU
> cases that you recently mentioned in an aside to this discussion.
>
>> Maybe the best solution in the long run is to add a "vertexSet"
>> attribute to stations directly to avoid connecting the functionality with
> the
>> labeling issues.
>
> Maybe, but then I'd welcome a more user-friendly name for such an attribute.
>
> My preference would still be to use/extend/tweak the<Access>  attributes,
> which are explicitly meant to specify stop/station details.
>
> I'm considering to create a new class named Access to collect all such
> parameters, rather than having these scattered around as separate attributes
> in quite a number of other classes.
>
>> I was under the impression, that you had implemented a bypass for hand-
>> made definitions in Tiles.xml: Is not exactly that the function of
>> HandmadeTiles.xml in the Tiles directory?
>> And the Berlin tile of 1835 is missing, whereas the 18EU tiles are
> included.
>> Would not adding Berlin tile there make it safe?
>
> Ah, I had completely forgotten about that file.
> I suppose it's only current function is to have Tiles.xml modifications
> readily available for manual replacement after creating the overall
> Tiles.xml file.
> In any case, it is not used by ConvertTilesXML in the Tiles.xml creation
> process.
>
> Perhaps I once intended to work on automatically merging the contents of
> HandmadeTiles.xml into Tiles.xml.
> But later on, we agreed upon adding the<Access>  tag, which has (at least in
> my mind) provided a much better solution to this kind of issues.
> So I don't intend to do any more work to facilitate the legacy process of
> tweaking Tiles.xml.
>
>>> For exactly this purpose I have added the 'loop' attribute, which was
>>> intended to replace your initial approach.
>>> Adding<Access  loop="no"/>    to the relevant hex definitions in Map.xml
>>> should enable you to pick up the exception via tile.isLoopAllowed() or
>>> stop.isLoopAllowed().
>>
>> That is the intention of this attribute, however it is not (yet)
>> supported by the revenue calculation code.
>
> I know.
>
> OK, to fix the existing issues you mentioned I'll scan HandmadeTiles.xml for
> cases that still apply and put these into the overall Tiles.xml.
> At least the Goderich tile can be removed because that problem has in the
> meantime been addressed in a different way.
> But I must repeat the warning that this procedure is unsustainable.
>
>> And the attribute itself does not fix the issue we have to address for
> 1837.
>
> Sure, and I had not intended to say otherwise.  For 1837 I proposed to add
> another attribute to allow<Access>   items affect individual stations rather
> than all stations on a tile.
>
> 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