Re: [Rails-devel] Stop properties

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

Erik,

> I think I have not added any setters yet, but I have already mentioned that
> we might need some. In cases like 1851 Birmingham, runTo is in fact
> phase-dependent (although you have probably already solved that with some
> modifier).

Yes that is a GraphModifier that removes Birmingham  from the graph in the 
phases required.

The runTo modifier is a generalization of that (except that it is not phase-
dependent).

> 
> I know, but I had hoped that you would like to add it (apologies for not
> asking so explicitly).
> 
> It's all in the spirit of giving more power to the non-programmers amongst
> us.  Several people have already started implementing games by preparing
> XML, only to find that they have to involve you and me to get the details
> done.  I'm very well aware that we cannot make everything configurable in
> XML, and that it would be silly to strive for it.  But why not do it for
> simple settings that occur relatively frequently?  I thought 'loop' would
> be such a case, and pretty easy to implement (but I cannot really judge
> that).

I am aware and support of other people adding games ;-)
The two important words above are "simple" and/or "frequently". 

However quite often it seems that two games share the same mechanism (most of 
the time because they use the same terminology), but they are substantially 
different in mechanism: For example unfortunately it is not enough to add an 
attribute " merge='yes' " to companies to allow them merging...

So the 1860 example cannot be easily solved by adding the attributes. The 
short explanation is that currently all simple track that only connects the 
scoring vertices are optimized away. It is possible to protect vertices from 
that (for similar cases), however I do not like the idea to protect all track 
vertices as it could be a drag on the revenue calculation, especially as 1860 
has some other rules to consider. So let us wait until we implement that game.

> 
> We also have cases like 18EU Paris/Berlin/Vienna, where I already have
> added loop="no". If you have no plan to start supporting it soon, my
> hopeful loop settings should indeed be removed.

I forgot about that case: If only scoring vertices are meant this is possible.
Maybe we should call this scoreTwice = "no" as it avoids people from thinking 
this is identical to loop (revisit twice).

This would replace the current identical name mechanism. 
However we would still need a mechanism to prevent scoring multiple-hex 
offboard areas twice. I am not sure how you would like to implement that?

I think an off-board area attributes (name, values etc.) should be defined 
only once and then have a list of hexes it refers to.
Then this object could be used directly to create the vertexVisitSet that I 
currently have to create for the algorithm.
But it makes the setup of the hexes harder, but I believe that is the correct 
solution. I could volunteer to implement that.

Stefan