rails-devel — List for discussion of Rails development

[Rails-devel] Tile and Token Lay GUI Hints

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

I checked in an experimental implementation that indicates possible hexes
for tile and token lay in CVS, based on the current implementation of
network graphs.

It takes into account possible tile upgrades and the current phase.
It is not perfect yet as it still might indicate some hexes which might not be 
upgradable (due to other constraints). Still it should be a superset of the 
allowed tile upgrades, those no possible hex should be missed.
The same holds for the possible locations for token lay.

Those are only visual hints, the actual checks have not changed, thus illegal 
tile and token lays are still allowed as before.

Stefan

Re: [Rails-devel] Map Correction, Network Info, Export

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

It works fine for me now. 

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Friday 09 April 2010 08:49
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Map Correction, Network Info, Export

Erik:
after my return from Stockholm to my desktop pc I had time to to figure that

out: I have now a dual installation of Java 5 and Java 6 on my desktop (not 
possible for my laptop unfortunately due to hd constraints), that I can test

under JRE 5.

Stefan

Some comments as those might be helpful for similar occasions:

> When trying Network Info, I'm getting an exception:
> 	java.lang.UnsupportedClassVersionError: Bad version number in .class
> file
> on line 589 in ORPanel.executeNetworkInfo():
>       NetworkGraphBuilder nwGraph = new NetworkGraphBuilder();
> Could this be another Java 5/6 clash?

That occurs if a jar was produced with a newer JDK version than the running 
JRE, independent of used language features. Thus I had a Java 5 compatible 
jar of jgraph, which was unfortunately compiled with a JDK version 6.

A similar issue arises now with the JUnit jar, which I added to the 
repository. As it is 3.8.2 it is definitely compatible with Java 5, but as
my 
Eclipse installation was compiled with JDK 6, it seems that this version
only 
runs under JRE 6, but at least it should avoid raising errors at compile 
time. As I assume that you have a Eclipse installation of Java 5 you could 
replace the jar in CVS with yours, than the testcases should also run under 
Java 5.

> Another glitch: in NetworkGraphBuilder.iterator, Eclipse consider the
> @Override annotation to be an error.
> I had to remove it to make this class compile. Could you check if that
> annotation can and should be removed indeed?

That is (again) the difference in override-annotations between 5 and 6 and I

forgot to set the Java 5 compatibility flag on my laptop.



----------------------------------------------------------------------------
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Map Correction, Network Info, Export

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

Answers below:
>
> > And at least to my knowledge there is no setting to let the JRE behave
> > like a
> > previous version, or is there?
>
> If you mean changes in the actual library code rather than the compiler,
> no, but then there really shouldn't be breaking changes between 1.5 and 1.6
> -- mostly 1.6 just added new APIs.

But still the bytecode of 1.6 is not compatible with 1.5 (unless the 
compatibility flag is set - at least I hope that it is then).
Avoiding the new APIs and the different annotation rules alone is not enough. 
Or do I miss something here?

>
> > The  other issue was that I am to lazy to checkout the sources of JUnit
> > myself
>
> and compiling it to to 5 again, if Erik can easily add one which works
> under
>
> > Java 5.
>
> Are you saying that JUnit ships only 1.6 class files?

No I am not (have not checked that - lazy), but at least the version of the 
junit jar that comes along with my eclipse build on my suse linux did not 
work with JRE 5, even if its manifest claims to be built with 1.4.

Re: [Rails-devel] Map Correction, Network Info, Export

[John A. T. <ja...@ja...>]

On Fri, Apr 9, 2010 at 10:38 AM, Stefan Frey <ste...@we...> wrote:

> That is actually the setting I use on my desktop (except that I forgot to
> set
> it on my laptop). However with out JRE 1.5 I will not find potential
> problems, if I use JRE 1.6 for running.
>

If you have the compliance level set to 1.5, AFAIK it will give you errors
for anything that would fail on a real 1.5.  For example, using
String.isEmpty will give an error on a 1.6 JDK with 1.5 compliance level.


> And at least to my knowledge there is no setting to let the JRE behave like
> a
> previous version, or is there?
>

If you mean changes in the actual library code rather than the compiler, no,
but then there really shouldn't be breaking changes between 1.5 and 1.6 --
mostly 1.6 just added new APIs.


> The  other issue was that I am to lazy to checkout the sources of JUnit
> myself

and compiling it to to 5 again, if Erik can easily add one which works under
> Java 5.
>

Are you saying that JUnit ships only 1.6 class files?

-- 
John A. Tamplin

Re: [Rails-devel] Map Correction, Network Info, Export

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

John,
thanks for pointing this out. 

That is actually the setting I use on my desktop (except that I forgot to set 
it on my laptop). However with out JRE 1.5 I will not find potential 
problems, if I use JRE 1.6 for running. 

And at least to my knowledge there is no setting to let the JRE behave like a 
previous version, or is there?

The  other issue was that I am to lazy to checkout the sources of JUnit myself 
and compiling it to to 5 again, if Erik can easily add one which works under 
Java 5.

Stefan


> Even if you have JDK 1.6 installed, you can configure Eclipse to use it as
> 1.5, which will produce class files compatible with 1.5 and give @Override
> warnings in the right places for 1.5.
>
> Under Window => Preferences => Java => Compiler, set the compliance level
> to 1.5.

Re: [Rails-devel] Map Correction, Network Info, Export

[John A. T. <ja...@ja...>]

On Fri, Apr 9, 2010 at 2:49 AM, Stefan Frey <ste...@we...> wrote:

> That occurs if a jar was produced with a newer JDK version than the running
> JRE, independent of used language features. Thus I had a Java 5 compatible
> jar of jgraph, which was unfortunately compiled with a JDK version 6.
>
> A similar issue arises now with the JUnit jar, which I added to the
> repository. As it is 3.8.2 it is definitely compatible with Java 5, but as
> my
> Eclipse installation was compiled with JDK 6, it seems that this version
> only
> runs under JRE 6, but at least it should avoid raising errors at compile
> time. As I assume that you have a Eclipse installation of Java 5 you could
> replace the jar in CVS with yours, than the testcases should also run under
> Java 5.


Even if you have JDK 1.6 installed, you can configure Eclipse to use it as
1.5, which will produce class files compatible with 1.5 and give @Override
warnings in the right places for 1.5.

Under Window => Preferences => Java => Compiler, set the compliance level to
1.5.

-- 
John A. Tamplin

Re: [Rails-devel] Map Correction, Network Info, Export

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

Erik:
after my return from Stockholm to my desktop pc I had time to to figure that 
out: I have now a dual installation of Java 5 and Java 6 on my desktop (not 
possible for my laptop unfortunately due to hd constraints), that I can test 
under JRE 5.

Stefan

Some comments as those might be helpful for similar occasions:

> When trying Network Info, I'm getting an exception:
> 	java.lang.UnsupportedClassVersionError: Bad version number in .class
> file
> on line 589 in ORPanel.executeNetworkInfo():
>       NetworkGraphBuilder nwGraph = new NetworkGraphBuilder();
> Could this be another Java 5/6 clash?

That occurs if a jar was produced with a newer JDK version than the running 
JRE, independent of used language features. Thus I had a Java 5 compatible 
jar of jgraph, which was unfortunately compiled with a JDK version 6.

A similar issue arises now with the JUnit jar, which I added to the 
repository. As it is 3.8.2 it is definitely compatible with Java 5, but as my 
Eclipse installation was compiled with JDK 6, it seems that this version only 
runs under JRE 6, but at least it should avoid raising errors at compile 
time. As I assume that you have a Eclipse installation of Java 5 you could 
replace the jar in CVS with yours, than the testcases should also run under 
Java 5.

> Another glitch: in NetworkGraphBuilder.iterator, Eclipse consider the
> @Override annotation to be an error.
> I had to remove it to make this class compile. Could you check if that
> annotation can and should be removed indeed?

That is (again) the difference in override-annotations between 5 and 6 and I 
forgot to set the Java 5 compatibility flag on my laptop.

Re: [Rails-devel] Map Correction, Network Info, Export

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

Stefan,

When trying Network Info, I'm getting an exception:
	java.lang.UnsupportedClassVersionError: Bad version number in .class
file
on line 589 in ORPanel.executeNetworkInfo():
      NetworkGraphBuilder nwGraph = new NetworkGraphBuilder(); 
Could this be another Java 5/6 clash?

Another glitch: in NetworkGraphBuilder.iterator, Eclipse consider the
@Override annotation to be an error. 
I had to remove it to make this class compile. Could you check if that
annotation can and should be removed indeed?

Erik.

-----Original Message-----
From: ste...@we... [mailto:ste...@we...] 
Sent: Monday 05 April 2010 21:13
To: Development game
Subject: [Rails-devel] Map Correction, Network Info, Export

Just a short update about my commit yesterday, collecting all my changes
since 
the last release. All stuff is pretty rough so far.

1) Map Correction
Activating map correction (Administrator =>  allows to up- and downgrade any

hex of the map free of any restriction (except that the tile must exist in 
the potential upgrade path of the initial tile of the hex). Tokens are not 
handled so far (especially for those cases where tokens have to be relaid).

Implementation is analog to cash corrections:
MapCorrectionManager creates and executes MapCorrectionActions. The 
intermediate steps of tile laying are handled by the Manager class as well 
(different to the LayTileAction, where the intermediate steps are controlled

by the UI classes).

2) Network Info
As a preliminary step to route connectivity and route calculation the map
and 
tile information is used to built a network graph. A visualization can be 
displayed in the MapPanel under Info => NetworkInfo for the complete map or 
the routes available for each company.

Based on the JGraphT library for the datastructure and JGraph for the visual

part. It might be necessary to add those to the Eclipse classpath manually, 
if building through Eclipse. The ant build script is adapted.

Implementation:
NetworkEdges and -Vertexes are the buidling blocks. NetworkIterator
implements 
the rules for a DFS iterator for the specific rules to traverse an 18xx map.

NetworkGraphBuilder contains methods to generate and visualize the graph. 

3) Export
Allows to export the map as CSV-File with HexID, TileID and Orientation.

Stefan

----------------------------------------------------------------------------
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Map Correction, Network Info, Export

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

Yes, I think all libraries should be put there.
I am now having the same problem again with the JGraph jars: Eclipse insists
that I have locally changed .classpath (which I have) and keeps insisting
that I have to commit that change (which might be OK because these jars are
already under /lib).

Erik.

-----Original Message-----
From: brett lentz [mailto:bre...@gm...] 
Sent: Tuesday 06 April 2010 19:43
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Map Correction, Network Info, Export

The Junit jars can go into /lib. I don't think we need to segregate it.

Though, the build.xml should probably be updated to exlude it from the
final release package.

---Brett.


On Tue, Apr 6, 2010 at 10:36 AM,  <ste...@we...> wrote:
> Phil:
> I tried to indicate those issues with Eclipse build in my e-mail, but
maybe it
> was not prominent enough.
>
> I have some guilt here as I proposed not to include a JUnit jar into the
Rails
> CVS, as it is a common library under a eclipse and can be activated by a
few
> clicks. But especially as the .classpath file is also part of the CVS this
> causes those issues. With that current setup it seems to be better to
include
> JUnit somewhere in the CVS.
>
> I do not know if lib is a good place, if we do that we have to exclude
that
> from getting into the Rails built. Maybe Brett has a good suggestion where
to
> put it (Maybe create test/lib?). Most likely this will happen soon after
we
> move to a new VCS ;-)
>
> Stefan
>
>
> -----Ursprüngliche Nachricht-----
> Von: Phil Davies <de...@gm...>
> Gesendet: Apr 6, 2010 11:17:08 AM
> An: "Development list for Rails: an 18xx game"
<rai...@li...>
> Betreff: Re: [Rails-devel] Map Correction, Network Info, Export
>
> Also, the JGraph and JGraphT jar files weren't in the library settings
> for the project...this might actually just be me being a little stupid
> with eclipse :p.  I've got it running now and I'm going to have a play
> with the network info stuff
>
> Phil
>
> On 6 April 2010 09:58, Phil Davies <de...@gm...> wrote:
>> Stefan,
>>
>> This all sounds really good, I went to have a test this morning and
>> the project properties has a reliance on junit.jar located in
>> c:\java\eclipse521 so it doesn't build straight off the CVS version at
>> the moment.
>>
>> I can fix this locally to test obviously but I think the checked in
>> version needs to be able to run standalone...
>>
>> Phil
>>
>> On 5 April 2010 20:12,   wrote:
>>> Just a short update about my commit yesterday, collecting all my changes
since
>>> the last release. All stuff is pretty rough so far.
>>>
>>> 1) Map Correction
>>> Activating map correction (Administrator =>  allows to up- and downgrade
any
>>> hex of the map free of any restriction (except that the tile must exist
in
>>> the potential upgrade path of the initial tile of the hex). Tokens are
not
>>> handled so far (especially for those cases where tokens have to be
relaid).
>>>
>>> Implementation is analog to cash corrections:
>>> MapCorrectionManager creates and executes MapCorrectionActions. The
>>> intermediate steps of tile laying are handled by the Manager class as
well
>>> (different to the LayTileAction, where the intermediate steps are
controlled
>>> by the UI classes).
>>>
>>> 2) Network Info
>>> As a preliminary step to route connectivity and route calculation the
map and
>>> tile information is used to built a network graph. A visualization can
be
>>> displayed in the MapPanel under Info => NetworkInfo for the complete map
or
>>> the routes available for each company.
>>>
>>> Based on the JGraphT library for the datastructure and JGraph for the
visual
>>> part. It might be necessary to add those to the Eclipse classpath
manually,
>>> if building through Eclipse. The ant build script is adapted.
>>>
>>> Implementation:
>>> NetworkEdges and -Vertexes are the buidling blocks. NetworkIterator
implements
>>> the rules for a DFS iterator for the specific rules to traverse an 18xx
map.
>>> NetworkGraphBuilder contains methods to generate and visualize the
graph.
>>>
>>> 3) Export
>>> Allows to export the map as CSV-File with HexID, TileID and Orientation.
>>>
>>> Stefan
>>>
>>>
----------------------------------------------------------------------------
--
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>
>>
>
>
----------------------------------------------------------------------------
--
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
----------------------------------------------------------------------------
--
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

----------------------------------------------------------------------------
--
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Network Info- user-selected route outlines

[Jim B. <ji...@ko...>]

I hope that- perhaps, as a preliminary feature to Rails-calculated routes- users will simply be able to outline their routes directly in Rails (by selecting the track, along the way)- 'route specification', if you will.

I know automatic calculation is a very popular, heavily requested feature.

Still, to me- 'route specification' is probably more important/fundamental than 'automatic route calculation'.

Indeed, I wonder if 'route specification' isn't the extent of 'automatic route calculation' that would be /allowed/, in a conventional, tournament-level 18xx game.  (I would expect that many 18xx experts feel calculating earnings properly is part of the game- not something that's necessarily /desirable/ to automate?)

Will automated route calculation be offered as an option?  If users /don't/ select automatic route calculation, will they still get some of the benefits of this work?  (Eg, specifically, for route-specification?)

Ideally, players could can still outline their own route(s), per-train, in the map view- Rails would then record that, and add-up/record the corresponding earnings precisely.  (And, of course- other users could review the earnings/routes, in the game history.)

regards,
-  jim

  

Re: [Rails-devel] Map Correction, Network Info, Export

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

The Junit jars can go into /lib. I don't think we need to segregate it.

Though, the build.xml should probably be updated to exlude it from the
final release package.

---Brett.


On Tue, Apr 6, 2010 at 10:36 AM,  <ste...@we...> wrote:
> Phil:
> I tried to indicate those issues with Eclipse build in my e-mail, but maybe it
> was not prominent enough.
>
> I have some guilt here as I proposed not to include a JUnit jar into the Rails
> CVS, as it is a common library under a eclipse and can be activated by a few
> clicks. But especially as the .classpath file is also part of the CVS this
> causes those issues. With that current setup it seems to be better to include
> JUnit somewhere in the CVS.
>
> I do not know if lib is a good place, if we do that we have to exclude that
> from getting into the Rails built. Maybe Brett has a good suggestion where to
> put it (Maybe create test/lib?). Most likely this will happen soon after we
> move to a new VCS ;-)
>
> Stefan
>
>
> -----Ursprüngliche Nachricht-----
> Von: Phil Davies <de...@gm...>
> Gesendet: Apr 6, 2010 11:17:08 AM
> An: "Development list for Rails: an 18xx game" <rai...@li...>
> Betreff: Re: [Rails-devel] Map Correction, Network Info, Export
>
> Also, the JGraph and JGraphT jar files weren't in the library settings
> for the project...this might actually just be me being a little stupid
> with eclipse :p.  I've got it running now and I'm going to have a play
> with the network info stuff
>
> Phil
>
> On 6 April 2010 09:58, Phil Davies <de...@gm...> wrote:
>> Stefan,
>>
>> This all sounds really good, I went to have a test this morning and
>> the project properties has a reliance on junit.jar located in
>> c:\java\eclipse521 so it doesn't build straight off the CVS version at
>> the moment.
>>
>> I can fix this locally to test obviously but I think the checked in
>> version needs to be able to run standalone...
>>
>> Phil
>>
>> On 5 April 2010 20:12,   wrote:
>>> Just a short update about my commit yesterday, collecting all my changes since
>>> the last release. All stuff is pretty rough so far.
>>>
>>> 1) Map Correction
>>> Activating map correction (Administrator =>  allows to up- and downgrade any
>>> hex of the map free of any restriction (except that the tile must exist in
>>> the potential upgrade path of the initial tile of the hex). Tokens are not
>>> handled so far (especially for those cases where tokens have to be relaid).
>>>
>>> Implementation is analog to cash corrections:
>>> MapCorrectionManager creates and executes MapCorrectionActions. The
>>> intermediate steps of tile laying are handled by the Manager class as well
>>> (different to the LayTileAction, where the intermediate steps are controlled
>>> by the UI classes).
>>>
>>> 2) Network Info
>>> As a preliminary step to route connectivity and route calculation the map and
>>> tile information is used to built a network graph. A visualization can be
>>> displayed in the MapPanel under Info => NetworkInfo for the complete map or
>>> the routes available for each company.
>>>
>>> Based on the JGraphT library for the datastructure and JGraph for the visual
>>> part. It might be necessary to add those to the Eclipse classpath manually,
>>> if building through Eclipse. The ant build script is adapted.
>>>
>>> Implementation:
>>> NetworkEdges and -Vertexes are the buidling blocks. NetworkIterator implements
>>> the rules for a DFS iterator for the specific rules to traverse an 18xx map.
>>> NetworkGraphBuilder contains methods to generate and visualize the graph.
>>>
>>> 3) Export
>>> Allows to export the map as CSV-File with HexID, TileID and Orientation.
>>>
>>> Stefan
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>
>>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Map Correction, Network Info, Export

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

Phil:
I tried to indicate those issues with Eclipse build in my e-mail, but maybe it 
was not prominent enough.

I have some guilt here as I proposed not to include a JUnit jar into the Rails 
CVS, as it is a common library under a eclipse and can be activated by a few 
clicks. But especially as the .classpath file is also part of the CVS this 
causes those issues. With that current setup it seems to be better to include 
JUnit somewhere in the CVS.

I do not know if lib is a good place, if we do that we have to exclude that 
from getting into the Rails built. Maybe Brett has a good suggestion where to 
put it (Maybe create test/lib?). Most likely this will happen soon after we 
move to a new VCS ;-) 

Stefan


-----Ursprüngliche Nachricht-----
Von: Phil Davies <de...@gm...>
Gesendet: Apr 6, 2010 11:17:08 AM
An: "Development list for Rails: an 18xx game" <rai...@li...>
Betreff: Re: [Rails-devel] Map Correction, Network Info, Export

Also, the JGraph and JGraphT jar files weren't in the library settings
for the project...this might actually just be me being a little stupid
with eclipse :p.  I've got it running now and I'm going to have a play
with the network info stuff

Phil

On 6 April 2010 09:58, Phil Davies <de...@gm...> wrote:
> Stefan,
>
> This all sounds really good, I went to have a test this morning and
> the project properties has a reliance on junit.jar located in
> c:\java\eclipse521 so it doesn't build straight off the CVS version at
> the moment.
>
> I can fix this locally to test obviously but I think the checked in
> version needs to be able to run standalone...
>
> Phil
>
> On 5 April 2010 20:12,   wrote:
>> Just a short update about my commit yesterday, collecting all my changes since
>> the last release. All stuff is pretty rough so far.
>>
>> 1) Map Correction
>> Activating map correction (Administrator =>  allows to up- and downgrade any
>> hex of the map free of any restriction (except that the tile must exist in
>> the potential upgrade path of the initial tile of the hex). Tokens are not
>> handled so far (especially for those cases where tokens have to be relaid).
>>
>> Implementation is analog to cash corrections:
>> MapCorrectionManager creates and executes MapCorrectionActions. The
>> intermediate steps of tile laying are handled by the Manager class as well
>> (different to the LayTileAction, where the intermediate steps are controlled
>> by the UI classes).
>>
>> 2) Network Info
>> As a preliminary step to route connectivity and route calculation the map and
>> tile information is used to built a network graph. A visualization can be
>> displayed in the MapPanel under Info => NetworkInfo for the complete map or
>> the routes available for each company.
>>
>> Based on the JGraphT library for the datastructure and JGraph for the visual
>> part. It might be necessary to add those to the Eclipse classpath manually,
>> if building through Eclipse. The ant build script is adapted.
>>
>> Implementation:
>> NetworkEdges and -Vertexes are the buidling blocks. NetworkIterator implements
>> the rules for a DFS iterator for the specific rules to traverse an 18xx map.
>> NetworkGraphBuilder contains methods to generate and visualize the graph.
>>
>> 3) Export
>> Allows to export the map as CSV-File with HexID, TileID and Orientation.
>>
>> Stefan
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Map Correction, Network Info, Export

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

Also, the JGraph and JGraphT jar files weren't in the library settings
for the project...this might actually just be me being a little stupid
with eclipse :p.  I've got it running now and I'm going to have a play
with the network info stuff

Phil

On 6 April 2010 09:58, Phil Davies <de...@gm...> wrote:
> Stefan,
>
> This all sounds really good, I went to have a test this morning and
> the project properties has a reliance on junit.jar located in
> c:\java\eclipse521 so it doesn't build straight off the CVS version at
> the moment.
>
> I can fix this locally to test obviously but I think the checked in
> version needs to be able to run standalone...
>
> Phil
>
> On 5 April 2010 20:12,  <ste...@we...> wrote:
>> Just a short update about my commit yesterday, collecting all my changes since
>> the last release. All stuff is pretty rough so far.
>>
>> 1) Map Correction
>> Activating map correction (Administrator =>  allows to up- and downgrade any
>> hex of the map free of any restriction (except that the tile must exist in
>> the potential upgrade path of the initial tile of the hex). Tokens are not
>> handled so far (especially for those cases where tokens have to be relaid).
>>
>> Implementation is analog to cash corrections:
>> MapCorrectionManager creates and executes MapCorrectionActions. The
>> intermediate steps of tile laying are handled by the Manager class as well
>> (different to the LayTileAction, where the intermediate steps are controlled
>> by the UI classes).
>>
>> 2) Network Info
>> As a preliminary step to route connectivity and route calculation the map and
>> tile information is used to built a network graph. A visualization can be
>> displayed in the MapPanel under Info => NetworkInfo for the complete map or
>> the routes available for each company.
>>
>> Based on the JGraphT library for the datastructure and JGraph for the visual
>> part. It might be necessary to add those to the Eclipse classpath manually,
>> if building through Eclipse. The ant build script is adapted.
>>
>> Implementation:
>> NetworkEdges and -Vertexes are the buidling blocks. NetworkIterator implements
>> the rules for a DFS iterator for the specific rules to traverse an 18xx map.
>> NetworkGraphBuilder contains methods to generate and visualize the graph.
>>
>> 3) Export
>> Allows to export the map as CSV-File with HexID, TileID and Orientation.
>>
>> Stefan
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>

Re: [Rails-devel] Map Correction, Network Info, Export

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

Stefan,

This all sounds really good, I went to have a test this morning and
the project properties has a reliance on junit.jar located in
c:\java\eclipse521 so it doesn't build straight off the CVS version at
the moment.

I can fix this locally to test obviously but I think the checked in
version needs to be able to run standalone...

Phil

On 5 April 2010 20:12,  <ste...@we...> wrote:
> Just a short update about my commit yesterday, collecting all my changes since
> the last release. All stuff is pretty rough so far.
>
> 1) Map Correction
> Activating map correction (Administrator =>  allows to up- and downgrade any
> hex of the map free of any restriction (except that the tile must exist in
> the potential upgrade path of the initial tile of the hex). Tokens are not
> handled so far (especially for those cases where tokens have to be relaid).
>
> Implementation is analog to cash corrections:
> MapCorrectionManager creates and executes MapCorrectionActions. The
> intermediate steps of tile laying are handled by the Manager class as well
> (different to the LayTileAction, where the intermediate steps are controlled
> by the UI classes).
>
> 2) Network Info
> As a preliminary step to route connectivity and route calculation the map and
> tile information is used to built a network graph. A visualization can be
> displayed in the MapPanel under Info => NetworkInfo for the complete map or
> the routes available for each company.
>
> Based on the JGraphT library for the datastructure and JGraph for the visual
> part. It might be necessary to add those to the Eclipse classpath manually,
> if building through Eclipse. The ant build script is adapted.
>
> Implementation:
> NetworkEdges and -Vertexes are the buidling blocks. NetworkIterator implements
> the rules for a DFS iterator for the specific rules to traverse an 18xx map.
> NetworkGraphBuilder contains methods to generate and visualize the graph.
>
> 3) Export
> Allows to export the map as CSV-File with HexID, TileID and Orientation.
>
> Stefan
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

[Rails-devel] Map Correction, Network Info, Export

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

Just a short update about my commit yesterday, collecting all my changes since 
the last release. All stuff is pretty rough so far.

1) Map Correction
Activating map correction (Administrator =>  allows to up- and downgrade any 
hex of the map free of any restriction (except that the tile must exist in 
the potential upgrade path of the initial tile of the hex). Tokens are not 
handled so far (especially for those cases where tokens have to be relaid).

Implementation is analog to cash corrections:
MapCorrectionManager creates and executes MapCorrectionActions. The 
intermediate steps of tile laying are handled by the Manager class as well 
(different to the LayTileAction, where the intermediate steps are controlled 
by the UI classes).

2) Network Info
As a preliminary step to route connectivity and route calculation the map and 
tile information is used to built a network graph. A visualization can be 
displayed in the MapPanel under Info => NetworkInfo for the complete map or 
the routes available for each company.

Based on the JGraphT library for the datastructure and JGraph for the visual 
part. It might be necessary to add those to the Eclipse classpath manually, 
if building through Eclipse. The ant build script is adapted.

Implementation:
NetworkEdges and -Vertexes are the buidling blocks. NetworkIterator implements 
the rules for a DFS iterator for the specific rules to traverse an 18xx map. 
NetworkGraphBuilder contains methods to generate and visualize the graph. 

3) Export
Allows to export the map as CSV-File with HexID, TileID and Orientation.

Stefan

Re: [Rails-devel] 1835 & Rails track network

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

Stefan,

A Station is a (potential) revenue point on a Tile: village, city*, pass,
port, mine, whatever 18xx designers have invented over the years.
A City (for lack of a better name) is a reference from a MapHex to the
Stations of the current Tile on that hex.
(In hindsight, TileStation and HexStation might have been better names).

A City is what remains stable** if a Tile is upgraded and thus becomes
detached from old and related to new Stations. The need for a  separate City
entity arose from the requirement to assign existing tokens to the right
Stations (cities*) during an upgrade of multistation Tiles, such as an OO
tile. So in fact Cities are only needed for tokenable Stations (but I think
non-tokenable stations are also assigned to Cities).

I hope this helps.

*lower case "city" refers to what in usual 18xx parlance is called a city. 
**strictly spoken, "stable" only applies if the number of tile stations
(cities*) does not change during the upgrade. Otherwise, Cities can merge or
even disappear.

Erik.

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Saturday 03 April 2010 11:44
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1835 & Rails track network

Erik:
I look forward to testing 1835 in Rails. 

In preparation of the results of Alex algorithm I did some experiments to 
build a network graph from the current available data in Rails. Actually it 
proved to be a lot easier than expected (less then 200 lines of code 
overall), as I built on a graph library (JGraphT, and for visualization 
JGraph). After that it is only a small step to define allowed Routes and 
Route extensions.

One thing I still have not fully investigated (both for routing and map 
corrections) is the relation between city and station objects. It might help

if you could give some hints, how you defined the interaction between
MapHex, 
Tile, Station and City classes, especially in the process of upgrading.

Brett & Erik:
With Erik progressing quickly to finish 1835, I am a little reluctant to
check 
in the preliminary code for the graph support, as those add a dependency on 
the two graph libraries mentioned above. Or what is your opinion here?
It would certainly be helpful to upgrade the revision system to one that 
supports branching better than CVS.

Stefan

On Friday 02 April 2010 22:13:17 Erik Vos wrote:
> Nationalisation was a lot easier to do then I had expected.
> Note: to keep is simple, the word "nationalisation" is not used anywhere.
> It's announced and reported as a normal buy, albeit from an unusual source
> at an unusual price.
> Also, players can now buy shares up to 100% throughout.
>
> Erik.
>
> -----Original Message-----
> From: Erik Vos [mailto:eri...@xs...]
> Sent: Wednesday 31 March 2010 00:01
> To: 'Development list for Rails: an 18xx game'
> Subject: [Rails-devel] 1835
>
> I have completed the Prussian formation in 1835. As far as I can see it
all
> works.
>
> Stefan Frey reported a bug in the initial player assigment in the Clemens
> variant, which I have also fixed.
>
> Next thing to do will be nationalisation.
>
> Erik.
>
>
>
---------------------------------------------------------------------------
>- --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
---------------------------------------------------------------------------
>--- Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel



----------------------------------------------------------------------------
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1835 & Rails track network

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

Erik:
I look forward to testing 1835 in Rails. 

In preparation of the results of Alex algorithm I did some experiments to 
build a network graph from the current available data in Rails. Actually it 
proved to be a lot easier than expected (less then 200 lines of code 
overall), as I built on a graph library (JGraphT, and for visualization 
JGraph). After that it is only a small step to define allowed Routes and 
Route extensions.

One thing I still have not fully investigated (both for routing and map 
corrections) is the relation between city and station objects. It might help 
if you could give some hints, how you defined the interaction between MapHex, 
Tile, Station and City classes, especially in the process of upgrading.

Brett & Erik:
With Erik progressing quickly to finish 1835, I am a little reluctant to check 
in the preliminary code for the graph support, as those add a dependency on 
the two graph libraries mentioned above. Or what is your opinion here?
It would certainly be helpful to upgrade the revision system to one that 
supports branching better than CVS.

Stefan

On Friday 02 April 2010 22:13:17 Erik Vos wrote:
> Nationalisation was a lot easier to do then I had expected.
> Note: to keep is simple, the word "nationalisation" is not used anywhere.
> It's announced and reported as a normal buy, albeit from an unusual source
> at an unusual price.
> Also, players can now buy shares up to 100% throughout.
>
> Erik.
>
> -----Original Message-----
> From: Erik Vos [mailto:eri...@xs...]
> Sent: Wednesday 31 March 2010 00:01
> To: 'Development list for Rails: an 18xx game'
> Subject: [Rails-devel] 1835
>
> I have completed the Prussian formation in 1835. As far as I can see it all
> works.
>
> Stefan Frey reported a bug in the initial player assigment in the Clemens
> variant, which I have also fixed.
>
> Next thing to do will be nationalisation.
>
> Erik.
>
>
> ---------------------------------------------------------------------------
>- --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ---------------------------------------------------------------------------
>--- Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1835

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

Nationalisation was a lot easier to do then I had expected. 
Note: to keep is simple, the word "nationalisation" is not used anywhere.
It's announced and reported as a normal buy, albeit from an unusual source
at an unusual price.
Also, players can now buy shares up to 100% throughout.

Erik.

-----Original Message-----
From: Erik Vos [mailto:eri...@xs...] 
Sent: Wednesday 31 March 2010 00:01
To: 'Development list for Rails: an 18xx game'
Subject: [Rails-devel] 1835

I have completed the Prussian formation in 1835. As far as I can see it all
works.

Stefan Frey reported a bug in the initial player assigment in the Clemens
variant, which I have also fixed.

Next thing to do will be nationalisation.

Erik.


----------------------------------------------------------------------------
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] [Rails-users] 1889 Private Power Issue

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

Reply to devel as I think it belongs there.

Justin:
thanks for pointing this out. Some comments below.

Usage of the 1889 E power: exchange to IR.
- You are right the 1889 rules do not define, when this exchange is possible.

- For simplicity the E power should work identical to the M&H swap to NYC in 
1830. I adapted the defintion of M&H and use the same special property, so 
Erik is best to address the issue of the current implementation.

The 1830 rules state in Table I: "The exchange can be made during the player's 
turn of a Stock Round or between turns of other players and Railroads in 
either Stock or Operating Rounds". 

My opinion on the rules are:

- I disagree with JC in two respects: First it can be done outside of 
your turn in the SR and second it is an additional action: I assume that this 
is always an additional action and it does not count as your one stock buy 
for that stock round turn (if executed at your turn). Especially you could 
buy one NYC share and then exchange the M&H during the same turn during a SR.

- I always wondered what happens if you exchange during an OR: Assume that the 
NYC already operates: Exhange the M&H after you privates distributed, but 
before the NYC operates: Are you entitled for two dividends? Assume that the 
NYC has not floated, but would be floated after the exchange: Can the NYC 
still operate? For that reason I would prefer any ruling to prevent a swap 
during the OR.

Fortunately it is more attractive to sell those privates to a railroad instead 
of doing the swap most of the time.

A more general comment on the timing issues:

- For pbem and network play powers that are optional for players at 
multiple times during turns (or even worse anytime) are annoying and 
potentially cause timing problems during ftf play. Another example for a 
similar power is the one of private B in 1889 (port tile laying), which can 
be played "... outside of the operating rounds of company controlled by 
another player. The player need not control a company...".  
When is "outside"? My interpretation is that is between turns of 
the railroads. The current implementation is that it is simply available at 
anytime in the specal menu and players can decide, which timing is the one to 
use.

Stefan

On Wednesday 31 March 2010 01:29:00 Justin Rebelo wrote:
> I wouldn't call this a bug, but I found something in 1889 that may be
> worth some polish if/when someone feels like it. I was unclear on the
> 1889 rules with regards to the Private Company E (which can be traded
> by the owning player for an IR share). The rules didn't clearly state
> whether this should be done during a stock turn, stock round, OR, etc.
> So, in rails, I tried to use the power during my corporation's
> operating turn (since some other games have privates which would allow
> this trade IIRC) and the message I got was: "Unexpected action:
> UseSpecialProperty: Swap E for 10% share of IR".
>
> I didn't know if this was a rails limitation on what should be allowed
> or whether rails just was following rules but not making that clear to
> me. I inquired on BGG and JC (who I generally consider an authority on
> rules) suggested that in this game, the trade must be done as a stock
> buying action.
>
> As such, rails appears to be following the rules accordingly, but it
> would be helpful if the response message to the user was clearer, such
> as "This special property must be used during your stock turn" or
> similar.
>
> I obviously have no idea if the code supports dynamic responses for
> things like this, but figured I'd point it out in case it matters to
> anyone.
>
> ---------------------------------------------------------------------------
>--- Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-users mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-users

[Rails-devel] 1835

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

I have completed the Prussian formation in 1835. As far as I can see it all
works.

Stefan Frey reported a bug in the initial player assigment in the Clemens
variant, which I have also fixed.

Next thing to do will be nationalisation.

Erik.

Re: [Rails-devel] Versioning

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

Chris -

I agree with you.

I hope that those people, like yourself, who have been encouraging new
users to try out our software are also helping shoulder some of that
support burden.

We'll absolutely try to help where we can. Just be aware that the
first step is very likely going to be upgrading to the latest version.
:-)

---Brett.



On Mon, Mar 29, 2010 at 5:12 PM, Chris Shaffer <chr...@gm...> wrote:
> While maintaining four copies of the base program might be realistic for
> developers or tech savvy users, it is by no means realistic for average end
> users.  There was a time, not so long ago, when you could reasonably assume
> that most, or nearly all, Rails users were tech savvy.  However, in recent
> months Rails has been evangelized to a much wider audience.  This is a
> tribute to the level of development and also to the developers!  However, it
> introduces new realities to considerations of technical support and
> expectations of user behavior that are not compatible with the previous
> situation.
>
> There is no way that [name withheld to protect the identity of a highly
> skilled 18xx player who happens to be tech-unsavvy] will run four versions
> of Rails, but I still want to play Rails with him.
>
> --
> Chris
>
> Please consider the environment before printing this e-mail.
>
>
> On Mon, Mar 29, 2010 at 1:51 PM, Phil Davies <de...@gm...> wrote:
>>
>> My general thoughts on this is that it's a LOT easier for users to
>> keep with one single version of rails for the entirety of one game
>> than it is for the devs to have to worry about every piece of
>> regression testing.  Personally I currently have 4 versions of rails
>> locally, one for each of 4 different PBEM games I have going and I
>> have no trouble with this setup.
>>
>> I make sure I store the log files of every game I play as well (You
>> can get the my.properties to do this for you) which means if there
>> ever is a critical bug that requires upgrading, you can easily replay
>> the game to that point in a newer version (Even the most complex game
>> of 1830, once thinking time is removed, takes about 15 minutes to
>> replay end to end)
>>
>> Phil
>>
>> On 29 March 2010 18:07, Stefan Frey <ste...@we...> wrote:
>> > My comments on the issues discussed:
>> >
>> > Auto-Update:
>> > I do not think that is possible and/or wise to do from inside Rails.
>> > Colossus (the titan game) supports the Java Webstart option. It still
>> > requires
>> > the installation of Webstart first and this could fail on some systems
>> > as
>> > well. However new releases of Webstart are less frequent compared to
>> > Rails.
>> >
>> > Versions and pbem:
>> > >From my knowledge of the code Erik always emphasizes the backward
>> > (code)
>> > compatibility of the Rails save files.
>> > As the game files are simply the stack of player's actions most issues
>> > arise
>> > if a bug fix that either restricts the strategy space (by preventing
>> > previously possible but illegal moves) or requires an additional
>> > activity of
>> > a player.
>> > Thus I would recommend upgrading to newer versions of Rails even for
>> > in-progress pbem as from that point on you benefit from the bug-fixes of
>> > the
>> > more recent versions. And I hope that the number of bugs fixed exceeds
>> > those
>> > created with each release.
>> >
>> > Regression tests:
>> > see my next e-mail, which went out to the users list last week, but did
>> > not
>> > make it to the devel list: save files of Rails (pbem) games are helpful
>> > to
>> > indicate upcoming version conflicts.
>> >
>> > Stefan
>> >
>> >
>> > On Monday 29 March 2010 18:40:27 brett lentz wrote:
>> >> Chris -
>> >>
>> >> I agree. An auto-update feature would be nice to have.
>> >>
>> >> It should go on the to-do list.
>> >>
>> >> ---Brett.
>> >>
>> >> On Mon, Mar 29, 2010 at 9:37 AM, Chris Shaffer
>> >> <chr...@gm...>
>> > wrote:
>> >> > I concur with Jim. It took scheduling a long distance phone call with
>> >> > a 3 hour time difference just to get Rails installed on one
>> >> > less-than-
>> >> > tech-savvy friend's home computer. He won't upgrade unless it is
>> >> > impossible to play and it will almost certainly require another round
>> >> > of me talking on the phone and saying "after you clicked that button,
>> >> > what does it say?". When CyberBoard forced an upgrade recently, I
>> >> > learned that his install of that program was 5 years out of date.
>> >> >
>> >> > Meanwhile, I update every time there is a new release.
>> >> >
>> >> > p.s. It would be nice to have an in game check for and install
>> >> > updates
>> >> > feature.
>> >> >
>> >> > --
>> >> > Chris Shaffer
>> >> >
>> >> > Please consider the environment before printing this email.
>> >> >
>> >> > On Mar 29, 2010, at 9:27 AM, Jim Black <ji...@ko...> wrote:
>> >> >> Brett,
>> >> >>
>> >> >> My post was titled "Versioning".
>> >> >>
>> >> >> In my reading, your comments below speak primarily to code
>> >> >> stability, and relative priorities of gaming bugs vs new titles.
>> >> >>
>> >> >> My comments weren't critical of Rails' stability, in general- and,
>> >> >> regardless- I think the new regression suites are critical, and will
>> >> >> make a profound improvement here anyway.
>> >> >>
>> >> >> Rather- I'm saying (a) it's very common for pbem tables to upgrade
>> >> >> Rails during a game, and, (b) it's very common for pbem users to be
>> >> >> running different versions of Rails /at the same time, at the same
>> >> >> table/.
>> >> >>
>> >> >> It would be useful if the Rails discussions, priorities, etc, simply
>> >> >> recognized this plain fact.
>> >> >>
>> >> >> Do with it, what you will- but, please- don't suggest most pbem
>> >> >> rails games are played start-to-finish by all the players with one
>> >> >> rails version; it's simply untrue.  Further- in my view, this leads
>> >> >> to simply ungrounded conclusions about the Rails user experience.
>> >> >>
>> >> >> - jim
>> >> >>
>> >> >>> Jim -
>> >> >>>
>> >> >>> I think you're missing the point.
>> >> >>>
>> >> >>> Each of us volunteers their time to the development of this
>> >> >>> project.
>> >> >>> The hours we dedicate are finite and limited.
>> >> >>>
>> >> >>> So, it's simply a question of how we spend that time.
>> >> >>>
>> >> >>> We certainly could spend that time making slow, deliberate, careful
>> >> >>> changes that don't break save file compatibility and doing the
>> >> >>> time-intensive regression testing to ensure that's the case.
>> >> >>>
>> >> >>> But... why would we? How does it help us achieve our goal of being
>> >> >>> able to support playing as many 18xx games electronically as we
>> >> >>> can?
>> >> >>>
>> >> >>> If we do things that way, it would take us literally years to
>> >> >>> implement any new feature because we'd need to painstakingly test
>> >> >>> every nook and cranny of the code to make sure those changes didn't
>> >> >>> break anything.
>> >> >>>
>> >> >>> Now, I'm not saying we shouldn't ever test anything. Stefan has
>> >> >>> done a
>> >> >>> great job improving our ability to test saved games.
>> >> >>>
>> >> >>> My point is, our time is limited and we must choose where to spend
>> >> >>> that time.
>> >> >>>
>> >> >>> The whole point of the e-mail you're quoting is that my
>> >> >>> recommendation
>> >> >>> on how to spend our limited time is to spend it on developing new
>> >> >>> features, implementing new games, and generally getting Rails into
>> >> >>> the
>> >> >>> state we'd like it to be in. The price we pay for focusing more on
>> >> >>> new
>> >> >>> development is that we will not be able to spend as much time on
>> >> >>> minimizing breakage.
>> >> >>>
>> >> >>> It's frustrating to hit a bug and have it tank your game. I
>> >> >>> understand
>> >> >>> this, perhaps more intimately than you're giving me credit.
>> >> >>> However,
>> >> >>> we can't be all things to everyone. Trade-offs and sacrifices are
>> >> >>> necessary if we want to get anything done.
>> >> >>>
>> >> >>> ---Brett.
>> >> >>
>> >> >> =
>> >> >> ---
>> >> >> ---
>> >> >> ---
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> Download Intel&#174; Parallel Studio Eval
>> >> >> Try the new software tools for yourself. Speed compiling, find bugs
>> >> >> proactively, and fine-tune applications for parallel performance.
>> >> >> See why Intel Parallel Studio got high marks during beta.
>> >> >> http://p.sf.net/sfu/intel-sw-dev
>> >> >> _______________________________________________
>> >> >> Rails-devel mailing list
>> >> >> Rai...@li...
>> >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >> >
>> >> >
>> >> > -------------------------------------------------------------------------
>> >> >----- Download Intel&#174; Parallel Studio Eval
>> >> > Try the new software tools for yourself. Speed compiling, find bugs
>> >> > proactively, and fine-tune applications for parallel performance.
>> >> > See why Intel Parallel Studio got high marks during beta.
>> >> > http://p.sf.net/sfu/intel-sw-dev
>> >> > _______________________________________________
>> >> > Rails-devel mailing list
>> >> > Rai...@li...
>> >> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >>
>> >>
>> >> ---------------------------------------------------------------------------
>> >>--- Download Intel&#174; Parallel Studio Eval
>> >> Try the new software tools for yourself. Speed compiling, find bugs
>> >> proactively, and fine-tune applications for parallel performance.
>> >> See why Intel Parallel Studio got high marks during beta.
>> >> http://p.sf.net/sfu/intel-sw-dev
>> >> _______________________________________________
>> >> Rails-devel mailing list
>> >> Rai...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Download Intel&#174; Parallel Studio Eval
>> > Try the new software tools for yourself. Speed compiling, find bugs
>> > proactively, and fine-tune applications for parallel performance.
>> > See why Intel Parallel Studio got high marks during beta.
>> > http://p.sf.net/sfu/intel-sw-dev
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] Versioning

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

While maintaining four copies of the base program might be realistic for
developers or tech savvy users, it is by no means realistic for average end
users.  There was a time, not so long ago, when you could reasonably assume
that most, or nearly all, Rails users were tech savvy.  However, in recent
months Rails has been evangelized to a much wider audience.  This is a
tribute to the level of development and also to the developers!  However, it
introduces new realities to considerations of technical support and
expectations of user behavior that are not compatible with the previous
situation.

There is no way that [name withheld to protect the identity of a highly
skilled 18xx player who happens to be tech-unsavvy] will run four versions
of Rails, but I still want to play Rails with him.

--
Chris

Please consider the environment before printing this e-mail.


On Mon, Mar 29, 2010 at 1:51 PM, Phil Davies <de...@gm...> wrote:

> My general thoughts on this is that it's a LOT easier for users to
> keep with one single version of rails for the entirety of one game
> than it is for the devs to have to worry about every piece of
> regression testing.  Personally I currently have 4 versions of rails
> locally, one for each of 4 different PBEM games I have going and I
> have no trouble with this setup.
>
> I make sure I store the log files of every game I play as well (You
> can get the my.properties to do this for you) which means if there
> ever is a critical bug that requires upgrading, you can easily replay
> the game to that point in a newer version (Even the most complex game
> of 1830, once thinking time is removed, takes about 15 minutes to
> replay end to end)
>
> Phil
>
> On 29 March 2010 18:07, Stefan Frey <ste...@we...> wrote:
> > My comments on the issues discussed:
> >
> > Auto-Update:
> > I do not think that is possible and/or wise to do from inside Rails.
> > Colossus (the titan game) supports the Java Webstart option. It still
> requires
> > the installation of Webstart first and this could fail on some systems as
> > well. However new releases of Webstart are less frequent compared to
> Rails.
> >
> > Versions and pbem:
> > >From my knowledge of the code Erik always emphasizes the backward (code)
> > compatibility of the Rails save files.
> > As the game files are simply the stack of player's actions most issues
> arise
> > if a bug fix that either restricts the strategy space (by preventing
> > previously possible but illegal moves) or requires an additional activity
> of
> > a player.
> > Thus I would recommend upgrading to newer versions of Rails even for
> > in-progress pbem as from that point on you benefit from the bug-fixes of
> the
> > more recent versions. And I hope that the number of bugs fixed exceeds
> those
> > created with each release.
> >
> > Regression tests:
> > see my next e-mail, which went out to the users list last week, but did
> not
> > make it to the devel list: save files of Rails (pbem) games are helpful
> to
> > indicate upcoming version conflicts.
> >
> > Stefan
> >
> >
> > On Monday 29 March 2010 18:40:27 brett lentz wrote:
> >> Chris -
> >>
> >> I agree. An auto-update feature would be nice to have.
> >>
> >> It should go on the to-do list.
> >>
> >> ---Brett.
> >>
> >> On Mon, Mar 29, 2010 at 9:37 AM, Chris Shaffer <chr...@gm...
> >
> > wrote:
> >> > I concur with Jim. It took scheduling a long distance phone call with
> >> > a 3 hour time difference just to get Rails installed on one less-than-
> >> > tech-savvy friend's home computer. He won't upgrade unless it is
> >> > impossible to play and it will almost certainly require another round
> >> > of me talking on the phone and saying "after you clicked that button,
> >> > what does it say?". When CyberBoard forced an upgrade recently, I
> >> > learned that his install of that program was 5 years out of date.
> >> >
> >> > Meanwhile, I update every time there is a new release.
> >> >
> >> > p.s. It would be nice to have an in game check for and install updates
> >> > feature.
> >> >
> >> > --
> >> > Chris Shaffer
> >> >
> >> > Please consider the environment before printing this email.
> >> >
> >> > On Mar 29, 2010, at 9:27 AM, Jim Black <ji...@ko...> wrote:
> >> >> Brett,
> >> >>
> >> >> My post was titled "Versioning".
> >> >>
> >> >> In my reading, your comments below speak primarily to code
> >> >> stability, and relative priorities of gaming bugs vs new titles.
> >> >>
> >> >> My comments weren't critical of Rails' stability, in general- and,
> >> >> regardless- I think the new regression suites are critical, and will
> >> >> make a profound improvement here anyway.
> >> >>
> >> >> Rather- I'm saying (a) it's very common for pbem tables to upgrade
> >> >> Rails during a game, and, (b) it's very common for pbem users to be
> >> >> running different versions of Rails /at the same time, at the same
> >> >> table/.
> >> >>
> >> >> It would be useful if the Rails discussions, priorities, etc, simply
> >> >> recognized this plain fact.
> >> >>
> >> >> Do with it, what you will- but, please- don't suggest most pbem
> >> >> rails games are played start-to-finish by all the players with one
> >> >> rails version; it's simply untrue.  Further- in my view, this leads
> >> >> to simply ungrounded conclusions about the Rails user experience.
> >> >>
> >> >> - jim
> >> >>
> >> >>> Jim -
> >> >>>
> >> >>> I think you're missing the point.
> >> >>>
> >> >>> Each of us volunteers their time to the development of this project.
> >> >>> The hours we dedicate are finite and limited.
> >> >>>
> >> >>> So, it's simply a question of how we spend that time.
> >> >>>
> >> >>> We certainly could spend that time making slow, deliberate, careful
> >> >>> changes that don't break save file compatibility and doing the
> >> >>> time-intensive regression testing to ensure that's the case.
> >> >>>
> >> >>> But... why would we? How does it help us achieve our goal of being
> >> >>> able to support playing as many 18xx games electronically as we can?
> >> >>>
> >> >>> If we do things that way, it would take us literally years to
> >> >>> implement any new feature because we'd need to painstakingly test
> >> >>> every nook and cranny of the code to make sure those changes didn't
> >> >>> break anything.
> >> >>>
> >> >>> Now, I'm not saying we shouldn't ever test anything. Stefan has
> >> >>> done a
> >> >>> great job improving our ability to test saved games.
> >> >>>
> >> >>> My point is, our time is limited and we must choose where to spend
> >> >>> that time.
> >> >>>
> >> >>> The whole point of the e-mail you're quoting is that my
> >> >>> recommendation
> >> >>> on how to spend our limited time is to spend it on developing new
> >> >>> features, implementing new games, and generally getting Rails into
> >> >>> the
> >> >>> state we'd like it to be in. The price we pay for focusing more on
> >> >>> new
> >> >>> development is that we will not be able to spend as much time on
> >> >>> minimizing breakage.
> >> >>>
> >> >>> It's frustrating to hit a bug and have it tank your game. I
> >> >>> understand
> >> >>> this, perhaps more intimately than you're giving me credit. However,
> >> >>> we can't be all things to everyone. Trade-offs and sacrifices are
> >> >>> necessary if we want to get anything done.
> >> >>>
> >> >>> ---Brett.
> >> >>
> >> >> =
> >> >> ---
> >> >> ---
> >> >> ---
> >> >> ---------------------------------------------------------------------
> >> >> Download Intel&#174; Parallel Studio Eval
> >> >> Try the new software tools for yourself. Speed compiling, find bugs
> >> >> proactively, and fine-tune applications for parallel performance.
> >> >> See why Intel Parallel Studio got high marks during beta.
> >> >> http://p.sf.net/sfu/intel-sw-dev
> >> >> _______________________________________________
> >> >> Rails-devel mailing list
> >> >> Rai...@li...
> >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >> >
> >> >
> -------------------------------------------------------------------------
> >> >----- Download Intel&#174; Parallel Studio Eval
> >> > Try the new software tools for yourself. Speed compiling, find bugs
> >> > proactively, and fine-tune applications for parallel performance.
> >> > See why Intel Parallel Studio got high marks during beta.
> >> > http://p.sf.net/sfu/intel-sw-dev
> >> > _______________________________________________
> >> > Rails-devel mailing list
> >> > Rai...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >>
> >>
> ---------------------------------------------------------------------------
> >>--- Download Intel&#174; Parallel Studio Eval
> >> Try the new software tools for yourself. Speed compiling, find bugs
> >> proactively, and fine-tune applications for parallel performance.
> >> See why Intel Parallel Studio got high marks during beta.
> >> http://p.sf.net/sfu/intel-sw-dev
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Download Intel&#174; Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Versioning

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

On version compatibility:

That is indeed what we strive for, but Rails is not yet mature enough to
guarantee that. Sometimes improving quality cannot be done without breaking
it:

1. When there is a bug fix that breaks an existing sequence of player
actions. For instance, when some bug had changed the playing order; or when
a missing action needs be inserted; or when a bug fix invalidates an
actually played action (such as buying a train or share, because after the
fix the company or player doesn’t have the money any more); we have seen
recent cases of all of these incompatibility causes.

My impression is, that we have passed the peak of such bug fixes. It is very
recently that Rails has started picking up significant usage, and it is no
wonder that in that period lots of bug reports and fixes have occurred.
Users have been keen to report these, and we have tried to issue fixes as
soon as we could manage (perhaps a bit too soon sometimes). Anyway, I think
Rails has been considerably hardened in the past months, also thanks to
Stefan's efforts to fix all my Undo-related oversights. So there is hope
that we have reached a higher level of stability now.

2. Occasionally we might find reasons to change the sequence of player
actions, insert extra actions or delete spurious ones. For instance, I'm
sometimes tempted to remove a 'Done' when that is the only real action that
can be taken, but I have so far managed to resist that temptation. In any
case, I think that such changes should never be done without prior
discussion in this group.

3. Maintaining backwards compatilibily can necessitate adding special
provisions, so that over time the program code may get polluted with code
for only that purpose. Occasionally a cleanup might be in order. We haven’t
done that for some time, and it is not really bad now, but over time the
need for such a cleanup might arise. IMO that should only be done at a major
(first version digit) or minor (second version digit) release, and with
proper and prior announcement.

The bottom line is, that backwards compatibility is a worthy goal, but
sometimes it is impossible to achieve, and sometimes it must be broken for
the good cause.

Erik.


-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Monday 29 March 2010 19:08
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Versioning

My comments on the issues discussed:

Auto-Update:
I do not think that is possible and/or wise to do from inside Rails.
Colossus (the titan game) supports the Java Webstart option. It still
requires 
the installation of Webstart first and this could fail on some systems as 
well. However new releases of Webstart are less frequent compared to Rails.

Versions and pbem:
>From my knowledge of the code Erik always emphasizes the backward (code) 
compatibility of the Rails save files.
As the game files are simply the stack of player's actions most issues arise

if a bug fix that either restricts the strategy space (by preventing 
previously possible but illegal moves) or requires an additional activity of

a player.
Thus I would recommend upgrading to newer versions of Rails even for 
in-progress pbem as from that point on you benefit from the bug-fixes of the

more recent versions. And I hope that the number of bugs fixed exceeds those

created with each release.

Regression tests:
see my next e-mail, which went out to the users list last week, but did not 
make it to the devel list: save files of Rails (pbem) games are helpful to 
indicate upcoming version conflicts.

Stefan


On Monday 29 March 2010 18:40:27 brett lentz wrote:
> Chris -
>
> I agree. An auto-update feature would be nice to have.
>
> It should go on the to-do list.
>
> ---Brett.
>
> On Mon, Mar 29, 2010 at 9:37 AM, Chris Shaffer <chr...@gm...> 
wrote:
> > I concur with Jim. It took scheduling a long distance phone call with
> > a 3 hour time difference just to get Rails installed on one less-than-
> > tech-savvy friend's home computer. He won't upgrade unless it is
> > impossible to play and it will almost certainly require another round
> > of me talking on the phone and saying "after you clicked that button,
> > what does it say?". When CyberBoard forced an upgrade recently, I
> > learned that his install of that program was 5 years out of date.
> >
> > Meanwhile, I update every time there is a new release.
> >
> > p.s. It would be nice to have an in game check for and install updates
> > feature.
> >
> > --
> > Chris Shaffer
> >
> > Please consider the environment before printing this email.
> >
> > On Mar 29, 2010, at 9:27 AM, Jim Black <ji...@ko...> wrote:
> >> Brett,
> >>
> >> My post was titled "Versioning".
> >>
> >> In my reading, your comments below speak primarily to code
> >> stability, and relative priorities of gaming bugs vs new titles.
> >>
> >> My comments weren't critical of Rails' stability, in general- and,
> >> regardless- I think the new regression suites are critical, and will
> >> make a profound improvement here anyway.
> >>
> >> Rather- I'm saying (a) it's very common for pbem tables to upgrade
> >> Rails during a game, and, (b) it's very common for pbem users to be
> >> running different versions of Rails /at the same time, at the same
> >> table/.
> >>
> >> It would be useful if the Rails discussions, priorities, etc, simply
> >> recognized this plain fact.
> >>
> >> Do with it, what you will- but, please- don't suggest most pbem
> >> rails games are played start-to-finish by all the players with one
> >> rails version; it's simply untrue.  Further- in my view, this leads
> >> to simply ungrounded conclusions about the Rails user experience.
> >>
> >> - jim
> >>
> >>> Jim -
> >>>
> >>> I think you're missing the point.
> >>>
> >>> Each of us volunteers their time to the development of this project.
> >>> The hours we dedicate are finite and limited.
> >>>
> >>> So, it's simply a question of how we spend that time.
> >>>
> >>> We certainly could spend that time making slow, deliberate, careful
> >>> changes that don't break save file compatibility and doing the
> >>> time-intensive regression testing to ensure that's the case.
> >>>
> >>> But... why would we? How does it help us achieve our goal of being
> >>> able to support playing as many 18xx games electronically as we can?
> >>>
> >>> If we do things that way, it would take us literally years to
> >>> implement any new feature because we'd need to painstakingly test
> >>> every nook and cranny of the code to make sure those changes didn't
> >>> break anything.
> >>>
> >>> Now, I'm not saying we shouldn't ever test anything. Stefan has
> >>> done a
> >>> great job improving our ability to test saved games.
> >>>
> >>> My point is, our time is limited and we must choose where to spend
> >>> that time.
> >>>
> >>> The whole point of the e-mail you're quoting is that my
> >>> recommendation
> >>> on how to spend our limited time is to spend it on developing new
> >>> features, implementing new games, and generally getting Rails into
> >>> the
> >>> state we'd like it to be in. The price we pay for focusing more on
> >>> new
> >>> development is that we will not be able to spend as much time on
> >>> minimizing breakage.
> >>>
> >>> It's frustrating to hit a bug and have it tank your game. I
> >>> understand
> >>> this, perhaps more intimately than you're giving me credit. However,
> >>> we can't be all things to everyone. Trade-offs and sacrifices are
> >>> necessary if we want to get anything done.
> >>>
> >>> ---Brett.
> >>
> >> =
> >> ---
> >> ---
> >> ---
> >> ---------------------------------------------------------------------
> >> Download Intel&#174; Parallel Studio Eval
> >> Try the new software tools for yourself. Speed compiling, find bugs
> >> proactively, and fine-tune applications for parallel performance.
> >> See why Intel Parallel Studio got high marks during beta.
> >> http://p.sf.net/sfu/intel-sw-dev
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
-------------------------------------------------------------------------
> >----- Download Intel&#174; Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
---------------------------------------------------------------------------
>--- Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel



----------------------------------------------------------------------------
--
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Versioning

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

My general thoughts on this is that it's a LOT easier for users to
keep with one single version of rails for the entirety of one game
than it is for the devs to have to worry about every piece of
regression testing.  Personally I currently have 4 versions of rails
locally, one for each of 4 different PBEM games I have going and I
have no trouble with this setup.

I make sure I store the log files of every game I play as well (You
can get the my.properties to do this for you) which means if there
ever is a critical bug that requires upgrading, you can easily replay
the game to that point in a newer version (Even the most complex game
of 1830, once thinking time is removed, takes about 15 minutes to
replay end to end)

Phil

On 29 March 2010 18:07, Stefan Frey <ste...@we...> wrote:
> My comments on the issues discussed:
>
> Auto-Update:
> I do not think that is possible and/or wise to do from inside Rails.
> Colossus (the titan game) supports the Java Webstart option. It still requires
> the installation of Webstart first and this could fail on some systems as
> well. However new releases of Webstart are less frequent compared to Rails.
>
> Versions and pbem:
> >From my knowledge of the code Erik always emphasizes the backward (code)
> compatibility of the Rails save files.
> As the game files are simply the stack of player's actions most issues arise
> if a bug fix that either restricts the strategy space (by preventing
> previously possible but illegal moves) or requires an additional activity of
> a player.
> Thus I would recommend upgrading to newer versions of Rails even for
> in-progress pbem as from that point on you benefit from the bug-fixes of the
> more recent versions. And I hope that the number of bugs fixed exceeds those
> created with each release.
>
> Regression tests:
> see my next e-mail, which went out to the users list last week, but did not
> make it to the devel list: save files of Rails (pbem) games are helpful to
> indicate upcoming version conflicts.
>
> Stefan
>
>
> On Monday 29 March 2010 18:40:27 brett lentz wrote:
>> Chris -
>>
>> I agree. An auto-update feature would be nice to have.
>>
>> It should go on the to-do list.
>>
>> ---Brett.
>>
>> On Mon, Mar 29, 2010 at 9:37 AM, Chris Shaffer <chr...@gm...>
> wrote:
>> > I concur with Jim. It took scheduling a long distance phone call with
>> > a 3 hour time difference just to get Rails installed on one less-than-
>> > tech-savvy friend's home computer. He won't upgrade unless it is
>> > impossible to play and it will almost certainly require another round
>> > of me talking on the phone and saying "after you clicked that button,
>> > what does it say?". When CyberBoard forced an upgrade recently, I
>> > learned that his install of that program was 5 years out of date.
>> >
>> > Meanwhile, I update every time there is a new release.
>> >
>> > p.s. It would be nice to have an in game check for and install updates
>> > feature.
>> >
>> > --
>> > Chris Shaffer
>> >
>> > Please consider the environment before printing this email.
>> >
>> > On Mar 29, 2010, at 9:27 AM, Jim Black <ji...@ko...> wrote:
>> >> Brett,
>> >>
>> >> My post was titled "Versioning".
>> >>
>> >> In my reading, your comments below speak primarily to code
>> >> stability, and relative priorities of gaming bugs vs new titles.
>> >>
>> >> My comments weren't critical of Rails' stability, in general- and,
>> >> regardless- I think the new regression suites are critical, and will
>> >> make a profound improvement here anyway.
>> >>
>> >> Rather- I'm saying (a) it's very common for pbem tables to upgrade
>> >> Rails during a game, and, (b) it's very common for pbem users to be
>> >> running different versions of Rails /at the same time, at the same
>> >> table/.
>> >>
>> >> It would be useful if the Rails discussions, priorities, etc, simply
>> >> recognized this plain fact.
>> >>
>> >> Do with it, what you will- but, please- don't suggest most pbem
>> >> rails games are played start-to-finish by all the players with one
>> >> rails version; it's simply untrue.  Further- in my view, this leads
>> >> to simply ungrounded conclusions about the Rails user experience.
>> >>
>> >> - jim
>> >>
>> >>> Jim -
>> >>>
>> >>> I think you're missing the point.
>> >>>
>> >>> Each of us volunteers their time to the development of this project.
>> >>> The hours we dedicate are finite and limited.
>> >>>
>> >>> So, it's simply a question of how we spend that time.
>> >>>
>> >>> We certainly could spend that time making slow, deliberate, careful
>> >>> changes that don't break save file compatibility and doing the
>> >>> time-intensive regression testing to ensure that's the case.
>> >>>
>> >>> But... why would we? How does it help us achieve our goal of being
>> >>> able to support playing as many 18xx games electronically as we can?
>> >>>
>> >>> If we do things that way, it would take us literally years to
>> >>> implement any new feature because we'd need to painstakingly test
>> >>> every nook and cranny of the code to make sure those changes didn't
>> >>> break anything.
>> >>>
>> >>> Now, I'm not saying we shouldn't ever test anything. Stefan has
>> >>> done a
>> >>> great job improving our ability to test saved games.
>> >>>
>> >>> My point is, our time is limited and we must choose where to spend
>> >>> that time.
>> >>>
>> >>> The whole point of the e-mail you're quoting is that my
>> >>> recommendation
>> >>> on how to spend our limited time is to spend it on developing new
>> >>> features, implementing new games, and generally getting Rails into
>> >>> the
>> >>> state we'd like it to be in. The price we pay for focusing more on
>> >>> new
>> >>> development is that we will not be able to spend as much time on
>> >>> minimizing breakage.
>> >>>
>> >>> It's frustrating to hit a bug and have it tank your game. I
>> >>> understand
>> >>> this, perhaps more intimately than you're giving me credit. However,
>> >>> we can't be all things to everyone. Trade-offs and sacrifices are
>> >>> necessary if we want to get anything done.
>> >>>
>> >>> ---Brett.
>> >>
>> >> =
>> >> ---
>> >> ---
>> >> ---
>> >> ---------------------------------------------------------------------
>> >> Download Intel&#174; Parallel Studio Eval
>> >> Try the new software tools for yourself. Speed compiling, find bugs
>> >> proactively, and fine-tune applications for parallel performance.
>> >> See why Intel Parallel Studio got high marks during beta.
>> >> http://p.sf.net/sfu/intel-sw-dev
>> >> _______________________________________________
>> >> Rails-devel mailing list
>> >> Rai...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>> > -------------------------------------------------------------------------
>> >----- Download Intel&#174; Parallel Studio Eval
>> > Try the new software tools for yourself. Speed compiling, find bugs
>> > proactively, and fine-tune applications for parallel performance.
>> > See why Intel Parallel Studio got high marks during beta.
>> > http://p.sf.net/sfu/intel-sw-dev
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>> ---------------------------------------------------------------------------
>>--- Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

[Rails-devel] Call for Rails save files

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

Already sent out to the users last week, but as most are still subscribed to 
devels only, a cross-posting:

All users of Rails:

To improve the library of test cases for Rails all users are invited 
to submit their saved game files. Especially fully completed games are of 
interest: It is possible to save games even after the end of game message.

But unfinished games with interesting and complicated moves are 
equally helpful.

And those you use Rails for pbem are invited as well to submit their current 
state of game: This strongly increases the likelihood that their game 
will still be reloadable with the next releases, at least up to the state of 
the submitted file.

Please state in the mail body the name of the submitter, 18xx gametype and if 
the game was a completed game or is a pbem in progress. Only submit 
save files that were created by a fairly recent Rails version (1.1.0 upwards, 
Dec2009+).

Simulated games can be submitted too, but please indicate that as well.

Simply send the save file as attachment off the list directly
to Erik Vos (eri...@xs...) or Stefan Frey (ste...@we...).

Thanks for your support!