rails-devel — List for discussion of Rails development

Re: [Rails-devel] 1826

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

I have done the missing special tiles.  Not sure if we also need to replace
the yellow and green tiles by ones that have negative numbers.  I think
there are one or two places where that could make a difference, so if needed
I'll replace these too.

 

Erik.

 

Van: Erik Vos [mailto:eri...@xs...] 
Verzonden: zaterdag 25 juni 2011 12:00
Aan: 'Development list for Rails: an 18xx game'
Onderwerp: Re: [Rails-devel] 1826

 

OK, thanks. I have committed these files. I will look at the special tiles
later.

 

Two comments:

-          Since Adam Badura's recent update it is no longer necessary to
specify a class name in Map.xml.

-          Accented characters do not correctly transfer this way. I had to
fix these. I suppose the only safe way is to use the (hexa)decimal UTF
values, as I did in 1835. However, the actual accented characters also
appear to work if entered via the Eclipse XML editor, see 18EU.

 

Erik.

 

Van: Scott Petersen [mailto:sc...@re...] 
Verzonden: zaterdag 25 juni 2011 4:22
Aan: Development list for Rails: an 18xx game
Onderwerp: [Rails-devel] 1826

 

On Fri, Jun 24, 2011 at 12:43 AM, Stefan Frey <ste...@we...> wrote:

it is not too bad and should be doable: My tasks should not be the
bottleneck,
at least I hope so.

 

With those encouraging words, I made some headway with the 1826 XML files.
They are attached.  There is a lot of stuff that still needs work--this is
just the items that I could do without a rules read.  The next step will be
to develop a list of items to resolve and add it to the wiki. I'll do that
sometime in the next week or so.

 

There are several preprinted tiles that will need to be made.  I am using a
placeholder for now.

 

Here is some text to add to the Gameslist

   <Game name="1826">

    <Note>Prototype</Note>

    <Description>1826</Description>

    <Players minimum="2" maximum="6" />

  </Game> 

 

Here are the tiles that need to be added to TileSet.xml.  I'll work on
adding their upgrades and formatting them once the tiles are created and
there is a valid Tiles.xml.

          <Tile id="3" quantity="2"/>

          <Tile id="4" quantity="6"/>

          <Tile id="5" quantity="2"/>

          <Tile id="6" quantity="2"/>

          <Tile id="7" quantity="4"/>

          <Tile id="8" quantity="16"/>

          <Tile id="9" quantity="21"/>

          <Tile id="57" quantity="4"/>

          <Tile id="58" quantity="6"/>

          <Tile id="14" quantity="3"/>

          <Tile id="15" quantity="3"/>

          <Tile id="16" quantity="1"/>

          <Tile id="19" quantity="1"/>

          <Tile id="20" quantity="1"/>

          <Tile id="23" quantity="5"/>

          <Tile id="24" quantity="5"/>

          <Tile id="25" quantity="3"/>

          <Tile id="26" quantity="1"/>

          <Tile id="27" quantity="1"/>

          <Tile id="28" quantity="1"/>

          <Tile id="29" quantity="1"/>

          <Tile id="87" quantity="2"/>

          <Tile id="88" quantity="2"/>

          <Tile id="141" quantity="1"/>

          <Tile id="142" quantity="1"/>

          <Tile id="143" quantity="1"/>

          <Tile id="203" quantity="1"/>

          <Tile id="204" quantity="2"/>

          <Tile id="514" quantity="1"/>

          <Tile id="619" quantity="3"/>

          <Tile id="39" quantity="1"/>

          <Tile id="40" quantity="1"/>

          <Tile id="41" quantity="2"/>

          <Tile id="42" quantity="2"/>

          <Tile id="43" quantity="3"/>

          <Tile id="44" quantity="1"/>

          <Tile id="45" quantity="2"/>

          <Tile id="46" quantity="2"/>

          <Tile id="47" quantity="3"/>

          <Tile id="63" quantity="5"/>

          <Tile id="70" quantity="1"/>

          <Tile id="515" quantity="1"/>

          <Tile id="611" quantity="2"/>

          <Tile id="513" quantity="3"/>

          <Tile id="516" quantity="1"/>

Re: [Rails-devel] 1826

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

OK, thanks. I have committed these files. I will look at the special tiles
later.

 

Two comments:

-          Since Adam Badura's recent update it is no longer necessary to
specify a class name in Map.xml.

-          Accented characters do not correctly transfer this way. I had to
fix these. I suppose the only safe way is to use the (hexa)decimal UTF
values, as I did in 1835. However, the actual accented characters also
appear to work if entered via the Eclipse XML editor, see 18EU.

 

Erik.

 

Van: Scott Petersen [mailto:sc...@re...] 
Verzonden: zaterdag 25 juni 2011 4:22
Aan: Development list for Rails: an 18xx game
Onderwerp: [Rails-devel] 1826

 

On Fri, Jun 24, 2011 at 12:43 AM, Stefan Frey <ste...@we...> wrote:

it is not too bad and should be doable: My tasks should not be the
bottleneck,
at least I hope so.

 

With those encouraging words, I made some headway with the 1826 XML files.
They are attached.  There is a lot of stuff that still needs work--this is
just the items that I could do without a rules read.  The next step will be
to develop a list of items to resolve and add it to the wiki. I'll do that
sometime in the next week or so.

 

There are several preprinted tiles that will need to be made.  I am using a
placeholder for now.

 

Here is some text to add to the Gameslist

   <Game name="1826">

    <Note>Prototype</Note>

    <Description>1826</Description>

    <Players minimum="2" maximum="6" />

  </Game> 

 

Here are the tiles that need to be added to TileSet.xml.  I'll work on
adding their upgrades and formatting them once the tiles are created and
there is a valid Tiles.xml.

          <Tile id="3" quantity="2"/>

          <Tile id="4" quantity="6"/>

          <Tile id="5" quantity="2"/>

          <Tile id="6" quantity="2"/>

          <Tile id="7" quantity="4"/>

          <Tile id="8" quantity="16"/>

          <Tile id="9" quantity="21"/>

          <Tile id="57" quantity="4"/>

          <Tile id="58" quantity="6"/>

          <Tile id="14" quantity="3"/>

          <Tile id="15" quantity="3"/>

          <Tile id="16" quantity="1"/>

          <Tile id="19" quantity="1"/>

          <Tile id="20" quantity="1"/>

          <Tile id="23" quantity="5"/>

          <Tile id="24" quantity="5"/>

          <Tile id="25" quantity="3"/>

          <Tile id="26" quantity="1"/>

          <Tile id="27" quantity="1"/>

          <Tile id="28" quantity="1"/>

          <Tile id="29" quantity="1"/>

          <Tile id="87" quantity="2"/>

          <Tile id="88" quantity="2"/>

          <Tile id="141" quantity="1"/>

          <Tile id="142" quantity="1"/>

          <Tile id="143" quantity="1"/>

          <Tile id="203" quantity="1"/>

          <Tile id="204" quantity="2"/>

          <Tile id="514" quantity="1"/>

          <Tile id="619" quantity="3"/>

          <Tile id="39" quantity="1"/>

          <Tile id="40" quantity="1"/>

          <Tile id="41" quantity="2"/>

          <Tile id="42" quantity="2"/>

          <Tile id="43" quantity="3"/>

          <Tile id="44" quantity="1"/>

          <Tile id="45" quantity="2"/>

          <Tile id="46" quantity="2"/>

          <Tile id="47" quantity="3"/>

          <Tile id="63" quantity="5"/>

          <Tile id="70" quantity="1"/>

          <Tile id="515" quantity="1"/>

          <Tile id="611" quantity="2"/>

          <Tile id="513" quantity="3"/>

          <Tile id="516" quantity="1"/>

Re: [Rails-devel] 18GA OSRR extra 2-train

[Scott P. <sc...@re...>]

On Fri, Jun 24, 2011 at 10:51 AM, Erik Vos <eri...@xs...> wrote:

> I have implemented the extra 2-train that comes with the OSRR private when
> bought by a company in 18GA.
>

Great.  I believe the game is now complete including the Cotton Port
variant.  I updated the wiki.

[Rails-devel] 18GA OSRR extra 2-train

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

I have implemented the extra 2-train that comes with the OSRR private when
bought by a company in 18GA. 
The simplest solution was to hardcode this feature in a new subclass
OperatingRound_18GA.

Erik.

Re: [Rails-devel] 1826 support , was Re: Train management & dual trains

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

> -----Oorspronkelijk bericht-----
> Van: Stefan Frey [mailto:ste...@we...]


> How about the merger into the SNCF and the loans? Are the rules used in
> 1826 fully compatible to comparable games (1856)?

Not fully compatible, but sufficiently similar to trust that this will not
be a major hurdle, just a matter of time.  But the devil is always in the
details...

Erik.

[Rails-devel] 1826 support , was Re: Train management & dual trains

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

it is not too bad and should be doable: My tasks should not be the bottleneck, 
at least I hope so.

H-trains:
a support of H-trains is easy to add, as the hex distances between nodes is an
attribute of the graph edges.

TGV:
a simple application of a RevenueModifier, as it simply requires to run the 
TGV trains separately from the other trains.

Reaching Destinations:
Main issues here are to have a  trigger that starts the connectivity check 
after each change of the map and the implementation of the effects.
Checking the connectivity itself on the network graph is easy.

How about the merger into the SNCF and the loans? Are the rules used in 1826 
fully compatible to comparable games (1856)?

Stefan

On Thursday, June 23, 2011 11:07:57 am Erik Vos wrote:
> IMO, the main non-trivial novelties with 1826 are
> - 5- to 10-share conversion,
> - H-trains,
> - TGV using the same track as other trains,
> - Reaching destinations.
> 
> Fortunately, the last three items are mainly for you, Stefan... :-)
> 
> As 1826 is high on my personal preference list, I wouldn't mind to give
> this game some priority.
> 
> I don't have 18Neb and don't know much about it, so I can't comment on that
> game.
> 
> Erik.
> 
> > -----Oorspronkelijk bericht-----
> > Van: Stefan Frey [mailto:ste...@we...]
> > Verzonden: donderdag 23 juni 2011 6:52
> > Aan: Development list for Rails: an 18xx game
> > Onderwerp: Re: [Rails-devel] Train management & dual trains
> > 
> > Scott:
> > I have not played those games, I can only claim ownership of them for a
> 
> few
> 
> > weeks now, but it seems (at least to me) that the rules deviations of
> > 1826 and 18Neb are not too complicated (but there are some). However
> > nearly all concepts are already implemented in some ways or another.
> > Compared to some of the partially-finished games that exist already,
> > they might be
> 
> easier
> 
> > to finish. And I would be more keen to have games supported that do not
> > have already a working implantation in Lemmi's moderator.
> > Stefan
> > 
> > On Wednesday, June 22, 2011 11:30:44 pm Scott Petersen wrote:
> > > On Wed, Jun 22, 2011 at 8:25 AM, Scott Petersen
> > 
> > <sc...@re...>wrote:
> > > > I intend to verify that the cash results are also the same at some
> > > > point soon.
> > > 
> > > I verified that the end game results are the same between the current
> > > code and the 1.4.2 release for my set of completed games.
> > > 
> > > Great work!  I wish I knew how I could contribute more.  I had started
> > > on XML files for 1826 and 18Neb, but I figured that we had enough
> > > partially-finished games for the moment to put too much effort into
> > > it.
> 
> ---------------------------------------------------------------------------
> - --
> 
> > Simplify data backup and recovery for your virtual environment with
> > vRanger.
> > Installation's a snap, and flexible recovery options mean your data is
> 
> safe,
> 
> > secure and there when you need it. Data protection magic?
> > Nope - It's vRanger. Get your free trial download today.
> > http://p.sf.net/sfu/quest-sfdev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- Simplify data backup and recovery for your virtual environment with
> vRanger. Installation's a snap, and flexible recovery options mean your
> data is safe, secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Train management & dual trains

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

IMO, the main non-trivial novelties with 1826 are
- 5- to 10-share conversion,
- H-trains,
- TGV using the same track as other trains,
- Reaching destinations.

Fortunately, the last three items are mainly for you, Stefan... :-)

As 1826 is high on my personal preference list, I wouldn't mind to give this
game some priority.

I don't have 18Neb and don't know much about it, so I can't comment on that
game.

Erik.

> -----Oorspronkelijk bericht-----
> Van: Stefan Frey [mailto:ste...@we...]
> Verzonden: donderdag 23 juni 2011 6:52
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] Train management & dual trains
> 
> Scott:
> I have not played those games, I can only claim ownership of them for a
few
> weeks now, but it seems (at least to me) that the rules deviations of 1826
> and 18Neb are not too complicated (but there are some). However nearly all
> concepts are already implemented in some ways or another. Compared to
> some of the partially-finished games that exist already, they might be
easier
> to finish. And I would be more keen to have games supported that do not
> have already a working implantation in Lemmi's moderator.
> Stefan
> 
> 
> On Wednesday, June 22, 2011 11:30:44 pm Scott Petersen wrote:
> > On Wed, Jun 22, 2011 at 8:25 AM, Scott Petersen
> <sc...@re...>wrote:
> > > I intend to verify that the cash results are also the same at some
> > > point soon.
> >
> > I verified that the end game results are the same between the current
> > code and the 1.4.2 release for my set of completed games.
> >
> > Great work!  I wish I knew how I could contribute more.  I had started
> > on XML files for 1826 and 18Neb, but I figured that we had enough
> > partially-finished games for the moment to put too much effort into
> > it.
> 
>
----------------------------------------------------------------------------
--
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data is
safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Train management & dual trains

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

Scott:
I have not played those games, I can only claim ownership of them for a few 
weeks now, but it seems (at least to me) that the rules deviations of 1826 and 
18Neb are not too complicated (but there are some). However nearly all 
concepts are already implemented in some ways or another. Compared to some of 
the partially-finished games that exist already, they might be easier to 
finish. And I would be more keen to have games supported that do not have 
already a working implantation in Lemmi's moderator.
Stefan


On Wednesday, June 22, 2011 11:30:44 pm Scott Petersen wrote:
> On Wed, Jun 22, 2011 at 8:25 AM, Scott Petersen <sc...@re...>wrote:
> > I intend to verify that the cash results are also the same at some point
> > soon.
> 
> I verified that the end game results are the same between the current code
> and the 1.4.2 release for my set of completed games.
> 
> Great work!  I wish I knew how I could contribute more.  I had started on
> XML files for 1826 and 18Neb, but I figured that we had
> enough partially-finished games for the moment to put too much effort into
> it.

Re: [Rails-devel] Train management & dual trains

[Scott P. <sc...@re...>]

On Wed, Jun 22, 2011 at 8:25 AM, Scott Petersen <sc...@re...>wrote:

> I intend to verify that the cash results are also the same at some point
> soon.


I verified that the end game results are the same between the current code
and the 1.4.2 release for my set of completed games.

Great work!  I wish I knew how I could contribute more.  I had started on
XML files for 1826 and 18Neb, but I figured that we had
enough partially-finished games for the moment to put too much effort into
it.

Re: [Rails-devel] Train management & dual trains

[Scott P. <sc...@re...>]

Erik, I ran several GameEnd files played with 1.4.x for PBEM games (1830,
1851, 1856, 1889).  They all passed.  I intend to verify that the cash
results are also the same at some point soon. My 18EU also broke.  Note that
these are just more data, not specifically engineered test cases.

Re: [Rails-devel] TileOrientation Enumeration

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

I wondered why I had not noticed this worthy contribution, but I just
checked my Outlook Junk mail box, and there it was (together with some other
mails of which some weren't junk at all).  Good thing that Brett is paying
attention to what I'm missing!

Erik.

> -----Oorspronkelijk bericht-----
> Van: brett lentz [mailto:bre...@gm...]
> Verzonden: maandag 13 juni 2011 21:10
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] TileOrientation Enumeration
> 
> Looks great.  Applied.
> 
> ---Brett.
> 
> 
> 
> 2011/6/12 Adam Badura <ab...@o2...>:
> > In the attachment there is a minor refactoring for tile orientation
> > which I developed while working on SVG advancement.
> >
> > I decided that it is useful on its own and is small enough for quick
review.
> > So here you have it.
> >
> > Adam Badura
> >
> > ----------------------------------------------------------------------
> > -------- EditLive Enterprise is the world's most technically advanced
> > content authoring tool. Experience the power of Track Changes, Inline
> > Image Editing and ensure content is compliant with Accessibility
> > Checking.
> > http://p.sf.net/sfu/ephox-dev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> 
>
----------------------------------------------------------------------------
--
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
Editing
> and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Train management & dual trains

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

BTW Stefan, your test case now fails in a later stage on what looks like an
operating order difference.  I haven't pursued that problem.

> -----Oorspronkelijk bericht-----
> Van: Erik Vos [mailto:eri...@xs...]
> Verzonden: woensdag 22 juni 2011 14:24
> Aan: 'Development list for Rails: an 18xx game'
> Onderwerp: Re: [Rails-devel] Train management & dual trains
> 
> > -----Oorspronkelijk bericht-----
> > Van: Stefan Frey [mailto:ste...@we...]
> > Verzonden: woensdag 22 juni 2011 7:17
> > Aan: Development list for Rails: an 18xx game
> > Onderwerp: Re: [Rails-devel] Train management & dual trains
> >
> > Erik:
> > of the official test suite no test goes through currently, as there
> > has
> been a
> > change of the game report regarding the usage of blank lines at the
> > begin
> of
> > the StartRound. Was there any specific reason to do that?
> 
> I can't remember any such change, so I can't give a specific reason, but
it's
> well possible that I have done that at some point.
> However, if our test cases are dependent on such details, I'm not very
happy
> about that.
> Improvements must remain possible. Very recently I added a report line
> about President's cash contributed in  emergency train buying - this was
> completely unreported so far.
> 
> I suspect that by now many old test cases will appear to be out of date
for
> other reasons too.  Almost all of my 18EU cases are invalid and must be
> edited because one redundant Skip action had been removed at some point.
> I suppose we should revisit that whole test set. That's a separate
subproject
> in its own right...
> 
> I attach two test cases that I have used intensively to test the train
> management changes against. These two cases cover a lot of ground.
> Unfortunately, the 18EU map is wrong because it still originates from the
> time before I rotated tile #4, so all these tiles are shown oriented
wrongly.
> Again, this applies to most of my 18EU test cases. I suppose I will have
to
> write a special conversion program to fix that...
> 
> > There is one (non-official) test however, that already stops with a
> null-point
> > exception on buying a train. Save file is attached.
> 
> That's caused by a bug in the 1830 Pere Marquette configuration. The
6-train
> releases a 7-train, which is not defined for that variant. This bug must
have
> crept in while recently adding many other variants. I don't have the PM
rules,
> but from your original commit I conclude, that PM has no 7-train, so I
have
> fixed it accordingly.  I have also added checks to catch such misfits
during XML
> parsing.
> 
> Erik.

Re: [Rails-devel] Train management & dual trains

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

> -----Oorspronkelijk bericht-----
> Van: Stefan Frey [mailto:ste...@we...]
> Verzonden: woensdag 22 juni 2011 7:17
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] Train management & dual trains
> 
> Erik:
> of the official test suite no test goes through currently, as there has
been a
> change of the game report regarding the usage of blank lines at the begin
of
> the StartRound. Was there any specific reason to do that?

I can't remember any such change, so I can't give a specific reason, but
it's well possible that I have done that at some point. 
However, if our test cases are dependent on such details, I'm not very happy
about that. 
Improvements must remain possible. Very recently I added a report line about
President's cash contributed in  emergency train buying - this was
completely unreported so far.

I suspect that by now many old test cases will appear to be out of date for
other reasons too.  Almost all of my 18EU cases are invalid and must be
edited because one redundant Skip action had been removed at some point.  I
suppose we should revisit that whole test set. That's a separate subproject
in its own right...

I attach two test cases that I have used intensively to test the train
management changes against. These two cases cover a lot of ground.
Unfortunately, the 18EU map is wrong because it still originates from the
time before I rotated tile #4, so all these tiles are shown oriented
wrongly. Again, this applies to most of my 18EU test cases. I suppose I will
have to write a special conversion program to fix that...

> There is one (non-official) test however, that already stops with a
null-point
> exception on buying a train. Save file is attached.

That's caused by a bug in the 1830 Pere Marquette configuration. The 6-train
releases a 7-train, which is not defined for that variant. This bug must
have crept in while recently adding many other variants. I don't have the PM
rules, but from your original commit I conclude, that PM has no 7-train, so
I have fixed it accordingly.  I have also added checks to catch such misfits
during XML parsing.

Erik.

Re: [Rails-devel] Train management & dual trains

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

Erik:
of the official test suite no test goes through currently, as there has been a 
change of the game report regarding the usage of blank lines at the begin of 
the StartRound. Was there any specific reason to do that? 

There is one (non-official) test however, that already stops with a null-point 
exception on buying a train. Save file is attached.

Stefan


On Wednesday, June 22, 2011 12:18:51 am Erik Vos wrote:
> I have done most of the train configuration and management changes that
> were necessary to allow dual trains, as exist in 18VA, 18Scan etc.
> It has amounted to a major overhaul of the train-related classes.
> 
> On the configuration side, the <Train> tag has been replaced by
> <TrainType>, and <Train> is now used only to define the two train types of
> a dual train certificate.
> For instance, the 18Scan 2/1+1 train is defined with
> 	<TrainType name="2/1+1" quantity="6">
> 		<Train name="2" majorStops="2" cost="100"/>
>             		<Train name="1+1" majorStops="1" minorStops="1"
> cost="80"/>
> 	</TrainType>
> 
> The single trains of all existing games are now defined like
> 	<TrainType name="2" majorStops="2" cost="80" quantity="6"/>
> In this case, the <Train> part is implicit.
> 
> The related class names are different from the tag names: <TrainType>
> relates to a new class TrainCertificateType, whereas <Train> still relates
> to class TrainType.
> Where applicable, attributes defined under <TrainType> propagate to
> <Train>, and those defined under <Defaults> propagate to both.
> The TrainTypeI interface has been discontinued.
> 
> Train objects refer to individual train *certificates*, and contain a new
> attribute actualTrainType to refer to the current TrainType. In case of
> single trains, the value is fixed, but for dual trains the initial value is
> null, and is assigned on buying whichever train type.
> The TrainI interface still exists.
> 
> I have tested with old saved files that contain examples of most special
> train actions, such as emergency buying, D-train exchange, excess train
> discarding, infinite trains and 18AL named trains. It all seems to work
> fine, but I encourage those that can work with the current code base to
> test with all your favourite saved files.
> 
> Train buying in 18Scan also works as far as this game presently can be
> played.  The two aspects of a dual train are shown as separate buy options,
> each at the correct price.
> 
> Revenue calculation also still seems to work, but I haven't really checked
> the numbers.
> 
> Erik
> 
> 
> ---------------------------------------------------------------------------
> --- EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Train management & dual trains

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

I have done most of the train configuration and management changes that were
necessary to allow dual trains, as exist in 18VA, 18Scan etc.  
It has amounted to a major overhaul of the train-related classes.

On the configuration side, the <Train> tag has been replaced by <TrainType>,
and <Train> is now used only to define the two train types of a dual train
certificate.
For instance, the 18Scan 2/1+1 train is defined with
	<TrainType name="2/1+1" quantity="6">
		<Train name="2" majorStops="2" cost="100"/>
            		<Train name="1+1" majorStops="1" minorStops="1"
cost="80"/>
	</TrainType>

The single trains of all existing games are now defined like
	<TrainType name="2" majorStops="2" cost="80" quantity="6"/>
In this case, the <Train> part is implicit.

The related class names are different from the tag names: <TrainType>
relates to a new class TrainCertificateType, whereas <Train> still relates
to class TrainType. 
Where applicable, attributes defined under <TrainType> propagate to <Train>,
and those defined under <Defaults> propagate to both.
The TrainTypeI interface has been discontinued.

Train objects refer to individual train *certificates*, and contain a new
attribute actualTrainType to refer to the current TrainType. In case of
single trains, the value is fixed, but for dual trains the initial value is
null, and is assigned on buying whichever train type.
The TrainI interface still exists.

I have tested with old saved files that contain examples of most special
train actions, such as emergency buying, D-train exchange, excess train
discarding, infinite trains and 18AL named trains. It all seems to work
fine, but I encourage those that can work with the current code base to test
with all your favourite saved files.

Train buying in 18Scan also works as far as this game presently can be
played.  The two aspects of a dual train are shown as separate buy options,
each at the correct price.

Revenue calculation also still seems to work, but I haven't really checked
the numbers.

Erik

Re: [Rails-devel] Train management

[Scott P. <sc...@re...>]

On Thu, Jun 9, 2011 at 5:17 PM, Erik Vos <eri...@xs...> wrote:

> OK, the 18TN 4-train obsoleting on buying the 2nd 6-train should work now.
> ****
>
> ** **
>
> The implementation is a bit provisional, as it only covers rusting yet.  I
> think we’ll have to move to a more generic approach, in which any type of
> action can be triggered that is normally associated with phase changes.
>

Erik, I played through a test game and verify that the second 6-train rusts
the 4-trains.
It looks like you implemented this with the following as a property of the
6-train.
 <Sub index="2" rustedTrain="4"/>

18TN's Game.xml is currently configured to obsolete the 2/3/4-trains.  All
of those should not have the obsoleting property.  The only trains that
obsolete are the 4-trains on the second 6-train (hard rust on 8-train).  As
train obsoletion is currently implemented, it is just a "free pass" at
another run once the train "rusts."  I think there is currently no mechanism
to make the train hard rust immediately, bypassing the obsolete "free pass."

As you said, we will have to take a look at a more general solution for the
half-phase changes.

Also, it would be nice to implement the "you must buy a train unless you
have no route" red text once obsolete trains are run and leave a company
trainless.  This must currently be triggered off something like a dividend
of zero because it does not appear after a company's obsolete trains run and
rust.

[Rails-devel] Running through off-map hexes

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

Ah, I knew these two issues were connected...

> -----Oorspronkelijk bericht-----
> Van: Stefan Frey [mailto:ste...@we...]
> Verzonden: donderdag 16 juni 2011 6:56
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] 1830 Reading
> 
> I had the impression, that you already created a bypass to allow manual
> adjustments of Tiles.xml in the case it is required.
> I am fine with TileSet.xml (or Map.xml) if this is what you think is best,
as you
> are responsible of the that area of program.

> -----Oorspronkelijk bericht-----
> Van: Stefan Frey [mailto:ste...@we...]
> Verzonden: donderdag 16 juni 2011 7:14
> Aan: rai...@li...
> Onderwerp: Re: [Rails-users] 1830 Reading & Coalfields Variant
> 
> The Goderich tile (-939) is not the correct one in 1830 Tiles.xml: The
station
> definition is omitted. The one in 1856 Tiles.xml is correct.
> However this is up to Erik to investigate, as Tiles.xml should be created
> automatically with the correct entries.

I had completely forgotten about this case.  For lack of a better idea at
that time, I must have changed the 1856 and 18EU Tiles.xml files manually,
after its generation. So much for my principles...
For a short-term solution, I will now also apply that fix to 1830.

For the long term, we need a better solution. 
One option is to use tile -903 to define stations and tracks, and use tile
-939 for display only. This is a trick that I already have used in a few
other cases.
The catch for you is, that you normally don't allow run-through via tile
-903.  To make that happen, I think we could use our new approach to add a
tag <Station runThrough="yes"/>.
However, as these games already use -903 for off-map areas that cannot be
run through, this new tag should be put into Map.xml. 
Another option would be to create a new tile -1939 that is identical to -903
but can be modified in TileSet.xml.

> I suggest  that the code to determine the question if a station is tokened
out
> or accessible is part of the main Rail code base.

Absolutely agreed.

> Thus if there is a method for a Station object, which allows to query the
> access rights, the question how this information is fed into this method,
is
> out of the control and interest of the revenue algorithm.
> 
> (A similar separation will be done for the value property, where the
revenue
> algorithm still decides, whether to query the hex or the station for the
> value.)

What you really (should) want to use are the City objects, because that's
where the (generic) Tile/Station and (specific) MapHex meet. (City is a bad
name, and for a long time I have already wanted to change it to HexStation,
but I didn't  get to it yet).  It should be possible to add all such methods
to that class, but I'll have to work out the details first before I'm sure
about it.  If we manage to do that, we might be able to use both Map.xml and
TileSet.xml to define station properties, as best fits the actual need. 

Erik.

Re: [Rails-devel] 1830 Reading

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

Erik,
I totally agree with your proposal.

I had the impression, that you already created a bypass to allow manual 
adjustments of Tiles.xml in the case it is required.
I am fine with TileSet.xml (or Map.xml) if this is what you think is best, as 
you are responsible of the that area of program.

In a sense there is no clear answer to that, as it depends if a property is 
tile specific (game-independent) => Tiles.xml, tile specific (game-dependent) 
=> TileSet.xml or hex specific => Map.xml. However in a case of a special tile 
which is fixed on only one hex all three so option are valid. 

I suggest  that the code to determine the question if a station is tokened out 
or accessible is part of the main Rail code base.

Thus if there is a method for a Station object, which allows to query the 
access rights, the question how this information is fed into this method, is 
out of the control and interest of the revenue algorithm.

(A similar separation will be done for the value property, where the revenue 
algorithm still decides, whether to query the hex or the station for the 
value.)

Stefan


On Wednesday, June 15, 2011 12:27:45 pm Erik Vos wrote:
> Stefan,
> 
> > is there any reason, why you put the driveThroughStation on map.xml
> > instead in tile.xml, other than the one discusses previously, that
> 
> tiles.xml is
> 
> > not game specific?
> 
> The reason is that Tiles.xml is generated from the TileDesigner XML export,
> via my class ConvertTilesXML.  Any manual tweaks to that output would be
> overwritten the next time something changes in the tile set of a game.
> 
> > However the tiles you defined are (very) game specific already.
> 
> So far, yes, but please note that runTo and runThrough are intended to
> provide a generic solution for all red off-map hexes as well.
> [ I wrote this before I saw your inclusion of an old mail of yours below.
> See below for further comments.]
> See for instance 18Scan, where red hexes can only be run to if tokened,
> whereas in 1800 no token is required to run to a similar off-map tile
> (although it's coloured white in that game).
> 
> > Both from logical and implementation issues I would prefer to define
> > attributes of stations in the station tag instead of the hex tag.
> 
> I can understand that.  I could answer (not quite seriously), that in this
> case we cannot really decide if this is a hex or a tile/station property,
> because these preprinted tiles are never upgraded. One wonders if that
> non-drivethrough property would survive if an upgrade would exist...
> 
> Although I basically agree with you, I found this way simpler to implement,
> at least for this first step.  To do it your way, tile-specific special
> code would be needed in ConvertTilesXML.
> See below.
> 
> > Coalfields:
> > For the coalfield hex a mechanism to buy the coalfield tokens is needed
> 
> first.
> 
> > Then it is easy to add the adjustment to the revenue calculator via the
> 
> static
> 
> > modifier approach similar to the bonus tokens.
> 
> Yes, that's on my list of things to do Real Soon Now.
> 
> > Stefan
> > 
> > By the way:
> > 
> > I have thought about similar issues in my mailing last year (04/29/10) on
> > "Changes to the Station objects", which cover some more cases due to a
> > more general approach.
> > 
> > A) Each station adds the following (additional) attributes:
> > 
> > tokenAllows = {RunThrough, RunFrom, NoAccess, N/A} If a token is laid it
> > allows to run through, to run from or no access?
> > 
> > openStationAllows = {RunThrough, RunTo, NoAccess, N/A} If a token is laid
> 
> it
> 
> > allows to run through, to run to or none?
> > 
> > closedStationAllows = {RunThrough, RunTo, NoAccess, N/A} If the station
> > is fully tokened and the company does not own a token there, what are
> > the possibilities?
> > 
> > To allow an easier definition I suggest to use station type definitions
> 
> like the
> 
> > company types etc.
> > 
> > A station is closed if the number of tokens equals the number of slots,
> > otherwise it is open.
> 
> Except in 1830 Altoona etc.
> 
> > By this definition a town is always closed, but by setting
> 
> closedStationAllows
> 
> > to RunThrough that is not an issue.
> > 
> > B) Different off-board locations:
> > There is a substantial variation of different kind of off-board
> > locations. There are at least four cases, may be more.
> > 
> > 1) Standard off-board locations (as in 1830) The off-board areas act as
> 
> sinks
> 
> > for all companies.
> > No tokens allowed.
> > (tokenAllows = N/A, openStationAllows = N/A, closedStationAllows = RunTo)
> > 
> > 2) Tokenable off-board locations (example: SP base in 1870) A base token
> 
> can
> 
> > be layed in at least one of the areas.
> > The rules claim that off-board areas are still sink for all companies,
> 
> except for
> 
> > the company with a token which can start a train there.
> > But it cannot run its trains through the hex (thus SP cannot have the
> > same train enter from NE and then continue to the E).
> > 
> > (tokenAllows = RunFrom, openStationAllows = RunTo, closedStationAllows =
> > RunTo)
> > 
> > 3) Run-through off-board locations (as Hamburg in 18EU) A non-tokenable
> > station (similar to towns), that allows running through it.
> > 
> > (tokenAllows = N/A, openStationAllows = N/A, closedStationAllows =
> > RunThrough)
> > 
> > And another from an non-implemented game:
> > 4) Tokenable run-to off-board locations (as in 18Scan) Here a base-token
> 
> is
> 
> > needed to run to the station.
> > 
> > (tokenAllows = RunFrom, openStationAllows = NoAccess ,
> > closedStationAllows =
> > NoAccess)
> > 
> > In  general a station is fully tokened if the nb of slots equals the nb
> > of
> 
> tokens.
> 
> > This implies that (default) towns are fully tokened (0=0), but the
> > fullyTokened attribute would be set to RunThrough.
> > 
> > StationTypes should be added to provide defaults.
> > 
> > C) Other new station attributes
> > runStationType = {Major, Minor}
> > Is it counted as city-type or town-type for plus-trains and
> 
> express-trains?
> 
> > name = {...}
> > I would like to add is a "name" attribute for stations on tiles.
> > Identical
> 
> names
> 
> > would imply that those stations are mutually exclusive for train runs.
> 
> They
> 
> > would be automatically added to the list of exclusions to the revenue
> > calculator.
> 
> Apologies that I did not remember this old mail of yours, and that I
> (probably) never responded to it.  So you had already thought through these
> matters long before I did.
> 
> All fine with me, but the catch still is that we cannot use Tiles.xml to
> define all these details. As long as we have to live with the limitations
> of TileDesigner, we only can use TileSet.xml and Map.xml to define such
> details.  I must insist upon that.
> 
> I now tend to think that we can best use TileSet.xml, as that is the place
> where we define ALL tile properties that TileDesginer cannot give us.  And
> for off-map hexes, this way it's only needed once per red tile type,
> instead of once per red hex.
> 
> Tiles.xml and TileSet.xml are parsed simultaneously, and in that process
> the contents of both files are effectively merged into the single Tile
> class and its related Track and Station classes.  So it's easy to
> propagate properties from TileSet.xml to the Stations.
> 
> I propose to add a <Station> tag to TileSet.xml and define any such special
> station properties there. In the unlikely case of multiple stations with
> different properties, we can use the (badly named) city number.
> 
> Erik.
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------------
> --- EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1830 Reading

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

Stefan,

> is there any reason, why you put the driveThroughStation on map.xml
> instead in tile.xml, other than the one discusses previously, that
tiles.xml is
> not game specific?

The reason is that Tiles.xml is generated from the TileDesigner XML export,
via my class ConvertTilesXML.  Any manual tweaks to that output would be
overwritten the next time something changes in the tile set of a game. 

> However the tiles you defined are (very) game specific already.

So far, yes, but please note that runTo and runThrough are intended to
provide a generic solution for all red off-map hexes as well.
[ I wrote this before I saw your inclusion of an old mail of yours below.
See below for further comments.]
See for instance 18Scan, where red hexes can only be run to if tokened,
whereas in 1800 no token is required to run to a similar off-map tile
(although it's coloured white in that game).

> Both from logical and implementation issues I would prefer to define
> attributes of stations in the station tag instead of the hex tag.

I can understand that.  I could answer (not quite seriously), that in this
case we cannot really decide if this is a hex or a tile/station property,
because these preprinted tiles are never upgraded. One wonders if that
non-drivethrough property would survive if an upgrade would exist...   

Although I basically agree with you, I found this way simpler to implement,
at least for this first step.  To do it your way, tile-specific special code
would be needed in ConvertTilesXML. 
See below.

> Coalfields:
> For the coalfield hex a mechanism to buy the coalfield tokens is needed
first.
> Then it is easy to add the adjustment to the revenue calculator via the
static
> modifier approach similar to the bonus tokens.

Yes, that's on my list of things to do Real Soon Now.

> Stefan
> 
> By the way:
> 
> I have thought about similar issues in my mailing last year (04/29/10) on
> "Changes to the Station objects", which cover some more cases due to a
> more general approach.
> 
> A) Each station adds the following (additional) attributes:
> 
> tokenAllows = {RunThrough, RunFrom, NoAccess, N/A} If a token is laid it
> allows to run through, to run from or no access?
> 
> openStationAllows = {RunThrough, RunTo, NoAccess, N/A} If a token is laid
it
> allows to run through, to run to or none?
> 
> closedStationAllows = {RunThrough, RunTo, NoAccess, N/A} If the station is
> fully tokened and the company does not own a token there, what are the
> possibilities?
> 
> To allow an easier definition I suggest to use station type definitions
like the
> company types etc.
> 
> A station is closed if the number of tokens equals the number of slots,
> otherwise it is open.

Except in 1830 Altoona etc.
 
> By this definition a town is always closed, but by setting
closedStationAllows
> to RunThrough that is not an issue.
> 
> B) Different off-board locations:
> There is a substantial variation of different kind of off-board locations.
> There are at least four cases, may be more.
> 
> 1) Standard off-board locations (as in 1830) The off-board areas act as
sinks
> for all companies.
> No tokens allowed.
> (tokenAllows = N/A, openStationAllows = N/A, closedStationAllows = RunTo)
> 
> 2) Tokenable off-board locations (example: SP base in 1870) A base token
can
> be layed in at least one of the areas.
> The rules claim that off-board areas are still sink for all companies,
except for
> the company with a token which can start a train there.
> But it cannot run its trains through the hex (thus SP cannot have the same
> train enter from NE and then continue to the E).
> 
> (tokenAllows = RunFrom, openStationAllows = RunTo, closedStationAllows =
> RunTo)
> 
> 3) Run-through off-board locations (as Hamburg in 18EU) A non-tokenable
> station (similar to towns), that allows running through it.
> 
> (tokenAllows = N/A, openStationAllows = N/A, closedStationAllows =
> RunThrough)
> 
> And another from an non-implemented game:
> 4) Tokenable run-to off-board locations (as in 18Scan) Here a base-token
is
> needed to run to the station.
> 
> (tokenAllows = RunFrom, openStationAllows = NoAccess ,
> closedStationAllows =
> NoAccess)
> 
> In  general a station is fully tokened if the nb of slots equals the nb of
tokens.
> This implies that (default) towns are fully tokened (0=0), but the
> fullyTokened attribute would be set to RunThrough.
> 
> StationTypes should be added to provide defaults.
> 
> C) Other new station attributes
> runStationType = {Major, Minor}
> Is it counted as city-type or town-type for plus-trains and
express-trains?
> 
> name = {...}
> I would like to add is a "name" attribute for stations on tiles. Identical
names
> would imply that those stations are mutually exclusive for train runs.
They
> would be automatically added to the list of exclusions to the revenue
> calculator.

Apologies that I did not remember this old mail of yours, and that I
(probably) never responded to it.  So you had already thought through these
matters long before I did.

All fine with me, but the catch still is that we cannot use Tiles.xml to
define all these details. As long as we have to live with the limitations of
TileDesigner, we only can use TileSet.xml and Map.xml to define such
details.  I must insist upon that.  

I now tend to think that we can best use TileSet.xml, as that is the place
where we define ALL tile properties that TileDesginer cannot give us.  And
for off-map hexes, this way it's only needed once per red tile type, instead
of once per red hex. 

Tiles.xml and TileSet.xml are parsed simultaneously, and in that process the
contents of both files are effectively merged into the single Tile class and
its related Track and Station classes.  So it's easy to propagate properties
from TileSet.xml to the Stations.

I propose to add a <Station> tag to TileSet.xml and define any such special
station properties there. In the unlikely case of multiple stations with
different properties, we can use the (badly named) city number.

Erik.

Re: [Rails-devel] 1830 Reading

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

Erik:

is there any reason, why you put the driveThroughStation on map.xml instead in 
tile.xml, other than the one discusses previously, that tiles.xml is not game 
specific?

However the tiles you defined are (very) game specific already.

Both from logical and implementation issues I would prefer to define 
attributes of stations in the station tag instead of the hex tag.

Coalfields:
For the coalfield hex a mechanism to buy the coalfield tokens is needed first. 
Then it is easy to add the adjustment to the revenue calculator via the static 
modifier approach similar to the bonus tokens.

Stefan

By the way:

I have thought about similar issues in my mailing last year (04/29/10) on 
"Changes to the Station objects", which cover some more cases due to a more 
general approach.

A) Each station adds the following (additional) attributes:

tokenAllows = {RunThrough, RunFrom, NoAccess, N/A}
If a token is laid it allows to run through, to run from or no access?

openStationAllows = {RunThrough, RunTo, NoAccess, N/A}
If a token is laid it allows to run through, to run to or none?

closedStationAllows = {RunThrough, RunTo, NoAccess, N/A}
If the station is fully tokened and the company does not own a token there, 
what are the possibilities?

To allow an easier definition I suggest to use station type definitions like 
the company types etc.

A station is closed if the number of tokens equals the number of slots, 
otherwise it is open. 

By this definition a town is always closed, but by setting closedStationAllows 
to RunThrough that is not an issue.

B) Different off-board locations:
There is a substantial variation of different kind of off-board locations. 
There are at least four cases, may be more.

1) Standard off-board locations (as in 1830)
The off-board areas act as sinks for all companies.
No tokens allowed.
(tokenAllows = N/A, openStationAllows = N/A, closedStationAllows = RunTo)

2) Tokenable off-board locations (example: SP base in 1870)
A base token can be layed in at least one of the areas.
The rules claim that off-board areas are still sink for all companies, except 
for the company with a token which can start a train there.
But it cannot run its trains through the hex (thus SP cannot have the same 
train enter from NE and then continue to the E).

(tokenAllows = RunFrom, openStationAllows = RunTo, closedStationAllows = 
RunTo)

3) Run-through off-board locations (as Hamburg in 18EU)
A non-tokenable station (similar to towns), that allows running through it.

(tokenAllows = N/A, openStationAllows = N/A, closedStationAllows = RunThrough)

And another from an non-implemented game:
4) Tokenable run-to off-board locations (as in 18Scan)
Here a base-token is needed to run to the station.

(tokenAllows = RunFrom, openStationAllows = NoAccess , closedStationAllows = 
NoAccess)

In  general a station is fully tokened if the nb of slots equals the nb of 
tokens. This implies that (default) towns are fully tokened (0=0), but the 
fullyTokened attribute would be set to RunThrough. 

StationTypes should be added to provide defaults.

C) Other new station attributes
runStationType = {Major, Minor}
Is it counted as city-type or town-type for plus-trains and express-trains?

name = {...}
I would like to add is a "name" attribute for stations on 
tiles. Identical names would imply that those stations are mutually exclusive 
for train runs. They would be automatically added to the list of exclusions 
to the revenue calculator.



On Thursday, April 28, 2011 11:24:49 am you wrote:
> Stefan,
> 
> 
> 
> I don't know if you are ready to restart doing bits of work for Rails, but
> here I have a problem that you might want to look into.
> 
> 
> 
> I found (not unexpectedly), that in the 1830 Reading variant, the H14 city
> is not closed for driving through by non-Reading trains, if there is no
> token in that city. See the attached saved file.
> 
> I did not test the original and new Altoona (H12) hexes, but I suppose
> these will behave similarly.
> 
> 
> 
> (BTW the strange route path shown is probably caused by the fact that the
> displayed SVG tile (-30006) differs from the tile that defines connectivity
> in Tiles.xml (-30007). I don't really worry about that.)
> 
> 
> 
> What we need, I think, is the ability to mark a hex to disallow driving
> through a station (city) except when there is a token.
> 
> That could for instance be accomplished by  an extra attribute in Map.xml,
> like 'driveThroughStation="tokenOnly"' (the other two -implicit- values
> being "yes" for normal tiles and "no" for off-map tiles).
> 
> Not sure if that would fit with your route determination logic. Anyway, I'm
> largely dependent on you to write the Java code for this fine-tuning
> detail.
> 
> 
> 
> Best regards,
> 
> Erik.
> 
> 
> 
> Van: Erik Vos [mailto:eri...@xs...]
> Verzonden: donderdag 28 april 2011 0:51
> Aan: 'Development list for Rails: an 18xx game'
> Onderwerp: Re: [Rails-devel] 1830 Reading
> 
> 
> 
> OK, added.
> 
> I have also created the Reading home hex (H14) tiles -30006 (displayed) and
> -30007 (internal, connectivity) and put these into the map.
> 
> BTW you also specified such a tile on H14 for Coalfields, but that is
> incorrect.
> 
> Erik.
> 
> 
> 
> Van: Scott Petersen [mailto:sc...@re...]
> Verzonden: woensdag 27 april 2011 23:46
> Aan: Development list for Rails: an 18xx game
> Onderwerp: [Rails-devel] 1830 Reading
> 
> 
> 
> While we are on a roll with making updates, here is a first pass at the
> Reading variant for 1830.  Note that this variant allows the C&A owner to
> select either the PRR or the RDG as the free share--this needs to be
> cleaned up a little with some nicer text.  I put in an extra variant
> option to accomodate for this, but ultimately, it would be nice to get
> this selection into the game.
> 
> 
> 
> I'm not sure how much interest there is in these variants, but I could see
> some BGGers getting excited about them.  Of course, until there is another
> release, very few people have access to the new stuff.
> 
> 
> 
> Personally, I now refuse to start any PBEM games that make systematic stock
> trashing a core strategy to doing well--it just takes too long.  Live games
> via Rails are okay of course.

Re: [Rails-devel] TileOrientation Enumeration

[Adam B. <ab...@o2...>]

I corrected here: 
https://sourceforge.net/apps/mediawiki/rails/index.php?title=Map.xml#Example. 
I haven't found any other places requiring correction thou I haven't looked 
that hard.

Adam Badura


-----Oryginalna wiadomość----- 
From: brett lentz
Sent: Tuesday, June 14, 2011 12:49 AM
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] TileOrientation Enumeration

I've upgraded your wiki access to Editor. Update away. :-)

---Brett.



On Mon, Jun 13, 2011 at 3:29 PM, Adam Badura <ab...@o2...> wrote:
>    Maybe this change requires updating some Wikis or tutorials or whatever
> as map XML files changed (a bit but still...)
>
>    Adam Badura
>
> -----Oryginalna wiadomość-----
> From: brett lentz
> Sent: Monday, June 13, 2011 9:10 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] TileOrientation Enumeration
>
> Looks great.  Applied.
>
> ---Brett.
>
>
>
> 2011/6/12 Adam Badura <ab...@o2...>:
>> In the attachment there is a minor refactoring for tile orientation which
>> I
>> developed while working on SVG advancement.
>>
>> I decided that it is useful on its own and is small enough for quick
>> review.
>> So here you have it.
>>
>> Adam Badura
>>
>> ------------------------------------------------------------------------------
>> EditLive Enterprise is the world's most technically advanced content
>> authoring tool. Experience the power of Track Changes, Inline Image
>> Editing and ensure content is compliant with Accessibility Checking.
>> http://p.sf.net/sfu/ephox-dev2dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel 

Re: [Rails-devel] TileOrientation Enumeration

[brett l. <bre...@gm...>]

I've upgraded your wiki access to Editor. Update away. :-)

---Brett.



On Mon, Jun 13, 2011 at 3:29 PM, Adam Badura <ab...@o2...> wrote:
>    Maybe this change requires updating some Wikis or tutorials or whatever
> as map XML files changed (a bit but still...)
>
>    Adam Badura
>
> -----Oryginalna wiadomość-----
> From: brett lentz
> Sent: Monday, June 13, 2011 9:10 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] TileOrientation Enumeration
>
> Looks great.  Applied.
>
> ---Brett.
>
>
>
> 2011/6/12 Adam Badura <ab...@o2...>:
>> In the attachment there is a minor refactoring for tile orientation which
>> I
>> developed while working on SVG advancement.
>>
>> I decided that it is useful on its own and is small enough for quick
>> review.
>> So here you have it.
>>
>> Adam Badura
>>
>> ------------------------------------------------------------------------------
>> EditLive Enterprise is the world's most technically advanced content
>> authoring tool. Experience the power of Track Changes, Inline Image
>> Editing and ensure content is compliant with Accessibility Checking.
>> http://p.sf.net/sfu/ephox-dev2dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] TileOrientation Enumeration

[Adam B. <ab...@o2...>]

    Maybe this change requires updating some Wikis or tutorials or whatever 
as map XML files changed (a bit but still...)

    Adam Badura

-----Oryginalna wiadomość----- 
From: brett lentz
Sent: Monday, June 13, 2011 9:10 PM
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] TileOrientation Enumeration

Looks great.  Applied.

---Brett.



2011/6/12 Adam Badura <ab...@o2...>:
> In the attachment there is a minor refactoring for tile orientation which 
> I
> developed while working on SVG advancement.
>
> I decided that it is useful on its own and is small enough for quick 
> review.
> So here you have it.
>
> Adam Badura
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel 

Re: [Rails-devel] Train management

[Chris S. <chr...@gm...>]

It seems to me from glancing at the rules that the 18EA trains are
equivalent to the various dual trains.  However, in 18EA, the train limit
changing never causes trains to be discarded to the pool - if a company
finds itself over limit due to phase change, it is allowed to stay over
limit.  Thus, the issue of train certificates in the pool is not relevant.

--
Chris

Please consider the environment before printing this e-mail.


On Mon, Jun 13, 2011 at 12:38 PM, Erik Vos <eri...@xs...> wrote:

> Thanks for the hint. Then MultiTrain or ChoiceTrain looks like a better
> name than DualTrain.
>
> Do such triple trains deviate in other aspects from the dual trains we
> know?
>
> The main point of considaration is the rule, that the choice cannot be
> changed when a chosen train is sold to another company, but erased when the
> train is discarded to the Pool?
>
> As discussed before, this rule is most explicitly stated in 18VA, but so
> far assumed to hold for all such choice trains.
>
>
> Erik.
>
>
>
> *Van:* Chris Shaffer [mailto:chr...@gm...]
> *Verzonden:* maandag 13 juni 2011 20:58
>
> *Aan:* Development list for Rails: an 18xx game
> *Onderwerp:* Re: [Rails-devel] Train management
>
>
>
> Note that, in 18EA there are triple train types - trains can be either
> freight or express or local.
>
>
>
> --
> Chris
>
> Please consider the environment before printing this e-mail.
>
> On Mon, Jun 13, 2011 at 8:59 AM, Erik Vos <eri...@xs...> wrote:
>
> > -----Oorspronkelijk bericht-----
> > Van: Stefan Frey [mailto:ste...@we...]
>
> > If you have flipTrain subclassing Train or have both be implementations
> of
> > the interface trainI is up to you. However I prefer the latter and trainI
> is an
> > unnecessary, as imho there is no need for an interface with only one
> > implementation (unless you provide an official API).
>
> We have many redundant interfaces, and I'd rather get rid of all of them,
> but there seems to be (or have been) a school of thought with some
> influence
> in this project that maintains that such interfaces are required about
> everywhere, just in case.  I prefer to use interfaces only when there is a
> actual need to provide some common functionality to classes in completely
> different hierarchies (good examples we have are the CashHolder, Moveable
> and MoveableHolder interfaces).
>
> We'll find out whether or not we really need TrainI when developing the
> dual
> train class; I will consider both options. This could the only other train
> class we will ever need: even the 18EU Pullmann has (right or wrong) been
> implemented with the standard Train class; its peculiarities are handled by
> special code.
>
>
> Erik.
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] Train management

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

Thanks for the hint. Then MultiTrain or ChoiceTrain looks like a better name
than DualTrain. 

Do such triple trains deviate in other aspects from the dual trains we know?


The main point of considaration is the rule, that the choice cannot be
changed when a chosen train is sold to another company, but erased when the
train is discarded to the Pool?

As discussed before, this rule is most explicitly stated in 18VA, but so far
assumed to hold for all such choice trains.


Erik.

 

Van: Chris Shaffer [mailto:chr...@gm...] 
Verzonden: maandag 13 juni 2011 20:58
Aan: Development list for Rails: an 18xx game
Onderwerp: Re: [Rails-devel] Train management

 

Note that, in 18EA there are triple train types - trains can be either
freight or express or local.


 

--
Chris

Please consider the environment before printing this e-mail.



On Mon, Jun 13, 2011 at 8:59 AM, Erik Vos <eri...@xs...> wrote:

> -----Oorspronkelijk bericht-----
> Van: Stefan Frey [mailto:ste...@we...]

> If you have flipTrain subclassing Train or have both be implementations of
> the interface trainI is up to you. However I prefer the latter and trainI
is an
> unnecessary, as imho there is no need for an interface with only one
> implementation (unless you provide an official API).

We have many redundant interfaces, and I'd rather get rid of all of them,
but there seems to be (or have been) a school of thought with some influence
in this project that maintains that such interfaces are required about
everywhere, just in case.  I prefer to use interfaces only when there is a
actual need to provide some common functionality to classes in completely
different hierarchies (good examples we have are the CashHolder, Moveable
and MoveableHolder interfaces).

We'll find out whether or not we really need TrainI when developing the dual
train class; I will consider both options. This could the only other train
class we will ever need: even the 18EU Pullmann has (right or wrong) been
implemented with the standard Train class; its peculiarities are handled by
special code.


Erik.








----------------------------------------------------------------------------
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel