rails-devel — List for discussion of Rails development

Re: [Rails-devel] Implementation details for revenue calculation

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

On Tue, Jun 8, 2010 at 6:19 PM, alexti <al...@sh...> wrote:
>> I hope that, at some point, Alex is interested in contributing code as
>> well as discussion. ;-)
>>
>> ---Brett.
> It seems that Stefan is taking care of the code better than I ever could
> ;-)
>
> I am interested in contributing AI to the project, unfortunately I see a
> serious gap between my interest and my ability :-(
>

Why should that stop you? ;-)

I've learned a ton about development (among other things) by starting
this project.

At this point, we have nobody else that's interested in developing an
AI (or cleaning up our API to facilitate AI development) and
contributing code. You're welcome to pick up the ball and run with it,
as the over-used sports metaphor goes.

There's a few different OSS projects with decent AI capabilities. So
long as the license is the same or more permissive, we can borrow
ideas from their code (or the code itself) to help get started.

If you've got the time and interest, sketch out some ideas and work up
a few patches. :-)

> Alex.
>

---Brett

Re: [Rails-devel] Implementation details for revenue calculation

[alexti <al...@sh...>]

> I hope that, at some point, Alex is interested in contributing code as
> well as discussion. ;-)
>
> ---Brett.
It seems that Stefan is taking care of the code better than I ever could  
;-)

I am interested in contributing AI to the project, unfortunately I see a  
serious gap between my interest and my ability :-(

Alex.

Re: [Rails-devel] Implementation details for revenue calculation

[alexti <al...@sh...>]

Stefan,

My comments are inline
> I have a first phase two prototype working. In fact it was not a too  
> difficult
> task, as I only create a multigraph with new edges, that define the new
> routes.
>
> Then I define "EdgeTravelSets", which define edges that are mutually
> exclusive. This is tracked by the calculator using reference counters,  
> as each
> edge might be excluded by several others.
I'm keeping a vector of exclusions for each edge. I haven't investigated  
what approach is more efficient. In the testcases I ran I've never seen  
this being a bottleneck, so my guess is that the storage method is  
probably unimportant for performance.

>
> The first results are promising so far and I believe I found the cause  
> for the
> difference in number of evaluations compared to your implementation.
> The main issue is that on a two phase graph the selection of neighbors is
> different to the original one (by definition).
>
> The effect was that the search for the 4-train set (8, 5+5, 4D, 6E) took
> between 30 - 140 seconds (compared to 70 seconds without).
What did the time depend on? I always had very stable times for any  
scenario we've tried. For the example above it was ~30 seconds, perhaps  
with 1 second spread.

> At first glance it was amazing that the run time did strongly vary and  
> the
> fact that the best  route is found remarkebly late in the process sheds  
> more
> light, why you believe that my revenue predicitor is of the magic type.
>
> I still sort the neighbors by value, but the ordering of the (potentially
> multiple) routes to them is random, as they are retrieved from a HashSet.
> The ordering of routes is important for the revenue predictor to work  
> well.
> Finding a good solution quick is important.
This is a very good point - I choose edge iteration order more or less  
randomly - I don't use any criteria to sort them. I kind of thought of  
trying to make more intelligent choice, but didn't come up with any good  
criterion.

> Without phase two optimization, the choice to visit the most valuable
> (neighboring) vertex is clearly the optimal approach, as each neigbor is  
> one
> track piece away. Thus the "costs" of each neighbor is identical.
>
> If you have done a phase two optimization, the most valuable vertex can  
> be
> quite far away, thus blocking several track pieces at the same time and
> ruling out a lot of other connections. Thus for phase two the cost of  
> each
> neighboring vertex vary substantially. Accordingly the cost has to be
> considered: The number of edges excluded must be an additional important
> criteria to select the routes.
>
> Take an example:
> Is it better to run for a nearby 20 vertex (which excludes one other  
> route) or
> the far away 50 vertex (which excludes three other routes and potentially
> bypasses the 10 vertex). There is no clear answer, but our preliminary
> results and my experiences with 18xx routes, implies that it is usually
> better to go for nearby stations first and save track first.
>
> Thus two approaches are possible:
> * Use Nb of edges excluded as a first criteria, value as a second only.  
> (Thus
> minimize costs first, then maximize revenue).
> In that case you would run to the 20 first.
>
> * Or combine the two and use something like cost-modified value  
> approach. For
> example choose the ratio between value and number of routes excluded
> (including the route selected).
> In that case you would run to the 50 first. (20/2 = 10, 50/4 = 12.5)
>
> I have implemented the ordering based on the first idea (cost-based) and  
> the
> time is now stable an 24 seconds run for the 4 train set, thus running  
> time
> decreased by factor 3.
I like your idea, I think it's a good criterion. My intuitive feeling is  
that (1) is a better approach. I agree that in normal 18xx games the  
routes follow specific pattern - generally people try to connect valuable  
location by the shortest route and the long scenic routes between two  
cities/towns is usually a sign of a well blocked map :)

>
> Number of evaluations one pass (70 seconds)
> 480961 evaluations, 2935133 predictions and 8828871 edges travelled.
>
> Number of evalutaions two pass with cost ordering (24 seconds)
> 475533 evaluations, 2910152 predictions and 2841394 edges travelled
>
> Number of evaluations two pass with value ordering (81 seconds)
> 1421981 evaluations, 7302480 predictions and 8297888 edges travelled
>
> It seems that edge travelling is the time limiting factor in my  
> approach, but
> that is not surprising as evaluation and prediction is pretty cheap  
> given the
> continuous update of the run values.
I want to try to use your approach to the edge ordering, but currently I  
took my implementation apart, because I wanted to restore vector  
computation functionality (which I broke when I added predictor) and this  
proves to be quite challenging (and, besides, the summer finally came here  
:) )

> To compare the validity of my approach, this are my figures about  
> vertices and
> edges:
>
> In scenario A the phase two graph consists of 23 vertices and 57  
> edges/routes.
> There are several routes that overlap with 9 other routes (J3.1 -> J9.1,
> K4.1 -> J3.1,J9.1 -> M2.1,K4.1 -> M2.1).
> In scenario B the numbers are 20 vertices and 151 edges/routes.
> The route that overlaps with most others is E8->D5 (over 19 hexes) that  
> shares
> track with 111 other routes.
I think I had the same numbers.

Alex.

Re: [Rails-devel] Rails 1.3 is now available.

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

We don't currently have the tile for Hamburg that shows the difference
either, I'd sort of argue that this is such a niche rule it's almost
not worth taking the effort over.  Unless of course there are games
with equally similar tiles that would benefit from this
differentiation

Phil

On 8 June 2010 22:23, Stefan Frey (web.de) <ste...@we...> wrote:
> Two bugs in 1.3:
> -> Serious, but easy to fix (already done in CVS):
> 18Kaas had the name of the new game option wrongly defined, that prevented any
> start/load of a 18Kaas game. Seems to be not a very popular choice, as no one
> complained so far...
>
> -> Very minor, but a difficult one:
> The (chromatic) rule in 1835 for the -10 malus to cross the Elbe in Hamburg is
> not complete: Currently only the malus is only applied if the train runs
> through Hamburg and crosses the Elbe.  There is a second part that is not yet
> implemented: If a train starts from a base token in Hamburg it is important
> if that base token lays south (Harburg) or north (City or Altona) the river
> Elbe. This is not possible to implement so far, as the current tile
> definition does not distinguish between the north/south slots on the brown
> Hamburg tile. I do not know if we should really go all the way to get that
> implemented, the current workaround is to reduce the revenue suggested by 10
> if that situation occurs (unless one finds an alternative run with identical
> revenue that does not start on other side of the river).
>
> Stefan
>
>
> On Monday 31 May 2010 16:27:38 brett lentz wrote:
>> I'm pleased to announce that Rails 1.3 is now available.
>>
>> This release adds an initial implementation of automated route and
>> revenue calculation as well as bug fixes for 1830, 1856, 1889. Also in
>> this release is revised documentation on how well-supported each game
>> is.
>>
>> Download the new release at http://rails.sourceforge.net/
>>
>> ---Brett.
>>
>> ---------------------------------------------------------------------------
>>---
>>
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Implementation details for revenue calculation

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

On Tue, Jun 8, 2010 at 1:57 PM, Stefan Frey (web.de) <ste...@we...> wrote:
> This (again) a specific mail on revenue calculation, that addresses Alex
> directly, but I prefer to keep the discussion on the develop list to allow
> archiving. I used the Rails archive throughout the work on my implementation
> and dug out several valuable thoughts (a special thanks goes to John
> Tamplin's contributions, his pseudo code form one of the mails is pretty
> similar to a core part).
>
> I hope that not too many complain, but in fact nobody is forced to read it to
> the end ;-)
>

Posting to the list is preferred.   Side conversations happen, and
that's fine.  However, reading through list archives is one of the
ways that many people learn how our development process works and
learn what we care about.

I hope that, at some point, Alex is interested in contributing code as
well as discussion. ;-)

---Brett.

Re: [Rails-devel] Rails 1.3 is now available.

[Stefan F. (web.de) <ste...@we...>]

Two bugs in 1.3:
-> Serious, but easy to fix (already done in CVS):
18Kaas had the name of the new game option wrongly defined, that prevented any 
start/load of a 18Kaas game. Seems to be not a very popular choice, as no one 
complained so far...

-> Very minor, but a difficult one:
The (chromatic) rule in 1835 for the -10 malus to cross the Elbe in Hamburg is 
not complete: Currently only the malus is only applied if the train runs 
through Hamburg and crosses the Elbe.  There is a second part that is not yet 
implemented: If a train starts from a base token in Hamburg it is important 
if that base token lays south (Harburg) or north (City or Altona) the river 
Elbe. This is not possible to implement so far, as the current tile 
definition does not distinguish between the north/south slots on the brown 
Hamburg tile. I do not know if we should really go all the way to get that 
implemented, the current workaround is to reduce the revenue suggested by 10 
if that situation occurs (unless one finds an alternative run with identical 
revenue that does not start on other side of the river).

Stefan 


On Monday 31 May 2010 16:27:38 brett lentz wrote:
> I'm pleased to announce that Rails 1.3 is now available.
>
> This release adds an initial implementation of automated route and
> revenue calculation as well as bug fixes for 1830, 1856, 1889. Also in
> this release is revised documentation on how well-supported each game
> is.
>
> Download the new release at http://rails.sourceforge.net/
>
> ---Brett.
>
> ---------------------------------------------------------------------------
>---
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Implementation details for revenue calculation

[Stefan F. (web.de) <ste...@we...>]

This (again) a specific mail on revenue calculation, that addresses Alex 
directly, but I prefer to keep the discussion on the develop list to allow 
archiving. I used the Rails archive throughout the work on my implementation 
and dug out several valuable thoughts (a special thanks goes to John 
Tamplin's contributions, his pseudo code form one of the mails is pretty 
similar to a core part).

I hope that not too many complain, but in fact nobody is forced to read it to 
the end ;-)

Alex,
I have a first phase two prototype working. In fact it was not a too difficult 
task, as I only create a multigraph with new edges, that define the new 
routes.

Then I define "EdgeTravelSets", which define edges that are mutually 
exclusive. This is tracked by the calculator using reference counters, as each 
edge might be excluded by several others.

The first results are promising so far and I believe I found the cause for the 
difference in number of evaluations compared to your implementation. 
The main issue is that on a two phase graph the selection of neighbors is 
different to the original one (by definition). 

The effect was that the search for the 4-train set (8, 5+5, 4D, 6E) took 
between 30 - 140 seconds (compared to 70 seconds without).
At first glance it was amazing that the run time did strongly vary and the 
fact that the best  route is found remarkebly late in the process sheds more 
light, why you believe that my revenue predicitor is of the magic type.

I still sort the neighbors by value, but the ordering of the (potentially 
multiple) routes to them is random, as they are retrieved from a HashSet.
The ordering of routes is important for the revenue predictor to work well. 
Finding a good solution quick is important.

Without phase two optimization, the choice to visit the most valuable 
(neighboring) vertex is clearly the optimal approach, as each neigbor is one 
track piece away. Thus the "costs" of each neighbor is identical.

If you have done a phase two optimization, the most valuable vertex can be 
quite far away, thus blocking several track pieces at the same time and 
ruling out a lot of other connections. Thus for phase two the cost of each 
neighboring vertex vary substantially. Accordingly the cost has to be 
considered: The number of edges excluded must be an additional important 
criteria to select the routes. 

Take an example:
Is it better to run for a nearby 20 vertex (which excludes one other route) or 
the far away 50 vertex (which excludes three other routes and potentially 
bypasses the 10 vertex). There is no clear answer, but our preliminary 
results and my experiences with 18xx routes, implies that it is usually 
better to go for nearby stations first and save track first.

Thus two approaches are possible:
* Use Nb of edges excluded as a first criteria, value as a second only. (Thus 
minimize costs first, then maximize revenue).
In that case you would run to the 20 first.

* Or combine the two and use something like cost-modified value approach. For 
example choose the ratio between value and number of routes excluded 
(including the route selected).
In that case you would run to the 50 first. (20/2 = 10, 50/4 = 12.5)

I have implemented the ordering based on the first idea (cost-based) and the 
time is now stable an 24 seconds run for the 4 train set, thus running time 
decreased by factor 3.

Number of evaluations one pass (70 seconds)
480961 evaluations, 2935133 predictions and 8828871 edges travelled.

Number of evalutaions two pass with cost ordering (24 seconds)
475533 evaluations, 2910152 predictions and 2841394 edges travelled

Number of evaluations two pass with value ordering (81 seconds)
1421981 evaluations, 7302480 predictions and 8297888 edges travelled

It seems that edge travelling is the time limiting factor in my approach, but 
that is not surprising as evaluation and prediction is pretty cheap given the 
continuous update of the run values.

Stefan


To compare the validity of my approach, this are my figures about vertices and 
edges:

In scenario A the phase two graph consists of 23 vertices and 57 edges/routes.
There are several routes that overlap with 9 other routes (J3.1 -> J9.1,  
K4.1 -> J3.1,J9.1 -> M2.1,K4.1 -> M2.1).

In scenario B the numbers are 20 vertices and 151 edges/routes.
The route that overlaps with most others is E8->D5 (over 19 hexes) that shares 
track with 111 other routes.

[Rails-devel] Fwd: [ rails-Bugs-3013209 ] 1835 stack order from IPO can be messed up

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

All,

Just raised the following bug on 1835 and thought it worth bringing up
for discussion.  I 'think' this is the only other supported game where
there are shares of a mixed type available for purchase (1856 has 5%
shares but I believe that the CGR is always either a 10% or 5% corp?).
 The game status interface doesn't really have the facility for
displaying exactly what share is the next available.

A veteran rails player will just click the cell and click yes in the
popup without really reading the message (I did, it took me a pass
round the table before I noticed I'd bought the 'wrong' share).

I'm not aware how many other games have mixed share values for
companies but is there a case here for a change to the UI to better
display what is on the cert that is offered?  maybe just something as
simple as anoter column to shows certs available rather than shares?
Not sure, just thought it was a point worth raising.

Phil


---------- Forwarded message ----------
From: SourceForge.net <no...@so...>
Date: 8 June 2010 13:15
Subject: [ rails-Bugs-3013209 ] 1835 stack order from IPO can be messed up
To: no...@so...


Bugs item #3013209, was opened at 2010-06-08 13:15
Message generated for change (Tracker Item Submitted) made by destrin
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=723360&aid=3013209&group_id=132173

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Game-specific
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Phil Davies (destrin)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1835 stack order from IPO can be messed up

Initial Comment:
With the attached save file:

Buy a cert of BAD from IPO (it will be 10%)
Moderator -> Forced Undo
Buy a cert of BAD from IPO (it will offer the 20% cert)

The 10% cert is being put back at the bottom of the cert stack when
the undo processes.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=723360&aid=3013209&group_id=132173

Re: [Rails-devel] Rails 1.3 is now available.

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

On Mon, May 31, 2010 at 7:27 AM, brett lentz <bre...@gm...> wrote:
> I'm pleased to announce that Rails 1.3 is now available.
>
> This release adds an initial implementation of automated route and
> revenue calculation as well as bug fixes for 1830, 1856, 1889. Also in
> this release is revised documentation on how well-supported each game
> is.
>
> Download the new release at http://rails.sourceforge.net/
>
> ---Brett.
>

Apologies all around. An issue with my e-mail prevented me from
sending out a proper changelog with my announcement.

So, here is the changelog for 1.3:

* Tile and Token Laying
- Hexes which are eligible for tile and token lays are highlighted
- Only a game hint, not enforced.

* Revenue Calculation
- Maximum revenue for the owned trains is suggested
- Presetting for the revenue entry, has still to be confirmed or can be
adjusted
- Should incorporate all game specific rules, including bonus rules

* Map Correction
- Downgrade of tiles is now possible
- Only tile availability is checked, otherwise no restrictions are applied
- Tile lays that require the re-laying out of tokens are not possible

* General
- Prevent 'foreign' token being layed on reserved home token slots.
- Fixed bugs in OO-tile and token laying.
- Fixed occasional incorrect priority deal assignment after 1830-style auctions.
- Fixed disappearance of last (highest) train bought.
- Added option to fix tile orientation (used for 1835 Hamburg).

* 1830
- Fixed possibility of buying a Diesel at exchange price without an
exchange taking place.

* 1835
- Finished/Fixed Prussian formation
- Allow 100% share ownership and nationalization.
- Bugs in initial round player order (Clemens variant) and BY flotation.
- Added several variant options.

* 1856
- (also for 18EU) added (invisible) City object to Goderich/Hamburg tile to
facilitate revenue calculation.
- Fixed bug in effect of repeated 5% CGR share sales on share price.
- Fixed W&S token lay cost problem.

* 18EU
- Fixes for bankruptcy rules (not yet tested under all possible circumstances).

Re: [Rails-devel] [Rails-users] [Rails-announce] Rails 1.3 is now available.

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

To avoid some disappointment with this release I will give some more hints
what to expect.

There has been some bug-fixes which can cause some save files to be 
incompatible with the new release. Exchange of trains is one example.
If such an error occurs either stay with the previous release or start at that 
point and replay the missing moves.

Another thing to mention is that route and revenue calculation is disabled by 
default for save files from previous Rails version. This allows pbem users to 
update to that rails version for bug-fixes who do want to play with automatic 
game support turned on. For new games the default is to activate them, but 
each of them can be deactivated under the game options.

And to finish here is that Erik has improved 1835 that it is ready for serious 
testing, but please do not start long-running pbems yet ;-)

Stefan

On Monday 31 May 2010 16:45:46 Jeff Feuer wrote:
> I just loaded up an 1830 save file in which I ended the previous OR by
> exchanging a 4 train for a D.  When I make the move and save the file
> (using either Rails 1.2.2 or Rails 1.3), Rails 1.3 says it's an illegal
> move and rewinds the game back to the buy train step.  It's definitely
> legal, and Rails 1.3 lets me do it, but it won't let me load up a save
> containing the move.
>
> Jeff
>
> brett lentz wrote:
> > I'm pleased to announce that Rails 1.3 is now available.
> >
> > This release adds an initial implementation of automated route and
> > revenue calculation as well as bug fixes for 1830, 1856, 1889. Also in
> > this release is revised documentation on how well-supported each game
> > is.
> >
> > Download the new release at http://rails.sourceforge.net/
> >
> > ---Brett.
> >
> > -------------------------------------------------------------------------
> >-----
> >
> > _______________________________________________
> > Rails-announce mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-announce
>
> ---------------------------------------------------------------------------
>---
>
> _______________________________________________
> Rails-users mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-users

Re: [Rails-devel] [Rails-announce] Rails 1.3 is now available.

[Jeff F. <fe...@op...>]

I just loaded up an 1830 save file in which I ended the previous OR by 
exchanging a 4 train for a D.  When I make the move and save the file 
(using either Rails 1.2.2 or Rails 1.3), Rails 1.3 says it's an illegal 
move and rewinds the game back to the buy train step.  It's definitely 
legal, and Rails 1.3 lets me do it, but it won't let me load up a save 
containing the move.

Jeff

brett lentz wrote:
> I'm pleased to announce that Rails 1.3 is now available.
>
> This release adds an initial implementation of automated route and
> revenue calculation as well as bug fixes for 1830, 1856, 1889. Also in
> this release is revised documentation on how well-supported each game
> is.
>
> Download the new release at http://rails.sourceforge.net/
>
> ---Brett.
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Rails-announce mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-announce
>
>
>   

[Rails-devel] Rails 1.3 is now available.

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

I'm pleased to announce that Rails 1.3 is now available.

This release adds an initial implementation of automated route and
revenue calculation as well as bug fixes for 1830, 1856, 1889. Also in
this release is revised documentation on how well-supported each game
is.

Download the new release at http://rails.sourceforge.net/

---Brett.

[Rails-devel] GameOptions for revenue calculation, route awareness

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

Final additions:

* GameOptions for revenue calculation and route awareness are defined.

Either Deactivate or suggest/highlight is possible.
The setting is such that for new games the functions are active by default, 
for saved games the default is to keep them deactivated.

I have added the possibility to overwrite (some) GameOptions via the
-D{name of gameoption}={setting of gameoption} from the command line.
The change is only temporary and will not be saved.

This is only possible for those options that are evaluated via the method 
GameManager.getGameOption(). 
All others (especially those evaluated at the time of parsing the xml files) 
are not effected. This avoids most of the potential reload problems.

Minor fixes due to recent testing:
* 1835: Added upgrade possibility of Nuernberg/Furth preprinted tille

* 18EU: Restrict minors to yellow tile lay in phases 5+, as they are still 
open until the final minor conversion round.

Stefan

[Rails-devel] MapCorrections

[Stefan F. (web.de) <ste...@we...>]

In preparation of the upcoming release I tried to improve the MapCorrection 
functionalities. In the end I mainly restrict the possible applications, 
especially downgrades to tiles that would increase the number of stations
are prevented. I was close to a possible relay of tokens, but there are too 
many tricky cases to consider. And the function should allow to solve 
potential problems, not cause new ones.

Restrictons enforced by the correction method:

1) The number of available tiles

2) A downgrade to the preprinted tile applies the original rotation 
automatically. 

3) Any up/downgrade that could cause a relay of token is prevented.

Not enforced are any connectivity rules, thus connectivity to existing track 
and not running into restricted hexes is not prevented.

The number of remaining tiles is now shown below the tile id in the upgrade 
panel display.

My last commit for the upcoming release is the game option that allows to 
activate route highlighting and revenue calculation (and will prevent any 
previously saved game from accessing those functions). This should be in 
sometime tomorrow.

Stefan

Re: [Rails-devel] 1835 phases

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

On Fri, May 28, 2010 at 2:57 PM, Erik Vos <eri...@xs...> wrote:

> In hindsight, that extra phase might as well have been called '3+' or '3½'
> (not sure if the ½ character would survive CVS; the 1889 ¥ didn't and had
> to
> be replaced).
>

As long as your encoding is set properly, it should.  However, you can just
use \uXXXX to identify the character you want and keep the source totally in
ASCII.

-- 
John A. Tamplin

Re: [Rails-devel] 1835 phases

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

You are right that I have deviated from the phase names in the rules.
The reason is, that I needed the extra '4+4' phase to trigger the related
Prussian formation step. There might have been other ways, but this was by
far the easiest way to achieve that.
In hindsight, that extra phase might as well have been called '3+' or '3½'
(not sure if the ½ character would survive CVS; the 1889 ¥ didn't and had to
be replaced).

Should the 1835 phases be renamed?

Erik.

-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Friday 28 May 2010 13:01
To: Development list for Rails: an 18xx game
Subject: [Rails-devel] 1835 phases

Erik,

The 1835 phases are named after the train that caused the phase
change, rather than in sequential order.  The rulebook I have for 1835
(admittedly a scanned English translation!) does name the phases in
order (game starts in phase 1, phase 2 happens on purchase of the
first 3).

Just thought I'd raise the point for discussion over which would be
preferred.  Personally, I much prefer naming the phase after the
train, however, there is an argument for supporting what the rulebook
says (as has been done for 1856).

Is the original rulebook different?

Phil

----------------------------------------------------------------------------
--

_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] 1835 phases

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

Erik,

The 1835 phases are named after the train that caused the phase
change, rather than in sequential order.  The rulebook I have for 1835
(admittedly a scanned English translation!) does name the phases in
order (game starts in phase 1, phase 2 happens on purchase of the
first 3).

Just thought I'd raise the point for discussion over which would be
preferred.  Personally, I much prefer naming the phase after the
train, however, there is an argument for supporting what the rulebook
says (as has been done for 1856).

Is the original rulebook different?

Phil

Re: [Rails-devel] Implementation details for revenue calculation

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

In  that respect: If I have figured it out correctly the default option in
the 
gamelist.xml defines the default for new games, the one in the specific 
game.xml sets the one for saved games. Correct? Thus there is no need for an

additional undefined setting, as I intended to add.

[EV] I had never intended such a difference, but you are probably correct.

Erik.

Re: [Rails-devel] Implementation details for revenue calculation

[Stefan F. (web.de) <ste...@we...>]

18AL named trains:

Erik:
I took your advice to add a game option: Choosing it the assignment of the 
name chits is done by the revenue calculator. In addition it deactivates the 
manual assignment. I have defined this as the default option.

In  that respect: If I have figured it out correctly the default option in the 
gamelist.xml defines the default for new games, the one in the specific 
game.xml sets the one for saved games. Correct? Thus there is no need for an 
additional undefined setting, as I intended to add.

Alex:
For 18AL this additional limitation is not active, as of the 4 locations 3 are 
red areas, thus one train could never apply for both chits.

In general the scoring of bonuses in cases where one train can only score a 
subset of a larger set and each bonus can only be scored by one train is a 
non trivial task and would require a enumeration.
 
At least I see no simply algorithm to assign the bonuses if a train could be 
eligible for several bonuses. Thus I chose to define a specific modifier for 
this simpler case here.

Stefan


On Wednesday 26 May 2010 02:28:24 alexti wrote:
> To my knowledge name chits are transferable at any time. Effectively they
> act as a location pair bonus available to one train only. The only extra
> limitation is that 2 name chits can not be assigned to the same train.
>
> On Tue, 25 May 2010 13:53:13 -0600, Stefan Frey <ste...@we...> wrote:
> > Another update to the update below:
> >
> > All remaining issues below are fixed now, namely the named trains
> > can be saved and are still assigned after (re-)loading.
> >
> > In hindsight I wonder now, if the naming of trains should not be part of
> > the
> > optimization process instead being done manually by the players.
> >
> > Having never played 18AL before, I assumed that the assignment is fixed
> > (at
> > least as long as the train does not rust).
> >
> > But from the rules (and the current implemenation) the owner can change
> > it
> > anytime. Theme aside in my eyes the named trains is a plain revenue bonus
> > (visit two vertices) which is available only for one train and
> > should/could
> > have been implemented accordingly.
> >
> > In my eyes this is similar to the Pullman car of 18EU, where the rules
> > state
> > that the owner chooses a station for doube counting, but in Rails the
> > Pullman
> > car takes part in the search for the optimal run.
> >
> > Opinions from more experienced 18AL players are welcome.
> >
> > Stefan
> >
> > On Friday 21 May 2010 18:18:49 Stefan Frey wrote:
> >> Again some more update:
> >>
> >> Full support for 18AL and 18EU is in, 1851 has only Birmingham missing.
> >> More details see below.
> >>
> >> As Brett and Erik keep quiet about their preference for a release soon,
> >> I
> >> kept adding functionality.
> >> Fortunately this proved to be very easy, as most elements are well
> >> prepared. I was especially surprised by the excellent support of named
> >> trains in 18AL, as  without revenue calculation it served no real
> >> purpose.
> >> Thus it is not surprising that there are still some minor hassles, which
> >> will be easy to iron out.
> >>
> >> Known open issues:
> >> -> Invisible Birmingham tile
> >> -> Named trains are not assigned after reload
> >> -> 4D in 18AL do not score double (they are not correctly initialized)
> >> -> Graph optimization after off-board area token is not correct
> >>
> >> Complete summary of revenue specifics:
> >>
> >> Independent tests of those is appreciated.
> >> Map Correction allows to create scenarios easily.
> >> Under NetworkInfo one can run any type of trains in any game, simply use
> >> standard train type names (like D, 4+4, 10, 5E, 4D).
> >>
> >> 1830:
> >> Multi-Hex off-board locations
> >>
> >> 1889:
> >> Diesel Revenue Bonus at off-board locations
> >>
> >> 1835:
> >> Berlin: No visit of multiple stations (yellow tile only)
> >> Hamburg: Elbe malus
> >> Plus Trains
> >>
> >> 18EU:
> >> Offboard-Bonus: Dependent on number of tokens visited
> >> Hamburg: Termination vs. Non-Termination
> >> Paris, Berlin, Vienna: No visit of multiple stations
> >> Pullman: Bonus for most valuable city
> >> Trains do not count Towns
> >>
> >> 18Kaas:
> >> Ruhr: Bonus for other stations/cities
> >>
> >> 1851
> >> Offboard-2-Offboard: 10 bonus for each stop
> >> Invisible Birmingham: still open
> >>
> >> 1856
> >> Bonus tokens
> >>
> >> 18AL
> >> Bonus tokens
> >> Named Trains
> >> Nashville, Mobile: Off-map destinations with token slot
> >> Trains do not count Towns
> >> 4D trains
> >>
> >> Conversion from Rails to Network attributes:
> >>
> >> - If a Rails hex has a value attribute, that value takes preference for
> >> all
> >> stations on that hex, thus the value attribute of the stations of the
> >> tile
> >> laid is irrelevant (no need for -1 or 0).
> >>
> >> - Run-Through ("Not a sink") rule listed by priority
> >> 1) Off-Map city: No one runs through (even with own token)
> >> 2) Slots=0: All run through
> >> 3) Nb Tokens = Slots: Only run through with own token
> >> 4) Nb Tokens < Slots: All run through
> >> In addition to rule 1: An own token in an off-map city allows to run
> >> from.
> >>
> >> - Location names to identify vertex sets:
> >> The location name is the combination of the city attribute of the hex
> >> and
> >> city tile. If any of them are undefined or equal to "", no location is
> >> defined. Exception are off-map cities, for which only the hex attribute
> >> is
> >> considered.
> >>
> >> Stefan
> >>
> >> ------------------------------------------------------------------------
> >>--- ---
> >>
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > -------------------------------------------------------------------------
> >-----
> >
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Implementation details for revenue calculation

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

Not being at all familiar with the boardgame version I'll be learning
as I go, so I'll test everything with the default settings in place
and we'll see what happens, I'll leave the more complex cases for a
second playthrough once I know what's going on :)

On 25 May 2010 19:02, Erik Vos <eri...@xs...> wrote:
> Yes, 1835 is definitely ready for some serious testing. There are a few
> known bugs; please check the game description text.
> The main problem is, that the game breaks if the Start Packet is not sold
> out AND the minors do run. That is why I recommend using the option "Minors
> don't run if BY has not floated".
>
> Erik.
>
> -----Original Message-----
> From: Phil Davies [mailto:de...@gm...]
> Sent: Tuesday 25 May 2010 09:03
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Implementation details for revenue calculation
>
> I'll probably be starting another game from source this week to test
> the impact on other games, is '35 at the stage where it would be
> worthwhile getting some testing feedback?  I was thinking of trying
> that out on my regulars.
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Implementation details for revenue calculation

[alexti <al...@sh...>]

To my knowledge name chits are transferable at any time. Effectively they  
act as a location pair bonus available to one train only. The only extra  
limitation is that 2 name chits can not be assigned to the same train.

On Tue, 25 May 2010 13:53:13 -0600, Stefan Frey <ste...@we...> wrote:

> Another update to the update below:
>
> All remaining issues below are fixed now, namely the named trains
> can be saved and are still assigned after (re-)loading.
>
> In hindsight I wonder now, if the naming of trains should not be part of  
> the
> optimization process instead being done manually by the players.
>
> Having never played 18AL before, I assumed that the assignment is fixed  
> (at
> least as long as the train does not rust).
>
> But from the rules (and the current implemenation) the owner can change  
> it
> anytime. Theme aside in my eyes the named trains is a plain revenue bonus
> (visit two vertices) which is available only for one train and  
> should/could
> have been implemented accordingly.
>
> In my eyes this is similar to the Pullman car of 18EU, where the rules  
> state
> that the owner chooses a station for doube counting, but in Rails the  
> Pullman
> car takes part in the search for the optimal run.
>
> Opinions from more experienced 18AL players are welcome.
>
> Stefan
>
>
> On Friday 21 May 2010 18:18:49 Stefan Frey wrote:
>> Again some more update:
>>
>> Full support for 18AL and 18EU is in, 1851 has only Birmingham missing.
>> More details see below.
>>
>> As Brett and Erik keep quiet about their preference for a release soon,  
>> I
>> kept adding functionality.
>> Fortunately this proved to be very easy, as most elements are well
>> prepared. I was especially surprised by the excellent support of named
>> trains in 18AL, as  without revenue calculation it served no real  
>> purpose.
>> Thus it is not surprising that there are still some minor hassles, which
>> will be easy to iron out.
>>
>> Known open issues:
>> -> Invisible Birmingham tile
>> -> Named trains are not assigned after reload
>> -> 4D in 18AL do not score double (they are not correctly initialized)
>> -> Graph optimization after off-board area token is not correct
>>
>> Complete summary of revenue specifics:
>>
>> Independent tests of those is appreciated.
>> Map Correction allows to create scenarios easily.
>> Under NetworkInfo one can run any type of trains in any game, simply use
>> standard train type names (like D, 4+4, 10, 5E, 4D).
>>
>> 1830:
>> Multi-Hex off-board locations
>>
>> 1889:
>> Diesel Revenue Bonus at off-board locations
>>
>> 1835:
>> Berlin: No visit of multiple stations (yellow tile only)
>> Hamburg: Elbe malus
>> Plus Trains
>>
>> 18EU:
>> Offboard-Bonus: Dependent on number of tokens visited
>> Hamburg: Termination vs. Non-Termination
>> Paris, Berlin, Vienna: No visit of multiple stations
>> Pullman: Bonus for most valuable city
>> Trains do not count Towns
>>
>> 18Kaas:
>> Ruhr: Bonus for other stations/cities
>>
>> 1851
>> Offboard-2-Offboard: 10 bonus for each stop
>> Invisible Birmingham: still open
>>
>> 1856
>> Bonus tokens
>>
>> 18AL
>> Bonus tokens
>> Named Trains
>> Nashville, Mobile: Off-map destinations with token slot
>> Trains do not count Towns
>> 4D trains
>>
>> Conversion from Rails to Network attributes:
>>
>> - If a Rails hex has a value attribute, that value takes preference for  
>> all
>> stations on that hex, thus the value attribute of the stations of the  
>> tile
>> laid is irrelevant (no need for -1 or 0).
>>
>> - Run-Through ("Not a sink") rule listed by priority
>> 1) Off-Map city: No one runs through (even with own token)
>> 2) Slots=0: All run through
>> 3) Nb Tokens = Slots: Only run through with own token
>> 4) Nb Tokens < Slots: All run through
>> In addition to rule 1: An own token in an off-map city allows to run  
>> from.
>>
>> - Location names to identify vertex sets:
>> The location name is the combination of the city attribute of the hex  
>> and
>> city tile. If any of them are undefined or equal to "", no location is
>> defined. Exception are off-map cities, for which only the hex attribute  
>> is
>> considered.
>>
>> Stefan
>>
>> ---------------------------------------------------------------------------
>> ---
>>
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [Rails-devel] Implementation details for revenue calculation

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

The 18AL rules (Mark Derrick version) say: "These tokens can be switched
between trains at any time during the operating railroad's turn of
operations". 

Automatic optimization of this placement seems a reasonable extension to me.
Perhaps a game option?

Erik.

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Tuesday 25 May 2010 21:53
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Implementation details for revenue calculation

Another update to the update below:

All remaining issues below are fixed now, namely the named trains
can be saved and are still assigned after (re-)loading.

In hindsight I wonder now, if the naming of trains should not be part of the

optimization process instead being done manually by the players.

Having never played 18AL before, I assumed that the assignment is fixed (at 
least as long as the train does not rust).

But from the rules (and the current implemenation) the owner can change it 
anytime. Theme aside in my eyes the named trains is a plain revenue bonus 
(visit two vertices) which is available only for one train and should/could 
have been implemented accordingly. 

In my eyes this is similar to the Pullman car of 18EU, where the rules state

that the owner chooses a station for doube counting, but in Rails the
Pullman 
car takes part in the search for the optimal run.

Opinions from more experienced 18AL players are welcome.

Stefan


On Friday 21 May 2010 18:18:49 Stefan Frey wrote:
> Again some more update:
>
> Full support for 18AL and 18EU is in, 1851 has only Birmingham missing.
> More details see below.
>
> As Brett and Erik keep quiet about their preference for a release soon, I
> kept adding functionality.
> Fortunately this proved to be very easy, as most elements are well
> prepared. I was especially surprised by the excellent support of named
> trains in 18AL, as  without revenue calculation it served no real purpose.
> Thus it is not surprising that there are still some minor hassles, which
> will be easy to iron out.
>
> Known open issues:
> -> Invisible Birmingham tile
> -> Named trains are not assigned after reload
> -> 4D in 18AL do not score double (they are not correctly initialized)
> -> Graph optimization after off-board area token is not correct
>
> Complete summary of revenue specifics:
>
> Independent tests of those is appreciated.
> Map Correction allows to create scenarios easily.
> Under NetworkInfo one can run any type of trains in any game, simply use
> standard train type names (like D, 4+4, 10, 5E, 4D).
>
> 1830:
> Multi-Hex off-board locations
>
> 1889:
> Diesel Revenue Bonus at off-board locations
>
> 1835:
> Berlin: No visit of multiple stations (yellow tile only)
> Hamburg: Elbe malus
> Plus Trains
>
> 18EU:
> Offboard-Bonus: Dependent on number of tokens visited
> Hamburg: Termination vs. Non-Termination
> Paris, Berlin, Vienna: No visit of multiple stations
> Pullman: Bonus for most valuable city
> Trains do not count Towns
>
> 18Kaas:
> Ruhr: Bonus for other stations/cities
>
> 1851
> Offboard-2-Offboard: 10 bonus for each stop
> Invisible Birmingham: still open
>
> 1856
> Bonus tokens
>
> 18AL
> Bonus tokens
> Named Trains
> Nashville, Mobile: Off-map destinations with token slot
> Trains do not count Towns
> 4D trains
>
> Conversion from Rails to Network attributes:
>
> - If a Rails hex has a value attribute, that value takes preference for
all
> stations on that hex, thus the value attribute of the stations of the tile
> laid is irrelevant (no need for -1 or 0).
>
> - Run-Through ("Not a sink") rule listed by priority
> 1) Off-Map city: No one runs through (even with own token)
> 2) Slots=0: All run through
> 3) Nb Tokens = Slots: Only run through with own token
> 4) Nb Tokens < Slots: All run through
> In addition to rule 1: An own token in an off-map city allows to run from.
>
> - Location names to identify vertex sets:
> The location name is the combination of the city attribute of the hex and
> city tile. If any of them are undefined or equal to "", no location is
> defined. Exception are off-map cities, for which only the hex attribute is
> considered.
>
> Stefan
>
>
---------------------------------------------------------------------------
>---
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel



----------------------------------------------------------------------------
--

_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Implementation details for revenue calculation

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

Another update to the update below:

All remaining issues below are fixed now, namely the named trains
can be saved and are still assigned after (re-)loading.

In hindsight I wonder now, if the naming of trains should not be part of the 
optimization process instead being done manually by the players.

Having never played 18AL before, I assumed that the assignment is fixed (at 
least as long as the train does not rust).

But from the rules (and the current implemenation) the owner can change it 
anytime. Theme aside in my eyes the named trains is a plain revenue bonus 
(visit two vertices) which is available only for one train and should/could 
have been implemented accordingly. 

In my eyes this is similar to the Pullman car of 18EU, where the rules state 
that the owner chooses a station for doube counting, but in Rails the Pullman 
car takes part in the search for the optimal run.

Opinions from more experienced 18AL players are welcome.

Stefan


On Friday 21 May 2010 18:18:49 Stefan Frey wrote:
> Again some more update:
>
> Full support for 18AL and 18EU is in, 1851 has only Birmingham missing.
> More details see below.
>
> As Brett and Erik keep quiet about their preference for a release soon, I
> kept adding functionality.
> Fortunately this proved to be very easy, as most elements are well
> prepared. I was especially surprised by the excellent support of named
> trains in 18AL, as  without revenue calculation it served no real purpose.
> Thus it is not surprising that there are still some minor hassles, which
> will be easy to iron out.
>
> Known open issues:
> -> Invisible Birmingham tile
> -> Named trains are not assigned after reload
> -> 4D in 18AL do not score double (they are not correctly initialized)
> -> Graph optimization after off-board area token is not correct
>
> Complete summary of revenue specifics:
>
> Independent tests of those is appreciated.
> Map Correction allows to create scenarios easily.
> Under NetworkInfo one can run any type of trains in any game, simply use
> standard train type names (like D, 4+4, 10, 5E, 4D).
>
> 1830:
> Multi-Hex off-board locations
>
> 1889:
> Diesel Revenue Bonus at off-board locations
>
> 1835:
> Berlin: No visit of multiple stations (yellow tile only)
> Hamburg: Elbe malus
> Plus Trains
>
> 18EU:
> Offboard-Bonus: Dependent on number of tokens visited
> Hamburg: Termination vs. Non-Termination
> Paris, Berlin, Vienna: No visit of multiple stations
> Pullman: Bonus for most valuable city
> Trains do not count Towns
>
> 18Kaas:
> Ruhr: Bonus for other stations/cities
>
> 1851
> Offboard-2-Offboard: 10 bonus for each stop
> Invisible Birmingham: still open
>
> 1856
> Bonus tokens
>
> 18AL
> Bonus tokens
> Named Trains
> Nashville, Mobile: Off-map destinations with token slot
> Trains do not count Towns
> 4D trains
>
> Conversion from Rails to Network attributes:
>
> - If a Rails hex has a value attribute, that value takes preference for all
> stations on that hex, thus the value attribute of the stations of the tile
> laid is irrelevant (no need for -1 or 0).
>
> - Run-Through ("Not a sink") rule listed by priority
> 1) Off-Map city: No one runs through (even with own token)
> 2) Slots=0: All run through
> 3) Nb Tokens = Slots: Only run through with own token
> 4) Nb Tokens < Slots: All run through
> In addition to rule 1: An own token in an off-map city allows to run from.
>
> - Location names to identify vertex sets:
> The location name is the combination of the city attribute of the hex and
> city tile. If any of them are undefined or equal to "", no location is
> defined. Exception are off-map cities, for which only the hex attribute is
> considered.
>
> Stefan
>
> ---------------------------------------------------------------------------
>---
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Implementation details for revenue calculation

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

Yes, 1835 is definitely ready for some serious testing. There are a few
known bugs; please check the game description text.
The main problem is, that the game breaks if the Start Packet is not sold
out AND the minors do run. That is why I recommend using the option "Minors
don't run if BY has not floated".

Erik.

-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Tuesday 25 May 2010 09:03
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Implementation details for revenue calculation

I'll probably be starting another game from source this week to test
the impact on other games, is '35 at the stage where it would be
worthwhile getting some testing feedback?  I was thinking of trying
that out on my regulars.

Re: [Rails-devel] Implementation details for revenue calculation

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

Stefan,

I've managed to run an 1856 game through with revenue calc once  
already with very little problems, though this was before you added  
token support.

It was certainly able to handle some 1200+ revenue Diesel runs with  
minimal impact on processing speed and I am certainly glad I didn't  
have to count those manually.

Phil

On 25 May 2010, at 08:59, Stefan Frey <ste...@we...> wrote:

> Phil:
> in my area (routing and revenue calculation) 1856 is the game I  
> hardly tested.
> If I am not wrong, it has no unique features, thus everything should  
> work
> fine, but that is a "should", thus tests would be very welcome there.
> 1835 should work ok in that respect.
> Stefan
>
>
> On Tuesday 25 May 2010 09:02:30 Phil Davies wrote:
>> I'll probably be starting another game from source this week to test
>> the impact on other games, is '35 at the stage where it would be
>> worthwhile getting some testing feedback?  I was thinking of trying
>> that out on my regulars.
>>
>> On 24 May 2010 12:48, Erik Vos <eri...@xs...> wrote:
>>> 18EU Bankruptcy now seems to work correctly, and is open for  
>>> testing for
>>> whoever is interested in this feature and can compile from the  
>>> sources.
>>> In particular, more testing is needed for side effects on other  
>>> games, as
>>> the processes of starting and closing companies has changed  
>>> somewhat. The
>>> visibility of companies in GameStatus and ORPanel was the last main
>>> issue.
>>>
>>> Undo is getting better, but doesn't yet seem work completely.
>>>
>>> More later this week.
>>>
>>> Erik.
>>>
>>> -----Original Message-----
>>> From: Stefan Frey [mailto:ste...@we...]
>>> Sent: Monday 24 May 2010 10:00
>>> To: Development list for Rails: an 18xx game
>>> Subject: Re: [Rails-devel] Implementation details for revenue  
>>> calculation
>>>
>>> Erik & Brett,
>>> currently quite occupied with other tasks I am only adding small  
>>> bits in
>>> an incremental way. I think 1.3.0 is appropriate with a new game
>>> supported and the first step to revenue and route support.
>>>
>>> I have added the support (or better removal) of the Birmingham tile
>>> before phase 4 by defining an according NetworkGraphModifier  
>>> interface,
>>> which allows
>>> to adjust the network graph immediately after creation. Changes  
>>> defined
>>> by this interface also effect the highlighting for tile and token  
>>> lays.
>>>
>>> This implies that all titles should be supported, but I am sure  
>>> there is
>>> still
>>> something is missing, especially for those games which I only know  
>>> from
>>> the rulebook.
>>>
>>> The fix of the 18EU bankruptcy should allow to close the bug  
>>> 2954661.
>>> Game End undos are already possible (I fixed that in 1.2).
>>> Do you think it will be possible to provide an undo possibility  
>>> for the
>>> bankruptcy in 18EU as well?
>>>
>>> Stefan
>>>
>>> On Friday 21 May 2010 22:10:41 Erik Vos wrote:
>>>> Next weekend sounds good. In view of all the great stuff added by
>>>> Stefan,
>>>
>>> a
>>>
>>>> minor release (1.3.0) might be appropriate?
>>>>
>>>> By now the bugs list is pretty empty; in the past few weeks I  
>>>> have fixed
>>>> quite a lot.
>>>>
>>>> I'm working on the 18EU bankruptcy rules, which were missing. I  
>>>> hope to
>>>
>>> get
>>>
>>>> that done this weekend, but I'm currently much distracted by other
>>>> activities, so progress is slow. Right now, 18EU hangs in case of a
>>>> bankruptcy, but I would't consider that a show-stopper; to my  
>>>> knowledge
>>>> bankruptcies are rare in 18EU.
>>>>
>>>> I have added comments to the 1835 description on a few remaining  
>>>> issues,
>>>> with workarounds, but otherwise I think it's about done. I have  
>>>> marked
>>>
>>> 1835
>>>
>>>> "almost playable".
>>>>
>>>> Erik.
>>>>
>>>> -----Original Message-----
>>>> From: brett lentz [mailto:bre...@gm...]
>>>> Sent: Friday 21 May 2010 18:55
>>>> To: Development list for Rails: an 18xx game
>>>> Subject: Re: [Rails-devel] Implementation details for revenue
>>>> calculation
>>>>
>>>> On Fri, May 21, 2010 at 9:18 AM, Stefan Frey <ste...@we...>  
>>>> wrote:
>>>>> Again some more update:
>>>>>
>>>>> Full support for 18AL and 18EU is in, 1851 has only Birmingham
>>>>> missing. More details see below.
>>>>>
>>>>> As Brett and Erik keep quiet about their preference for a release
>>>>> soon,
>>>
>>> I
>>>
>>>> kept
>>>>
>>>>> adding functionality.
>>>>
>>>> Excellent work.
>>>>
>>>> As for when to do a new release, a lot of it is down to how stable
>>>> your changes are.  It sounds like we may be nearing a point where  
>>>> we
>>>> are ready for a new release.
>>>>
>>>> How does next weekend sound?
>>>>
>>>> ---Brett.
>>>
>>> --- 
>>> --- 
>>> -------------------------------------------------------------------
>>> --
>>>
>>>> - --
>>>>
>>>> _______________________________________________
>>>> Rails-devel mailing list
>>>> Rai...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>
>>> --- 
>>> --- 
>>> -------------------------------------------------------------------
>>> --
>>>
>>>> ---
>>>>
>>>> _______________________________________________
>>>> Rails-devel mailing list
>>>> Rai...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>
>>> --- 
>>> --- 
>>> -------------------------------------------------------------------
>>> --- --
>>>
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>
>>>
>>> --- 
>>> --- 
>>> -------------------------------------------------------------------
>>> -----
>>>
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>> --- 
>> --- 
>> ---------------------------------------------------------------------
>> ---
>>
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
> --- 
> --- 
> --- 
> ---------------------------------------------------------------------
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel