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

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:
sorry I forgot to reply to your question on automated tests recently:
The test cases are dependent on the game report, but the can be reinitialized 
easily by a few mouse clicks (see the document before).
So the short answer: No the test cases do not depend on minor detail changes, 
as long as the use case is followed. And they can easily be reinitialized 
again, but all bugs that got in in the mean time will stay undetected.

Thus the use case for changes in the game report is:
A) Check that all test cases report green.
B) Make the code change that alters the game report.
{C) All test cases will report red.} 
D) Reinitialize all test cases by selecting the root test directory.
{E) All test cases will report green.}

This is not required if you change only the text in LocalizedProperties, as 
the test is language independent.

However after you ignored the test cases for so long (and I did not run the 
tests myself), that I wanted to figure out first, why the did not run at all. 
And it can always be related to changes in the game report or due to 
undetected bugs.

But as the report changed the undetected bugs (if there are any left) will 
stay undetected, as I will simply reinitialize the test cases and all will 
show green again.

I still hope I could convince you to use the tests, as they are the only 
chance to capture bugs especially for those games which are not implemented by 
yourself (as in the 1889 example before).

Stefan


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

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

[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] 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

[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

[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

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

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

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

Stefan,

Wasn't it the case that all or most of the old tests did no longer work?  Or
have you fixed that in the meantime?

Obviously, the value of regression testing hinges upon the correctness and
reach of the test set, and I didn't have a high opinion of our original set
on both accounts. 
If I remember correctly, soon after you created this test set, I found it
starting to fall apart, and I apologize for not having spent any effort to
fix it while you were away. To me, JUnit testing was new, and I'm still not
used to it. 

However, I agree that it's a good thing to have and use such a test set, so
I'll have another look at it. A good and complete Wiki page would definitely
help a lot.

As to the test set, I think this should be a mix of complete games and
specially constructed test cases.  I only can provide the latter, as I don't
use Rails for playing myself. 
Scott Petersen has recently (22 June) reported that he had successfully run
a series of complete games of various kinds after I had done the Train
management changes.  Perhaps Scott could be persuaded to make his files
available for regression testing?  

I will try to familiarize myself again with this stuff, and then try to
select some useful test cases for addition to the set. The name of such
specially constructed saved files should somehow indicate their purpose.

Erik.
  
> -----Oorspronkelijk bericht-----
> Van: Stefan Frey [mailto:ste...@we...]
> Verzonden: dinsdag 5 juli 2011 7:47
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] Train management & dual trains
> 
> Erik:
> sorry I forgot to reply to your question on automated tests recently:
> The test cases are dependent on the game report, but the can be
> reinitialized easily by a few mouse clicks (see the document before).
> So the short answer: No the test cases do not depend on minor detail
> changes, as long as the use case is followed. And they can easily be
> reinitialized again, but all bugs that got in in the mean time will stay
> undetected.
> 
> Thus the use case for changes in the game report is:
> A) Check that all test cases report green.
> B) Make the code change that alters the game report.
> {C) All test cases will report red.}
> D) Reinitialize all test cases by selecting the root test directory.
> {E) All test cases will report green.}
> 
> This is not required if you change only the text in LocalizedProperties,
as the
> test is language independent.
> 
> However after you ignored the test cases for so long (and I did not run
the
> tests myself), that I wanted to figure out first, why the did not run at
all.
> And it can always be related to changes in the game report or due to
> undetected bugs.
> 
> But as the report changed the undetected bugs (if there are any left) will
stay
> undetected, as I will simply reinitialize the test cases and all will show
green
> again.
> 
> I still hope I could convince you to use the tests, as they are the only
chance
> to capture bugs especially for those games which are not implemented by
> yourself (as in the 1889 example before).
> 
> Stefan
> 
> 
> >
> > 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.
> 
>
----------------------------------------------------------------------------
--
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

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

[Phil D. <de...@gm...>]

If you need more save files of games played to completion, I can
always provide more.

On 5 July 2011 12:01, Erik Vos <eri...@xs...> wrote:
> Stefan,
>
> Wasn't it the case that all or most of the old tests did no longer work?  Or
> have you fixed that in the meantime?
>
> Obviously, the value of regression testing hinges upon the correctness and
> reach of the test set, and I didn't have a high opinion of our original set
> on both accounts.
> If I remember correctly, soon after you created this test set, I found it
> starting to fall apart, and I apologize for not having spent any effort to
> fix it while you were away. To me, JUnit testing was new, and I'm still not
> used to it.
>
> However, I agree that it's a good thing to have and use such a test set, so
> I'll have another look at it. A good and complete Wiki page would definitely
> help a lot.
>
> As to the test set, I think this should be a mix of complete games and
> specially constructed test cases.  I only can provide the latter, as I don't
> use Rails for playing myself.
> Scott Petersen has recently (22 June) reported that he had successfully run
> a series of complete games of various kinds after I had done the Train
> management changes.  Perhaps Scott could be persuaded to make his files
> available for regression testing?
>
> I will try to familiarize myself again with this stuff, and then try to
> select some useful test cases for addition to the set. The name of such
> specially constructed saved files should somehow indicate their purpose.
>
> Erik.
>
>> -----Oorspronkelijk bericht-----
>> Van: Stefan Frey [mailto:ste...@we...]
>> Verzonden: dinsdag 5 juli 2011 7:47
>> Aan: Development list for Rails: an 18xx game
>> Onderwerp: Re: [Rails-devel] Train management & dual trains
>>
>> Erik:
>> sorry I forgot to reply to your question on automated tests recently:
>> The test cases are dependent on the game report, but the can be
>> reinitialized easily by a few mouse clicks (see the document before).
>> So the short answer: No the test cases do not depend on minor detail
>> changes, as long as the use case is followed. And they can easily be
>> reinitialized again, but all bugs that got in in the mean time will stay
>> undetected.
>>
>> Thus the use case for changes in the game report is:
>> A) Check that all test cases report green.
>> B) Make the code change that alters the game report.
>> {C) All test cases will report red.}
>> D) Reinitialize all test cases by selecting the root test directory.
>> {E) All test cases will report green.}
>>
>> This is not required if you change only the text in LocalizedProperties,
> as the
>> test is language independent.
>>
>> However after you ignored the test cases for so long (and I did not run
> the
>> tests myself), that I wanted to figure out first, why the did not run at
> all.
>> And it can always be related to changes in the game report or due to
>> undetected bugs.
>>
>> But as the report changed the undetected bugs (if there are any left) will
> stay
>> undetected, as I will simply reinitialize the test cases and all will show
> green
>> again.
>>
>> I still hope I could convince you to use the tests, as they are the only
> chance
>> to capture bugs especially for those games which are not implemented by
>> yourself (as in the 1889 example before).
>>
>> Stefan
>>
>>
>> >
>> > 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.
>>
>>
> ----------------------------------------------------------------------------
> --
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

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

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

I attached a few--I have more that were not quite played to completion
that passed.

On Tue, Jul 5, 2011 at 6:03 AM, Phil Davies <de...@gm...> wrote:
> If you need more save files of games played to completion, I can
> always provide more.