rails-devel — List for discussion of Rails development

Re: [Rails-devel] 2x Bug Reports 18TN Rails 1.7.3

[John D. G. <jd...@di...>]

On 2012-05-20 06:48, Stefan Frey wrote:
> Erik:
> to be precise: The game test cases are not invalidate, but the 
> associated reports have to be recreated for the test cases (as you did).
> 
> I will release a bug-fix Rails 1.7.5 tonight, so if there are further 
> fixes you will like to add...

18EU is still leaving on the board the stations of minor companies that
merged, if the station was not replaced by a major-company station
(whether because the major company already has a station in the hex or
the president chose not to keep that station).

It would be nice if Rails had a "Refresh the map" function (in Special?)
that worked for all games.

Re: [Rails-devel] 2x Bug Reports 18TN Rails 1.7.3

[Erik V. <eri...@xs...>]

> I will release a bug-fix Rails 1.7.5 tonight, so if there are further
fixes you will
> like to add...

Later this week, perhaps, but not today.

Erik.

Re: [Rails-devel] 2x Bug Reports 18TN Rails 1.7.3

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

Erik:
to be precise: The game test cases are not invalidate, but the 
associated reports have to be recreated for the test cases (as you did).

I will release a bug-fix Rails 1.7.5 tonight, so if there are further 
fixes you will like to add...

Stefan

PS: I will use the same text for the revenue calculation information text.



On 05/20/2012 02:58 PM, Erik Vos wrote:
>> Related question to Erik: the civil war phase start is only shown as
> "Start of
>> Phase 3 1/2" in report window. Is it possible to make this more explicit?
>> Something like Civil War has started and one train is rendered unusable.
>
> Done.  All extra phase info, provided in<Phase><Info>  tags, is now also
> reported to the report window.
> The new text for 18TN is "Civil War begins. One train per company is
> unusable for one round."
>
> @Stefan,  this text sort of duplicates your "pretty print" text "Civil War
> is active."  I don't know if these two texts can/should be merged.
>
> 18TN and some 1835 test cases have been replaced.
> The info text "Closes all privates", used in 1835 at the start of phase 5,
> has been reformulated to "All privates close" to make it match with the
> Report style.
>
> No doubt a lot more interesting info could be added to many game reports
> this way.  But please note, that each addition can invalidate all or most
> JUnit test cases of the affected game.
>
> Note: the reuse of the existing extra phase info text means, that the same
> text is reported in the Info menu per phase, and in the report when that
> phase starts.
>
> 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

Re: [Rails-devel] 2x Bug Reports 18TN Rails 1.7.3

[Erik V. <eri...@xs...>]

> Related question to Erik: the civil war phase start is only shown as
"Start of
> Phase 3 1/2" in report window. Is it possible to make this more explicit?
> Something like Civil War has started and one train is rendered unusable.

Done.  All extra phase info, provided in <Phase><Info> tags, is now also
reported to the report window.
The new text for 18TN is "Civil War begins. One train per company is
unusable for one round."

@Stefan,  this text sort of duplicates your "pretty print" text "Civil War
is active."  I don't know if these two texts can/should be merged.

18TN and some 1835 test cases have been replaced.  
The info text "Closes all privates", used in 1835 at the start of phase 5,
has been reformulated to "All privates close" to make it match with the
Report style.

No doubt a lot more interesting info could be added to many game reports
this way.  But please note, that each addition can invalidate all or most
JUnit test cases of the affected game.

Note: the reuse of the existing extra phase info text means, that the same
text is reported in the Info menu per phase, and in the report when that
phase starts.

Erik.

Re: [Rails-devel] 2x Bug Reports 18TN Rails 1.7.3

[Mike B. <com...@ip...>]

Thanks for the clarification, Stefan. Hopefully some good will come from the
error through your question to Erik.

Mike Bourke
Campaign Mastery http://www.campaignmastery.com
Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com



---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 120519-0, 19/05/2012
Tested on: 20/05/2012 8:57:13 PM
avast! - copyright (c) 1988-2012 AVAST Software.
http://www.avast.com

Re: [Rails-devel] 2x Bug Reports 18TN Rails 1.7.3

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

Mike,
thanks for your detailed feedback.
All of the reported behavior is due to the Civil War is active (check 
the 18TN rules for details).

Currently the revenue calculation shows this in the detailed view with 
the comment "Civil War is active". However it is possible to add more 
information there (like "Due to Civil War 3-train is inactive").

In the scenario a) GMO has only one train, thus no train runs at all, so 
no feedback from the revenue calculation at all. That is not that 
straightforward to change (but I will keep it on my list).

Related question to Erik: the civil war phase start is only shown as 
"Start of Phase 3 1/2" in report window. Is it possible to make this 
more explicit? Something like Civil War has started and one train is 
rendered unusable.

Stefan


On 05/19/2012 10:22 AM, Mike Bourke wrote:
> Hi guys,
>
> Well, here I am again with another couple of bugs to be ironed out before
> Rails is fully functional.
>
> Savegame: 18TN_20120518_0802_a.rails
>
> The above savegame is taken from quite early in the game. GMO has just
> finished laying track. It has a 3 train and two clear choices of route - one
> south, worth  $70, and one north worth $90. So why, when the player clicks
> "No token", does Rails fail to calculate a route that will pay a dividend?
>
> Savegame: 18TN_20120518_0806_e.rails
>
> In the next operating round, I noticed something else unusual. The L&N
> appears not to calculate its revenues incorrectly, ignoring its third train.
> The option shown has a two train running from B17 to A16 and the three train
> running through the initial railhead (F11-B13-H11) instead of running two
> trains from that rail head (B13-F11-E10 and B13-H11). Using the third train
> adds $40 to the revenue. I have not noticed this behaviour in earlier
> versions of Rails. Note the description of the Best Run value also reflects
> this - apparently completely ignoring the existence of the second 2-train.
> The same thing then happens to the IC in it's operating round. Refer to the
> above savegame.
>
> Savegame: 18TN_20120518_0817_d.rails
>
> A few seconds later, the same thing happens with the SOU's operating round.
> This company has two routes from home base (F17) to E22, and it has two
> trains - a two and a three train. The existence of the 2 train is completely
> ignored, as shown by the above savegame.
>
> However, the GMO, which now has two 3-trains, is able to run them both
> according to the game. Later in the game, when the L&N has both a 3 and a 4
> train, they behave normally. So this appears to have something to do with 2
> trains specifically.
>
> Mike Bourke
> Campaign Mastery http://www.campaignmastery.com
> Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com
>
>
>
>
>
>
> ---
> avast! Antivirus: Outbound message clean.
> Virus Database (VPS): 120518-0, 18/05/2012
> Tested on: 19/05/2012 6:22:12 PM
> avast! - copyright (c) 1988-2012 AVAST Software.
> http://www.avast.com
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> 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

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

[Erik V. <eri...@xs...>]

Stefan,

Thanks for your explanation. 
"Vertex set" sounds like a set of vertexes, but I understand you are using
it in a more restricted sense: a "set of mutually exclusive vertexes",
right?
I thought such a thing was called a mutex, not so?

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

No, that wouldn't help in this case.  My preference still is to use
'loop="no"' for these cases (in Map.xml).
The effect should be (if I understand your terminology) that all stations on
a single Tile or MapHex having this access parameter should be included in a
vertex set.

Indeed we need a different mechanism for multi-hex constraints, and perhaps
we should then use that mechanism for single-hex constraints as well, to
replace 'loop="no"'.
The continued use of 'city' (or 'name' or 'mutexID') is also acceptable to
me if we move it to TileSet.xml, which should be easy to do.
For other (better?) solutions I await your detailed proposal.

The use of different internal and external tile IDs is mainly meant to
handle cases where the image does not reflect the actual tile structure
(tracks and stations). In a few cases it is also used to avoid XML code
duplication where structurally identical tiles have different images
(sometimes just a different background colour).
Notorious examples are:
- Goderich (explained in my previous post)
- the 'stick' versions of the brown plain track tiles 544-546 in 18EU and
other games.
- the Altoona and Reading tiles in the 1830 Coalfields and Reading variants.
The tile images show an unconnected station, which in reality should be
handled as if it is connected to all track edges.
In all such cases you'll see either <Tile id="xxx" pic="yyy"> or <Hex ...
tile="xxx" pic="yyy">.

Erik.

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

Re: [Rails-devel] 1837 Revenue Calculation

[Erik V. <eri...@xs...>]

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

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

Re: [Rails-devel] 1837 Revenue Calculation

[Erik V. <eri...@xs...>]

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

[Rails-devel] 2x Bug Reports 18TN Rails 1.7.3

[Mike B. <com...@ip...>]

Hi guys,

Well, here I am again with another couple of bugs to be ironed out before
Rails is fully functional.

Savegame: 18TN_20120518_0802_a.rails

The above savegame is taken from quite early in the game. GMO has just
finished laying track. It has a 3 train and two clear choices of route - one
south, worth  $70, and one north worth $90. So why, when the player clicks
"No token", does Rails fail to calculate a route that will pay a dividend?

Savegame: 18TN_20120518_0806_e.rails

In the next operating round, I noticed something else unusual. The L&N
appears not to calculate its revenues incorrectly, ignoring its third train.
The option shown has a two train running from B17 to A16 and the three train
running through the initial railhead (F11-B13-H11) instead of running two
trains from that rail head (B13-F11-E10 and B13-H11). Using the third train
adds $40 to the revenue. I have not noticed this behaviour in earlier
versions of Rails. Note the description of the Best Run value also reflects
this - apparently completely ignoring the existence of the second 2-train.
The same thing then happens to the IC in it's operating round. Refer to the
above savegame.

Savegame: 18TN_20120518_0817_d.rails

A few seconds later, the same thing happens with the SOU's operating round.
This company has two routes from home base (F17) to E22, and it has two
trains - a two and a three train. The existence of the 2 train is completely
ignored, as shown by the above savegame.

However, the GMO, which now has two 3-trains, is able to run them both
according to the game. Later in the game, when the L&N has both a 3 and a 4
train, they behave normally. So this appears to have something to do with 2
trains specifically.

Mike Bourke
Campaign Mastery http://www.campaignmastery.com
Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com

Re: [Rails-devel] 1837 Revenue Calculation

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

You are right, this is confusing:

As already mentioned, this is the unfortunate side-effect of the 
implicit use of an identical city-attribute to define stations that 
cannot be visited together in the same run.

To avoid that and for flexibility I suggest using a vertexSet or 
stationSet tag for map.xml instead in the long-run.

A quick workaround for 1837 is to setup the vertexSet inside the
RevenueModifiers which we need anyway.

Stefan


On 05/19/2012 08:42 AM, John David Galt wrote:
> On 2012-05-18 21:49, Stefan Frey 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.
>
> I have the map XML set up to use the coal company name as city="name".  Perhaps
> more than one string is needed, but I have been assuming that city="string" is
> for displaying.
>
> ------------------------------------------------------------------------------
> 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

Re: [Rails-devel] 1837 Revenue Calculation

[John D. G. <jd...@di...>]

On 2012-05-18 21:49, Stefan Frey 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.

I have the map XML set up to use the coal company name as city="name".  Perhaps
more than one string is needed, but I have been assuming that city="string" is
for displaying.

Re: [Rails-devel] 1837 Revenue Calculation

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

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

The scenario that both have the name "mine", but that the "loop" 
attribute on the map.xml overrides the behavior seems odd to me.

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. Or add a vertexSet tag to Map.xml which 
explicitly lists the stations that cannot be run to at the same time.

More comments see below.
Stefan


On 05/18/2012 07:40 PM, Erik Vos wrote:
> Stefan,
>
> Modifying Tiles.xml is inherently unsafe.  You are betting on me not having
> to fix tiles in a game, or if I do, that I would remember to retrofit your
> changes manually.
> I'd consider that a pretty unsafe bet, as it has already turned out to be
> with 1835 - although not yet with 18EU.
> In theory I could hardcode such specialties in the now generic
> ConvertTilesXML class, but that is not a route that I want to take.
> (The whole tile creation process is explained at length in the Wiki page
> that I published earlier this week.)

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?

>
> 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.
And the attribute itself does not fix the issue we have to address for 1837.

>
> Erik.
>
>> -----Original Message-----
>> From: Stefan Frey [mailto:ste...@we...]
>> Sent: Friday, May 18, 2012 1:24 PM
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] 1837 Revenue Calculation
>>
>> Erik:
>> in principle there is no need to add a special type for individual stops.
> I
>> referred to the attribute that allowed the naming of stations in
> Tiles.xml.
>>
>> The current code supports the "city"-attribute for the Station tag in
> Tiles.xml.
>> This allowed the naming of individual stations and thus creates
> automatically
>> VertexVisitSets for identical named stations.
>> This is used for e.g. for the Paris and Berlin/Vienna Tiles in 18EU.
>>
>> It was also (initially) implemented for Berlin in 1835, however this was
> erased
>> by a commit from you 11 months ago (so this requires a fix, as yellow
> Berlin-
>> Berlin runs are allowed currently).
>>
>> I remember that you were in opposition to this approach (most likely as
> you
>> create the Tiles.xml automatically and so there is always the danger of
>> removing this, but I believed that you were able to provide an automatic
> by-
>> pass). So maybe you can suggest a different handling.
>>
>> Keep in mind that the name approach is used for the off-board map,
>> however the names are taken here from Map.xml.
>>
>> Stefan
>>
>>
>> On 05/17/2012 10:54 AM, Erik Vos wrote:
>>> OK.
>>> We don't yet have the capability to assign special types to individual
>>> stops on one tile, so I will work to add such a capability.
>>> Perhaps adding a 'stop' attribute to the<Access>   tag will do (in
>>> other places 'city' is used, but I think those can better be replaced by
> 'stop'
>>> too).
>>>
>>> Erik.
>>>
>>>> -----Original Message-----
>>>> From: Stefan Frey [mailto:ste...@we...]
>>>> Sent: Tuesday, May 15, 2012 1:53 PM
>>>> To: Development list for Rails: an 18xx game
>>>> Subject: Re: [Rails-devel] 1837 Revenue Calculation
>>>>
>>>> Erik:
>>>> town or offboard does not matter as the node will be replaced by a
>>>> bonus- node anyway.
>>>>
>>>> Another good thing about setting name/id to "mine" is that this
>>>> identifies
>>> the
>>>> correct node(s) to replace (in the case of ZKB).
>>>> So for ZKB the definition of the tile should be a two-town tile with
>>>> the
>>> correct
>>>> town labeled as "mine".
>>>> Stefan
>>>>
>>>>
>>>> On 05/15/2012 01:37 PM, Erik Vos wrote:
>>>>> BTW I chose the mines to be town type because towns cannot be
>> tokened.
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Erik Vos [mailto:eri...@xs...]
>>>>>> Sent: Tuesday, May 15, 2012 1:12 PM
>>>>>> To: 'Development list for Rails: an 18xx game'
>>>>>> Subject: Re: [Rails-devel] 1837 Revenue Calculation
>>>>>>
>>>>>> See below.
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Stefan Frey [mailto:ste...@we...]
>>>>>>
>>>>>>> B) Define the coal tiles as offboard fields. Add a
>>>>>>> StaticRevenueModifier
>>>>>> that
>>>>>>> removes the offboard (major scoring) node and replace it by a
>>>>>>> bonus vertex for the G-trains only. (Bonus vertices can be defined
>>>>>>> to be train
>>>>>> dependent,
>>>>>>> whereas scoring nodes have to be identical).
>>>>>>
>>>>>> I have provisionally defined the mine tiles as fixed (i.e. grey)
>>>>>> with a
>>>>> town that
>>>>>> has zero (i.e. variable) value.
>>>>>> (This definition is mainly for usage in XML, the real picture will
>>>>>> be
>>>>> different
>>>>>> once we have better SVG tiles).
>>>>>> I can change that if you want, but my thinking was that this hex
>>>>>> would not really behave as an off-board one.
>>>>>> And I can replace the town by a city if you prefer that.
>>>>>>
>>>>>> One potential problem is the ZKB mine tile, with has two stops: a
>>>>> fixed-value
>>>>>> village and a variable-value mine.
>>>>>> Can you handle that? See below.
>>>>>>
>>>>>>> C) Add a name="Mine" attribute to all mines. This automatically
>>>>>>> treats
>>>>>> them
>>>>>>> as a VertexVisitSet and thus a train can only visit one of them.
>>>>>>> Alternatively this could be checked in step D) too.
>>>>>>
>>>>>> In Map.xml or in TileSet.xml?
>>>>>> For the ZKB this should apply to only one of the two stops, so
>>>>>> perhaps we should add an extra 'city="1"' attribute.
>>>>>>
>>>>>>> D) Add a DynamicRevenueModifier that checks that routes of
>>>>>>> G-Trains have at least one mine in their route, otherwise the
>>>>>>> route will be
>>> void.
>>>>>>>
>>>>>>> I can easily add those elements, however I will wait until it is
>>>>>>> possible
>>>>>> to have
>>>>>>> 1837 at least startup, so that I am able to test.
>>>>>>
>>>>>> 1837 already starts, in that it displays all initial windows. I
>>>>>> haven't
>>>>> tried
>>>>>> anything beyond that point. The only specific class is
>>>>>> StartRound_1835; otherwise, the 1830 rules apply.
>>>>>>
>>>>>> 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
>>>>>
>>>>>
>>>>> --------------------------------------------------------------------
>>>>> --
>>>>> --------
>>>>> 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
>>>>
>>>>
>>>>
>>> ----------------------------------------------------------------------
>>> ------
>>> --
>>>> 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
>>>
>>>
>>> ----------------------------------------------------------------------
>>> --------
>>> 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
>>
>>
>>
> ----------------------------------------------------------------------------
> --
>> 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
>
>
> ------------------------------------------------------------------------------
> 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

Re: [Rails-devel] 1837 Revenue Calculation

[Erik V. <eri...@xs...>]

Stefan,

Modifying Tiles.xml is inherently unsafe.  You are betting on me not having
to fix tiles in a game, or if I do, that I would remember to retrofit your
changes manually.
I'd consider that a pretty unsafe bet, as it has already turned out to be
with 1835 - although not yet with 18EU.
In theory I could hardcode such specialties in the now generic
ConvertTilesXML class, but that is not a route that I want to take.
(The whole tile creation process is explained at length in the Wiki page
that I published earlier this week.)

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

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Friday, May 18, 2012 1:24 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1837 Revenue Calculation
> 
> Erik:
> in principle there is no need to add a special type for individual stops.
I
> referred to the attribute that allowed the naming of stations in
Tiles.xml.
> 
> The current code supports the "city"-attribute for the Station tag in
Tiles.xml.
> This allowed the naming of individual stations and thus creates
automatically
> VertexVisitSets for identical named stations.
> This is used for e.g. for the Paris and Berlin/Vienna Tiles in 18EU.
> 
> It was also (initially) implemented for Berlin in 1835, however this was
erased
> by a commit from you 11 months ago (so this requires a fix, as yellow
Berlin-
> Berlin runs are allowed currently).
> 
> I remember that you were in opposition to this approach (most likely as
you
> create the Tiles.xml automatically and so there is always the danger of
> removing this, but I believed that you were able to provide an automatic
by-
> pass). So maybe you can suggest a different handling.
> 
> Keep in mind that the name approach is used for the off-board map,
> however the names are taken here from Map.xml.
> 
> Stefan
> 
> 
> On 05/17/2012 10:54 AM, Erik Vos wrote:
> > OK.
> > We don't yet have the capability to assign special types to individual
> > stops on one tile, so I will work to add such a capability.
> > Perhaps adding a 'stop' attribute to the<Access>  tag will do (in
> > other places 'city' is used, but I think those can better be replaced by
'stop'
> > too).
> >
> > Erik.
> >
> >> -----Original Message-----
> >> From: Stefan Frey [mailto:ste...@we...]
> >> Sent: Tuesday, May 15, 2012 1:53 PM
> >> To: Development list for Rails: an 18xx game
> >> Subject: Re: [Rails-devel] 1837 Revenue Calculation
> >>
> >> Erik:
> >> town or offboard does not matter as the node will be replaced by a
> >> bonus- node anyway.
> >>
> >> Another good thing about setting name/id to "mine" is that this
> >> identifies
> > the
> >> correct node(s) to replace (in the case of ZKB).
> >> So for ZKB the definition of the tile should be a two-town tile with
> >> the
> > correct
> >> town labeled as "mine".
> >> Stefan
> >>
> >>
> >> On 05/15/2012 01:37 PM, Erik Vos wrote:
> >>> BTW I chose the mines to be town type because towns cannot be
> tokened.
> >>>
> >>>> -----Original Message-----
> >>>> From: Erik Vos [mailto:eri...@xs...]
> >>>> Sent: Tuesday, May 15, 2012 1:12 PM
> >>>> To: 'Development list for Rails: an 18xx game'
> >>>> Subject: Re: [Rails-devel] 1837 Revenue Calculation
> >>>>
> >>>> See below.
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Stefan Frey [mailto:ste...@we...]
> >>>>
> >>>>> B) Define the coal tiles as offboard fields. Add a
> >>>>> StaticRevenueModifier
> >>>> that
> >>>>> removes the offboard (major scoring) node and replace it by a
> >>>>> bonus vertex for the G-trains only. (Bonus vertices can be defined
> >>>>> to be train
> >>>> dependent,
> >>>>> whereas scoring nodes have to be identical).
> >>>>
> >>>> I have provisionally defined the mine tiles as fixed (i.e. grey)
> >>>> with a
> >>> town that
> >>>> has zero (i.e. variable) value.
> >>>> (This definition is mainly for usage in XML, the real picture will
> >>>> be
> >>> different
> >>>> once we have better SVG tiles).
> >>>> I can change that if you want, but my thinking was that this hex
> >>>> would not really behave as an off-board one.
> >>>> And I can replace the town by a city if you prefer that.
> >>>>
> >>>> One potential problem is the ZKB mine tile, with has two stops: a
> >>> fixed-value
> >>>> village and a variable-value mine.
> >>>> Can you handle that? See below.
> >>>>
> >>>>> C) Add a name="Mine" attribute to all mines. This automatically
> >>>>> treats
> >>>> them
> >>>>> as a VertexVisitSet and thus a train can only visit one of them.
> >>>>> Alternatively this could be checked in step D) too.
> >>>>
> >>>> In Map.xml or in TileSet.xml?
> >>>> For the ZKB this should apply to only one of the two stops, so
> >>>> perhaps we should add an extra 'city="1"' attribute.
> >>>>
> >>>>> D) Add a DynamicRevenueModifier that checks that routes of
> >>>>> G-Trains have at least one mine in their route, otherwise the
> >>>>> route will be
> > void.
> >>>>>
> >>>>> I can easily add those elements, however I will wait until it is
> >>>>> possible
> >>>> to have
> >>>>> 1837 at least startup, so that I am able to test.
> >>>>
> >>>> 1837 already starts, in that it displays all initial windows. I
> >>>> haven't
> >>> tried
> >>>> anything beyond that point. The only specific class is
> >>>> StartRound_1835; otherwise, the 1830 rules apply.
> >>>>
> >>>> 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
> >>>
> >>>
> >>> --------------------------------------------------------------------
> >>> --
> >>> --------
> >>> 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
> >>
> >>
> >>
> > ----------------------------------------------------------------------
> > ------
> > --
> >> 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
> >
> >
> > ----------------------------------------------------------------------
> > --------
> > 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
> 
> 
>
----------------------------------------------------------------------------
--
> 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

Re: [Rails-devel] 1837 Revenue Calculation

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

Erik:
in principle there is no need to add a special type for individual 
stops. I referred to the attribute that allowed the naming of stations 
in Tiles.xml.

The current code supports the "city"-attribute for the Station tag in 
Tiles.xml. This allowed the naming of individual stations and thus 
creates automatically VertexVisitSets for identical named stations.
This is used for e.g. for the Paris and Berlin/Vienna Tiles in 18EU.

It was also (initially) implemented for Berlin in 1835, however this was 
erased by a commit from you 11 months ago (so this requires a fix, as 
yellow Berlin-Berlin runs are allowed currently).

I remember that you were in opposition to this approach (most likely as 
you create the Tiles.xml automatically and so there is always the danger 
of removing this, but I believed that you were able to provide an 
automatic by-pass). So maybe you can suggest a different handling.

Keep in mind that the name approach is used for the off-board map, 
however the names are taken here from Map.xml.

Stefan


On 05/17/2012 10:54 AM, Erik Vos wrote:
> OK.
> We don't yet have the capability to assign special types to individual stops
> on one tile, so I will work to add such a capability.
> Perhaps adding a 'stop' attribute to the<Access>  tag will do (in other
> places 'city' is used, but I think those can better be replaced by 'stop'
> too).
>
> Erik.
>
>> -----Original Message-----
>> From: Stefan Frey [mailto:ste...@we...]
>> Sent: Tuesday, May 15, 2012 1:53 PM
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] 1837 Revenue Calculation
>>
>> Erik:
>> town or offboard does not matter as the node will be replaced by a bonus-
>> node anyway.
>>
>> Another good thing about setting name/id to "mine" is that this identifies
> the
>> correct node(s) to replace (in the case of ZKB).
>> So for ZKB the definition of the tile should be a two-town tile with the
> correct
>> town labeled as "mine".
>> Stefan
>>
>>
>> On 05/15/2012 01:37 PM, Erik Vos wrote:
>>> BTW I chose the mines to be town type because towns cannot be tokened.
>>>
>>>> -----Original Message-----
>>>> From: Erik Vos [mailto:eri...@xs...]
>>>> Sent: Tuesday, May 15, 2012 1:12 PM
>>>> To: 'Development list for Rails: an 18xx game'
>>>> Subject: Re: [Rails-devel] 1837 Revenue Calculation
>>>>
>>>> See below.
>>>>
>>>>> -----Original Message-----
>>>>> From: Stefan Frey [mailto:ste...@we...]
>>>>
>>>>> B) Define the coal tiles as offboard fields. Add a
>>>>> StaticRevenueModifier
>>>> that
>>>>> removes the offboard (major scoring) node and replace it by a bonus
>>>>> vertex for the G-trains only. (Bonus vertices can be defined to be
>>>>> train
>>>> dependent,
>>>>> whereas scoring nodes have to be identical).
>>>>
>>>> I have provisionally defined the mine tiles as fixed (i.e. grey) with
>>>> a
>>> town that
>>>> has zero (i.e. variable) value.
>>>> (This definition is mainly for usage in XML, the real picture will be
>>> different
>>>> once we have better SVG tiles).
>>>> I can change that if you want, but my thinking was that this hex
>>>> would not really behave as an off-board one.
>>>> And I can replace the town by a city if you prefer that.
>>>>
>>>> One potential problem is the ZKB mine tile, with has two stops: a
>>> fixed-value
>>>> village and a variable-value mine.
>>>> Can you handle that? See below.
>>>>
>>>>> C) Add a name="Mine" attribute to all mines. This automatically
>>>>> treats
>>>> them
>>>>> as a VertexVisitSet and thus a train can only visit one of them.
>>>>> Alternatively this could be checked in step D) too.
>>>>
>>>> In Map.xml or in TileSet.xml?
>>>> For the ZKB this should apply to only one of the two stops, so
>>>> perhaps we should add an extra 'city="1"' attribute.
>>>>
>>>>> D) Add a DynamicRevenueModifier that checks that routes of G-Trains
>>>>> have at least one mine in their route, otherwise the route will be
> void.
>>>>>
>>>>> I can easily add those elements, however I will wait until it is
>>>>> possible
>>>> to have
>>>>> 1837 at least startup, so that I am able to test.
>>>>
>>>> 1837 already starts, in that it displays all initial windows. I
>>>> haven't
>>> tried
>>>> anything beyond that point. The only specific class is
>>>> StartRound_1835; otherwise, the 1830 rules apply.
>>>>
>>>> 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
>>>
>>>
>>> ----------------------------------------------------------------------
>>> --------
>>> 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
>>
>>
>>
> ----------------------------------------------------------------------------
> --
>> 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
>
>
> ------------------------------------------------------------------------------
> 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

Re: [Rails-devel] 1837 Revenue Calculation

[Erik V. <eri...@xs...>]

OK.
We don't yet have the capability to assign special types to individual stops
on one tile, so I will work to add such a capability.
Perhaps adding a 'stop' attribute to the <Access> tag will do (in other
places 'city' is used, but I think those can better be replaced by 'stop'
too).

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Tuesday, May 15, 2012 1:53 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1837 Revenue Calculation
> 
> Erik:
> town or offboard does not matter as the node will be replaced by a bonus-
> node anyway.
> 
> Another good thing about setting name/id to "mine" is that this identifies
the
> correct node(s) to replace (in the case of ZKB).
> So for ZKB the definition of the tile should be a two-town tile with the
correct
> town labeled as "mine".
> Stefan
> 
> 
> On 05/15/2012 01:37 PM, Erik Vos wrote:
> > BTW I chose the mines to be town type because towns cannot be tokened.
> >
> >> -----Original Message-----
> >> From: Erik Vos [mailto:eri...@xs...]
> >> Sent: Tuesday, May 15, 2012 1:12 PM
> >> To: 'Development list for Rails: an 18xx game'
> >> Subject: Re: [Rails-devel] 1837 Revenue Calculation
> >>
> >> See below.
> >>
> >>> -----Original Message-----
> >>> From: Stefan Frey [mailto:ste...@we...]
> >>
> >>> B) Define the coal tiles as offboard fields. Add a
> >>> StaticRevenueModifier
> >> that
> >>> removes the offboard (major scoring) node and replace it by a bonus
> >>> vertex for the G-trains only. (Bonus vertices can be defined to be
> >>> train
> >> dependent,
> >>> whereas scoring nodes have to be identical).
> >>
> >> I have provisionally defined the mine tiles as fixed (i.e. grey) with
> >> a
> > town that
> >> has zero (i.e. variable) value.
> >> (This definition is mainly for usage in XML, the real picture will be
> > different
> >> once we have better SVG tiles).
> >> I can change that if you want, but my thinking was that this hex
> >> would not really behave as an off-board one.
> >> And I can replace the town by a city if you prefer that.
> >>
> >> One potential problem is the ZKB mine tile, with has two stops: a
> > fixed-value
> >> village and a variable-value mine.
> >> Can you handle that? See below.
> >>
> >>> C) Add a name="Mine" attribute to all mines. This automatically
> >>> treats
> >> them
> >>> as a VertexVisitSet and thus a train can only visit one of them.
> >>> Alternatively this could be checked in step D) too.
> >>
> >> In Map.xml or in TileSet.xml?
> >> For the ZKB this should apply to only one of the two stops, so
> >> perhaps we should add an extra 'city="1"' attribute.
> >>
> >>> D) Add a DynamicRevenueModifier that checks that routes of G-Trains
> >>> have at least one mine in their route, otherwise the route will be
void.
> >>>
> >>> I can easily add those elements, however I will wait until it is
> >>> possible
> >> to have
> >>> 1837 at least startup, so that I am able to test.
> >>
> >> 1837 already starts, in that it displays all initial windows. I
> >> haven't
> > tried
> >> anything beyond that point. The only specific class is
> >> StartRound_1835; otherwise, the 1830 rules apply.
> >>
> >> 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
> >
> >
> > ----------------------------------------------------------------------
> > --------
> > 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
> 
> 
>
----------------------------------------------------------------------------
--
> 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

[Rails-devel] Tile creation process

[Erik V. <eri...@xs...>]

I have added a page named "Tile creation" to the Wiki.  This page describes
the rather complex procedures that I'm using to create and publish tile XML
and SVG files.
Parts of this expand or supersede other Wiki info, so some cleanup may be in
order.
I'm planning to add some guidelines on tile numbering later, as well as on
using different internal and external tile IDs.  

This description is only meant to document the process, which is so complex
partly because of the limitations of TileDesigner.
It is not meant to encourage everybody to start designing tiles this way for
Rails.  
The consensus a while ago was, that it is better to keep it in one hand, and
for now I'm still willing and able to take the burden.

Erik.

Re: [Rails-devel] 1837 Revenue Calculation

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

Erik:
town or offboard does not matter as the node will be replaced by a 
bonus-node anyway.

Another good thing about setting name/id to "mine" is that this 
identifies the correct node(s) to replace (in the case of ZKB).
So for ZKB the definition of the tile should be a two-town tile with the 
correct town labeled as "mine".
Stefan


On 05/15/2012 01:37 PM, Erik Vos wrote:
> BTW I chose the mines to be town type because towns cannot be tokened.
>
>> -----Original Message-----
>> From: Erik Vos [mailto:eri...@xs...]
>> Sent: Tuesday, May 15, 2012 1:12 PM
>> To: 'Development list for Rails: an 18xx game'
>> Subject: Re: [Rails-devel] 1837 Revenue Calculation
>>
>> See below.
>>
>>> -----Original Message-----
>>> From: Stefan Frey [mailto:ste...@we...]
>>
>>> B) Define the coal tiles as offboard fields. Add a
>>> StaticRevenueModifier
>> that
>>> removes the offboard (major scoring) node and replace it by a bonus
>>> vertex for the G-trains only. (Bonus vertices can be defined to be
>>> train
>> dependent,
>>> whereas scoring nodes have to be identical).
>>
>> I have provisionally defined the mine tiles as fixed (i.e. grey) with a
> town that
>> has zero (i.e. variable) value.
>> (This definition is mainly for usage in XML, the real picture will be
> different
>> once we have better SVG tiles).
>> I can change that if you want, but my thinking was that this hex would not
>> really behave as an off-board one.
>> And I can replace the town by a city if you prefer that.
>>
>> One potential problem is the ZKB mine tile, with has two stops: a
> fixed-value
>> village and a variable-value mine.
>> Can you handle that? See below.
>>
>>> C) Add a name="Mine" attribute to all mines. This automatically treats
>> them
>>> as a VertexVisitSet and thus a train can only visit one of them.
>>> Alternatively this could be checked in step D) too.
>>
>> In Map.xml or in TileSet.xml?
>> For the ZKB this should apply to only one of the two stops, so perhaps we
>> should add an extra 'city="1"' attribute.
>>
>>> D) Add a DynamicRevenueModifier that checks that routes of G-Trains
>>> have at least one mine in their route, otherwise the route will be void.
>>>
>>> I can easily add those elements, however I will wait until it is
>>> possible
>> to have
>>> 1837 at least startup, so that I am able to test.
>>
>> 1837 already starts, in that it displays all initial windows. I haven't
> tried
>> anything beyond that point. The only specific class is StartRound_1835;
>> otherwise, the 1830 rules apply.
>>
>> 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
>
>
> ------------------------------------------------------------------------------
> 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

Re: [Rails-devel] 1837 Revenue Calculation

[Erik V. <eri...@xs...>]

BTW I chose the mines to be town type because towns cannot be tokened.

> -----Original Message-----
> From: Erik Vos [mailto:eri...@xs...]
> Sent: Tuesday, May 15, 2012 1:12 PM
> To: 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] 1837 Revenue Calculation
> 
> See below.
> 
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> 
> > B) Define the coal tiles as offboard fields. Add a
> > StaticRevenueModifier
> that
> > removes the offboard (major scoring) node and replace it by a bonus
> > vertex for the G-trains only. (Bonus vertices can be defined to be
> > train
> dependent,
> > whereas scoring nodes have to be identical).
> 
> I have provisionally defined the mine tiles as fixed (i.e. grey) with a
town that
> has zero (i.e. variable) value.
> (This definition is mainly for usage in XML, the real picture will be
different
> once we have better SVG tiles).
> I can change that if you want, but my thinking was that this hex would not
> really behave as an off-board one.
> And I can replace the town by a city if you prefer that.
> 
> One potential problem is the ZKB mine tile, with has two stops: a
fixed-value
> village and a variable-value mine.
> Can you handle that? See below.
> 
> > C) Add a name="Mine" attribute to all mines. This automatically treats
> them
> > as a VertexVisitSet and thus a train can only visit one of them.
> > Alternatively this could be checked in step D) too.
> 
> In Map.xml or in TileSet.xml?
> For the ZKB this should apply to only one of the two stops, so perhaps we
> should add an extra 'city="1"' attribute.
> 
> > D) Add a DynamicRevenueModifier that checks that routes of G-Trains
> > have at least one mine in their route, otherwise the route will be void.
> >
> > I can easily add those elements, however I will wait until it is
> > possible
> to have
> > 1837 at least startup, so that I am able to test.
> 
> 1837 already starts, in that it displays all initial windows. I haven't
tried
> anything beyond that point. The only specific class is StartRound_1835;
> otherwise, the 1830 rules apply.
> 
> 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

Re: [Rails-devel] A question or two about the Rails XML interface.

[Erik V. <eri...@xs...>]

Modifying existing TileDesigner-created tiles works best.  Please remember:

# Notes on creating new tiles:
(...)
# 3. If tiles are modified with Inkscape, before saving, set the following
properties
#    via File|DocumentProperties:
#    - First press 'Fit page to selection'. This should change the size to
#      Width=393.00 and Height=341.00.
#    - To add the extra whitespace below the tile image that TileDesigner
also adds
#      (for unknown reasons), change the Height to 357.50.
#    - Then save the tile.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Tuesday, May 15, 2012 12:34 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] A question or two about the Rails XML
interface.
> 
> Converting from bitmap to a vector graphic unfortunately hardly exceeds,
> however for simple graphs (like our tiles) there should be working
> algorithms.
> 
> I prefer creating a SVG in two ways:
> A) Edit the SVG file directly. Actually the tile designer svg files are
not that
> difficult to understand after one adds newlines to separate the XML
> elements.
> B) Use Inkscape which is an opensource vector graphics program which uses
> SVG.
> Most often I combine A) and B).
> 
> I can create the mine tiles if you like, but be warned I am not an artist
at all.
> I would simply paste the mine symbol from wikipedia
> http://upload.wikimedia.org/wikipedia/commons/8/8c/Mining_symbol.svg
> onto the tiles.
> 
> Stefan
> 
> On 05/13/2012 12:56 AM, Erik Vos wrote:
> > Is anyone able to convert .gif to .svg?
> > See below for some requirements that include the required SVG size
> > (copied from CombineTiles.pl as mentioned in my previous reply).
> >
> > Once that has been done, we can use the .svg equivalents in the
displays.
> > Internally we still need standard TileDesigner equivalents, for which
> > we can use existing standard off-map city or town tiles (or perhaps we
> > need new ones, with stop type "mine" or such).
> >
> > # Notes on creating new tiles:
> > # 1. In TileDesigner, export SVG tiles with size=170 and filename
> > template=tile<c0>.
> > #    Do this with ID checked into directory tiles/TDwithID, and again
> > #    with ID unchecked into directory tiles/TDwoID.
> > # 2. If the saved tiles turn out to invisible, use program
> > FixInvisibility.pl
> > #    to remove superfluous strings ' xmlns=""'. It is unknown why
> > TileDesigner
> > #    sometimes includes this string in the path tags.
> > # 3. If tiles are modified with Inkscape, before saving, set the
> > following properties
> > #    via File|DocumentProperties:
> > #    - First press 'Fit page to selection'. This should change the size
to
> > #      Width=393.00 and Height=341.00.
> > #    - To add the extra whitespace below the tile image that
TileDesigner
> > also adds
> > #      (for unknown reasons), change the Height to 357.50.
> > #    - Then save the tile.
> > # 4. Use this program to combine tiles from the following directories
> > into
> > tiles/svg:
> > #    - From tiles/TDwithID: all tiles with an ID>  0 (not preprinted
tiles).
> > #      These images have the id on the tile.
> > #    - From tiles/TDwoID: all tiles with an ID<= 0 (preprinted tiles).
> > #      These images do not have the ID on the tile (create these
separately
> > from TD).
> > #    - From tiles/handmade: all tiles in that dir will overwrite any of
the
> > above.
> > #      These are the tiles modified by hand or with Inkscape.
> >
> >> -----Original Message-----
> >> From: John David Galt [mailto:jd...@di...]
> >> Sent: Sunday, May 13, 2012 12:14 AM
> >> To: Development list for Rails: an 18xx game
> >> Subject: Re: [Rails-devel] A question or two about the Rails XML
> > interface.
> >>
> >> Here are the three "mine tiles", in the two sizes of .gif that
> >> 18xx.net
> > uses.
> >> I've left off the names and the values for the "offboard run" in the
> >> hope
> > that
> >> Rails can generate those dynamically.
> >>
> >> If some other format would work better, I'll see if I can create it.
> >> Let
> > me
> >> know.
> >
> >
> > ----------------------------------------------------------------------
> > --------
> > 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
> 
> 
>
----------------------------------------------------------------------------
--
> 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

Re: [Rails-devel] 1837 Revenue Calculation

[Erik V. <eri...@xs...>]

See below.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]

> B) Define the coal tiles as offboard fields. Add a StaticRevenueModifier
that
> removes the offboard (major scoring) node and replace it by a bonus vertex
> for the G-trains only. (Bonus vertices can be defined to be train
dependent,
> whereas scoring nodes have to be identical).

I have provisionally defined the mine tiles as fixed (i.e. grey) with a town
that has zero (i.e. variable) value.
(This definition is mainly for usage in XML, the real picture will be
different once we have better SVG tiles).
I can change that if you want, but my thinking was that this hex would not
really behave as an off-board one.
And I can replace the town by a city if you prefer that.

One potential problem is the ZKB mine tile, with has two stops: a
fixed-value village and a variable-value mine.
Can you handle that? See below.
 
> C) Add a name="Mine" attribute to all mines. This automatically treats
them
> as a VertexVisitSet and thus a train can only visit one of them.
> Alternatively this could be checked in step D) too.

In Map.xml or in TileSet.xml?
For the ZKB this should apply to only one of the two stops, so perhaps we
should add an extra 'city="1"' attribute.
 
> D) Add a DynamicRevenueModifier that checks that routes of G-Trains have
> at least one mine in their route, otherwise the route will be void.
> 
> I can easily add those elements, however I will wait until it is possible
to have
> 1837 at least startup, so that I am able to test.

1837 already starts, in that it displays all initial windows. I haven't
tried anything beyond that point. The only specific class is
StartRound_1835; otherwise, the 1830 rules apply.

Erik.

Re: [Rails-devel] A question or two about the Rails XML interface.

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

Converting from bitmap to a vector graphic unfortunately hardly exceeds, 
however for simple graphs (like our tiles) there should be working 
algorithms.

I prefer creating a SVG in two ways:
A) Edit the SVG file directly. Actually the tile designer svg files are 
not that difficult to understand after one adds newlines to separate the 
XML elements.
B) Use Inkscape which is an opensource vector graphics program which 
uses SVG.
Most often I combine A) and B).

I can create the mine tiles if you like, but be warned I am not an 
artist at all.
I would simply paste the mine symbol from wikipedia 
http://upload.wikimedia.org/wikipedia/commons/8/8c/Mining_symbol.svg
onto the tiles.

Stefan

On 05/13/2012 12:56 AM, Erik Vos wrote:
> Is anyone able to convert .gif to .svg?
> See below for some requirements that include the required SVG size (copied
> from CombineTiles.pl as mentioned in my previous reply).
>
> Once that has been done, we can use the .svg equivalents in the displays.
> Internally we still need standard TileDesigner equivalents, for which we can
> use existing standard off-map city or town tiles
> (or perhaps we need new ones, with stop type "mine" or such).
>
> # Notes on creating new tiles:
> # 1. In TileDesigner, export SVG tiles with size=170 and filename
> template=tile<c0>.
> #    Do this with ID checked into directory tiles/TDwithID, and again
> #    with ID unchecked into directory tiles/TDwoID.
> # 2. If the saved tiles turn out to invisible, use program
> FixInvisibility.pl
> #    to remove superfluous strings ' xmlns=""'. It is unknown why
> TileDesigner
> #    sometimes includes this string in the path tags.
> # 3. If tiles are modified with Inkscape, before saving, set the following
> properties
> #    via File|DocumentProperties:
> #    - First press 'Fit page to selection'. This should change the size to
> #      Width=393.00 and Height=341.00.
> #    - To add the extra whitespace below the tile image that TileDesigner
> also adds
> #      (for unknown reasons), change the Height to 357.50.
> #    - Then save the tile.
> # 4. Use this program to combine tiles from the following directories into
> tiles/svg:
> #    - From tiles/TDwithID: all tiles with an ID>  0 (not preprinted tiles).
> #      These images have the id on the tile.
> #    - From tiles/TDwoID: all tiles with an ID<= 0 (preprinted tiles).
> #      These images do not have the ID on the tile (create these separately
> from TD).
> #    - From tiles/handmade: all tiles in that dir will overwrite any of the
> above.
> #      These are the tiles modified by hand or with Inkscape.
>
>> -----Original Message-----
>> From: John David Galt [mailto:jd...@di...]
>> Sent: Sunday, May 13, 2012 12:14 AM
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] A question or two about the Rails XML
> interface.
>>
>> Here are the three "mine tiles", in the two sizes of .gif that 18xx.net
> uses.
>> I've left off the names and the values for the "offboard run" in the hope
> that
>> Rails can generate those dynamically.
>>
>> If some other format would work better, I'll see if I can create it.  Let
> me
>> know.
>
>
> ------------------------------------------------------------------------------
> 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

[Rails-devel] 1837 Revenue Calculation

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

John & Erik:
sorry for not responding earlier, pretty busy period now:
It is great to see an 1837 implementation soon, as I was able
to play that game already - even if I do not own a copy myself
next to 1849/1850 Sicily the ugliest gap of my collection.

You touched the problem about how to implement the 1837 revenue 
calculation.

Most train properties are already covered by the settings in xml.
The main issue is the handling of G-Trains and coal companies.

There are several possibilities to handle that I would suggest the 
following:

A) Give no home token to coal companies (this avoids displaying them). 
Instead add a StaticGraphModifier that adds a home token for coal 
companies for revenue and route purposes.

B) Define the coal tiles as offboard fields. Add a StaticRevenueModifier 
that removes the offboard (major scoring) node and replace it by a bonus 
vertex for the G-trains only. (Bonus vertices
can be defined to be train dependent, whereas scoring nodes have to be 
identical).

C) Add a name="Mine" attribute to all mines. This automatically treats 
them as a VertexVisitSet and thus a train can only visit one of them. 
Alternatively this could be checked in step D) too.

D) Add a DynamicRevenueModifier that checks that routes of G-Trains have 
at least one mine in their route, otherwise the route will be void.

I can easily add those elements, however I will wait until it is 
possible to have 1837 at least startup, so that I am able to test.

Stefan