rails-devel — List for discussion of Rails development

Re: [Rails-devel] Automatic route calculation

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

You are right: as I draw my (mental) picture I implicitly added the 
restriction that after a move in the inner circle you have to move out. 
Somehow similar to the inner circle in Titan ;-) 
Then again you have an additional restriction to maintain.

But I am simply guessing here and if his algorithm is working, Alex will have 
a solution, which he is the best to explain.

STefan
>
> [EV] How do you prevent backtracking in this case? Going 2-8-10-12-6?
>
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> - I prefer your definition of the graph to the one in tiles.xml (inherited
> from the tiledesigner) as you only have to count edges and you do not have
> to
> consider that you are not allowed to visit the same side (a node/vertex in
> Rails) twice. Rails defines tile 25 (the green Y) with two edges that both
> start from the same side  (see tiles.xml), but only one of each edge can be
> used per revenue turn.
>
> [EV] I would rather think that the current Rails Tile definition would be
> easier to use, as the only two requirements to make it work are:
> - each edge (and station) may be visited only once,
> - return from an edge is never allowed.
> See my question above: it seems harder to do with the extra vertexes, as it
> doen't seem to be clear what would prevent going 8-12-10. Or is that
> somehow built into the vertex #7-12 properties?
>
> Erik.
>
>
> ---------------------------------------------------------------------------
>--- Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Automatic route calculation

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

Hi Erik,

I've meant (2), but (1) is also included. And I agree that (1) is much  
simpler.

Alex.

On Sun, 21 Mar 2010 08:48:58 -0600, Erik Vos <eri...@xs...> wrote:

> Hi Alex,
>
> Of course there is much interest in handling routes.
>
> To me, "route calculation" sounds ambiguous, as it could mean two  
> different
> things:
> 1. Route determination, for the purpose of selecting valid tile and token
> lays.
> 2. Revenue calculation.
> I suppose you refer to the latter. Rails has neither yet.
>
> If I would ever have the time and guts to turn my developments efforts to
> the subject of routes, I would start with the former, which I guess is
> easiest to start with, and also much needed.
>
> In any case, Rails does not yet maintain a connection grid, but the bits  
> and
> pieces (tracks and stations) do exist as attributes of the Tile class.  
> From
> there it shouldn't be too difficult to compose a complete connection  
> grid.
>
> Feel free to download the source code and try sorting out where and how  
> your
> code might fit in.
>
> Erik.
>
> -----Original Message-----
> From: Alex Tikhonov [mailto:al...@sh...]
> Sent: Sunday 21 March 2010 01:10
> To: rai...@li...
> Subject: [Rails-devel] Automatic route calculation
>
> Hi all,
>
> Per Brett Lentz suggestion I am moving this discussion here and reporting
> my message from 18x yahoo group.
>
> This is my first post here, but I have been lurking for a while. I wonder
> if there is an interest in adding automatic route calculation to Rails. I
> am trying to create AI for some of the games (and no, it's not going
> well), but as a side effect I have code that computes the routes. It
> supports some of more widely used rules (various town treatment, city and
> route bonuses, multipliers etc). It runs on an abstract connectivity
> graph, so it should not be too hard to integrate.
>
> Alex.
>
> ----------------------------------------------------------------------------
> --
> 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


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

Re: [Rails-devel] Automatic route calculation

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

> [EV] How do you prevent backtracking in this case? Going 2-8-10-12-6?
Sorry, I have not explained it correctly. I have this algorithm nearly  
independent from the game data and the connectivity graph used in the  
route search is different from the tile description itself (and while  
explaining it I've mixed them together). The "outer" vertices (#1-#6) are  
 from the tile definition and don't appear in the connectivity graph at  
all. So when Y tile connectivity is converted into the abstract graph for  
route calculation, there will be 5 edges: (2'-8,8-10,10-4',6'-12,12-10).
2', 4' and 6' are vertices that are in the adjacent hexes (such that for  
example, 4' is the same vertex as vertex 7 of the hex just below this  
one). Backtracking is prevented by allowing only one edge from any  
particular tile to be used consequently unless it starts or ends in the  
center.

I also should notice that all these vertices are purely abstract, there is  
no data corresponding to them in the program. Only particular vertices  
(such as with city or town) get their own data (I call them nodes).


On Sun, 21 Mar 2010 09:05:28 -0600, Erik Vos <eri...@xs...> wrote:

> OK, I see you have already though about route determination.
>
> -----Original Message-----
> From: alexti [mailto:al...@sh...]
> Let's say we have a hex
> oriented so that one side is facing north, another south and the other 4
> NW, SW, NE and SE. For each hex there will be 13 vertices. One in the
> center (#0), 6 vertices each in the middle of the hex edge (#1-#6, #1 is
> North, counting clockwise) and 6 more in the middle of the line  
> connecting
> each of vertices #1-#6 to the center. Vertices #1-#6 will be shared with
> other adjacent hexes. Let's say we have green Y tile (two gently curving
> tracks from S to NW and from S to NE). Connectivity graph for such tile
> will be (2-8,8-10,10-4,6-12,12-10). 10-4 edge represents the bottom of  
> "Y"
> and this ensures that only one of the track segments on this tile can be
> used.
>
> [EV] How do you prevent backtracking in this case? Going 2-8-10-12-6?
>
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> - I prefer your definition of the graph to the one in tiles.xml  
> (inherited
> from the tiledesigner) as you only have to count edges and you do not  
> have
> to
> consider that you are not allowed to visit the same side (a node/vertex  
> in
> Rails) twice. Rails defines tile 25 (the green Y) with two edges that  
> both
> start from the same side  (see tiles.xml), but only one of each edge can  
> be
> used per revenue turn.
>
> [EV] I would rather think that the current Rails Tile definition would be
> easier to use, as the only two requirements to make it work are:
> - each edge (and station) may be visited only once,
> - return from an edge is never allowed.
> See my question above: it seems harder to do with the extra vertexes, as  
> it
> doen't seem to be clear what would prevent going 8-12-10. Or is that  
> somehow
> built into the vertex #7-12 properties?
>
> 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


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

Re: [Rails-devel] Automatic route calculation

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

On Sun, Mar 21, 2010 at 11:05 AM, Erik Vos <eri...@xs...> wrote:

> [EV] I would rather think that the current Rails Tile definition would be
> easier to use, as the only two requirements to make it work are:
> - each edge (and station) may be visited only once,
>

Note that when you are counting multiple trains, you can visit the same
station more than once, but you still can't visit the same hex-edge more
than once (and some games have additional restrictions that one train may
not visit multiple stations on the same hex).

-- 
John A. Tamplin

Re: [Rails-devel] Automatic route calculation

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

On Sun, Mar 21, 2010 at 1:43 AM, alexti <al...@sh...> wrote:

> I am not completely sure if you were referring to the difficulties of the
> algorithm or the difficulties of the integration, but I assume it's former.
>

Yes, I am talking about the actual algorithm.  Please see the archives for
several long discussions on the idea, but I will bring up a few specific
points here.


> Perhaps I should explain how the algorithm works to make things more
> clear. There are two parts to the algorithm - route selection and route
> evaluation. Route selection is performed on the abstract connectivity
> graph (which is a vector of edges and a associative map of vertices). Each
> edge is a pair of vertex coordinates on 2-D grid (I use specific encoding
> that allows to go between these vertices and hexes (or tiles) and back by
> simple arithmetics). Vertex information contains some basic data, such as
> whether there is a town at this vertex, if it's blocked [by station
> markers of other companies], current town/city value etc... The way this
> connectivity graph is defined takes care of handling use of track segments
> and visiting same cities. It would be easier to show he method on the
> picture, but I will try to describe it here. Let's say we have a hex
> oriented so that one side is facing north, another south and the other 4
> NW, SW, NE and SE. For each hex there will be 13 vertices. One in the
> center (#0), 6 vertices each in the middle of the hex edge (#1-#6, #1 is
> North, counting clockwise) and 6 more in the middle of the line connecting
> each of vertices #1-#6 to the center. Vertices #1-#6 will be shared with
> other adjacent hexes. Let's say we have green Y tile (two gently curving
> tracks from S to NW and from S to NE). Connectivity graph for such tile
> will be (2-8,8-10,10-4,6-12,12-10). 10-4 edge represents the bottom of "Y"
> and this ensures that only one of the track segments on this tile can be
> used. This definition method also takes care of defining tiles such as
> yellow and green Toronto from 1856 or Moscow from 1861.
>

I'm not sure I get the value of having a fixed set of vertices inside the
tile -- why not just have them where they are needed?  A #57 tile for
example, has only one interior vertex, and a #8 tile has none.  It seems
like what you want to do is just maintain a connectivity graph of hex edges
and scoring points (actually, you will probably want several connectivity
graphs for different train types, like one ignoring dots for trains that
ignore them).

In general the search for optimal routes work by selecting a route,
> evaluating its value, removing the used edges from the graph and running
> the search again on the remaining graph (with remaining trains). Then
> choosing the "next" route and repeating the process, until the set of
> routes with the highest total value is found. In the route selection
> process there are 3 direction of iteration: "head", "tail" and "branch".
> "Head" and "tail" is extending (by one edge) from the head or from the
> tail (each route starts from the station) and "branch" is replacing last
> added edge with the possible alternative. This guarantees to iterate over
> every possible route (here by route I mean route in graph terms, it's not
> necessarily a valid route in 18xx terms). In practice, I'm using few
> optimizations to eliminate complete scan, but that's probably unimportant
> for non-AI use.
>

A brute-force search of all possible routes is O(n!), and is really only
feasible (even on modern machines) for 1830-like games.  Games like 18US
that have simplified plain track tend to have a couple orders of magnitude
more possible routes.

If you try to take into account the train types to avoid evaluating all
possible routes, then you run into the following problems:

   - trains that can skip stops, like 1846's n/m trains and 1844's 8E trains
   - trains that can substitute types of stops (like n+m trains)
   - bonuses given when particular sets of stops are included on the route
   - games that allow a train to run through one fully blocked city, like
   1860
   - games that have choices about stops that give money to the company
   instead of the dividend, like halts in 1860

The route evaluation part needs to be aware of the rules of the specific
> games. Route evaluation logic gets a proposed route as a vector of
> vertices it visits. As a result it gives a value and the vector of
> vertices it has used (this is used for optimization by skipping the routes
> that just an extension from the unused side). In a simple case evaluation
> would be simple - just total values of the best subset of cities and
> towns, but various bonuses make things more complicated. I'm using a bonus
> table containing various bonuses and their requirements. Bonuses can be:
> add extra value to the vertex, multiply value of the vertex, add value to
> the route (for example if 2 specific locations are visited) etc... Bonuses
> can be defined as sets if it's necessary to allow only one bonus from the
> set to be applied. Because of that, the route evaluation algorithm has to
> return updated "bonus usage context". There may be a need to iterate over
> bonus choices (such as not apply some bonus when possible), but I am not
> sure what game has such set of possible bonuses to require it. I haven't
> done such iteration because it would be bad for AI case (because of
> performance), for non-AI case, it's probably not a big issue.
>

Maybe I am missing it, but I don't see where you are covering running
multiple trains where they can't reuse the same track.  You can't simply
choose the optimal run for trains individually, you have to choose them all
together which adds another factor to brute-force search.


> Some parts of the route evaluation code might need to be updated for
> specific games, but such updates should not affect the logic for anything
> else. Two types of trains I am aware of that might require more thought
> are hex trains and "N out of M" trains. Essentially, my current assumption
> is that for any route candidate the optimal route use (meaning use of
> trains and bonuses) can always be determined if both head and tail
> vertices are used.
>

I really think that a pure brute-force algorithm is not going to be suitable
for many of the games out there.  Many years ago, when desktops were about
as powerful as my phone is now, I wrote a route calculation algorithm for
1830-style games that transformed the problem into a flow graph problem and
used max-flow/min-cut to compute the best route for a set of trains.
 Unfortunately, I have lost that code and it was also not extensible for
many of the other train types that have been added in new designs.

Maybe we can start with a brute-force algorithm with a user-settable timeout
where it aborts processing if it is just going to take too long, so that
games that can make use of it can benefit from it and then in the endgame of
the more complicated games users will have to go back to counting manually.

My personal belief is that for basic route calculation after the player has
completed their move we should shoot for 5 seconds on a 5-year-old laptop.
 Note that this doesn't help while placing track, such as running various
what-if scenarios to help the player would require the algorithm be an order
of magnitude faster.  Likewise, an AI player would need to evaluate routes
in many possible positions for lookahead and evaluating opponents' likely
moves, so it would need route calculation to be another order of magnitude
faster than that.

The first and second scenarios are probably doable today with a brute force
algorithm for 1830-like games, and probably not doable at all for endgames
of more complicated games.

-- 
John A. Tamplin

Re: [Rails-devel] Automatic route calculation

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

OK, I see you have already though about route determination. 

-----Original Message-----
From: alexti [mailto:al...@sh...] 
Let's say we have a hex  
oriented so that one side is facing north, another south and the other 4  
NW, SW, NE and SE. For each hex there will be 13 vertices. One in the  
center (#0), 6 vertices each in the middle of the hex edge (#1-#6, #1 is  
North, counting clockwise) and 6 more in the middle of the line connecting  
each of vertices #1-#6 to the center. Vertices #1-#6 will be shared with  
other adjacent hexes. Let's say we have green Y tile (two gently curving  
tracks from S to NW and from S to NE). Connectivity graph for such tile  
will be (2-8,8-10,10-4,6-12,12-10). 10-4 edge represents the bottom of "Y"  
and this ensures that only one of the track segments on this tile can be  
used. 

[EV] How do you prevent backtracking in this case? Going 2-8-10-12-6?

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
- I prefer your definition of the graph to the one in tiles.xml (inherited 
from the tiledesigner) as you only have to count edges and you do not have
to 
consider that you are not allowed to visit the same side (a node/vertex in 
Rails) twice. Rails defines tile 25 (the green Y) with two edges that both 
start from the same side  (see tiles.xml), but only one of each edge can be 
used per revenue turn.

[EV] I would rather think that the current Rails Tile definition would be
easier to use, as the only two requirements to make it work are:
- each edge (and station) may be visited only once,
- return from an edge is never allowed.
See my question above: it seems harder to do with the extra vertexes, as it
doen't seem to be clear what would prevent going 8-12-10. Or is that somehow
built into the vertex #7-12 properties?

Erik.

Re: [Rails-devel] Automatic route calculation

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

Hi Alex,

Of course there is much interest in handling routes.

To me, "route calculation" sounds ambiguous, as it could mean two different
things:
1. Route determination, for the purpose of selecting valid tile and token
lays. 
2. Revenue calculation.
I suppose you refer to the latter. Rails has neither yet.

If I would ever have the time and guts to turn my developments efforts to
the subject of routes, I would start with the former, which I guess is
easiest to start with, and also much needed.

In any case, Rails does not yet maintain a connection grid, but the bits and
pieces (tracks and stations) do exist as attributes of the Tile class. From
there it shouldn't be too difficult to compose a complete connection grid.

Feel free to download the source code and try sorting out where and how your
code might fit in.

Erik.

-----Original Message-----
From: Alex Tikhonov [mailto:al...@sh...] 
Sent: Sunday 21 March 2010 01:10
To: rai...@li...
Subject: [Rails-devel] Automatic route calculation

Hi all,

Per Brett Lentz suggestion I am moving this discussion here and reporting  
my message from 18x yahoo group.

This is my first post here, but I have been lurking for a while. I wonder
if there is an interest in adding automatic route calculation to Rails. I
am trying to create AI for some of the games (and no, it's not going
well), but as a side effect I have code that computes the routes. It
supports some of more widely used rules (various town treatment, city and
route bonuses, multipliers etc). It runs on an abstract connectivity
graph, so it should not be too hard to integrate.

Alex.

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

Re: [Rails-devel] Automatic route calculation

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

Hi Alex,
on a first glance it makes a lot of sense and I would definitely like to see 
some route calculation support for example in 1870 or 1835 with Preussen.

And from your description you have already included a lot of additional game 
options. I am very curious about your solution for this important feature and
I assume this is true for anyone involved with the project.

Some quick questions and comments:

- I prefer your definition of the graph to the one in tiles.xml (inherited 
from the tiledesigner) as you only have to count edges and you do not have to 
consider that you are not allowed to visit the same side (a node/vertex in 
Rails) twice. Rails defines tile 25 (the green Y) with two edges that both 
start from the same side  (see tiles.xml), but only one of each edge can be 
used per revenue turn.

- Is your algorithm implemented in Java and what is the calculation time for 
standard hardware and a reasonable difficult setting? (Your text below seems 
to imply close to zero, if you can use it for AI).

- From your description I conjecture that  you already maintain a dictionary 
that maps tile ids to your vertix/edge defintions. In that case that would 
easy to add, if the data format is used can be converted to xml. Rails 
maintains a similar definition file in tiles/tiles.xml. 

Stefan


On Sunday 21 March 2010 06:43:31 alexti wrote:
> I am not completely sure if you were referring to the difficulties of the
> algorithm or the difficulties of the integration, but I assume it's former.
>
> Perhaps I should explain how the algorithm works to make things more
> clear. There are two parts to the algorithm - route selection and route
> evaluation. Route selection is performed on the abstract connectivity
> graph (which is a vector of edges and a associative map of vertices). Each
> edge is a pair of vertex coordinates on 2-D grid (I use specific encoding
> that allows to go between these vertices and hexes (or tiles) and back by
> simple arithmetics). Vertex information contains some basic data, such as
> whether there is a town at this vertex, if it's blocked [by station
> markers of other companies], current town/city value etc... The way this
> connectivity graph is defined takes care of handling use of track segments
> and visiting same cities. It would be easier to show he method on the
> picture, but I will try to describe it here. Let's say we have a hex
> oriented so that one side is facing north, another south and the other 4
> NW, SW, NE and SE. For each hex there will be 13 vertices. One in the
> center (#0), 6 vertices each in the middle of the hex edge (#1-#6, #1 is
> North, counting clockwise) and 6 more in the middle of the line connecting
> each of vertices #1-#6 to the center. Vertices #1-#6 will be shared with
> other adjacent hexes. Let's say we have green Y tile (two gently curving
> tracks from S to NW and from S to NE). Connectivity graph for such tile
> will be (2-8,8-10,10-4,6-12,12-10). 10-4 edge represents the bottom of "Y"
> and this ensures that only one of the track segments on this tile can be
> used. This definition method also takes care of defining tiles such as
> yellow and green Toronto from 1856 or Moscow from 1861.
>
> In general the search for optimal routes work by selecting a route,
> evaluating its value, removing the used edges from the graph and running
> the search again on the remaining graph (with remaining trains). Then
> choosing the "next" route and repeating the process, until the set of
> routes with the highest total value is found. In the route selection
> process there are 3 direction of iteration: "head", "tail" and "branch".
> "Head" and "tail" is extending (by one edge) from the head or from the
> tail (each route starts from the station) and "branch" is replacing last
> added edge with the possible alternative. This guarantees to iterate over
> every possible route (here by route I mean route in graph terms, it's not
> necessarily a valid route in 18xx terms). In practice, I'm using few
> optimizations to eliminate complete scan, but that's probably unimportant
> for non-AI use.
>
> The route evaluation part needs to be aware of the rules of the specific
> games. Route evaluation logic gets a proposed route as a vector of
> vertices it visits. As a result it gives a value and the vector of
> vertices it has used (this is used for optimization by skipping the routes
> that just an extension from the unused side). In a simple case evaluation
> would be simple - just total values of the best subset of cities and
> towns, but various bonuses make things more complicated. I'm using a bonus
> table containing various bonuses and their requirements. Bonuses can be:
> add extra value to the vertex, multiply value of the vertex, add value to
> the route (for example if 2 specific locations are visited) etc... Bonuses
> can be defined as sets if it's necessary to allow only one bonus from the
> set to be applied. Because of that, the route evaluation algorithm has to
> return updated "bonus usage context". There may be a need to iterate over
> bonus choices (such as not apply some bonus when possible), but I am not
> sure what game has such set of possible bonuses to require it. I haven't
> done such iteration because it would be bad for AI case (because of
> performance), for non-AI case, it's probably not a big issue.
>
> Some parts of the route evaluation code might need to be updated for
> specific games, but such updates should not affect the logic for anything
> else. Two types of trains I am aware of that might require more thought
> are hex trains and "N out of M" trains. Essentially, my current assumption
> is that for any route candidate the optimal route use (meaning use of
> trains and bonuses) can always be determined if both head and tail
> vertices are used.
>
> Alex
>
> On Sat, 20 Mar 2010 18:17:41 -0600, John A. Tamplin <ja...@ja...> wrote:
> > Yes, though see the archives for details about why it may be harder than
> > you
> > think.
> >
> > John A. Tamplin (Android)
> >
> > On Mar 20, 2010 8:12 PM, "Alex Tikhonov" <al...@sh...> wrote:
> >
> > Hi all,
> >
> > Per Brett Lentz suggestion I am moving this discussion here and reporting
> > my message from 18x yahoo group.
> >
> > This is my first post here, but I have been lurking for a while. I wonder
> > if there is an interest in adding automatic route calculation to Rails. I
> > am trying to create AI for some of the games (and no, it's not going
> > well), but as a side effect I have code that computes the routes. It
> > supports some of more widely used rules (various town treatment, city and
> > route bonuses, multipliers etc). It runs on an abstract connectivity
> > graph, so it should not be too hard to integrate.
> >
> > Alex.
> >
> > -------------------------------------------------------------------------
> >----- 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] Bug fix release 1.2.2?

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

Brett:
I would like to commit my changes that allow regression testing for Rails.
Could we have the bug fix release out of the door before that?

The changes include a few changes to some of the base classes to allow Rails 
to process several different 18xx games in sequence and to the ReportBuffer 
class, as the comparison is based on the game report.

I would prefer to have the bug fix release out without those changes, which 
might include some side effects. 

The other possibility would be to branch, but I do not know exactly how to 
branch and merge with cvs. Do we have a decision already about the future 
system? I would be glad about svn as I use that for work as well and it seems 
to be well integrated to eclipse.

Stefan


On Friday 19 March 2010 22:02:01 brett lentz wrote:
> Should we do a 1.2.2 release for this?
>
>
> ---Brett.
>
> On Fri, Mar 19, 2010 at 1:53 PM, Erik Vos <eri...@xs...> wrote:
> > This problem was indeed caused by the Stefan's fix. That fix was
> > basically correct, as my way to allow done in this case was a shortcut
> > that broke the (unwritten) rules. But the purpose of that shortcut
> > (enabling Done) was not reinstated in any other way.
> >
> > I have now done it in the regular way. Done will now be enabled after
> > repaying loans.
> >
> > Erik.
> >
> >
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Friday 19 March 2010 17:05
> > To: rai...@li...
> > Subject: Re: [Rails-devel] Fwd: Problem with Rails 1.2
> >
> > Erik:
> > from the description alone I guess that this is caused by a bug fix of
> > mine on the undo mechanism. Do you remember our discussion about the
> > change from the postcondition check (which requires the use of state
> > variables) for the done button to a precondition check (which avoids
> > that).
> >
> > It seems that there is a case not covered in the 1856 repay loan action
> > step
> >
> > yet, that does not set the doneAllowed variable. Thus it might be a good
> > guess to check the preconditions there.
> >
> > I look forward to checking in my automated testing procedures which
> > hopefully
> > reduce those side-effects of refactoring.
> >
> > STefan
> >
> > On Friday 19 March 2010 16:10:49 brett lentz wrote:
> >> ---------- Forwarded message ----------
> >> From: Arne Östlund <arn...@gl...>
> >> Date: Thu, Mar 18, 2010 at 11:27 PM
> >> Subject: Problem with Rails 1.2
> >> To: rai...@li...
> >>
> >>
> >> Hi Brett/Erik
> >>
> >> We are playing an 1856 PBeM campaigne. Due to an error with Rails
> >> 1.1.3 I tried to recreate our moves in Rail 1.2 to current status by
> >> redo some turns. But when I repayed the Loans for LPS after an
> >> withhold, one OR before the CGR formation, the game stalled. The only
> >> option I got was to Undo. So we can not pass this state and continue
> >> the game!
> >>
> >> /Arne Östlund
> >
> > -------------------------------------------------------------------------
> >--- --
> > Download Intel&#174; Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> > -------------------------------------------------------------------------
> >----- Download Intel&#174; Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ---------------------------------------------------------------------------
>--- Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Automatic route calculation

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

I am not completely sure if you were referring to the difficulties of the  
algorithm or the difficulties of the integration, but I assume it's former.

Perhaps I should explain how the algorithm works to make things more  
clear. There are two parts to the algorithm - route selection and route  
evaluation. Route selection is performed on the abstract connectivity  
graph (which is a vector of edges and a associative map of vertices). Each  
edge is a pair of vertex coordinates on 2-D grid (I use specific encoding  
that allows to go between these vertices and hexes (or tiles) and back by  
simple arithmetics). Vertex information contains some basic data, such as  
whether there is a town at this vertex, if it's blocked [by station  
markers of other companies], current town/city value etc... The way this  
connectivity graph is defined takes care of handling use of track segments  
and visiting same cities. It would be easier to show he method on the  
picture, but I will try to describe it here. Let's say we have a hex  
oriented so that one side is facing north, another south and the other 4  
NW, SW, NE and SE. For each hex there will be 13 vertices. One in the  
center (#0), 6 vertices each in the middle of the hex edge (#1-#6, #1 is  
North, counting clockwise) and 6 more in the middle of the line connecting  
each of vertices #1-#6 to the center. Vertices #1-#6 will be shared with  
other adjacent hexes. Let's say we have green Y tile (two gently curving  
tracks from S to NW and from S to NE). Connectivity graph for such tile  
will be (2-8,8-10,10-4,6-12,12-10). 10-4 edge represents the bottom of "Y"  
and this ensures that only one of the track segments on this tile can be  
used. This definition method also takes care of defining tiles such as  
yellow and green Toronto from 1856 or Moscow from 1861.

In general the search for optimal routes work by selecting a route,  
evaluating its value, removing the used edges from the graph and running  
the search again on the remaining graph (with remaining trains). Then  
choosing the "next" route and repeating the process, until the set of  
routes with the highest total value is found. In the route selection  
process there are 3 direction of iteration: "head", "tail" and "branch".  
"Head" and "tail" is extending (by one edge) from the head or from the  
tail (each route starts from the station) and "branch" is replacing last  
added edge with the possible alternative. This guarantees to iterate over  
every possible route (here by route I mean route in graph terms, it's not  
necessarily a valid route in 18xx terms). In practice, I'm using few  
optimizations to eliminate complete scan, but that's probably unimportant  
for non-AI use.

The route evaluation part needs to be aware of the rules of the specific  
games. Route evaluation logic gets a proposed route as a vector of  
vertices it visits. As a result it gives a value and the vector of  
vertices it has used (this is used for optimization by skipping the routes  
that just an extension from the unused side). In a simple case evaluation  
would be simple - just total values of the best subset of cities and  
towns, but various bonuses make things more complicated. I'm using a bonus  
table containing various bonuses and their requirements. Bonuses can be:  
add extra value to the vertex, multiply value of the vertex, add value to  
the route (for example if 2 specific locations are visited) etc... Bonuses  
can be defined as sets if it's necessary to allow only one bonus from the  
set to be applied. Because of that, the route evaluation algorithm has to  
return updated "bonus usage context". There may be a need to iterate over  
bonus choices (such as not apply some bonus when possible), but I am not  
sure what game has such set of possible bonuses to require it. I haven't  
done such iteration because it would be bad for AI case (because of  
performance), for non-AI case, it's probably not a big issue.

Some parts of the route evaluation code might need to be updated for  
specific games, but such updates should not affect the logic for anything  
else. Two types of trains I am aware of that might require more thought  
are hex trains and "N out of M" trains. Essentially, my current assumption  
is that for any route candidate the optimal route use (meaning use of  
trains and bonuses) can always be determined if both head and tail  
vertices are used.

Alex

On Sat, 20 Mar 2010 18:17:41 -0600, John A. Tamplin <ja...@ja...> wrote:

> Yes, though see the archives for details about why it may be harder than  
> you
> think.
>
> John A. Tamplin (Android)
>
> On Mar 20, 2010 8:12 PM, "Alex Tikhonov" <al...@sh...> wrote:
>
> Hi all,
>
> Per Brett Lentz suggestion I am moving this discussion here and reporting
> my message from 18x yahoo group.
>
> This is my first post here, but I have been lurking for a while. I wonder
> if there is an interest in adding automatic route calculation to Rails. I
> am trying to create AI for some of the games (and no, it's not going
> well), but as a side effect I have code that computes the routes. It
> supports some of more widely used rules (various town treatment, city and
> route bonuses, multipliers etc). It runs on an abstract connectivity
> graph, so it should not be too hard to integrate.
>
> Alex.
>
> ------------------------------------------------------------------------------
> 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


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

Re: [Rails-devel] Automatic route calculation

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

Yes, though see the archives for details about why it may be harder than you
think.

John A. Tamplin (Android)

On Mar 20, 2010 8:12 PM, "Alex Tikhonov" <al...@sh...> wrote:

Hi all,

Per Brett Lentz suggestion I am moving this discussion here and reporting
my message from 18x yahoo group.

This is my first post here, but I have been lurking for a while. I wonder
if there is an interest in adding automatic route calculation to Rails. I
am trying to create AI for some of the games (and no, it's not going
well), but as a side effect I have code that computes the routes. It
supports some of more widely used rules (various town treatment, city and
route bonuses, multipliers etc). It runs on an abstract connectivity
graph, so it should not be too hard to integrate.

Alex.

------------------------------------------------------------------------------
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] Automatic route calculation

[Alex T. <al...@sh...>]

Hi all,

Per Brett Lentz suggestion I am moving this discussion here and reporting  
my message from 18x yahoo group.

This is my first post here, but I have been lurking for a while. I wonder
if there is an interest in adding automatic route calculation to Rails. I
am trying to create AI for some of the games (and no, it's not going
well), but as a side effect I have code that computes the routes. It
supports some of more widely used rules (various town treatment, city and
route bonuses, multipliers etc). It runs on an abstract connectivity
graph, so it should not be too hard to integrate.

Alex.

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

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

Alex -

Route calculation is probably the most requested feature. So, yes,
we'd be very interested to have your contributions.

Let's move this discussion to the rails-devel mailing list.  Please
subscribe, if you're not already subscribed:
https://lists.sourceforge.net/lists/listinfo/rails-devel

---Brett.



On Sat, Mar 20, 2010 at 10:44 AM, alexti00 <al...@sh...> wrote:
>
>
> Hi all,
>
> This is my first post here, but I have been lurking for a while. I wonder if there is an interest in adding automatic route calculation to Rails. I am trying to create AI for some of the games (and no, it's not going well), but as a side effect I have code that computes the routes. It supports some of more widely used rules (various town treatment, city and route bonuses, multipliers etc). It runs on an abstract connectivity graph, so it should not be too hard to integrate.
>
> Alex.
>
> --- In 18...@ya..., brett lentz <wakko666@...> 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.
>>
>
>
>
>
> ------------------------------------
>
> This is a message from the 18xx mailing list.Yahoo! Groups Links
>
> <*> To visit your group on the web, go to:
>    http://groups.yahoo.com/group/18xx/
>
> <*> Your email settings:
>    Individual Email | Traditional
>
> <*> To change settings online go to:
>    http://groups.yahoo.com/group/18xx/join
>    (Yahoo! ID required)
>
> <*> To change settings via email:
>    18x...@ya...
>    18x...@ya...
>
> <*> To unsubscribe from this group, send an email to:
>    18x...@ya...
>
> <*> Your use of Yahoo! Groups is subject to:
>    http://docs.yahoo.com/info/terms/
>
>

Re: [Rails-devel] Fwd: Problem with Rails 1.2

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

the bug I fixed is still fixed with Erik's fix.
I would recommend another release is possible, after that I would check
in my changes to enable automated regression testing, which requires some 
minor changes on two utility Rails classes.
STefan

On Friday 19 March 2010 22:02:01 brett lentz wrote:
> Should we do a 1.2.2 release for this?
>
>
> ---Brett.
>
> On Fri, Mar 19, 2010 at 1:53 PM, Erik Vos <eri...@xs...> wrote:
> > This problem was indeed caused by the Stefan's fix. That fix was
> > basically correct, as my way to allow done in this case was a shortcut
> > that broke the (unwritten) rules. But the purpose of that shortcut
> > (enabling Done) was not reinstated in any other way.
> >
> > I have now done it in the regular way. Done will now be enabled after
> > repaying loans.
> >
> > Erik.
> >
> >
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Friday 19 March 2010 17:05
> > To: rai...@li...
> > Subject: Re: [Rails-devel] Fwd: Problem with Rails 1.2
> >
> > Erik:
> > from the description alone I guess that this is caused by a bug fix of
> > mine on the undo mechanism. Do you remember our discussion about the
> > change from the postcondition check (which requires the use of state
> > variables) for the done button to a precondition check (which avoids
> > that).
> >
> > It seems that there is a case not covered in the 1856 repay loan action
> > step
> >
> > yet, that does not set the doneAllowed variable. Thus it might be a good
> > guess to check the preconditions there.
> >
> > I look forward to checking in my automated testing procedures which
> > hopefully
> > reduce those side-effects of refactoring.
> >
> > STefan
> >
> > On Friday 19 March 2010 16:10:49 brett lentz wrote:
> >> ---------- Forwarded message ----------
> >> From: Arne Östlund <arn...@gl...>
> >> Date: Thu, Mar 18, 2010 at 11:27 PM
> >> Subject: Problem with Rails 1.2
> >> To: rai...@li...
> >>
> >>
> >> Hi Brett/Erik
> >>
> >> We are playing an 1856 PBeM campaigne. Due to an error with Rails
> >> 1.1.3 I tried to recreate our moves in Rail 1.2 to current status by
> >> redo some turns. But when I repayed the Loans for LPS after an
> >> withhold, one OR before the CGR formation, the game stalled. The only
> >> option I got was to Undo. So we can not pass this state and continue
> >> the game!
> >>
> >> /Arne Östlund
> >
> > -------------------------------------------------------------------------
> >--- --
> > Download Intel&#174; Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> > -------------------------------------------------------------------------
> >----- Download Intel&#174; Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ---------------------------------------------------------------------------
>--- Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Fwd: Problem with Rails 1.2

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

Should we do a 1.2.2 release for this?


---Brett.



On Fri, Mar 19, 2010 at 1:53 PM, Erik Vos <eri...@xs...> wrote:
> This problem was indeed caused by the Stefan's fix. That fix was basically
> correct, as my way to allow done in this case was a shortcut that broke the
> (unwritten) rules. But the purpose of that shortcut (enabling Done) was not
> reinstated in any other way.
>
> I have now done it in the regular way. Done will now be enabled after
> repaying loans.
>
> Erik.
>
>
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Friday 19 March 2010 17:05
> To: rai...@li...
> Subject: Re: [Rails-devel] Fwd: Problem with Rails 1.2
>
> Erik:
> from the description alone I guess that this is caused by a bug fix of mine
> on the undo mechanism. Do you remember our discussion about the change from
> the postcondition check (which requires the use of state variables) for the
> done button to a precondition check (which avoids that).
>
> It seems that there is a case not covered in the 1856 repay loan action step
>
> yet, that does not set the doneAllowed variable. Thus it might be a good
> guess to check the preconditions there.
>
> I look forward to checking in my automated testing procedures which
> hopefully
> reduce those side-effects of refactoring.
>
> STefan
>
>
> On Friday 19 March 2010 16:10:49 brett lentz wrote:
>> ---------- Forwarded message ----------
>> From: Arne Östlund <arn...@gl...>
>> Date: Thu, Mar 18, 2010 at 11:27 PM
>> Subject: Problem with Rails 1.2
>> To: rai...@li...
>>
>>
>> Hi Brett/Erik
>>
>> We are playing an 1856 PBeM campaigne. Due to an error with Rails
>> 1.1.3 I tried to recreate our moves in Rail 1.2 to current status by
>> redo some turns. But when I repayed the Loans for LPS after an
>> withhold, one OR before the CGR formation, the game stalled. The only
>> option I got was to Undo. So we can not pass this state and continue
>> the game!
>>
>> /Arne Östlund
>
>
>
> ----------------------------------------------------------------------------
> --
> 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] Fwd: Problem with Rails 1.2

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

This problem was indeed caused by the Stefan's fix. That fix was basically
correct, as my way to allow done in this case was a shortcut that broke the
(unwritten) rules. But the purpose of that shortcut (enabling Done) was not
reinstated in any other way.

I have now done it in the regular way. Done will now be enabled after
repaying loans.

Erik.


-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Friday 19 March 2010 17:05
To: rai...@li...
Subject: Re: [Rails-devel] Fwd: Problem with Rails 1.2

Erik:
from the description alone I guess that this is caused by a bug fix of mine
on the undo mechanism. Do you remember our discussion about the change from 
the postcondition check (which requires the use of state variables) for the 
done button to a precondition check (which avoids that). 

It seems that there is a case not covered in the 1856 repay loan action step

yet, that does not set the doneAllowed variable. Thus it might be a good 
guess to check the preconditions there.

I look forward to checking in my automated testing procedures which
hopefully 
reduce those side-effects of refactoring. 

STefan


On Friday 19 March 2010 16:10:49 brett lentz wrote:
> ---------- Forwarded message ----------
> From: Arne Östlund <arn...@gl...>
> Date: Thu, Mar 18, 2010 at 11:27 PM
> Subject: Problem with Rails 1.2
> To: rai...@li...
>
>
> Hi Brett/Erik
>
> We are playing an 1856 PBeM campaigne. Due to an error with Rails
> 1.1.3 I tried to recreate our moves in Rail 1.2 to current status by
> redo some turns. But when I repayed the Loans for LPS after an
> withhold, one OR before the CGR formation, the game stalled. The only
> option I got was to Undo. So we can not pass this state and continue
> the game!
>
> /Arne Östlund



----------------------------------------------------------------------------
--
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] Fwd: Problem with Rails 1.2

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

Erik:
from the description alone I guess that this is caused by a bug fix of mine
on the undo mechanism. Do you remember our discussion about the change from 
the postcondition check (which requires the use of state variables) for the 
done button to a precondition check (which avoids that). 

It seems that there is a case not covered in the 1856 repay loan action step 
yet, that does not set the doneAllowed variable. Thus it might be a good 
guess to check the preconditions there.

I look forward to checking in my automated testing procedures which hopefully 
reduce those side-effects of refactoring. 

STefan


On Friday 19 March 2010 16:10:49 brett lentz wrote:
> ---------- Forwarded message ----------
> From: Arne Östlund <arn...@gl...>
> Date: Thu, Mar 18, 2010 at 11:27 PM
> Subject: Problem with Rails 1.2
> To: rai...@li...
>
>
> Hi Brett/Erik
>
> We are playing an 1856 PBeM campaigne. Due to an error with Rails
> 1.1.3 I tried to recreate our moves in Rail 1.2 to current status by
> redo some turns. But when I repayed the Loans for LPS after an
> withhold, one OR before the CGR formation, the game stalled. The only
> option I got was to Undo. So we can not pass this state and continue
> the game!
>
> /Arne Östlund

[Rails-devel] Fwd: Problem with Rails 1.2

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

---------- Forwarded message ----------
From: Arne Östlund <arn...@gl...>
Date: Thu, Mar 18, 2010 at 11:27 PM
Subject: Problem with Rails 1.2
To: rai...@li...


Hi Brett/Erik

We are playing an 1856 PBeM campaigne. Due to an error with Rails
1.1.3 I tried to recreate our moves in Rail 1.2 to current status by
redo some turns. But when I repayed the Loans for LPS after an
withhold, one OR before the CGR formation, the game stalled. The only
option I got was to Undo. So we can not pass this state and continue
the game!

/Arne Östlund

Re: [Rails-devel] 1889: tile upgrades

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

On Thu, Mar 18, 2010 at 2:49 PM, Stefan Frey <ste...@we...> wrote:

> And how do you place 448 (brown K) on 14 (green X) and keep all existing
> connections?


Sorry -- obviously, you have to maintain existing track so 448 can't upgrade
14.

-- 
John A. Tamplin

Re: [Rails-devel] 1889: tile upgrades

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

And how do you place 448 (brown K) on 14 (green X) and keep all existing 
connections? 

On Thursday 18 March 2010 17:10:08 John A. Tamplin wrote:
> On Thu, Mar 18, 2010 at 11:50 AM, Aliza Panitz 
<ali...@gm...>wrote:
> > I was playing 1889 with a few of my imaginary friends, and noticed
> > that #57 (straight yellow city) does not upgrade to #205 or #206 (the
> > two obnoxious single-bang green Y shapes).
> >
> > This faithfully follows the tile upgrade sheet in the 1889 rules, but
> > I've confirmed with John Tamplin that this is an error; the upgrade
> > should be legal.
> >
> > He also mentions that "the 448 tile should be playable on any of the
> > green city tiles."
> >
> > I'm hesitant to call this a Rails bug, since Rails implemented the
> > printed rules, but it's something that should be changed.
> >
> > (This was in Rails 1.2, and I know that I need to upgrade to 1.2.1,
> > but I doubt it makes a difference.)
> >
> > Is it OK if I file a bug report based on my private conversation with
> > John?
>
> Here is a (hopefully) correct tile upgrade chart.

Re: [Rails-devel] 1889: tile upgrades

[Justin R. <jus...@gm...>]

Yeah John Tamplin's sheet shows a 14 upgrading to a 448 and that seems
not right...

On Thu, Mar 18, 2010 at 11:24 AM, Stefan Frey <ste...@we...> wrote:
> Aliza:
> thanks for your test and your update. Two comments.
>
> A) Tile 57 upgrades
> I am a little surprised, because I thought that this is intentional. I think
> there are not many places, that cry for the straight city, but it allows some
> tragic tile lays.
> But I usually prefer tile manifests that only require visual inspection if one
> tile can replace the other (retain all connections and are of the same type),
> thus that change makes sense.
>
> B) Tile 448 upgrades all green cities
> Is that really true? How should that work. Tile 448 is a K brown tile. How can
> you place that on a green X (14)? Or the green windmill (13)? Rails would
> mark those upgrades as impossible, as not all connections can be maintained.
>
> If there is agreement on A) I will fix that. For B) I would like to have some
> confirmation that I fully understand the implications.
>
> STefan
>
>
>
> On Thursday 18 March 2010 16:50:13 Aliza Panitz wrote:
>> I was playing 1889 with a few of my imaginary friends, and noticed
>> that #57 (straight yellow city) does not upgrade to #205 or #206 (the
>> two obnoxious single-bang green Y shapes).
>>
>> This faithfully follows the tile upgrade sheet in the 1889 rules, but
>> I've confirmed with John Tamplin that this is an error; the upgrade
>> should be legal.
>>
>> He also mentions that "the 448 tile should be playable on any of the
>> green city tiles."
>>
>> I'm hesitant to call this a Rails bug, since Rails implemented the
>> printed rules, but it's something that should be changed.
>>
>> (This was in Rails 1.2, and I know that I need to upgrade to 1.2.1,
>> but I doubt it makes a difference.)
>>
>> Is it OK if I file a bug report based on my private conversation with John?
>>
>>  - Aliza
>>
>> ---------------------------------------------------------------------------
>>--- 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] 1889: tile upgrades

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

Aliza:
thanks for your test and your update. Two comments.

A) Tile 57 upgrades
I am a little surprised, because I thought that this is intentional. I think 
there are not many places, that cry for the straight city, but it allows some 
tragic tile lays. 
But I usually prefer tile manifests that only require visual inspection if one 
tile can replace the other (retain all connections and are of the same type), 
thus that change makes sense.

B) Tile 448 upgrades all green cities
Is that really true? How should that work. Tile 448 is a K brown tile. How can 
you place that on a green X (14)? Or the green windmill (13)? Rails would 
mark those upgrades as impossible, as not all connections can be maintained.

If there is agreement on A) I will fix that. For B) I would like to have some 
confirmation that I fully understand the implications. 

STefan



On Thursday 18 March 2010 16:50:13 Aliza Panitz wrote:
> I was playing 1889 with a few of my imaginary friends, and noticed
> that #57 (straight yellow city) does not upgrade to #205 or #206 (the
> two obnoxious single-bang green Y shapes).
>
> This faithfully follows the tile upgrade sheet in the 1889 rules, but
> I've confirmed with John Tamplin that this is an error; the upgrade
> should be legal.
>
> He also mentions that "the 448 tile should be playable on any of the
> green city tiles."
>
> I'm hesitant to call this a Rails bug, since Rails implemented the
> printed rules, but it's something that should be changed.
>
> (This was in Rails 1.2, and I know that I need to upgrade to 1.2.1,
> but I doubt it makes a difference.)
>
> Is it OK if I file a bug report based on my private conversation with John?
>
>  - Aliza
>
> ---------------------------------------------------------------------------
>--- Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] 1889: tile upgrades

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

I was playing 1889 with a few of my imaginary friends, and noticed
that #57 (straight yellow city) does not upgrade to #205 or #206 (the
two obnoxious single-bang green Y shapes).

This faithfully follows the tile upgrade sheet in the 1889 rules, but
I've confirmed with John Tamplin that this is an error; the upgrade
should be legal.

He also mentions that "the 448 tile should be playable on any of the
green city tiles."

I'm hesitant to call this a Rails bug, since Rails implemented the
printed rules, but it's something that should be changed.

(This was in Rails 1.2, and I know that I need to upgrade to 1.2.1,
but I doubt it makes a difference.)

Is it OK if I file a bug report based on my private conversation with John?

 - Aliza

Re: [Rails-devel] Implementation levels

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

Yeah, Undo issues aplenty, as well as some odd issues with a saved
game that constantly got corrupted with the first company formation
post phase 5 (it didn't seem to save the home city in the save file).
Also the issues we had previously with Pullmans getting force
discarded incorrectly.  These were either with version 1.1.2 or a
saved file I brought forward so I didn't log bugs for them since I
wanted to run through the gamesteps again in the newer version and see
if some of the bug fixes had resolved some of them.

You can go bankrupt in 18EU, what should happen is that all remaining
holdings for that player go to the pool, presidency transfers to a new
president if applicable, if not the company closes and the player is
eliminated from the game.  In practice this has only happened once to
me in a f2f game and we decided to just call it based on net worth of
the remaining players but in theory you should carry on with that
player eliminated.

On 17 March 2010 22:25, Stefan Frey <ste...@we...> wrote:
> 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
>
>
>
> ------------------------------------------------------------------------------
> 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 1.2.1 is available.

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

This releases fixes a critical bug that affects the playability of
1830 and 1889. Also included is a fix to the rails.sh shell script.

All users of 1.2 should upgrade.

---Brett.