rails-devel — List for discussion of Rails development

Re: [Rails-devel] Implementation levels

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

Phil,
with respect to 18EU:

Which issues did you run into? From my only true ftf test game we only 
experienced the usual undo-related ones (which should be a thing of the past 
hopefully) and the wrong bankruptcy scenario, which stopped our play 
eventually.

I do not know if 18EU belongs to the category of those games where no player 
should ever go bankrupt (as in 1835), and we (or at least the one who went 
bankrupt) did something out of the norm.

Stefan


On Wednesday 17 March 2010 13:20:44 Phil Davies wrote:
> Stefan,
>
> I think your definitions are pretty good, although under B, you put
> 'version incompatibilities possible'.  Theoretically with the amount
> of shared code that impacts across multiple games and the shared tile
> database, version incompatibilities could always creep in?  Obviously
> we would want to minimise them but I think it's not unreasonable to
> expect people to use a consistent version for their games.
>
> For existing support levels, my opinions:
> 1825: D
> 1830: B (Can you swap the M&H at any time now?  A bugfix release that
> resolves the private swap bug might put this very close to A)
> 1851: B
> 18AL: B
> 18EU: C/B (I had a lot of issues in 1.1.3, I should retry a game in
> 1.2 to see how the bugfixes hold up
>
> Phil
>
> On 16 March 2010 22:33, Stefan Frey <ste...@we...> wrote:
> > After some discussion with Erik and Brett how to assign the playability
> > of the variants I am supporting now, I tried to assign some definitions
> > to each level of implementation.
> >
> > As Erik already remarked, there none of the variants fits into A) for
> > now, but that is hardly surprising given that Rails is still in beta.
> >
> > I would be glad to hear more opinions on both the categories themselves
> > and how to assign the current supported 18xx variants.
> >
> > Stefan
> >
> > My suggestions are:
> > 1870 - D
> > 1889 - B
> >
> > Implementation Levels:
> >
> > A) Mature
> > - Several independent plays until the end reported
> > - Full implementation of the ruleset
> > - All possible moves are available
> > - No illegal move possible (except tile and token lays, revenue
> > calculation) => Serious ftf play possible
> > => pbem play possible
> >
> > B) Fully Playable
> > - Full implementation of the ruleset
> > - All possible moves are available
> > - Might still allow a few illegal moves (in addition to tile and token
> > lays, revenue calculation)
> > => Serious ftf play possible, but bugs are possible
> > => use with caution for pbem play, version incompatibilities possible
> >
> > C) Almost Playable
> > - Nearly complete implementation of the ruleset
> > - Not all possible moves are available
> > - Illegal moves are possible
> > => Serious testing possible, do not expect to complete a game
> > => not recommended for pbem play
> >
> > D) Experimental
> > - Rules and components are incomplete
> > => Some testing possible
> >
> >
> > -------------------------------------------------------------------------
> >----- 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] Implementation levels

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

Save file compatilibity is important for regression testing, as long we
don’t have better ways to retest existing functionality than by loading old
saved files (at least I don't). Several classes have extra code to cope with
that. One day we might decide to take the hit and clean up all such code,
but IMO that should be a conscious decision. Fortunately, the main thing to
do about that is making sure that PossibleAction subclasses can still
deserialize when extra attributes have been added.

These days, most incompabilities arise as a consequence of bug fixing. This
might make old moves illegal (for instance, when the order of operation of
companies has changed). Another recent example is the inclusion of an extra
action to select the home city on a OO tile (1830 Erie, 1856 THB). The only
option to resume such a broken game with a new version is replaying the game
from the start, or from a file saved just before the cause of the change.

Erik.

-----Original Message-----
From: brett lentz [mailto:bre...@gm...] 
Sent: Wednesday 17 March 2010 18:14
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Implementation levels

On Wed, Mar 17, 2010 at 9:58 AM, Chris Shaffer <chr...@gm...>
wrote:
>> I agree, somewhat.  I think the assumption should just be to finish a
>> game with the same version of Rails that started the game.
>>
>> Until the codebase matures a bit, I don't really think it's worthwhile
>> to spend a ton of effort worrying about save file compatibility.
>
> The one concern I have with this is showstopper bugs.  If a group is
playing
> a game, gets halfway through, and can't continue because of a bug, there
> should be some support for converting their game to the new version with
the
> bugfix.
>
> --
> Chris


Of course.   I'm not saying that we won't support users when they have
problems.  We absolutely should and will.

I'm saying that, as developers, we shouldn't spend a lot of time
trying to preserve backwards compatibility with old save formats. It's
extra work that just doesn't buy us anything at this stage in rails'
maturity.

If the number of safe files that we need to migrate forward to the new
format grows substantially, obviously we'll need to change this
strategy or develop tools to allow users to migrate save files. For
now, I'd just like to see bug fixes and new games/features take a
higher priority than save file compatibility.

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

Re: [Rails-devel] Implementation levels

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

On Wed, Mar 17, 2010 at 9:58 AM, Chris Shaffer <chr...@gm...> wrote:
>> I agree, somewhat.  I think the assumption should just be to finish a
>> game with the same version of Rails that started the game.
>>
>> Until the codebase matures a bit, I don't really think it's worthwhile
>> to spend a ton of effort worrying about save file compatibility.
>
> The one concern I have with this is showstopper bugs.  If a group is playing
> a game, gets halfway through, and can't continue because of a bug, there
> should be some support for converting their game to the new version with the
> bugfix.
>
> --
> Chris


Of course.   I'm not saying that we won't support users when they have
problems.  We absolutely should and will.

I'm saying that, as developers, we shouldn't spend a lot of time
trying to preserve backwards compatibility with old save formats. It's
extra work that just doesn't buy us anything at this stage in rails'
maturity.

If the number of safe files that we need to migrate forward to the new
format grows substantially, obviously we'll need to change this
strategy or develop tools to allow users to migrate save files. For
now, I'd just like to see bug fixes and new games/features take a
higher priority than save file compatibility.

---Brett.

Re: [Rails-devel] Implementation levels

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

>
> I agree, somewhat.  I think the assumption should just be to finish a
> game with the same version of Rails that started the game.
>
> Until the codebase matures a bit, I don't really think it's worthwhile
> to spend a ton of effort worrying about save file compatibility.
>

The one concern I have with this is showstopper bugs.  If a group is playing
a game, gets halfway through, and can't continue because of a bug, there
should be some support for converting their game to the new version with the
bugfix.

--
Chris

Please consider the environment before printing this e-mail.

Re: [Rails-devel] Implementation levels

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

On Wed, Mar 17, 2010 at 5:20 AM, Phil Davies <de...@gm...> wrote:
> Stefan,
>
> I think your definitions are pretty good, although under B, you put
> 'version incompatibilities possible'.  Theoretically with the amount
> of shared code that impacts across multiple games and the shared tile
> database, version incompatibilities could always creep in?  Obviously
> we would want to minimise them but I think it's not unreasonable to
> expect people to use a consistent version for their games.


I agree, somewhat.  I think the assumption should just be to finish a
game with the same version of Rails that started the game.

Until the codebase matures a bit, I don't really think it's worthwhile
to spend a ton of effort worrying about save file compatibility.

---Brett.

Re: [Rails-devel] Implementation levels

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

Stefan,

I think your definitions are pretty good, although under B, you put
'version incompatibilities possible'.  Theoretically with the amount
of shared code that impacts across multiple games and the shared tile
database, version incompatibilities could always creep in?  Obviously
we would want to minimise them but I think it's not unreasonable to
expect people to use a consistent version for their games.

For existing support levels, my opinions:
1825: D
1830: B (Can you swap the M&H at any time now?  A bugfix release that
resolves the private swap bug might put this very close to A)
1851: B
18AL: B
18EU: C/B (I had a lot of issues in 1.1.3, I should retry a game in
1.2 to see how the bugfixes hold up

Phil


On 16 March 2010 22:33, Stefan Frey <ste...@we...> wrote:
> After some discussion with Erik and Brett how to assign the playability of the
> variants I am supporting now, I tried to assign some definitions to each
> level of implementation.
>
> As Erik already remarked, there none of the variants fits into A) for now, but
> that is hardly surprising given that Rails is still in beta.
>
> I would be glad to hear more opinions on both the categories themselves and
> how to assign the current supported 18xx variants.
>
> Stefan
>
> My suggestions are:
> 1870 - D
> 1889 - B
>
> Implementation Levels:
>
> A) Mature
> - Several independent plays until the end reported
> - Full implementation of the ruleset
> - All possible moves are available
> - No illegal move possible (except tile and token lays, revenue calculation)
> => Serious ftf play possible
> => pbem play possible
>
> B) Fully Playable
> - Full implementation of the ruleset
> - All possible moves are available
> - Might still allow a few illegal moves (in addition to tile and token lays,
> revenue calculation)
> => Serious ftf play possible, but bugs are possible
> => use with caution for pbem play, version incompatibilities possible
>
> C) Almost Playable
> - Nearly complete implementation of the ruleset
> - Not all possible moves are available
> - Illegal moves are possible
> => Serious testing possible, do not expect to complete a game
> => not recommended for pbem play
>
> D) Experimental
> - Rules and components are incomplete
> => Some testing possible
>
>
> ------------------------------------------------------------------------------
> 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] error report, Rails 1.2 *nix tarball

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

Thanks a lot, the bug exists and was already be reported,
see the workaround in the bug report:

- Edit rails.sh and replace 1.1.3 by 1.2
- Start Rails from command line with java -jar ./rails-1.2.jar

Maybe you can communicate the more critical bug: It is not possible to 
exchange privates into shares in both 1830 and 1889 in Rails version 1.2.

Erik already fixed that bug and I hope that a bug fix release is soon 
available.
STefan

On Tuesday 16 March 2010 23:40:33 Aliza Panitz wrote:
> [Forwarded from our local list, I have not verified this myself.]
>
>
> ---------- Forwarded message ----------
> From: [snip]
> Date: Tue, Mar 16, 2010 at 2:27 PM
> Subject: Re: New version of Rails available
> To: [snip]
>
> I'd like to let the developer know that he needs to update the (*nix)
> shell script - it's still set to run rails-1.1.3.jar instead of
> rails-1.2.jar.  A simple fix, but also one easy to overlook.  How do I
> get in touch with him?  Or does someone on this list know him?
>
> Thanks,
> Michael
>
> On Mon, Mar 15, 2010 at 4:51 PM, James Cheevers <ja...@or...> wrote:
> > The Rails team is pleased to announce the availability of a new
> > version of Rails.
> >
> > You can download the latest version here:
> > https://sourceforge.net/projects/rails/files/Rails/1.2/
> >
> > Some highlights from this release are:
> >
> > * No Map Mode (for improved use as a table top game moderator)
> > - Replaces Token and Tile lay actions with a simple Operating Cost button
> > - Only supported for 1830, 1851, 1889, 18EU and 18Kaas
> > (1856 and 18AL have special Token Lays)
> >
> > * Cash Correction in Moderator Menu
> > - Allows moderators to adjust the cash position of players and floated
> > Companies
> > - When adjustments are made, a message is added to the Report Window
> > and a warning to the next Player will be displayed
> >
> > * 1889 support
> > - Full implementation of the rule set
> > - Limitation in forced selling: Change of director in other companies is
> > not prevented by Rails (see rule 10.6.2), thus House rule to play that
> > like 1830 is possible. Otherwise end the game at that point.
> > - Beginner Game includes all changes as defined in the rule book.
> >
> > * Several bug fixes to the undo mechanism
> > - Undo of end of game conditions and from the end of game window is
> > possible.
> > - It is (should) be possible now to cross round boundaries using the
> > forced undo mechanism.
> > - IMPORTANT: Undoing any action that moves tokens back on the same stock
> > space
> > can cause the token stack to be mixed up. This can cause games being in a
> > corrupt state and save files to be unloadable.
> > (this is true for all previous Rails releases including 1.1.3)
> >
> > * Many more bug fixes, especially to 1856, 18EU, 18AL.
> >
> > ---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

[Rails-devel] error report, Rails 1.2 *nix tarball

[Aliza P. <ali...@gm...>]

[Forwarded from our local list, I have not verified this myself.]


---------- Forwarded message ----------
From: [snip]
Date: Tue, Mar 16, 2010 at 2:27 PM
Subject: Re: New version of Rails available
To: [snip]

I'd like to let the developer know that he needs to update the (*nix)
shell script - it's still set to run rails-1.1.3.jar instead of
rails-1.2.jar.  A simple fix, but also one easy to overlook.  How do I
get in touch with him?  Or does someone on this list know him?

Thanks,
Michael

On Mon, Mar 15, 2010 at 4:51 PM, James Cheevers <ja...@or...> wrote:
> The Rails team is pleased to announce the availability of a new
> version of Rails.
>
> You can download the latest version here:
> https://sourceforge.net/projects/rails/files/Rails/1.2/
>
> Some highlights from this release are:
>
> * No Map Mode (for improved use as a table top game moderator)
> - Replaces Token and Tile lay actions with a simple Operating Cost button
> - Only supported for 1830, 1851, 1889, 18EU and 18Kaas
> (1856 and 18AL have special Token Lays)
>
> * Cash Correction in Moderator Menu
> - Allows moderators to adjust the cash position of players and floated
> Companies
> - When adjustments are made, a message is added to the Report Window
> and a warning to the next Player will be displayed
>
> * 1889 support
> - Full implementation of the rule set
> - Limitation in forced selling: Change of director in other companies is not
> prevented by Rails (see rule 10.6.2), thus House rule to play that like 1830
> is possible. Otherwise end the game at that point.
> - Beginner Game includes all changes as defined in the rule book.
>
> * Several bug fixes to the undo mechanism
> - Undo of end of game conditions and from the end of game window is
> possible.
> - It is (should) be possible now to cross round boundaries using the forced
> undo mechanism.
> - IMPORTANT: Undoing any action that moves tokens back on the same stock
> space
> can cause the token stack to be mixed up. This can cause games being in a
> corrupt state and save files to be unloadable.
> (this is true for all previous Rails releases including 1.1.3)
>
> * Many more bug fixes, especially to 1856, 18EU, 18AL.
>
> ---Brett.
>
>
>

[Rails-devel] Implementation levels

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

After some discussion with Erik and Brett how to assign the playability of the 
variants I am supporting now, I tried to assign some definitions to each 
level of implementation. 

As Erik already remarked, there none of the variants fits into A) for now, but 
that is hardly surprising given that Rails is still in beta.

I would be glad to hear more opinions on both the categories themselves and 
how to assign the current supported 18xx variants.

Stefan

My suggestions are:
1870 - D
1889 - B

Implementation Levels:

A) Mature
- Several independent plays until the end reported
- Full implementation of the ruleset
- All possible moves are available
- No illegal move possible (except tile and token lays, revenue calculation)
=> Serious ftf play possible
=> pbem play possible

B) Fully Playable
- Full implementation of the ruleset
- All possible moves are available
- Might still allow a few illegal moves (in addition to tile and token lays, 
revenue calculation)
=> Serious ftf play possible, but bugs are possible
=> use with caution for pbem play, version incompatibilities possible

C) Almost Playable
- Nearly complete implementation of the ruleset
- Not all possible moves are available
- Illegal moves are possible
=> Serious testing possible, do not expect to complete a game
=> not recommended for pbem play

D) Experimental
- Rules and components are incomplete
=> Some testing possible

Re: [Rails-devel] New mailing lists

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

Good catch.  I'll do that.

---Brett.



On Tue, Mar 16, 2010 at 2:57 AM, Phil Davies <de...@gm...> wrote:
> Brett (or anyone who has edit rights)
>
> It would be worth adding the new mailing list links to the front page
> of http://rails.sourceforge.net/ since currently that only links to
> the -devel mailing list.
>
> Phil
>
> On 12 March 2010 17:37, brett lentz <bre...@gm...> wrote:
>> Hey gang -
>>
>> I've created two new mailing lists:
>>
>> rails-users and rails-announce.
>>
>> The -users list will be for non-technical discussions, gameplay and
>> rules interpretation discussions, and support requests from users.
>>
>> The -announce list will be for anybody that wants to skip the
>> discussions and just hear about new releases. It'll be a very low
>> traffic list that's only used to distribute major news.
>>
>> ---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
>

Re: [Rails-devel] Rails

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

Stephen,

Unfortunately, documentation isn't particularly detailed at the
moment, what little there is.  Like most small community projects,
contributors are keen to spend their free time adding exciting
functionality rather than the more boring documentation, despite the
usefulness it would provide!

That said, we're a fairly helpful bunch when it comes to helping
people get set up with the game so feel free to ask any questions you
want, we have both this list and also a rails-users list
(https://lists.sourceforge.net/lists/listinfo/rails-users) which is
aimed at

Given that you found the mailing list, I imagine you have managed to
locate and download the latest release?  Have you been able to fire it
up yet?  If you let me know whether you are running on Windows, Mac OS
or some other OS then I can help you get the software running if you
haven't got that far.  Once it's running you can easily set up a
sample game with a couple of imaginary users to see how the system
plays out.  To an experience 18XX player it should be reasonably
self-explanatory but feel free to ask questions and we'll do our best
to help!

Phil

On 15 March 2010 20:50, Stephen Webb <ste...@mi...> wrote:
> Hi guys
>
> I have only just seen your program for the first time today. As I run
> an 18xx hobby zine I am very interested in how it works. Is there a
> link to somewhere that will explain to me how to operate the software?
>
> Regards
>
> Stephen Webb
>
> ------------------------------------------------------------------------------
> 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] New mailing lists

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

Brett (or anyone who has edit rights)

It would be worth adding the new mailing list links to the front page
of http://rails.sourceforge.net/ since currently that only links to
the -devel mailing list.

Phil

On 12 March 2010 17:37, brett lentz <bre...@gm...> wrote:
> Hey gang -
>
> I've created two new mailing lists:
>
> rails-users and rails-announce.
>
> The -users list will be for non-technical discussions, gameplay and
> rules interpretation discussions, and support requests from users.
>
> The -announce list will be for anybody that wants to skip the
> discussions and just hear about new releases. It'll be a very low
> traffic list that's only used to distribute major news.
>
> ---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
>

[Rails-devel] Rails

[Stephen W. <ste...@mi...>]

Hi guys

I have only just seen your program for the first time today. As I run
an 18xx hobby zine I am very interested in how it works. Is there a
link to somewhere that will explain to me how to operate the software?

Regards

Stephen Webb

Re: [Rails-devel] Rails 1.2 is available.

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

On Sun, Mar 14, 2010 at 5:28 PM, Randy Shipp <ran...@gm...> wrote:
> On Sun, Mar 14, 2010 at 1:49 PM, brett lentz <wak...@gm...> wrote:
>>
>> The Rails team is pleased to announce the availability of a new
>> version of Rails.
>
>
>>
>> Some highlights from this release are:
>>
>> - Only supported for 1830, 1851, 1889, 18EU and 18Kaas
>> (1856 and 18AL have special Token Lays)
>>
>
> ----------
> Does this mean the Operating Cost button doesn't work in 18AL, or that 18AL
> no longer works at all with this version?  I obviously don't want to upgrade
> if it will break my game in progress.  Thanks in advance for your help.
> Randy...


The Operating Cost feature is not supported with 18AL.  The ability to
play 18AL has not changed.

---Brett.

Re: [Rails-devel] Rails 1.2 is available.

[Randy S. <ran...@gm...>]

On Sun, Mar 14, 2010 at 1:49 PM, brett lentz <wak...@gm...> wrote:

> The Rails team is pleased to announce the availability of a new
> version of Rails.
>


> Some highlights from this release are:
>
> - Only supported for 1830, 1851, 1889, 18EU and 18Kaas
> (1856 and 18AL have special Token Lays)
>

----------
Does this mean the Operating Cost button doesn't work in 18AL, or that 18AL
no longer works at all with this version?  I obviously don't want to upgrade
if it will break my game in progress.  Thanks in advance for your help.

Randy...

[Rails-devel] Rails 1.2 is available.

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

The Rails team is pleased to announce the availability of a new
version of Rails.

You can download the latest version here:
https://sourceforge.net/projects/rails/files/Rails/1.2/

Some highlights from this release are:

* No Map Mode  (for improved use as a table top game moderator)
- Replaces Token and Tile lay actions with a simple Operating Cost button
- Only supported for 1830, 1851, 1889, 18EU and 18Kaas
(1856 and 18AL have special Token Lays)

* Cash Correction in Moderator Menu
- Allows moderators to adjust the cash position of players and floated Companies
- When adjustments are made, a message is added to the Report Window
and a warning to the next Player will be displayed

* 1889 support
- Full implementation of the rule set
- Limitation in forced selling: Change of director in other companies is not
prevented by Rails (see rule 10.6.2), thus House rule to play that like 1830
is possible. Otherwise end the game at that point.
- Beginner Game includes all changes as defined in the rule book.

* Several bug fixes to the undo mechanism
- Undo of end of game conditions and from the end of game window is possible.
- It is (should) be possible now to cross round boundaries using the forced
undo mechanism.
- IMPORTANT: Undoing any action that moves tokens back on the same stock space
can cause the token stack to be mixed up. This can cause games being in a
corrupt state and save files to be unloadable.
(this is true for all previous Rails releases including 1.1.3)

* Many more bug fixes, especially to 1856, 18EU, 18AL.


---Brett.

Re: [Rails-devel] 1856

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

To continue playing the game with the newest code, you would have to go back
to just before the first OR turn of the THB in OR4.1.
If you can send me a saved file of that situation, I will try to check if
CGR formation now runs correctly.

Erik.

-----Original Message-----
From: Aliza Panitz [mailto:ali...@gm...] 
Sent: Sunday 14 March 2010 02:33
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1856

Thanks.  If you want earlier savefiles from the same game Jim or I can
provide them.

On Sat, Mar 13, 2010 at 10:55 AM, Erik Vos <eri...@xs...> wrote:
> I have (hopefully) fixed a few problems reported by Jim B(lack?) for 1856.
I
> could not reproduce these problems with the current code because a
> previously applied fix (an extra question about where to place a home
token
> on an OO tile) put an extra question that was not answered by the provided
> saved files. But a rerun with 1.1.3 and a code inspection revealed two
> issues that now have been fixed.
>
> Erik.
>
>
>
----------------------------------------------------------------------------
--
> 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] 1856

[Aliza P. <ali...@gm...>]

Thanks.  If you want earlier savefiles from the same game Jim or I can
provide them.

On Sat, Mar 13, 2010 at 10:55 AM, Erik Vos <eri...@xs...> wrote:
> I have (hopefully) fixed a few problems reported by Jim B(lack?) for 1856. I
> could not reproduce these problems with the current code because a
> previously applied fix (an extra question about where to place a home token
> on an OO tile) put an extra question that was not answered by the provided
> saved files. But a rerun with 1.1.3 and a code inspection revealed two
> issues that now have been fixed.
>
> Erik.
>
>
> ------------------------------------------------------------------------------
> 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] Stockmarket type aka 1825 dev?

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

On 2010-03-09 15:21, brett lentz wrote:
> Or we can just divorce the text displayed by the map from the internal
> grid numbering and just maintain a mapping.

I like this idea because it doesn't require games which use oddball numbering/
lettering on their grids (such as 1853 which has lower case letters on X, upper
case on Y) to change to some other method on the Rails screen.

[Rails-devel] 1856

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

I have (hopefully) fixed a few problems reported by Jim B(lack?) for 1856. I
could not reproduce these problems with the current code because a
previously applied fix (an extra question about where to place a home token
on an OO tile) put an extra question that was not answered by the provided
saved files. But a rerun with 1.1.3 and a code inspection revealed two
issues that now have been fixed.

Erik.

[Rails-devel] Fixes

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

Two fixes:

- 18AL tile #446 can only be laid on Birmingham. Montgomery is now excluded.
(reported by Chris Shaffer)
- 1856 share just bought cannot be sold in the same turn (for simplicity,
implemented as: if a share was bought, at least one share must remain if
shares of that company are sold later in that same turn). (reported several
times, lastly by Aliza Panitz).

Erik.

Re: [Rails-devel] Stockmarket type aka 1825 dev?

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

Aliza, it's not going to be a big deal having brown tiles as
preprinted on a board, this is doable now.  Erik just changed my
original tile to grey to match the colours rails uses everywhere else
and I think this makes sense since it is not an upgradeable tile on
the board.

[EV] ... and also to enforce the rule that no loose track may end against a
blind brown hex side.

> There is at least one game out there (18io) which has fixed map tiles
> that are deliberately brown, not gray, so that people can lay "tragic
> track" leading into them (or even just have more flexibility upgrading
> adjacent city hexes.)

[EV] I such a case we can of course define brown tiles. The colour derives
from the tile class, not vice versa.

Erik.

Re: [Rails-devel] Interesting BGG thread with Rails users

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

On Fri, Mar 12, 2010 at 10:13 AM, Jim Black <ji...@ko...> wrote:
>
> Brett wrote:
>> Do you think it would be helpful to add a rails-users mailing list to give people a place to discuss more user-centric topics?
>
> And, Stefan wrote:
>> I believe that  a split into two lists would be really helpful, as I
>> sometimes  avoid the devel list for java specific stuff to avoid
>> scare off those from the devel list who are ("only") interested in
>> 18xx stuff (like rule questions and get feedback on the state of bugs).
>> Maybe even keep the current mailing list for that reason and add
>> a new one like devel-internal, devel-implementation or devel-java?
>
> I think Stefan's idea is a good one- a smaller list for developers/code-contributors /only/.
>
> This list could stay for more community discussion, etc.
>
> I think your team should keep encouraging that any bug reports should be filed as incidents, not freely reported to the list.  I fear that bugs that get reported to the list, but not filed as incidents, have three problems:  unnecessary noise on the list; the developers understandably inevitably lose track of specific list discussions or informal commitments, and thirdly; they're just not fixed as promptly as a result (or tracked as easily).
>
> Finally, though, I have to say that /nothing/ we do here would turn this particular list into a representative "Rails user community" forum.   This is just too technical of a group, imho- when I've asked that simple config options be defaults, everyone here was comfortable with launching separate versions of rails and/or editing my.properties, etc- I don't think that's remotely representative of the majority of rails users.  Rather, I think the rails users /on this list/ are much more technical than the average rails user from the geek, and the discussions here represent your more technical users and advocates.
>
> So, separate Rails user groups/discussions elsewhere- like on the geek- seem inevitable, and, ultimately, a good thing.
>
> best,
>  - jim
>

I agree.  The goal isn't to replace discussion elsewhere, but to be
inclusive and provide an "official" place that exists alongside the
informal discussions that happen elsewhere.

We've had the space for the more technical users for a while now, but
now that the project seems to have gained wider adoption, it's
probably time that we expanded our scope to allow the less technical
users to become a part of the discussion, too.


----Brett

Re: [Rails-devel] Interesting BGG thread with Rails users

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

Brett wrote:
> Do you think it would be helpful to add a rails-users mailing list to give people a place to discuss more user-centric topics?

And, Stefan wrote:
> I believe that  a split into two lists would be really helpful, as I 
> sometimes  avoid the devel list for java specific stuff to avoid
> scare off those from the devel list who are ("only") interested in 
> 18xx stuff (like rule questions and get feedback on the state of bugs). 
> Maybe even keep the current mailing list for that reason and add 
> a new one like devel-internal, devel-implementation or devel-java?

I think Stefan's idea is a good one- a smaller list for developers/code-contributors /only/.   

This list could stay for more community discussion, etc.

I think your team should keep encouraging that any bug reports should be filed as incidents, not freely reported to the list.  I fear that bugs that get reported to the list, but not filed as incidents, have three problems:  unnecessary noise on the list; the developers understandably inevitably lose track of specific list discussions or informal commitments, and thirdly; they're just not fixed as promptly as a result (or tracked as easily).

Finally, though, I have to say that /nothing/ we do here would turn this particular list into a representative "Rails user community" forum.   This is just too technical of a group, imho- when I've asked that simple config options be defaults, everyone here was comfortable with launching separate versions of rails and/or editing my.properties, etc- I don't think that's remotely representative of the majority of rails users.  Rather, I think the rails users /on this list/ are much more technical than the average rails user from the geek, and the discussions here represent your more technical users and advocates.

So, separate Rails user groups/discussions elsewhere- like on the geek- seem inevitable, and, ultimately, a good thing.

best,
 - jim

[Rails-devel] New mailing lists

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

Hey gang -

I've created two new mailing lists:

rails-users and rails-announce.

The -users list will be for non-technical discussions, gameplay and
rules interpretation discussions, and support requests from users.

The -announce list will be for anybody that wants to skip the
discussions and just hear about new releases. It'll be a very low
traffic list that's only used to distribute major news.

---Brett.