rails-devel — List for discussion of Rails development

[Rails-devel] Item names for game engine, UI and debugging

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

For Rails2.0 I have introduced both conventions for
A) names to identify items (for the game engine)
B) names of items for the UI (for the user)
C) names of items for debugging

In some cases they coincide (e.g. companies), in many cases they
differ.

The chosen methods are:
A) Game engine names

String getId() (method of Item interface)
Unique identifier for a given parent

String getURI() (method of Item interface)
Unique identifier in the context

String getFullURI() (method of Item interface)
Unique identifier in the game engine

Examples for getId() are:
Certificates: cert_0, cert_1
Trains: 3_0, 3_1, 3_2, 3_3

Examples for getURI() are:
Certificates: Public/B&O/cert_0
Trains: 3_0

Examples for getFullURI() are:
Certificates: /CompanyManager/Public/B&O/cert_0
Trains: /TrainManager/3_0


B) UI names
String toText() (new method of Item interface)

toText() is already the method that Models use to communicate to the
observer in  the UI.
So I extend this to non-Model items, that toText() generates the String 
used to display for the User.

The default (defined e.g. in AbstractItem, RailsItem etc.) is that 
toText() links to getId().


C) Debugging information
String toString() method

The default is ClassName followed by FullURI (for states) or URI (for items)

Examples:
Train{URI=3_0}
PublicCompany{URI=Public/B&O}
BooleanState{FullURI=/CompanyManager/Public/NYC/closed}

One could (rightly) wonder why not choose toString() instead of toText() 
for the UI names?

The reason is that I reserve toString() for debug information.

There are two reasons for it:
ii) (Main) I want refactor support for calls to toText().
toString() is often implicitly called by omitting toString() in string 
concatenation.
String s = "Train:" + train;
instead of
String s = "Train:" + train.toText();

i) The new logger (sl4j) supports a resource-friendly mechanism to use

log.debug("Bought new train {}", train);
which automatically calls train.toString() if log is enabled, but does 
not call any method if log is turned off.

[Rails-devel] Rails2.0: (Almost) all of Rails 1.x merged

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

All commits of the Rails 1.x tree are now merged into the Rails2.0 
branch (this makes Rails2.0_merge obsolete and will be deleted soon).

So everyone (and especially the one-and-only Erik) is invited to start 
coding against Rails2.0 from now on.

Major change so far are the revised classes/interfaces of the 
state/model packages (see previous mails).

Current (known) issues soon to be fixed are:
* Undo/Redo in the UI is deactivated
* Some annoyance in the UI that items are referred by the id instead of 
the name (e.g. a train called 3_3 instead of simply 3)
(see next mail on toText() methods)

The only exception are those commits that have been related to the 
started implementation of 1880, before I can merge them I have to get a 
better picture of the requirements, but this will be done soon.

Testing of Rails2.0 in development is already possible by fetching the 
git branch.

I will release a alpha version as soon as I have enabled (or gave up on) 
WebStart support (see separate mail for this).

Further roadmap:
* Start revised Round classes
* Use that to finish 1825
==> Release of Rails2.0
* Add tile lay allowance algorithm
* Support realtime-online play
==> Release of Rails2.1

Other plans (independent of releases)
* Improve ftf-play (no-map mode) with an optimized gui
* Finish 1880 (if not Martin continues his work there)

Stefan

Re: [Rails-devel] Issue with Private Bid Auction order

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

If I understand everyone correct the issue is only about which player 
starts the bidding in the contested item auction.

It is common understanding that
A) Only those players can participate that have bid previously and the 
starting price is the current highest bid with a minimum raise of 5$.

This is stated both by 1830(AH) and 1830(Mayfair 2nd).

It is also seems pretty clear that
B) The player order is still clockwise (skipping those players who have 
not bid).

This is missing in 1830(AH), but included 1830(Mayfair 2nd)

A previously known issue was:
C) Do players who pass in the (sub)-auction leave the auction?

This is missing in 1830(AH), but resolved in 1830(Mayfair 2nd: NO)

There is an option in Rails to choose the solution for C (Leave Private 
Auction on Pass), default is set to NO.

The new issue is:
D) Which player has the first bid?

This is missing in 1830(AH), but resolved in 1830(Mayfair 2nd) by "The 
player with the lowest bid starts the bidding" (page 26)

Unfortunately this (perfectly valid solution) is different to all other 
games in Rails that use the 1830 style auction, including the two other 
Mayfair 18xx titles:

1856: "... starting with the bidding player to the left of the player 
with the highest bid" (p. 9)
1870: "... starting with the bidding player to the left of the player 
with the highest bid" (p. 10)
1889: "... starting with the bidding player to the left of the player 
with the highest bid" (p. 6)
18AL/18GA: "...beginning with the player after the one who made the 
highest bid" (both p. 7)


 From my personal experience I got the impression that this is the 
general consensus how to play in 1830 as well.

So questions are
1) Why did Mayfair propose a rule fix that is different to the solution 
in all the other games after 1830 which share the same type of auction?
Maybe they were not even aware of this?

2) Should Rails add a game option for this? And if so, should this be 
the default for 1830 (knowing that this is different to the default of 
all the 1830 "derivatives")?

3) Are there tournament rules (e.g. used at the WBC) for 18xx, which we 
could use to resolve those issues? Or was this addressed at the yahoo 
list already and I have missed that discussion.

 From a development perspective I prefer to avoid including too many 
game options (especially for such non-game changing issues).
And as a 18xx player I prefer to have rules sets standardized in minor 
details.

Remark:
Another interesting bit is from Steve Thomas 1830 clarifications:

"When there are three or more bidding players, some groups hold an 
organised auction, where players bid or pass in player order; in some 
groups a player passing may not rejoin the auction. Others (including my 
own group) have a free-for-all, where any eligible player may make a bid 
at any time, and the auction ends when all players agree to stop."

There is no intention to mimick a free-for-all auction in Rails for the 
time-being ;-)


On 09/24/2012 02:24 PM, Bob Probst wrote:
> 3 player 1830, rails file attached.
>
> We had 3 players bidding on C&A and Rails directed the next bid to the
> middle player, not the player with the lowest bid.
>
> Player 1 is Joshua.
> Player 2 is Adam.
> Player 3 is Bob.
>
> Adam just passed on the M&H, Joshua bought it at $150 and Rails directed
> me to bid next on the C&A.
>
> SVNRR: $20 Joshua purchases for $20
> C&StL: $40 Adam 55, Bob pass
> D&H: $70 Joshua pass, Bob 100
> M&H: $110 *Adam pass*, Joshua 150
> C&A: $160 Joshua 165, Bob 170, Adam 175
> B&O: $220
>
> *Bob* (with C&A)
>
> As I understand, the original rules were somewhat ambiguous on how this
> should be done
>
> The new Mayfair reprint states that the next in line is the lowest
> bidder (pg 26) and my experience with a wide variety of players is to
> have it go to the lowest bidder as well.
>
> I'd recommend that RAILS adhere to the current ruleset.
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Bug: Rails 1.7.10, 18EU, route calculation

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

On reload of the provided save file the bug does not occur.
However I have no doubt that it was possible to create the bug using the 
undo mechanism of Rails1.x in combination with the company merger 
procedures for 18EU.

I hope that such cases will occur less often (and will be easier to fix 
and track if they do) in Rails2.0.

Could you please double-check that if you reload your savefile the 
revenue calculation works correctly?

Stefan

On 09/23/2012 03:09 AM, John David Galt wrote:
> At the point of this save file, SNCF is being shown a run that goes straight
> through the #1 token as if #1 had already been closed.
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://ad.doubleclick.net/clk;258768047;13503038;j?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>
>
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Issue with Private Bid Auction order

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

On 2012-09-27 20:47, Dave Mitton wrote:
> First off; I believe and play with people that have never disagreed 
> with me... that
> the main order of the Initial Stock Round in 1830 stays in seating 
> order and does not skip around.
> 
> Auctions are triggered by a purchase that causes the contested 
> private to be next in private order. Once triggered they happen 
> outside the SR turn order.
> 
> So if there are bids on all privates except the SVRR, and then the 
> SVRR is purchased,
> the auctions happen, and then the next player in order gets their SR turn.

Agreed on all of the above.

> In the BBG game; it was the order of the auction that surprised people.
> Evidently RAILS conducted the auction in table order as well.  This 
> was surprising because it did not start with the low bidder, but the 
> next around the table from the previous auction.
> In some ways it really doesn't matter,  The current "ante" (to borrow 
> some poker terminology) to stay in the auction was set by the highest 
> bidder or last bidder.  However you must admit that it is traditional 
> that an auction starts with the person that bid first (and is 
> therefore the lowest stale bid).

No.  It is traditional for the auction to go around the table in seating
order, starting with the player after the one who made the last and highest
bid (for the item now being auctioned) before the auction began.

All other bids for the same item that were made before the auction began
have no further effect except to establish eligibility; they may have been
made in any order, since they happened on stock turns on which each player
could have bought or bid on other items.  There is no reason to want to
preserve the order in which they were made.

Re: [Rails-devel] Issue with Private Bid Auction order

[Dave M. <da...@mi...>]

I think Bob is trying to relate the situation he found in the game 
they are playing on BBG.
http://www.boardgamegeek.com/thread/817997/1830-pbem-game-watch-it-progress-and-post-your-a/page/3


First off; I believe and play with people that have never disagreed 
with me... that
the main order of the Initial Stock Round in 1830 stays in seating 
order and does not skip around.

Auctions are triggered by a purchase that causes the contested 
private to be next in private order. Once triggered they happen 
outside the SR turn order.

So if there are bids on all privates except the SVRR, and then the 
SVRR is purchased,
the auctions happen, and then the next player in order gets their SR turn.

In the BBG game; it was the order of the auction that surprised people.
Evidently RAILS conducted the auction in table order as well.  This 
was surprising because it did not start with the low bidder, but the 
next around the table from the previous auction.
In some ways it really doesn't matter,  The current "ante" (to borrow 
some poker terminology) to stay in the auction was set by the highest 
bidder or last bidder.  However you must admit that it is traditional 
that an auction starts with the person that bid first (and is 
therefore the lowest stale bid).

It should be simple for RAILS to start auctions from that basis, not 
the current table order, or some unrelated state.

Dave.

On 9/25/2012 10:40 PM, John David Galt wrote:
>On 2012-09-24 05:24, Bob Probst wrote:
> > 3 player 1830, rails file attached.
> >
> > We had 3 players bidding on C&A and Rails directed the next bid 
> to the middle player, not the player with the lowest bid.
> >
> > Player 1 is Joshua.
> > Player 2 is Adam.
> > Player 3 is Bob.
> >
> > Adam just passed on the M&H, Joshua bought it at $150 and Rails 
> directed me to bid next on the C&A.
> >
> > SVNRR: $20 Joshua purchases for $20
> > C&StL: $40 Adam 55, Bob pass
> > D&H: $70 Joshua pass, Bob 100
> > M&H: $110 *Adam pass*, Joshua 150
> > C&A: $160 Joshua 165, Bob 170, Adam 175
> > B&O: $220
> >
> > *Bob* (with C&A)
> >
> > As I understand, the original rules were somewhat ambiguous on 
> how this should be done
> >
> > The new Mayfair reprint states that the next in line is the 
> lowest bidder (pg 26) and my experience with a wide variety of 
> players is to have it go to the lowest bidder as well.
> >
> > I'd recommend that RAILS adhere to the current ruleset.
>
>The exact order of events is not clear from your message.  However, my
>experience (based mostly on the original 1830 rules) says this:
>
>    1) Within the auction for one item, bid turns go in regular seating order
>(skipping those players who didn't make themselves eligible by bidding on that
>item before somebody triggered the auction by buying the preceding item).
>The person who bid highest (and thus last) on that item before it went up for
>auction is regarded as having bid last, so the player after him gets the first
>turn in the auction.
>
>    2) Turns in the initial stock round also go in regular seating order (but
>are a separate sequence from any auctions that may interrupt the stock round).
>For most games, including 1830 as usually played, auctions do not change this
>sequence (that is, after an auction or series of auctions, the stock round
>continues with the player after the player who made the purchase that
>triggered the auction(s), regardless of who buys the auctioned item).
>
>    But in games (including, for some people, 1830) in which an auction does
>change whose turn it is in the stock round, the next turn always goes to the
>player after the player who bought the auctioned item.
>
>I have never heard of a rule where the lowest bidder gets the next turn;
>neither have most 18xx players; and 1830 should certainly not be changed to
>work that way unless it is made optional.
>
>------------------------------------------------------------------------------
>Live Security Virtual Conference
>Exclusive live event will cover all the ways today's security and
>threat landscape has changed and how IT managers can respond. Discussions
>will include endpoint security, mobile security and the latest in malware
>threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>_______________________________________________
>Rails-devel mailing list
>Rai...@li...
>https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Issue with Private Bid Auction order

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

On 2012-09-24 05:24, Bob Probst wrote:
> 3 player 1830, rails file attached.
> 
> We had 3 players bidding on C&A and Rails directed the next bid to the middle player, not the player with the lowest bid.
> 
> Player 1 is Joshua. 
> Player 2 is Adam. 
> Player 3 is Bob. 
> 
> Adam just passed on the M&H, Joshua bought it at $150 and Rails directed me to bid next on the C&A.
> 
> SVNRR: $20 Joshua purchases for $20
> C&StL: $40 Adam 55, Bob pass
> D&H: $70 Joshua pass, Bob 100
> M&H: $110 *Adam pass*, Joshua 150
> C&A: $160 Joshua 165, Bob 170, Adam 175
> B&O: $220
> 
> *Bob* (with C&A)
> 
> As I understand, the original rules were somewhat ambiguous on how this should be done
> 
> The new Mayfair reprint states that the next in line is the lowest bidder (pg 26) and my experience with a wide variety of players is to have it go to the lowest bidder as well.
> 
> I'd recommend that RAILS adhere to the current ruleset.

The exact order of events is not clear from your message.  However, my
experience (based mostly on the original 1830 rules) says this:

   1) Within the auction for one item, bid turns go in regular seating order
(skipping those players who didn't make themselves eligible by bidding on that
item before somebody triggered the auction by buying the preceding item).
The person who bid highest (and thus last) on that item before it went up for
auction is regarded as having bid last, so the player after him gets the first
turn in the auction.

   2) Turns in the initial stock round also go in regular seating order (but
are a separate sequence from any auctions that may interrupt the stock round).
For most games, including 1830 as usually played, auctions do not change this
sequence (that is, after an auction or series of auctions, the stock round
continues with the player after the player who made the purchase that
triggered the auction(s), regardless of who buys the auctioned item).

   But in games (including, for some people, 1830) in which an auction does
change whose turn it is in the stock round, the next turn always goes to the
player after the player who bought the auctioned item.

I have never heard of a rule where the lowest bidder gets the next turn;
neither have most 18xx players; and 1830 should certainly not be changed to
work that way unless it is made optional.

[Rails-devel] Bug: Rails 1.7.10, 18EU, route calculation

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

At the point of this save file, SNCF is being shown a run that goes straight
through the #1 token as if #1 had already been closed.

[Rails-devel] Release Rails 1.7.10 available

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

A new maintenance release for Rails 1.x series

Downloads are available at http://rails.sourceforge.net/ or by the
direct link http://sourceforge.net/projects/rails/files/Rails/1.7.10/

Contributors: Stefan Frey

Bugs reported by theos and Russel J. Alphey

Lists of bugs fixed:
- fixed bug in starting a company in 18EU if only one start price is 
possible
- fixed bug that the ReportWindow does not scroll down at game start

[Rails-devel] Rails2.0: Status update

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

Some good, some bad news:
The good one first is that all test games of Rails1.x now run with 
success in Rails2.0, so this should cover a lot of functionality.

In addition I am half-way through merging the changes of Rails1.x since 
Rails2.0 development branched off (this was after the release of 1.5.0).
The current state of that is in additional branch on sourceforge 
(rails2.0_merge).

The bad news is that those merges take longer than expected (or better 
longer than I hoped), especially those of Erik to get 1835 running.

So expect another 2 or 3 weeks until I will release the first alpha 
version of Rails2.0.

Stefan

[Rails-devel] Release Rails 1.7.9 available

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

A new maintenance release for Rails 1.x series

Downloads are available at http://rails.sourceforge.net/ or by the
direct link http://sourceforge.net/projects/rails/files/Rails/1.7.9/

Contributors: Stefan Frey

Bugs reported by Arne Österlund

Lists of bugs fixed:
- List of recent files does not work with few entries
- 1830 Coalfields (and others with obsolete trains):
Obsolete Trains in Pool should rust (previously they stayed forever)

Re: [Rails-devel] Stop properties framework

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

I have pushed the Access-related code to master unchanged, so we have a
common basis to work from. 
Please find my original description below. As said there, the only attribute
I could test so far is the score type.

Some further remarks, partly in response to comments by Stefan:

1.  If the 'loop' attribute turns out to be redundant (as I suspect,
noticing Stefan's plans to handle tile revisits), it can easily be removed.

2. The same applies to all other attributes, and new ones can also be added
pretty simply. The only exception is stopType, which is required as it plays
a role in the precedence rules.

3. Although 9 precedence levels look like serious overkill, it offers
flexibility, and in practice you will probably never use more than two or
three. 
The precedence list can be simplified as follows: 
1/2. Per specific station on a hex or tile.
3/4. Per specific hex(es) or tile(s).
5/6. Default per stop type (city, town, etc.) 
7/8. General defaults (per game).
9. Hardcoded 'fall-through' default per stop type.
In each pair, a specification per hex precedes a specification per tile.

You'll probably define the generic access properties of a game on level 5 or
6 in either MapManager or TileManager, as Stefan wants it.  In addition, you
may need to specify some exceptions on level 3 or 4, whichever is more
appropriate in each case. Usage of levels 1/2 is rare; these levels were
only added to enable handling a specific preprinted tile in 1837 (and that
need, which we couldn't handle in the old way, triggered this whole
upgrade).

4. The current code is the end result after several rework cycles. I
consider it rather elegant, but please judge for yourself.

5. The Stop class still contains a lot of debug logging, which is very
useful in testing, but needs to be restricted or removed later on.

Erik

> -----Original Message-----
> From: Erik Vos [mailto:eri...@xs...]
> Sent: Friday, June 01, 2012 12:26 AM
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] Stop properties framework
> 
> Stefan (and possibly others),
> 
> Sorry, this is long.  I intend to put an even longer version in the Wiki
later on.
> 
> I'm happy to report that I have made quite some progress with the new Stop
> properties framework, that was discussed a while ago.
> It's almost ready to be pushed, but I would first like to present its main
> aspects and reopen it for discussion.  I would like to publish it as a
whole.
> 
> This framework is intended to provide maximum flexibility in stop property
> configuration, on many levels. It is also intended to address the
following
> requirements and bugs:
> - 1837: the need to assign different types to different stops with
different
> properties on one mine tile.
> - 1835: the Berlin loop bug, also relevant to 18EU.  As discussed,
Stefan's
> existing method is not maintainable.
> - 1837 (and other games): the requirement that certain trains may only
> access one stop of a given type (i.e. mine).
> 
> Please note, that this framework only addresses the problems mentioned
> (and several others) in *configuring* such properties.  Currently, just
one of
> these properties is being used by Stefan's route and revenue calculation
> code, so there is a lot more work to do to bridge our two worlds.  See the
> end of this message for more remarks on this aspect.
> 
> The stop properties are now collected in a new class named Access.  The
> properties are unchanged from the previous situation, except that one new
> property has been added:
> 
> - stopType (city, town, port, mine, pass etc.). The list of values is
hardcoded,
> but easily extendable if needed.
> 
> - runTo (can a train run to a certain station?).  Still unused.  It is
intended to
> configure initial access restrictions like those of 1851 Birmingham and
1835
> Elsass-Lothringen.
> 
> - runThrough (can a train run through a certain station?). Still unused.
> Probably useful for off-map areas, Goderich and other cases.
> 
> - loop (can a train re-enter a hex visited before?). Still unused, and
perhaps
> redundant.  It was intended to prevent the Paris/Berlin/Vienna loop
> problems in 18EU and 1835, but that issue can be equally well addressed by
> the trainMutexID, to be discussed below. 'loop' may still prove useful for
> 1860, where no train may re-enter ANY hex.
> 
> - score type: major or minor (e.g. for 1835 n+m trains and for the many
> games where towns do not count against the train size).  This is the only
stop
> property already in use.  The new framework allows more fine-grained
> configuration.
> 
> - trainMutexID (provisional name).  The value can be any string.  This
stop
> property is new, and intends to replace the 'city name' that Stefan
currently
> is using to prevent the Berlin (etc.) loops.  As discussed earlier, that
solution
> is not well sustainable. Another potential use of trainMutexID is to
address
> the rule in 1837 and 18VA that goods trains may hit only one mine station
> each.
> 
> In principle, all stop properties can be defined per hex, per tile, per
station,
> per stop type, or even globally, but several (pretty obvious) exceptions
exist.
> The configuration levels are, in order of precedence:
> 
>  1. Specific MapHex station (defined in Map.xml with 'station' value > 0).
>  2. Specific Tile station (defined in TileSet.xml with 'station' value >
0).
> For preprinted tiles (id<=0) only.
>  3. MapHex (defined in Map.xml with 'station' value absent or 0).
>  4. Tile (defined in TileSet.xml with 'station' value absent or 0).  For
preprinted
> tiles (id<=0) only.
>  5. MapManager default per stop type (defined as default in Map.xml).
>  6. TileManager default per stop type (defined as default in TileSet.xml).
>  7. MapManager general default (defined in Map.xml).
>  8. TileManager general default (defined in TileSet.xml).
>  9. Generic default per stop-type (hardcoded).
> 
> Any property still undefined on a certain level "falls through" to the
next
> level.  It's probably preferable to define properties per hex rather than
per
> tile, but (at least for preprinted tiles) both are possible.
> 
> Both property parsing and the precedence "fall-through" mechanism are
> methods of class Access.  This refactoring has allowed to clean up some
> repetitive code in various classes.
> 
> Comments per property:
> 
> - stop type can only be defined on levels 1-4, as it is required further
down. If
> still undefined after level 4, it is derived from the tile Station type.
> - runTo and runThrough: levels 1-8.
> - scoreType and trainMutexID: levels 1-6.
> 
> I could only test the fall-through mechanism with scoreType, as that is
the
> only item currently used by Stefan's code.  Testing was easy, by setting
> conflicting score type values ('major' and 'minor') on different levels
for ports
> and villages in 18EU, and watching the displayed train routes.
> 
> I have also tested trainMutexId, after (temporarily) changing lines 257
and
> 258 in NetworkVertex to call city.getTrainMutexID() instead of
> station.getCityName().
> This way, I could switch the Berlin loop allowance on and off.
> 
> Stefan, I was wondering why your setting of city="B/V" for the
Berlin/Vienna
> tiles in 18EU did prevent one-hex loopback, but not the Berlin-Vienna
route.
> I guess you are doing this check per hex only.  If you could lift that
restriction,
> and look at duplicate city names (or whatever) on all stops of a route, I
think
> we would have a strong mechanism to achieve all kinds of train access
> limitations.
> 
> Configuring stop properties is done with the <Access> XML tag, as follows
> 	<Access station="1" type="city" runTo="yes" runThrough="no"
> score="minor" trainMutexID="X"/>
> where all attributes are optional (and in this example all or most are
> redundant anyway).
> The <Access> tag can be put inside <Tile>, <Hex> or in the <Defaults>
> sections of Map.xml and TiIeSet.xml. Multiple occurrences are allowed.
> 
> I have added stop types like "port", "mine", "halt", "pass", just in case.
> For instance, in 18EU I can now declare the port properties in Map.xml:
> <Defaults>
> 	<Access type="port" score="minor"/>
> </Defaults>
> 
> If only a stop type needs be declared, a shortcut is possible by putting
its
> definition inside the <Tile> or <Hex> tags.
> So, for the 18EU port of Amsterdam, we could have
> 	<Hex name="A4" value="10" tile="-800" orientation="0">
> 		<Access type="port"/>
> 	</Hex>
> but this can be merged to
> 	<Hex name="A4" type="port" value="10" tile="-800"
> orientation="0"/> BTW 'type="port"' has replaced the (completely unused)
> 'port="yes"' in 18EU/Map.xml.
> 
> Whether or not this all will turn out to be useful remains an open
question,
> because Stefan appears to have implemented some restrictions in ways that
> may not directly correlate with this framework.  So, to make it work, some
> bridge must be built somewhere.  I am also open to add <Access> attributes
> that would directly call Stefan's classes, as I understand he has
suggested,
> provided that the new attribute names are a bit user-friendly.  I am
thinking
> of attributes like accessModifier and/or revenueModifier.  The latter may
be
> needed anyway.
> 
> Comments welcome.  No hurry.
> 
> Erik.
> 
> 
> 
> 
> 
> 
>
----------------------------------------------------------------------------
--
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware
threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Stop properties framework

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

Stefan,

I remember that a while ago you had already sent some comments on my below
proposal, and at that time I was working on a further response when I got
distracted and the whole issue fell by the wayside. I'll have to revisit all
of it, which I hopefully can do later this week (fortunately - for this
project - the weather is seriously worsening over here :-)).  

Indeed I think it's best to finish my work in about its current state,
taking into account whichever of your comments appeal to me, and commit the
whole thing so that we have a clear base to work from.

On the 9 levels: obviously we'll never use all of them together. However, I
think all or most of these levels will find a good use in some context, and
in any case it turned out to be very easy to provide all that flexibility.
But let's continue discussing the fine details later.

Erik

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Monday, September 10, 2012 7:33 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Stop properties framework
> 
> Erik:
> it seems to me that this got never pushed to the Rails1.x track.
> Maybe you could either push that to master or send me as a patch, so that
I
> can add it to Rails2.0?
> 
> As stated in the previous mail, I have refactored the MapHex and Stop
> classes a little bit to make them undo-proof, but there are still the
Access
> attributes to be handled.
> 
> I agree that a separate Access-Class is a great improvement, maybe I do
not
> agree on having 9 levels of configuration, as I prefer to have the
defaults set
> either in TileManager or MapManager, but not allow to set them both
> (preferably the former). And it will get confusing if e.g. one sets
defaults in
> both.
> 
> And I suggest to remove the Station types: Having a hard-coded "OffMap"
> and a xml-defined "offmap" is not a good solution. However most of the
> usages for the Station types is inside the algorithm code, thus it is my
duty to
> fix that.
> 
> Thanks,
> Stefan
> 
> On 06/01/2012 12:25 AM, Erik Vos wrote:
> > Stefan (and possibly others),
> >
> > Sorry, this is long.  I intend to put an even longer version in the
> > Wiki later on.
> >
> > I'm happy to report that I have made quite some progress with the new
> > Stop properties framework, that was discussed a while ago.
> > It's almost ready to be pushed, but I would first like to present its
> > main aspects and reopen it for discussion.  I would like to publish it
> > as a whole.
> >
> > This framework is intended to provide maximum flexibility in stop
> > property configuration, on many levels. It is also intended to address
> > the following requirements and bugs:
> > - 1837: the need to assign different types to different stops with
> > different properties on one mine tile.
> > - 1835: the Berlin loop bug, also relevant to 18EU.  As discussed,
> > Stefan's existing method is not maintainable.
> > - 1837 (and other games): the requirement that certain trains may only
> > access one stop of a given type (i.e. mine).
> >
> > Please note, that this framework only addresses the problems mentioned
> > (and several others) in *configuring* such properties.  Currently,
> > just one of these properties is being used by Stefan's route and
> > revenue calculation code, so there is a lot more work to do to bridge
> > our two worlds.  See the end of this message for more remarks on this
> aspect.
> >
> > The stop properties are now collected in a new class named Access.
> > The properties are unchanged from the previous situation, except that
> > one new property has been added:
> >
> > - stopType (city, town, port, mine, pass etc.). The list of values is
> > hardcoded, but easily extendable if needed.
> >
> > - runTo (can a train run to a certain station?).  Still unused.  It is
> > intended to configure initial access restrictions like those of 1851
> > Birmingham and 1835 Elsass-Lothringen.
> >
> > - runThrough (can a train run through a certain station?). Still unused.
> > Probably useful for off-map areas, Goderich and other cases.
> >
> > - loop (can a train re-enter a hex visited before?). Still unused, and
> > perhaps redundant.  It was intended to prevent the Paris/Berlin/Vienna
> > loop problems in 18EU and 1835, but that issue can be equally well
> > addressed by the trainMutexID, to be discussed below. 'loop' may still
> > prove useful for 1860, where no train may re-enter ANY hex.
> >
> > - score type: major or minor (e.g. for 1835 n+m trains and for the
> > many games where towns do not count against the train size).  This is
> > the only stop property already in use.  The new framework allows more
> > fine-grained configuration.
> >
> > - trainMutexID (provisional name).  The value can be any string.  This
> > stop property is new, and intends to replace the 'city name' that
> > Stefan currently is using to prevent the Berlin (etc.) loops.  As
> > discussed earlier, that solution is not well sustainable. Another
> > potential use of trainMutexID is to address the rule in 1837 and 18VA
> > that goods trains may hit only one mine station each.
> >
> > In principle, all stop properties can be defined per hex, per tile,
> > per station, per stop type, or even globally, but several (pretty
> > obvious) exceptions exist.
> > The configuration levels are, in order of precedence:
> >
> >   1. Specific MapHex station (defined in Map.xml with 'station' value >
0).
> >   2. Specific Tile station (defined in TileSet.xml with 'station' value
> 0).
> > For preprinted tiles (id<=0) only.
> >   3. MapHex (defined in Map.xml with 'station' value absent or 0).
> >   4. Tile (defined in TileSet.xml with 'station' value absent or 0).
> > For preprinted tiles (id<=0) only.
> >   5. MapManager default per stop type (defined as default in Map.xml).
> >   6. TileManager default per stop type (defined as default in
TileSet.xml).
> >   7. MapManager general default (defined in Map.xml).
> >   8. TileManager general default (defined in TileSet.xml).
> >   9. Generic default per stop-type (hardcoded).
> >
> > Any property still undefined on a certain level "falls through" to the
> > next level.  It's probably preferable to define properties per hex
> > rather than per tile, but (at least for preprinted tiles) both are
possible.
> >
> > Both property parsing and the precedence "fall-through" mechanism are
> > methods of class Access.  This refactoring has allowed to clean up
> > some repetitive code in various classes.
> >
> > Comments per property:
> >
> > - stop type can only be defined on levels 1-4, as it is required
> > further down. If still undefined after level 4, it is derived from the
> > tile Station type.
> > - runTo and runThrough: levels 1-8.
> > - scoreType and trainMutexID: levels 1-6.
> >
> > I could only test the fall-through mechanism with scoreType, as that
> > is the only item currently used by Stefan's code.  Testing was easy,
> > by setting conflicting score type values ('major' and 'minor') on
> > different levels for ports and villages in 18EU, and watching the
displayed
> train routes.
> >
> > I have also tested trainMutexId, after (temporarily) changing lines
> > 257 and
> > 258 in NetworkVertex to call city.getTrainMutexID() instead of
> > station.getCityName().
> > This way, I could switch the Berlin loop allowance on and off.
> >
> > Stefan, I was wondering why your setting of city="B/V" for the
> > Berlin/Vienna tiles in 18EU did prevent one-hex loopback, but not the
> Berlin-Vienna route.
> > I guess you are doing this check per hex only.  If you could lift that
> > restriction, and look at duplicate city names (or whatever) on all
> > stops of a route, I think we would have a strong mechanism to achieve
> > all kinds of train access limitations.
> >
> > Configuring stop properties is done with the <Access> XML tag, as
follows
> > 	<Access station="1" type="city" runTo="yes" runThrough="no"
> > score="minor" trainMutexID="X"/>
> > where all attributes are optional (and in this example all or most are
> > redundant anyway).
> > The <Access> tag can be put inside <Tile>, <Hex> or in the <Defaults>
> > sections of Map.xml and TiIeSet.xml. Multiple occurrences are allowed.
> >
> > I have added stop types like "port", "mine", "halt", "pass", just in
case.
> > For instance, in 18EU I can now declare the port properties in Map.xml:
> > <Defaults>
> > 	<Access type="port" score="minor"/>
> > </Defaults>
> >
> > If only a stop type needs be declared, a shortcut is possible by
> > putting its definition inside the <Tile> or <Hex> tags.
> > So, for the 18EU port of Amsterdam, we could have
> > 	<Hex name="A4" value="10" tile="-800" orientation="0">
> > 		<Access type="port"/>
> > 	</Hex>
> > but this can be merged to
> > 	<Hex name="A4" type="port" value="10" tile="-800"
> orientation="0"/>
> > BTW 'type="port"' has replaced the (completely unused) 'port="yes"' in
> > 18EU/Map.xml.
> >
> > Whether or not this all will turn out to be useful remains an open
> > question, because Stefan appears to have implemented some restrictions
> > in ways that may not directly correlate with this framework.  So, to
> > make it work, some bridge must be built somewhere.  I am also open to
> > add <Access> attributes that would directly call Stefan's classes, as
> > I understand he has suggested, provided that the new attribute names
> > are a bit user-friendly.  I am thinking of attributes like
> > accessModifier and/or revenueModifier.  The latter may be needed
> anyway.
> >
> > Comments welcome.  No hurry.
> >
> > Erik.
> >
> >
> >
> >
> >
> >
> > ----------------------------------------------------------------------
> > --------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond.
> > Discussions will include endpoint security, mobile security and the
> > latest in malware threats.
> > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> 
> 
>
----------------------------------------------------------------------------
--
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware
threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] I have forced buy train issues in 1830

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

The Coalfield rules do not define how to handle that case, but I assume 
that the only reasonable assumption is that trains in the bank pool 
which obsolete, get rusted immediately.

All other possible solutions raise even more follow-up questions (when 
to rust, is it possible to still buy them etc).

18AL rules (in 4.2.5.1) clearly states that obsolete trains get removed 
immediately and cannot be traded between companies.

That should be easy to fix, if all agree to use this approach for 1830 
coalfields too.
Stefan


On 09/10/2012 09:23 AM, Dr....@t-... wrote:
> Hi Arne,
>
> what has me wondering, why are the obsolete trains removed after the
> next run ?
>
> Since the trains in the bank pool dont run they dont get removed....
> Thats definately a bug in the logic.
>
> Regards,
>
> Martin
>
> *Von:* Arne Östlund <ar...@gl...>
> *An:* <rai...@li...>
> *Betreff:* Re: [Rails-devel] I have forced buy train issues in 1830
> *Datum:* Mon, 10 Sep 2012 05:08:57 +0200
>
> I am forced to buy a train with Erie. The problem is that som rusted
> trains still are in the train pool. I want to buy the T7 but am forced
> to buy a T3. Rediculous. I play with Rails 1.7.8.
> /Arne
>
> On Sat, 08 Sep 2012 19:10:55 +0000,
> rai...@li... <javascript:void(0)> wrote:
>  > Send Rails-devel mailing list submissions to
>  > rai...@li... <javascript:void(0)>
>  >
>  > To subscribe or unsubscribe via the World Wide Web, visit
>  > https://lists.sourceforge.net/lists/listinfo/rails-devel
> <?ctl=dereferer&to=aHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vcmFpbHMtZGV2ZWw%3D>
>  > or, via email, send a message with subject or body 'help' to
>  > rai...@li... <javascript:void(0)>
>  >
>  > You can reach the person managing the list at
>  > rai...@li... <javascript:void(0)>
>  >
>  > When replying, please edit your Subject line so it is more specific
>  > than "Re: Contents of Rails-devel digest..."
>  >
>  >
>  > Today's Topics:
>  >
>  > 1. Rails 2.0: Next Status Update (Stefan Frey)
>  > 2. Game report - 1.7.8 - 18EU hangs (John David Galt)
>  >
>  >
>  >
>  > ----------------------------------------------------------------------
>  >
>  > Message: 1
>  > Date: Sat, 08 Sep 2012 10:17:50 +0200
>  > From: Stefan Frey <ste...@we... <javascript:void(0)>>
>  > Subject: [Rails-devel] Rails 2.0: Next Status Update
>  > To: Development list for Rails: an 18xx game
>  > <rai...@li... <javascript:void(0)>>
>  > Message-ID: <504...@we... <javascript:void(0)>>
>  > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>  >
>  > ** Another milestone is reached:
>  > Two of the test games in 1889 (1889_A and 1889_B in test/real) can be
>  > replayed in full and the complete UI comes up without error. Still a
>  > few
>  > rough edges, but all actions get processed.
>  >
>  > In addition there are few tests that are missing in Rails 1.x. All
>  > tests
>  > throw a RuntimeError exception, thus currently Rails2.0 fails fast.
>  >
>  > * If the ChangeStack is closed, no state can be changed.
>  >
>  > * Loaded actions are validated using .equalsAsOption against the
>  > available actions.
>  >
>  > * No item/component with an identical id can be created during the
>  > game
>  > (exception due to undo).
>  >
>  > I will do an alpha release for others to test soon (maybe in one week
>  > or
>  > so), but please do not expect anything exciting (the next milestone
>  > is
>  > to reach the compatibility with and the stability of Rails1.x).
>  >
>  > ** Next steps:
>  > The immediate next step is to merge/adopt all changes of Rails1.x
>  > after
>  > were added after Rails2.0 branched off.
>  >
>  > Completing that I will release beta versions.
>  >
>  > Then I will focus on refactoring the round classes and finalizing
>  > 1825.
>  >
>  > Finishing 1825 will be the trigger to release Rails 2.0.
>  >
>  > ** Rails 1.x
>  > If one considers to add new feature or games, my recommendation is
>  > now
>  > to make those changes for Rails2.0. I understand if others
>  > (especially
>  > Erik) is reluctant to change already, but I cannot guarantee that I
>  > will
>  > adopt changes which will be committed to Rails 1.x
>  > However I will do releases for Rails1.x if there is the need to do
>  > so.
>  >
>  >
>  >
>  >
>  >
>  > ------------------------------
>  >
>  > Message: 2
>  > Date: Sat, 08 Sep 2012 12:10:42 -0700
>  > From: John David Galt <jd...@di...
> <javascript:void(0)>>
>  > Subject: [Rails-devel] Game report - 1.7.8 - 18EU hangs
>  > To: rai...@li... <javascript:void(0)>
>  > Message-ID: <504...@di...
> <javascript:void(0)>>
>  > Content-Type: text/plain; charset="iso-8859-1"
>  >
>  > I recently had my monitor blow up and had to go back to one about 20
>  > years old
>  > with a smaller screen. As a result I've had to twiddle most of the
>  > programs I
>  > use so that they'll display reasonably on the small screen, and Rails
>  > is no
>  > exception. Still, I tried a four player game of 18EU.
>  >
>  > The first thing I notice is that most of the windows are now too tall
>  > for the
>  > monitor to display without scroll bars. The two most annoying cases
>  > are the
>  > Game Status and Map windows.
>  >
>  > The Game Status window insists on re-sizing itself after every single
>  > action
>  > (and that's typically twice per player turn; once after buying a
>  > share, and
>  > again after hitting Done). Even saving the game causes the window to
>  > resize.
>  > And every time it resizes itself it is too tall for the screen, with
>  > the Done
>  > (or Pass) button completely below the screen and (usually) the title
>  > bar part
>  > way above the screen, thus requiring three manual moves per
>  > occurrence (drag
>  > the whole window down by title bar to get to the top edge; then drag
>  > the top
>  > edge down to make the window fit the screen; then drag the whole
>  > window up so
>  > that I can get to the Done or Pass button). I can only add that this
>  > would
>  > not be quite as annoying if the Done or Pass button were within the
>  > area
>  > controlled by the scroll bars, so it could be reached using them,
>  > and/or if
>  > there were a keyboard shortcut for Done or Pass. I would like to
>  > have the
>  > ability to end any action by hitting "D" as I do in Colossus.
>  >
>  > The Map window is not quite as bad, because it only re-sizes itself
>  > at the
>  > beginning of each round. However, its scroll bars control only the
>  > map
>  > proper, so there is no way to resize the company-status lines below
>  > the map.
>  > The result on my screen is that I have to view the map through a
>  > "mail slot"
>  > about two hexes tall, with no way to make it bigger -- and I have to
>  > scroll
>  > that "mail slot" to reach the controls for every single tile or token
>  > laying
>  > action.
>  >
>  > Anyhow: the attached game runs, under those conditions, until the end
>  > of
>  > stock round 3. Then instead of starting the next operating round, it
>  > stays
>  > on the Game Status window, with the Treasury Shares column
>  > highlighted as if
>  > it were the end of a company's turn, and with all controls disabled
>  > except
>  > the Autopass button, which does nothing. So I can't continue.
>  > -------------- next part --------------
>  > A non-text attachment was scrubbed...
>  > Name: 18EU_20120908_1847_OperatingRound 2.1.rails
>  > Type: application/octet-stream
>  > Size: 16988 bytes
>  > Desc: not available
>  >
>  > ------------------------------
>  >
>  >
>  >
> ------------------------------------------------------------------------------
>  > Live Security Virtual Conference
>  > Exclusive live event will cover all the ways today's security and
>  > threat landscape has changed and how IT managers can respond.
>  > Discussions
>  > will include endpoint security, mobile security and the latest in
>  > malware
>  > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> <?ctl=dereferer&to=aHR0cDovL3d3dy5hY2NlbGFjb21tLmNvbS9qYXcvc2ZybmwwNDI0MjAxMi8xMTQvNTAxMjIyNjMv>
>  >
>  > ------------------------------
>  >
>  > _______________________________________________
>  > Rails-devel mailing list
>  > Rai...@li... <javascript:void(0)>
>  > https://lists.sourceforge.net/lists/listinfo/rails-devel
> <?ctl=dereferer&to=aHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vcmFpbHMtZGV2ZWw%3D>
>  >
>  >
>  > End of Rails-devel Digest, Vol 58, Issue 5
>  > ******************************************
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] I have forced buy train issues in 1830

[<Dr....@t-...>]

Hi Arne, 

	what has me wondering, why are the obsolete trains removed after the
next run ? 

	Since the trains in the bank pool dont run they dont get removed....
Thats definately a bug in the logic.  

	Regards, 

	Martin

	  Von: Arne Östlund <ar...@gl...>
 An: <rai...@li...>
 Betreff: Re: [Rails-devel] I have forced buy train issues in 1830
 Datum: Mon, 10 Sep 2012 05:08:57 +0200

 I am forced to buy a train with Erie. The problem is that som rusted 
 trains still are in the train pool. I want to buy the T7 but am
forced 
 to buy a T3. Rediculous. I play with Rails 1.7.8.
 /Arne

 On Sat, 08 Sep 2012 19:10:55 +0000, 
 rai...@li... [1] wrote:
 > Send Rails-devel mailing list submissions to
 >  rai...@li... [2]
 >
 > To subscribe or unsubscribe via the World Wide Web, visit
 >  https://lists.sourceforge.net/lists/listinfo/rails-devel [3]
 > or, via email, send a message with subject or body 'help' to
 >  rai...@li... [4]
 >
 > You can reach the person managing the list at
 >  rai...@li... [5]
 >
 > When replying, please edit your Subject line so it is more specific
 > than "Re: Contents of Rails-devel digest..."
 >
 >
 > Today's Topics:
 >
 >    1. Rails 2.0: Next Status Update (Stefan Frey)
 >    2. Game report - 1.7.8 - 18EU hangs (John David Galt)
 >
 >
 > 
 >
----------------------------------------------------------------------
 >
 > Message: 1
 > Date: Sat, 08 Sep 2012 10:17:50 +0200
 > From: Stefan Frey <ste...@we... [6]>
 > Subject: [Rails-devel] Rails 2.0: Next Status Update
 > To: Development list for Rails: an 18xx game
 >  <rai...@li... [7]>
 > Message-ID: <504...@we... [8]>
 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 >
 > ** Another milestone is reached:
 > Two of the test games in 1889 (1889_A and 1889_B in test/real) can
be
 > replayed in full and the complete UI comes up without error. Still
a 
 > few
 > rough edges, but all actions get processed.
 >
 > In addition there are few tests that are missing in Rails 1.x. All 
 > tests
 > throw a RuntimeError exception, thus currently Rails2.0 fails fast.
 >
 > * If the ChangeStack is closed, no state can be changed.
 >
 > * Loaded actions are validated using .equalsAsOption against the
 > available actions.
 >
 > * No item/component with an identical id can be created during the 
 > game
 > (exception due to undo).
 >
 > I will do an alpha release for others to test soon (maybe in one
week 
 > or
 > so), but please do not expect anything exciting (the next milestone

 > is
 > to reach the compatibility with and the stability of Rails1.x).
 >
 > ** Next steps:
 > The immediate next step is to merge/adopt all changes of Rails1.x 
 > after
 > were added after Rails2.0 branched off.
 >
 > Completing that I will release beta versions.
 >
 > Then I will focus on refactoring the round classes and finalizing 
 > 1825.
 >
 > Finishing 1825 will be the trigger to release Rails 2.0.
 >
 > ** Rails 1.x
 > If one considers to add new feature or games, my recommendation is 
 > now
 > to make those changes for Rails2.0. I understand if others 
 > (especially
 > Erik) is reluctant to change already, but I cannot guarantee that I

 > will
 > adopt changes which will be committed to Rails 1.x
 > However I will do releases for Rails1.x if there is the need to do 
 > so.
 >
 >
 >
 >
 >
 > ------------------------------
 >
 > Message: 2
 > Date: Sat, 08 Sep 2012 12:10:42 -0700
 > From: John David Galt <jd...@di... [9]>
 > Subject: [Rails-devel] Game report - 1.7.8 - 18EU hangs
 > To: rai...@li... [10]
 > Message-ID: <504...@di... [11]>
 > Content-Type: text/plain; charset="iso-8859-1"
 >
 > I recently had my monitor blow up and had to go back to one about
20
 > years old
 > with a smaller screen.  As a result I've had to twiddle most of the
 > programs I
 > use so that they'll display reasonably on the small screen, and
Rails 
 > is no
 > exception.  Still, I tried a four player game of 18EU.
 >
 > The first thing I notice is that most of the windows are now too
tall 
 > for the
 > monitor to display without scroll bars.  The two most annoying
cases 
 > are the
 > Game Status and Map windows.
 >
 > The Game Status window insists on re-sizing itself after every
single 
 > action
 > (and that's typically twice per player turn; once after buying a 
 > share, and
 > again after hitting Done).  Even saving the game causes the window
to 
 > resize.
 > And every time it resizes itself it is too tall for the screen,
with 
 > the Done
 > (or Pass) button completely below the screen and (usually) the
title 
 > bar part
 > way above the screen, thus requiring three manual moves per 
 > occurrence (drag
 > the whole window down by title bar to get to the top edge; then
drag 
 > the top
 > edge down to make the window fit the screen; then drag the whole 
 > window up so
 > that I can get to the Done or Pass button).  I can only add that
this 
 > would
 > not be quite as annoying if the Done or Pass button were within the

 > area
 > controlled by the scroll bars, so it could be reached using them, 
 > and/or if
 > there were a keyboard shortcut for Done or Pass.  I would like to 
 > have the
 > ability to end any action by hitting "D" as I do in Colossus.
 >
 > The Map window is not quite as bad, because it only re-sizes itself

 > at the
 > beginning of each round.  However, its scroll bars control only the

 > map
 > proper, so there is no way to resize the company-status lines below

 > the map.
 > The result on my screen is that I have to view the map through a 
 > "mail slot"
 > about two hexes tall, with no way to make it bigger -- and I have
to 
 > scroll
 > that "mail slot" to reach the controls for every single tile or
token 
 > laying
 > action.
 >
 > Anyhow: the attached game runs, under those conditions, until the
end 
 > of
 > stock round 3.  Then instead of starting the next operating round,
it 
 > stays
 > on the Game Status window, with the Treasury Shares column 
 > highlighted as if
 > it were the end of a company's turn, and with all controls disabled

 > except
 > the Autopass button, which does nothing.  So I can't continue.
 > -------------- next part --------------
 > A non-text attachment was scrubbed...
 > Name: 18EU_20120908_1847_OperatingRound 2.1.rails
 > Type: application/octet-stream
 > Size: 16988 bytes
 > Desc: not available
 >
 > ------------------------------
 >
 > 
 >
------------------------------------------------------------------------------
 > Live Security Virtual Conference
 > Exclusive live event will cover all the ways today's security and
 > threat landscape has changed and how IT managers can respond. 
 > Discussions
 > will include endpoint security, mobile security and the latest in 
 > malware
 > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
[12]
 >
 > ------------------------------
 >
 > _______________________________________________
 > Rails-devel mailing list
 > Rai...@li... [13]
 > https://lists.sourceforge.net/lists/listinfo/rails-devel [14]
 >
 >
 > End of Rails-devel Digest, Vol 58, Issue 5
 > ******************************************

Links:
------
[1] javascript:void(0)
[2] javascript:void(0)
[3]
?ctl=dereferer&amp;to=aHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vcmFpbHMtZGV2ZWw%3D
[4] javascript:void(0)
[5] javascript:void(0)
[6] javascript:void(0)
[7] javascript:void(0)
[8] javascript:void(0)
[9] javascript:void(0)
[10] javascript:void(0)
[11] javascript:void(0)
[12]
?ctl=dereferer&amp;to=aHR0cDovL3d3dy5hY2NlbGFjb21tLmNvbS9qYXcvc2ZybmwwNDI0MjAxMi8xMTQvNTAxMjIyNjMv
[13] javascript:void(0)
[14]
?ctl=dereferer&amp;to=aHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vcmFpbHMtZGV2ZWw%3D

Re: [Rails-devel] Stop properties framework

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

Erik:
it seems to me that this got never pushed to the Rails1.x track.
Maybe you could either push that to master or send me as a patch, so 
that I can add it to Rails2.0?

As stated in the previous mail, I have refactored the MapHex and Stop 
classes a little bit to make them undo-proof, but there are still the 
Access attributes to be handled.

I agree that a separate Access-Class is a great improvement, maybe I do 
not agree on having 9 levels of configuration, as I prefer to have the 
defaults set either in TileManager or MapManager, but not allow to set 
them both (preferably the former). And it will get confusing if e.g. one 
sets defaults in both.

And I suggest to remove the Station types: Having a hard-coded "OffMap" 
and a xml-defined "offmap" is not a good solution. However most of the 
usages for the Station types is inside the algorithm code, thus it is my 
duty to fix that.

Thanks,
Stefan

On 06/01/2012 12:25 AM, Erik Vos wrote:
> Stefan (and possibly others),
>
> Sorry, this is long.  I intend to put an even longer version in the Wiki
> later on.
>
> I'm happy to report that I have made quite some progress with the new Stop
> properties framework, that was discussed a while ago.
> It's almost ready to be pushed, but I would first like to present its main
> aspects and reopen it for discussion.  I would like to publish it as a
> whole.
>
> This framework is intended to provide maximum flexibility in stop property
> configuration, on many levels. It is also intended to address the following
> requirements and bugs:
> - 1837: the need to assign different types to different stops with different
> properties on one mine tile.
> - 1835: the Berlin loop bug, also relevant to 18EU.  As discussed, Stefan's
> existing method is not maintainable.
> - 1837 (and other games): the requirement that certain trains may only
> access one stop of a given type (i.e. mine).
>
> Please note, that this framework only addresses the problems mentioned (and
> several others) in *configuring* such properties.  Currently, just one of
> these properties is being used by Stefan's route and revenue calculation
> code, so there is a lot more work to do to bridge our two worlds.  See the
> end of this message for more remarks on this aspect.
>
> The stop properties are now collected in a new class named Access.  The
> properties are unchanged from the previous situation, except that one new
> property has been added:
>
> - stopType (city, town, port, mine, pass etc.). The list of values is
> hardcoded, but easily extendable if needed.
>
> - runTo (can a train run to a certain station?).  Still unused.  It is
> intended to configure initial access restrictions like those of 1851
> Birmingham and 1835 Elsass-Lothringen.
>
> - runThrough (can a train run through a certain station?). Still unused.
> Probably useful for off-map areas, Goderich and other cases.
>
> - loop (can a train re-enter a hex visited before?). Still unused, and
> perhaps redundant.  It was intended to prevent the Paris/Berlin/Vienna loop
> problems in 18EU and 1835, but that issue can be equally well addressed by
> the trainMutexID, to be discussed below. 'loop' may still prove useful for
> 1860, where no train may re-enter ANY hex.
>
> - score type: major or minor (e.g. for 1835 n+m trains and for the many
> games where towns do not count against the train size).  This is the only
> stop property already in use.  The new framework allows more fine-grained
> configuration.
>
> - trainMutexID (provisional name).  The value can be any string.  This stop
> property is new, and intends to replace the 'city name' that Stefan
> currently is using to prevent the Berlin (etc.) loops.  As discussed
> earlier, that solution is not well sustainable. Another potential use of
> trainMutexID is to address the rule in 1837 and 18VA that goods trains may
> hit only one mine station each.
>
> In principle, all stop properties can be defined per hex, per tile, per
> station, per stop type, or even globally, but several (pretty obvious)
> exceptions exist.
> The configuration levels are, in order of precedence:
>
>   1. Specific MapHex station (defined in Map.xml with 'station' value > 0).
>   2. Specific Tile station (defined in TileSet.xml with 'station' value > 0).
> For preprinted tiles (id<=0) only.
>   3. MapHex (defined in Map.xml with 'station' value absent or 0).
>   4. Tile (defined in TileSet.xml with 'station' value absent or 0).  For
> preprinted tiles (id<=0) only.
>   5. MapManager default per stop type (defined as default in Map.xml).
>   6. TileManager default per stop type (defined as default in TileSet.xml).
>   7. MapManager general default (defined in Map.xml).
>   8. TileManager general default (defined in TileSet.xml).
>   9. Generic default per stop-type (hardcoded).
>
> Any property still undefined on a certain level "falls through" to the next
> level.  It's probably preferable to define properties per hex rather than
> per tile, but (at least for preprinted tiles) both are possible.
>
> Both property parsing and the precedence "fall-through" mechanism are
> methods of class Access.  This refactoring has allowed to clean up some
> repetitive code in various classes.
>
> Comments per property:
>
> - stop type can only be defined on levels 1-4, as it is required further
> down. If still undefined after level 4, it is derived from the tile Station
> type.
> - runTo and runThrough: levels 1-8.
> - scoreType and trainMutexID: levels 1-6.
>
> I could only test the fall-through mechanism with scoreType, as that is the
> only item currently used by Stefan's code.  Testing was easy, by setting
> conflicting score type values ('major' and 'minor') on different levels for
> ports and villages in 18EU, and watching the displayed train routes.
>
> I have also tested trainMutexId, after (temporarily) changing lines 257 and
> 258 in NetworkVertex to call city.getTrainMutexID() instead of
> station.getCityName().
> This way, I could switch the Berlin loop allowance on and off.
>
> Stefan, I was wondering why your setting of city="B/V" for the Berlin/Vienna
> tiles in 18EU did prevent one-hex loopback, but not the Berlin-Vienna route.
> I guess you are doing this check per hex only.  If you could lift that
> restriction, and look at duplicate city names (or whatever) on all stops of
> a route, I think we would have a strong mechanism to achieve all kinds of
> train access limitations.
>
> Configuring stop properties is done with the <Access> XML tag, as follows
> 	<Access station="1" type="city" runTo="yes" runThrough="no"
> score="minor" trainMutexID="X"/>
> where all attributes are optional (and in this example all or most are
> redundant anyway).
> The <Access> tag can be put inside <Tile>, <Hex> or in the <Defaults>
> sections of Map.xml and TiIeSet.xml. Multiple occurrences are allowed.
>
> I have added stop types like "port", "mine", "halt", "pass", just in case.
> For instance, in 18EU I can now declare the port properties in Map.xml:
> <Defaults>
> 	<Access type="port" score="minor"/>
> </Defaults>
>
> If only a stop type needs be declared, a shortcut is possible by putting its
> definition inside the <Tile> or <Hex> tags.
> So, for the 18EU port of Amsterdam, we could have
> 	<Hex name="A4" value="10" tile="-800" orientation="0">
> 		<Access type="port"/>
> 	</Hex>
> but this can be merged to
> 	<Hex name="A4" type="port" value="10" tile="-800" orientation="0"/>
> BTW 'type="port"' has replaced the (completely unused) 'port="yes"' in
> 18EU/Map.xml.
>
> Whether or not this all will turn out to be useful remains an open question,
> because Stefan appears to have implemented some restrictions in ways that
> may not directly correlate with this framework.  So, to make it work, some
> bridge must be built somewhere.  I am also open to add <Access> attributes
> that would directly call Stefan's classes, as I understand he has suggested,
> provided that the new attribute names are a bit user-friendly.  I am
> thinking of attributes like accessModifier and/or revenueModifier.  The
> latter may be needed anyway.
>
> Comments welcome.  No hurry.
>
> Erik.
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] HomeCityNumber (city attribute)

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

Erik:
thanks for your reply. Unfortunately I cannot spare you the questions, 
as the TileMove is the last of the old Move-Classes to replace by the 
standard undo mechanism. And this involves looking into the 
MapHex/Station/Stop/Tile classes.

First sorry that I was partly wrong in my initial mail:

The station number is in fact derived from the id-tag in Tiles.xml, and 
not from the position-number, double-checked that again: It is true that 
the city attribute of the home tag of a company refers to the station 
number and the station number is the integer after "city" in the 
id-attribute:

Example:

<Tile colour="brown" id="66" name="66">
		<Station id="city1" position="002" slots="1" type="City" value="50"/>
		<Station id="city2" position="452" slots="1" type="City" value="50"/>
	
However the whole mechanism was not undo-proof:

In MapHex:
Both the list stops and the map mStops were not realized with state 
variables. Most likely they were still protected by the Tile-Move, but I 
have not double-checked this.

In Stop:
The related station itself is a GenericState. But all other variables 
(like slots, trackEdges and the access Attributes) are initialized once 
after the station changes. This is not undo proof, and this implies e.g. 
that the number of slots is not protected.

I have removed the duplication of stops and mStops in MapHex and made 
the attributes in stop undo-proof (or simply replaced a local variable 
by a call to the station attribute).
The access attributes have still to be fixed, but this relates to the 
next mail.

Stefan


On 09/05/2012 03:31 PM, Erik Vos wrote:
> Hi Stefan,
>
> The HexMap stop (city) number is a separate entity from the tile city
> number.
> Initially, it is derived from the city numbers of the first tile laid, or
> the preprinted tile if it already has tracks.
> When tiles are upgraded, the HexMap city numbers normally do not change; the
> HexMap stops become related to the new tile cities, in a way that existing
> tracks remain connected to a HexMap stop with the same number.
> This means, that after an upgrade the HexMap city numbers may become
> different from the current tile city numbers. The current tile city numbers
> have no meaning for game play.
>
> If the old tile had no tracks, there is nothing to preserve, so the new tile
> city numbers are just copied. Any home token stops on such tiles have city
> number 0, which indicates that these must be assigned manually as soon as a
> tile with some track is laid (Erie, THB, Badische).
>
> If during an upgrade the number of stops on a tile changes, HexMap stop
> numbers are reassigned, although (I believe) it is attempted to retain the
> old numbers where possible.
>
> This all is complex stuff indeed. It took me a lot of time and false starts
> to get this reasonably working, and it is quite possible that cases exist
> that do not work out well.
>
> Erik.
>
>> -----Original Message-----
>> From: Stefan Frey [mailto:ste...@we...]
>> Sent: Wednesday, September 05, 2012 1:57 PM
>> To: Development list for Rails: an 18xx game
>> Subject: [Rails-devel] HomeCityNumber (city attribute)
>>
>> Erik,
>> is it intentional that the HomeCityNumber refers to the position inside
> the list
>> of Stops of HexMap?
>>
>> I refer to the following code in method layHome of mapHex:
>>
>>                   Stop homeCity = stops.get(Math.max(stopNumber - 1, 0));
>>                   homes.put(company, homeCity);
>>
>> I thought that mStops.get(...) instead of stops.get(...) would have been
> the
>> more logical choice as mStops maps the stations/stops ids to the objects.
>>
>> Usually if Rails refer to Stations it is the number defined by position on
> the
>> tile and not the order number.
>>
>> This caught me by surprise yesterday and took quite some time to track
>> down.
>>
>> This has a strong influence on the definition of the city attribute of the
> Home
>> tag: Instead of the specification of the station position, it refers to
> the
>> ordering of stations inside the Tile definition.
>> However in the full loop it makes some sense, as in the Tile definition
> the
>> stations have ids, that are identical with the ordering of the
> definitions.
>>
>> But those ids are not used to set up the station numbers, those are based
> on
>> the position on the tile.
>>
>> As you are the expert of Tile and Map definitions, I want to ask you for
> your
>> opinion: Is there more behind it or is it something we should fix in the
> longer
>> run at least (and could add some comments in the code/configuration for
> this
>> behavior)?
>>
>> Stefan
>>
>>
> ----------------------------------------------------------------------------
> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and threat
>> landscape has changed and how IT managers can respond. Discussions will
>> include endpoint security, mobile security and the latest in malware
> threats.
>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] I have forced buy train issues in 1830

[Arne Ö. <ar...@gl...>]

 I am forced to buy a train with Erie. The problem is that som rusted 
 trains still are in the train pool. I want to buy the T7 but am forced 
 to buy a T3. Rediculous. I play with Rails 1.7.8.
 /Arne

 On Sat, 08 Sep 2012 19:10:55 +0000, 
 rai...@li... wrote:
> Send Rails-devel mailing list submissions to
> 	rai...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.sourceforge.net/lists/listinfo/rails-devel
> or, via email, send a message with subject or body 'help' to
> 	rai...@li...
>
> You can reach the person managing the list at
> 	rai...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Rails-devel digest..."
>
>
> Today's Topics:
>
>    1. Rails 2.0: Next Status Update (Stefan Frey)
>    2. Game report - 1.7.8 - 18EU hangs (John David Galt)
>
>
> 
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 08 Sep 2012 10:17:50 +0200
> From: Stefan Frey <ste...@we...>
> Subject: [Rails-devel] Rails 2.0: Next Status Update
> To: Development list for Rails: an 18xx game
> 	<rai...@li...>
> Message-ID: <504...@we...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> ** Another milestone is reached:
> Two of the test games in 1889 (1889_A and 1889_B in test/real) can be
> replayed in full and the complete UI comes up without error. Still a 
> few
> rough edges, but all actions get processed.
>
> In addition there are few tests that are missing in Rails 1.x. All 
> tests
> throw a RuntimeError exception, thus currently Rails2.0 fails fast.
>
> * If the ChangeStack is closed, no state can be changed.
>
> * Loaded actions are validated using .equalsAsOption against the
> available actions.
>
> * No item/component with an identical id can be created during the 
> game
> (exception due to undo).
>
> I will do an alpha release for others to test soon (maybe in one week 
> or
> so), but please do not expect anything exciting (the next milestone 
> is
> to reach the compatibility with and the stability of Rails1.x).
>
> ** Next steps:
> The immediate next step is to merge/adopt all changes of Rails1.x 
> after
> were added after Rails2.0 branched off.
>
> Completing that I will release beta versions.
>
> Then I will focus on refactoring the round classes and finalizing 
> 1825.
>
> Finishing 1825 will be the trigger to release Rails 2.0.
>
> ** Rails 1.x
> If one considers to add new feature or games, my recommendation is 
> now
> to make those changes for Rails2.0. I understand if others 
> (especially
> Erik) is reluctant to change already, but I cannot guarantee that I 
> will
> adopt changes which will be committed to Rails 1.x
> However I will do releases for Rails1.x if there is the need to do 
> so.
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 08 Sep 2012 12:10:42 -0700
> From: John David Galt <jd...@di...>
> Subject: [Rails-devel] Game report - 1.7.8 - 18EU hangs
> To: rai...@li...
> Message-ID: <504...@di...>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I recently had my monitor blow up and had to go back to one about 20
> years old
> with a smaller screen.  As a result I've had to twiddle most of the
> programs I
> use so that they'll display reasonably on the small screen, and Rails 
> is no
> exception.  Still, I tried a four player game of 18EU.
>
> The first thing I notice is that most of the windows are now too tall 
> for the
> monitor to display without scroll bars.  The two most annoying cases 
> are the
> Game Status and Map windows.
>
> The Game Status window insists on re-sizing itself after every single 
> action
> (and that's typically twice per player turn; once after buying a 
> share, and
> again after hitting Done).  Even saving the game causes the window to 
> resize.
> And every time it resizes itself it is too tall for the screen, with 
> the Done
> (or Pass) button completely below the screen and (usually) the title 
> bar part
> way above the screen, thus requiring three manual moves per 
> occurrence (drag
> the whole window down by title bar to get to the top edge; then drag 
> the top
> edge down to make the window fit the screen; then drag the whole 
> window up so
> that I can get to the Done or Pass button).  I can only add that this 
> would
> not be quite as annoying if the Done or Pass button were within the 
> area
> controlled by the scroll bars, so it could be reached using them, 
> and/or if
> there were a keyboard shortcut for Done or Pass.  I would like to 
> have the
> ability to end any action by hitting "D" as I do in Colossus.
>
> The Map window is not quite as bad, because it only re-sizes itself 
> at the
> beginning of each round.  However, its scroll bars control only the 
> map
> proper, so there is no way to resize the company-status lines below 
> the map.
> The result on my screen is that I have to view the map through a 
> "mail slot"
> about two hexes tall, with no way to make it bigger -- and I have to 
> scroll
> that "mail slot" to reach the controls for every single tile or token 
> laying
> action.
>
> Anyhow: the attached game runs, under those conditions, until the end 
> of
> stock round 3.  Then instead of starting the next operating round, it 
> stays
> on the Game Status window, with the Treasury Shares column 
> highlighted as if
> it were the end of a company's turn, and with all controls disabled 
> except
> the Autopass button, which does nothing.  So I can't continue.
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: 18EU_20120908_1847_OperatingRound 2.1.rails
> Type: application/octet-stream
> Size: 16988 bytes
> Desc: not available
>
> ------------------------------
>
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. 
> Discussions
> will include endpoint security, mobile security and the latest in 
> malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
> ------------------------------
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> End of Rails-devel Digest, Vol 58, Issue 5
> ******************************************

Re: [Rails-devel] Game report - 1.7.8 - 18EU hangs

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

On 2012-09-08 23:26, Stefan Frey wrote:
> Starting place for Game Report:
> Do you refer to the window position on the screen or the position of the 
> report inside the report window. The latter is wrong at startup of the 
> game, as it does not scroll to the bottom. I am under the impression 
> this did work in the past. Will have to check that.

I'm referring to the position of the window on the screen.  I am assuming that
the content in the window is always upper left justified, with scrollbars if
needed.

> If it is the former: All window positions/sizes are saved automatically 
> after closing of Rails. I do not know what happens during the game at 
> resizes (does it resize to the latest saved position or does it resize 
> to the current status?)

It seems to use the saved positions (even for a later playing of the same game)
even though some of them are now off screen.  It would be nice to have a "reset"
ability, at least in configuration, but preferably usable in mid-game too.

> For me the major annoyance is that windows that are on the second 
> monitor if I start Rails dual-heads. Next time I start up with only one 
> monitor, some windows will be completely hidden (as they are located 
> off-screen).

I've never tried dual monitors on a Windows system.

> So two possible remedies:
> A) Provide an option to reset the window positions to some robust defaults).

Yes.  (The existing "cascade windows" option seems to work for all except the
Report window.)

> B) Check if a window is located on an invisible position and then move 
> that window back to the default (at least at startup).

Auto-detecting this would be nice but probably not strictly necessary, unless
the off-screen window is going to start causing exceptions to be thrown.

Re: [Rails-devel] Game report - 1.7.8 - 18EU hangs

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

 > What can I set in the Configuration?  If there were options to reduce 
the> font size and to change the starting place for Game Report, the 
problems
 > would go away.
 >

Try: Configuration => Tab Fonts => Font scaling to change the Font size 
of the UI elements.

Starting place for Game Report:
Do you refer to the window position on the screen or the position of the 
report inside the report window. The latter is wrong at startup of the 
game, as it does not scroll to the bottom. I am under the impression 
this did work in the past. Will have to check that.

If it is the former: All window positions/sizes are saved automatically 
after closing of Rails. I do not know what happens during the game at 
resizes (does it resize to the latest saved position or does it resize 
to the current status?)

For me the major annoyance is that windows that are on the second 
monitor if I start Rails dual-heads. Next time I start up with only one 
monitor, some windows will be completely hidden (as they are located 
off-screen).

So two possible remedies:
A) Provide an option to reset the window positions to some robust defaults).
B) Check if a window is located on an invisible position and then move 
that window back to the default (at least at startup).

For future development of the UI:
Unfortunately Frederick who did the latest improvements of the Swing UI 
is not active anymore.

There are several issues to fix there, but similar to the core engine, 
it would make sense to refactor the UI to some degree before changing 
their behavior and/or adding more functionality.

In the mean time a good start is to agree on what are the bad/good 
issues and make a priority list of potential enhancements.

Stefan

Re: [Rails-devel] Game report - 1.7.8 - 18EU hangs

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

On 2012-09-08 17:05, Mike Bourke wrote:
> It sounds to me like the game 'freeze' is another case of the user interface
> problems stemming from the small screen size - he is simply unable to find
> the correct control to move the game on from wherever it is freezing. Just a
> suspicion, though - it's possible that the small screen is causing some
> positional element in the display to return an invalid location. That would
> probably point to a bug not in the game but in the OS environment - a java
> bug, or a bug in the compiler or wherever.

At the time it happened, the only windows on the screen were Game Status and
Stock Chart.  The others were minimized.  (Game Report still wants to display
at its old bottom right location, which is completely off the screen now; the
only way I found to get it back was to right-click the icon in the Windows
taskbar and select Maximize.)

> We tend to think of the support infrastructure as being perfect and
> infallible relative to our own software, but sometimes its not, and we can
> spend a lot of time assuming that the software we've written is the cause of
> a bug. When there is a breakdown of the software environment, it can be the
> last place we think to look, and sometimes it should be higher up the list.
> 
> If there IS a bug beyond the user interface problems, that would seem the
> place to look.

What can I set in the Configuration?  If there were options to reduce the
font size and to change the starting place for Game Report, the problems
would go away.

Re: [Rails-devel] Game report - 1.7.8 - 18EU hangs

[Mike B. <com...@ip...>]

It sounds to me like the game 'freeze' is another case of the user interface
problems stemming from the small screen size - he is simply unable to find
the correct control to move the game on from wherever it is freezing. Just a
suspicion, though - it's possible that the small screen is causing some
positional element in the display to return an invalid location. That would
probably point to a bug not in the game but in the OS environment - a java
bug, or a bug in the compiler or wherever.

We tend to think of the support infrastructure as being perfect and
infallible relative to our own software, but sometimes its not, and we can
spend a lot of time assuming that the software we've written is the cause of
a bug. When there is a breakdown of the software environment, it can be the
last place we think to look, and sometimes it should be higher up the list.

If there IS a bug beyond the user interface problems, that would seem the
place to look.

Mike Bourke
Campaign Mastery http://www.campaignmastery.com
Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com



---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 120908-0, 08/09/2012
Tested on: 9/09/2012 10:05:15 AM
avast! - copyright (c) 1988-2012 AVAST Software.
http://www.avast.com

Re: [Rails-devel] Game report - 1.7.8 - 18EU hangs

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

On 2012-09-08 14:34, Erik Vos wrote:
> I can find no problem with your attached file, it runs fine and finishes
> with a normal start of OR 2.1.
> The behaviour you describe is typical for an uncatched exception - is
> anything displayed on the console?

No.  What's in the Game Report window is it.

Re: [Rails-devel] Game report - 1.7.8 - 18EU hangs

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

I can find no problem with your attached file, it runs fine and finishes
with a normal start of OR 2.1.
The behaviour you describe is typical for an uncatched exception - is
anything displayed on the console?

On your UI-related remarks: the interplay between cell resizing and
scrolling in Java Swing is an esoteric matter, at least to me - hopefully
someone out there has a better grasp on it than I do.

Erik.

> -----Original Message-----
> From: John David Galt [mailto:jd...@di...]
> Sent: Saturday, September 08, 2012 9:11 PM
> To: rai...@li...
> Subject: [Rails-devel] Game report - 1.7.8 - 18EU hangs
> 
> I recently had my monitor blow up and had to go back to one about 20 years
> old with a smaller screen.  As a result I've had to twiddle most of the
> programs I use so that they'll display reasonably on the small screen, and
> Rails is no exception.  Still, I tried a four player game of 18EU.
> 
> The first thing I notice is that most of the windows are now too tall for
the
> monitor to display without scroll bars.  The two most annoying cases are
the
> Game Status and Map windows.
> 
> The Game Status window insists on re-sizing itself after every single
action
> (and that's typically twice per player turn; once after buying a share,
and
> again after hitting Done).  Even saving the game causes the window to
resize.
> And every time it resizes itself it is too tall for the screen, with the
Done (or
> Pass) button completely below the screen and (usually) the title bar part
way
> above the screen, thus requiring three manual moves per occurrence (drag
> the whole window down by title bar to get to the top edge; then drag the
> top edge down to make the window fit the screen; then drag the whole
> window up so that I can get to the Done or Pass button).  I can only add
that
> this would not be quite as annoying if the Done or Pass button were within
> the area controlled by the scroll bars, so it could be reached using them,
> and/or if there were a keyboard shortcut for Done or Pass.  I would like
to
> have the ability to end any action by hitting "D" as I do in Colossus.
> 
> The Map window is not quite as bad, because it only re-sizes itself at the
> beginning of each round.  However, its scroll bars control only the map
> proper, so there is no way to resize the company-status lines below the
map.
> The result on my screen is that I have to view the map through a "mail
slot"
> about two hexes tall, with no way to make it bigger -- and I have to
scroll that
> "mail slot" to reach the controls for every single tile or token laying
action.
> 
> Anyhow: the attached game runs, under those conditions, until the end of
> stock round 3.  Then instead of starting the next operating round, it
stays on
> the Game Status window, with the Treasury Shares column highlighted as if
it
> were the end of a company's turn, and with all controls disabled except
the
> Autopass button, which does nothing.  So I can't continue.

[Rails-devel] Game report - 1.7.8 - 18EU hangs

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

I recently had my monitor blow up and had to go back to one about 20 years old
with a smaller screen.  As a result I've had to twiddle most of the programs I
use so that they'll display reasonably on the small screen, and Rails is no
exception.  Still, I tried a four player game of 18EU.

The first thing I notice is that most of the windows are now too tall for the
monitor to display without scroll bars.  The two most annoying cases are the
Game Status and Map windows.

The Game Status window insists on re-sizing itself after every single action
(and that's typically twice per player turn; once after buying a share, and
again after hitting Done).  Even saving the game causes the window to resize.
And every time it resizes itself it is too tall for the screen, with the Done
(or Pass) button completely below the screen and (usually) the title bar part
way above the screen, thus requiring three manual moves per occurrence (drag
the whole window down by title bar to get to the top edge; then drag the top
edge down to make the window fit the screen; then drag the whole window up so
that I can get to the Done or Pass button).  I can only add that this would
not be quite as annoying if the Done or Pass button were within the area
controlled by the scroll bars, so it could be reached using them, and/or if
there were a keyboard shortcut for Done or Pass.  I would like to have the
ability to end any action by hitting "D" as I do in Colossus.

The Map window is not quite as bad, because it only re-sizes itself at the
beginning of each round.  However, its scroll bars control only the map
proper, so there is no way to resize the company-status lines below the map.
The result on my screen is that I have to view the map through a "mail slot"
about two hexes tall, with no way to make it bigger -- and I have to scroll
that "mail slot" to reach the controls for every single tile or token laying
action.

Anyhow: the attached game runs, under those conditions, until the end of
stock round 3.  Then instead of starting the next operating round, it stays
on the Game Status window, with the Treasury Shares column highlighted as if
it were the end of a company's turn, and with all controls disabled except
the Autopass button, which does nothing.  So I can't continue.