rails-devel — List for discussion of Rails development

Re: [Rails-devel] Splitting up the OR window.

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

A few somewhat belated answers.

> From: Stefan Frey [mailto:ste...@we...]
> Sent: Thursday, November 24, 2011 3:16 PM
> 
> I support allowing to split up Map and Company window. If there is a valid
> reason to keep them together, add a configuration for that. I am wondering
> if we could add another yes/no option to combine the Player and Company
> window, that would be optimal for a two-screen setup, that I am using
> myself here.

The split itself wouldn't be easy (as the past join has proved), making it
optional would complicate matters even more.
In any case, quite some UI refactoring would be needed. 
Anyway, I was only collecting opinions, I have no plan to work on such a
split (yet).

> A more general approach is to add a docking framework, which would allow
> user to drag and drop panels as they like.
> However from my (limited) knowledge there seems to be not a clear choice
> which swing docking library to select if any.

A few years ago, someone announced to start working on an Eclipse version.
That's the last thing I heard about that (nice) idea.

> And I am not even sure that I would still choose Swing for a rewrite of
the
> user interface. I would prefer something from the ajax/gwt/jquery et.al.
> world. This would ease migration to allow play on mobile devices and have
> the server part of the cloud (e.g. using the google AppEngine).

Personally, I'd rather see *additional* user interfaces than a complete
replacement.  

> From: John David Galt [mailto:jd...@di...]
> Sent: Friday, November 25, 2011 12:55 AM
> 
> I would like to see the lists of companies removed from both the map
> window and the Game Status window, to become a new window I would call
> Company Actions.
> (The remainder of the Game Status window would be Player Actions.)

I'm not sure if this idea appeals to me.  One result would be, that all
share-trading *player actions* would have to be executed in the *company
actions* window.
Admittedly, most of the quite substantial overlap between the two windows
would be removed, but I'm not sure if that overlap is such a bad thing.
 
> Like Erik, my main motivation is the annoying tendency of the map window
> to resize itself before and during operating rounds.  So maybe it would be
> better, as well as simpler, just to implement a decree that once the game
> begins, no window shall ever move or resize itself except manually.  If a
> window suddenly needs to display data that won't fit within its existing
area
> (as when new companies form), let it sprout scroll bars instead of
changing
> size.

That's on my wish (and potential to-do) list.

Erik.

Re: [Rails-devel] Special tile laying

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

Erik:
quick answer on the last issue:
The special menu entry was used to facility the special tile lay of private B
in Rails: Player B is allowed to lay the tile independent of an ownership of 
the company.
So removing that possibility breaks 1889 support and potentially existing game 
files.
Stefan


> 4) I have removed the additional inclusion of such special tile lays as
> options in the "Special" menu. This was accomplished by a different
> mechanism and would not follow the above new rules.
> I'm not entirely sure why this menu option had been included, and if it is
> really needed.  I'll check my old emails later, but I can think now of two
> reasons:
> - special tiles lays exist that are permitted outside the normal tile
> laying step,
> - increasing user-friendliness by adding an alternative procedure, with the
> usual "special action" highlight.
> In any case, if this feature must be retained, it will have to be provided
> by the UI rather than by the game engine, as it was previously.
> 
> Erik.
> 
> 
> ---------------------------------------------------------------------------
> --- All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Special tile laying

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

I have committed the first bunch of code to fix problems with laying tiles
using private special properties.
There problems have been reported by John David Galt.

The bugs so far fixed relate to offering, and in some cases even accepting
invalid tile lays by using special properties, such as:
- replacing a yellow tile by another one, e.g. 18AL Lumber Terminal,
- upgrading a yellow tile to a green one, e.g. 1830 F16 (D&H) or B20 (D&H).
The three cases mentioned above now work correctly. I still have to test
other cases in 1835 and 1889.

So far only the game engine has been affected.  The changes include:

1) The already existing but unused option to restrict special tile lays to a
certain colour is now used and enforced.  This applies to 1830 in hex B20
(C&StL).

2) Laying tiles of which the colour is specified explicitly (C&StL) or
implicitly by prescribing  a specific tile (D&H, Lumber Terminal) are now
checked against:
  2a. The colours allowed in the current phase. This has no effect in the
above cases, but it will have effect for the green special upgrade in 1846
(Lake Shore Line).
  2b. The colour of tile(s) already present in any explicitly specified
hexes. See the rules under 3). Blocked hexes are no longer offered (except
in the static help text, unfortunately).  If no hex(es) remain, the special
tile lay will not be offered at all.

3) Any tile to be laid must be either:
  3a. A regular upgrade (blank to yellow, yellow to green etc.), following
normal upgrade rules, or
  3b. An explicitly specified "irregular" upgrade of the old to the new tile
(in TileSet.xml).  I don't know any cases yet where this applies for special
tile lays, but 1856 has regular yellow-to-yellow upgrades, so I think we
must include this case.

4) I have removed the additional inclusion of such special tile lays as
options in the "Special" menu. This was accomplished by a different
mechanism and would not follow the above new rules.
I'm not entirely sure why this menu option had been included, and if it is
really needed.  I'll check my old emails later, but I can think now of two
reasons:
- special tiles lays exist that are permitted outside the normal tile laying
step,
- increasing user-friendliness by adding an alternative procedure, with the
usual "special action" highlight.
In any case, if this feature must be retained, it will have to be provided
by the UI rather than by the game engine, as it was previously.

Erik.

[Rails-devel] Rails 1.5.4 available

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

A new bug-fix release 1.5.4 for Rails is available.

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

Thanks to all contributors (Erik Vos, Stefan Frey)
and those who reported bugs 
(Thomas Wall Hannaford, Hildebrand Tigelaar, John David Galt).

List of bugs fixed:
- 18AL, 18Kaas, (1870): Green tile #25 was not upgradeable to #45 and #46
- 18AL (and others?): The registration of buying one train to prevent any 
further buys was not undoable.
- 18AL: Background map for 18AL included (thanks to John David Galt for his 
permission)
- 1835: allow dumped president's share to be exchanged against a 20% share.
- 1835: BA home token is now laid in its first OR.
- 1835: Fixed PR train discarding bugs.
- 18EU, 18GA: Background map could not be displayed in previous released 
versions, this is fixed.
- All games (required for 1835): Added tooltips to Game Status share fields to 
display portfolio composition.
- All games: Fixed offering special token lays where that is not actually 
allowed. 
WARNING: The last fix might make existing save files unloadable.

Note: To show a background map, the option has to be switched on in 
Configuration => Map/Report => Display background map.
Background maps are only available for 18EU, 18GA and 18AL so far.

Re: [Rails-devel] Preparing new release: Version number?

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

I surely have no problem with a new release now.  
Erik

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Sunday, November 27, 2011 10:01 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Preparing new release: Version number?
> 
> Erik,
> would you still agree that a 1.5.4 is possible to allow testing the fixed
issues
> and close the background map error or would you prefer to wait a few more
> days to have all released in one go?
> If there is developing going on I would like to keep releases in regular
> intervals, this keeps the other contributors in the loop.
> Stefan
> 
> On Sunday, November 27, 2011 09:47:58 pm Erik Vos wrote:
> > Stefan,
> >
> > No, I'm not ready yet.  The issue with offering impossible special
> > tile lays is still open.
> > (I wouldn't call such an issue a bug myself; IMO, bugs are failures
> > and limitations that inhibit correct play. Here we have a case of
> > incorrect play, that isn't even allowed, just suggested, but even if
> > it would be allowed I'd still consider it a mere flaw rather than a
> > bug, as it can be avoided. But that aside).
> >
> > I know what to do, but haven't found the time yet.
> > In addition, a scan through old mails and bug reports uncovered a few
> > more issues with 1835 (mostly raised by JDG as well) that I would like
> > to consider.
> > Later this week, I hope.
> >
> > > if 1835 is ready
> >
> > Or ready again.  It turns out to be very hard to exactly define "ready".
> > I'd say: after I have done the outstanding fixes, it's as ready as I'm
> > aware of.  But so it was the previous time.
> > Anyhow, there is little doubt that John David Galt and another
> > excellent testers will keep finding bugs and flaws, until eternity, or
> > the lifetime of Rails, whichever comes first.
> >
> > Erik.
> >
> >
> >
> > ----------------------------------------------------------------------
> > -----
> > --- All the data continuously generated in your IT infrastructure
> > contains a definitive record of customers, application performance,
> > security threats, fraudulent activity, and more. Splunk takes this
> > data and makes sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-novd2d
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
>
----------------------------------------------------------------------------
--
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security threats,
> fraudulent activity, and more. Splunk takes this data and makes sense of
it. IT
> sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Preparing new release: Version number?

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

Erik,
would you still agree that a 1.5.4 is possible to allow testing the fixed 
issues and close the background map error or would you prefer to wait a few 
more days to have all released in one go?
If there is developing going on I would like to keep releases in regular 
intervals, this keeps the other contributors in the loop.
Stefan

On Sunday, November 27, 2011 09:47:58 pm Erik Vos wrote:
> Stefan,
> 
> No, I'm not ready yet.  The issue with offering impossible special tile
> lays is still open.
> (I wouldn't call such an issue a bug myself; IMO, bugs are failures and
> limitations that inhibit correct play. Here we have a case of incorrect
> play, that isn't even allowed, just suggested, but even if it would be
> allowed I'd still consider it a mere flaw rather than a bug, as it can be
> avoided. But that aside).
> 
> I know what to do, but haven't found the time yet.
> In addition, a scan through old mails and bug reports uncovered a few more
> issues with 1835 (mostly raised by JDG as well) that I would like to
> consider.
> Later this week, I hope.
> 
> > if 1835 is ready
> 
> Or ready again.  It turns out to be very hard to exactly define "ready".
> I'd say: after I have done the outstanding fixes, it's as ready as I'm
> aware of.  But so it was the previous time.
> Anyhow, there is little doubt that John David Galt and another excellent
> testers will keep finding bugs and flaws, until eternity, or the lifetime
> of Rails, whichever comes first.
> 
> Erik.
> 
> 
> 
> ---------------------------------------------------------------------------
> --- All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Preparing new release: Version number?

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

Stefan,

No, I'm not ready yet.  The issue with offering impossible special tile lays
is still open. 
(I wouldn't call such an issue a bug myself; IMO, bugs are failures and
limitations that inhibit correct play. Here we have a case of incorrect
play, that isn't even allowed, just suggested, but even if it would be
allowed I'd still consider it a mere flaw rather than a bug, as it can be
avoided. But that aside).

I know what to do, but haven't found the time yet.  
In addition, a scan through old mails and bug reports uncovered a few more
issues with 1835 (mostly raised by JDG as well) that I would like to
consider.
Later this week, I hope.

> if 1835 is ready

Or ready again.  It turns out to be very hard to exactly define "ready". 
I'd say: after I have done the outstanding fixes, it's as ready as I'm aware
of.  But so it was the previous time.
Anyhow, there is little doubt that John David Galt and another excellent
testers will keep finding bugs and flaws, until eternity, or the lifetime of
Rails, whichever comes first.

Erik.
 

[Rails-devel] Preparing new release: Version number?

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

Erik,
are all bug reports for 1835 fixed by now?
I would like to put out a new release tonight or tomorrow morning and if
1835 is ready, it would be version 1.6.0. Otherwise it will be 1.5.4.
Stefan

Re: [Rails-devel] Loading background maps from jar (was: How do i run Rails on Windows)

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

> Final comment:
> Is there any usage for the configuration option map.root_directory?
> Otherwise I would drop that so far, unless we know how we want to use
> that.

I suppose this is a leftover from my initial attempts with 18EU.  I can't
find any usage now, so I suppose it can safely be removed. 

Erik.

Re: [Rails-devel] Loading background maps from jar (was: How do i run Rails on Windows)

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

As suspected the background map could only be located from the file system, 
this does not work with the released .jar.

Again I struggled a little bit with the Rails classLoader which is clearly 
legacy code from Colossus (in the comments it is still referred to as 
ColossusClassLoader): However simply using the standard approach
using getClass().getResource(URI) worked, even if I do not exactly how it gets 
resolved.

Only issue was that I needed to add an additional separator at the beginning 
of the path.

Final comment:
Is there any usage for the configuration option map.root_directory?
Otherwise I would drop that so far, unless we know how we want to use that.

Stefan


> I wonder if no other user ever tried using a background map before???
> 
> Seems that the map file is not correctly located in the jar, thus uses not
> the default Class/Resource-Loader. As we developers run from Eclipse
> we have not seen the bug before. I will look into that.
> I have changing the Classloader high on my priority-list for Rails 2.x for
> several reasons anyway.
> 
> Stefan
> 
> On Tuesday, November 22, 2011 05:11:28 am Jerry Anderson wrote:
> > Ok - i figured out what i was doing wrong. the game starts but I am not
> > seeing the background map for 18GA. I am getting an error about the path.
> > There is no "data" directory. This is the error
> > java.io.FileNotFoundException:
> > C:\Personal\18XX\rails-1.5.3\rails-1.5.3\data\18GA\MapImage.svg (The
> > system cannot find the path specified) at
> > java.io.FileInputStream.open(Native Method)
> > 
> >  at java.io.FileInputStream.<init>(Unknown Source)
> >  at java.io.FileInputStream.<init>(Unknown Source)
> >  at sun.net.www.protocol.file.FileURLConnection.connect(Unknown Source)
> >  at sun.net.www.protocol.file.FileURLConnection.getInputStream(Unknown
> > 
> > Source) at
> > org.apache.batik.util.ParsedURLData.openStreamInternal(ParsedURLData.java
> > : 547) at
> > org.apache.batik.util.ParsedURLData.openStream(ParsedURLData.java:471) at
> > org.apache.batik.util.ParsedURL.openStream(ParsedURL.java:417) at
> > org.apache.batik.dom.svg.SAXSVGDocumentFactory.createDocument(SAXSVGDocum
> > e ntFactory.java:158) at
> > org.apache.batik.dom.svg.SAXSVGDocumentFactory.createSVGDocument(SAXSVGDo
> > c umentFactory.java:124) at
> > org.apache.batik.bridge.DocumentLoader.loadDocument(DocumentLoader.java:1
> > 0 6) at
> > org.apache.batik.swing.svg.SVGDocumentLoader.run(SVGDocumentLoader.java:8
> > 4 )
> > 
> > 
> > 
> > ________________________________
> > 
> >  From: Jerry Anderson <jer...@ya...>
> > 
> > To: "rai...@li..."
> > <rai...@li...> Sent: Monday, November 21, 2011 7:34
> > PM
> > Subject: [Rails-users] How do i run Rails on Windows
> > 
> > 
> > Are there instructions somewhere that explain how to run the game. I see
> > the batch file but I have no idea what to supply as a command line
> > parameter. %1.
> > 
> > -------------------------------------------------------------------------
> > -- --- All the data continuously generated in your IT infrastructure
> > contains a definitive record of customers, application performance,
> > security threats, fraudulent activity, and more. Splunk takes this data
> > and makes sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-novd2d
> > _______________________________________________
> > Rails-users mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-users
> 
> ---------------------------------------------------------------------------
> --- All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Fixed offerering impossible special token lays

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

> Which brings me on the subject that JUnit testing does not always seem to
> report "Load interrupted" cases.
> Yesterday night, the tests were OK, but this morning they showed failures.
> It's probably my ineptitude with JUnit, but it seems that interrupted loads
> sometimes can pass undetected.
> I tried to fix that by adding a report line at that point (GameFileIO line
> 227), but I haven't yet seen any impact of that change on the JUnit testing
> result.

Erik:
Most likely you should not blame JUnit but my implementation/usage of JUnit 
instead.

JUnit in general reports uncatched exceptions (category "errors") and those 
cases that are defined failures of the test case (category "failures").

For the test games we define failed games as those for which the stored report 
differs from the current game report. As long as there is no difference 
between those the test case passed.

Currently load interruptions are catched exceptions of the GameLoad class, 
thus a load interruption alone does not raise an error.
If the first run which defines the stored report had the same load 
interruption, the test reports are identical, thus no failure is correctly 
reported by JUnit. 

So you should check first if you test case runs correctly first and only then 
add it to the suite of test games. Otherwise it is garbage in, garbage out.

And if you think about it, for some cases it might make sense: Suppose you 
want to check that in some cases the load interruption should be raised. Then 
you are able to add those games too and this behavior is testable too.
This is a general principle of testing: Not only should you test if in correct 
setups the correct behavior occurs, but also that illegal setups get handled 
gracefully.

So in short: For me it seems the correct behavior. The only help that could be 
possible is to raise a warning, if a report should be stored after a load 
interruption.

Stefan



> 
> I have also added an action count to the LoadInterrupted message, to
> facilitate debugging such problems.
> 
> Erik.
> 
> 
> ---------------------------------------------------------------------------
> --- All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Fixed offerering impossible special token lays

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

> It did broke three of my brand-new test cases, which I initially withdrew,
until
> I realised that I could fix these as well pretty easily.

Actually, these test case fixes weren't complete yet.  Now they should be.

Which brings me on the subject that JUnit testing does not always seem to
report "Load interrupted" cases. 
Yesterday night, the tests were OK, but this morning they showed failures.
It's probably my ineptitude with JUnit, but it seems that interrupted loads
sometimes can pass undetected.
I tried to fix that by adding a report line at that point (GameFileIO line
227), but I haven't yet seen any impact of that change on the JUnit testing
result.

I have also added an action count to the LoadInterrupted message, to
facilitate debugging such problems.

Erik.

Re: [Rails-devel] Splitting up the OR window.

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

> "Originally, Rails had separate windows for the map and the OR status panel.
> Brett Lentz has combined the two already in a pretty early stage.
> 
> Personally, I would have left these apart. Sometimes (e.g. in 1835) it's
> really annoying having these two screens joined, because the whole OR Window
> now is too high, and always resizes that way at the start of a new OR (I
> don't know how to fix that).
> So I'm all for a split-up."
> 
> Opinions?

I would like to see the lists of companies removed from both the map window and
the Game Status window, to become a new window I would call Company Actions.
(The remainder of the Game Status window would be Player Actions.)

Like Erik, my main motivation is the annoying tendency of the map window to
resize itself before and during operating rounds.  So maybe it would be better,
as well as simpler, just to implement a decree that once the game begins, no
window shall ever move or resize itself except manually.  If a window suddenly
needs to display data that won't fit within its existing area (as when new
companies form), let it sprout scroll bars instead of changing size.

Re: [Rails-devel] Fixed offerering impossible special token lays

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

> From: John David Galt [mailto:jd...@di...]
> 9. The Pfalzbahnen owner is being offered opportunities to lay a token
using
> its special power even when impossible (because the company currently
> operating has run out of tokens and/or already has one in the Pfalz hex).

Before offering a special token lay, the following checks are now executed:
- if the company has any tokens left,
- if the company hasn't any token yet on the target hex (if there is/are any
target location(s)),
- if the target hex (if any) is not blocked for token laying because a home
token of another company is not yet placed (of the BA, in this case),

Please note: this fix may break existing saved games.  A warning to that
effect should be added to the next release including this fix.
It did broke three of my brand-new test cases, which I initially withdrew,
until I realised that I could fix these as well pretty easily.

Erik.

Re: [Rails-devel] Can special tile lays ever be an upgrade?

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

1846 has privates that allow green upgrades as special tile lays.

--
Chris

Please consider the environment before printing this e-mail.


On Thu, Nov 24, 2011 at 10:49 AM, Erik Vos <eri...@xs...> wrote:

> I have started to look after my backlog of old "follow-up" emails.
>
> > From: John David Galt [mailto:jd...@di...]
> > Stefan Frey wrote:
> > > Some minor bug fixes:
> > >
> > > A. Special tile lays
> > > Currently special tile lays had hardly any checks for its validity.
> > >
> > > Examples:
> > > a) In 1889 the port tile can be laid on a hex already containing a
> > > yellow broad curve town tile.
> > > b) In 18AL the lumberjack tile can be laid on a hex already containing
> > > a yellow broad curve tile.
> > > c) In 1830 the D&H allows upgrading to green tiles if a yellow tile
> > > was laid already.
> > >
> > > The following changes prevent this:
> > > - Special tile lays always increase tile colour number.
> >
> > I don't understand this, unless it means that the tile colour must follow
> the
> > same progression (from what's already in the hex) as a regular tile lay.
> > This is a good general rule, but we need to be able to declare exceptions
> in a
> > game definition.
> >
> > > - Special tile lays always check the allowed tile colour of the current
> phase.
> >
> > If this is true, I would think it would solve the Pfalz problem (just
> notice that
> > the hex is already yellow).
>
> Alternatively, can we assume it to be a hard rule that special tile lays
> must always be *initial* lays, no upgrades?
> Because that would be a simple check.
>
> Most rule books state this rule in some way or another, although sometimes
> I
> can assert it only by assuming that all usage of the terms "place"/"lay"
> (as
> opposed to "replace"/"upgrade") is deliberately intended to refer to
> initial
> tile lays only.
>
> Are any specific exceptions known where a special tile lay can be an
> upgrade
> of a tile laid earlier?
>
> Erik.
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Can special tile lays ever be an upgrade?

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

I have started to look after my backlog of old "follow-up" emails.

> From: John David Galt [mailto:jd...@di...]
> Stefan Frey wrote:
> > Some minor bug fixes:
> >
> > A. Special tile lays
> > Currently special tile lays had hardly any checks for its validity.
> >
> > Examples:
> > a) In 1889 the port tile can be laid on a hex already containing a
> > yellow broad curve town tile.
> > b) In 18AL the lumberjack tile can be laid on a hex already containing
> > a yellow broad curve tile.
> > c) In 1830 the D&H allows upgrading to green tiles if a yellow tile
> > was laid already.
> >
> > The following changes prevent this:
> > - Special tile lays always increase tile colour number.
> 
> I don't understand this, unless it means that the tile colour must follow
the
> same progression (from what's already in the hex) as a regular tile lay.
> This is a good general rule, but we need to be able to declare exceptions
in a
> game definition.
> 
> > - Special tile lays always check the allowed tile colour of the current
phase.
> 
> If this is true, I would think it would solve the Pfalz problem (just
notice that
> the hex is already yellow).

Alternatively, can we assume it to be a hard rule that special tile lays
must always be *initial* lays, no upgrades? 
Because that would be a simple check.

Most rule books state this rule in some way or another, although sometimes I
can assert it only by assuming that all usage of the terms "place"/"lay" (as
opposed to "replace"/"upgrade") is deliberately intended to refer to initial
tile lays only.  

Are any specific exceptions known where a special tile lay can be an upgrade
of a tile laid earlier?

Erik.

Re: [Rails-devel] Splitting up the OR window.

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

Oh... one other note on the OpenShift front...

I know that we talked about Continuous Integration a while back. Well,
there's pre-built support for Jenkins (aka. Hudson) in OpenShift, if
anybody is interested in taking advantage of that for Rails.

http://www.javaworld.com/javaworld/jw-11-2011/111115-red-hat-open-shift.html

---Brett.




---------- Forwarded message ----------
From: brett lentz <bre...@gm...>
Date: Thu, Nov 24, 2011 at 12:12 PM
Subject: Re: [Rails-devel] Splitting up the OR window.
To: "Development list for Rails: an 18xx game"
<rai...@li...>


Comments inline...

On Thu, Nov 24, 2011 at 9:16 AM, Stefan Frey <ste...@we...> wrote:
> Erik & Brett:
> I support allowing to split up Map and Company window. If there is a valid
> reason to keep them together, add a configuration for that. I am wondering if
> we could add another yes/no option to combine the Player and Company window,
> that would be optimal for a two-screen setup, that I am using myself here.
>
> A more general approach is to add a docking framework, which would allow user
> to drag and drop panels as they like.

I would *far* prefer this over making a single arbitrary change.
There's a high probability that while some users may like the new
layout, some will prefer the current layout and we'd be upsetting that
portion of the userbase by forcing an unwanted change on them.

So, if we're going to do anything, it needs to *add* functionality,
not simply change it for something that's different, but not
objectively better.

I'd also remind you that dual monitors are *not* the norm, so we'd be
moving *away* from a layout that best accommodates the majority of
players. That just strikes me as moving in the wrong direction. We're
already a niche hobby, there's nothing to be gained by further
reducing our userbase.

> However from my (limited) knowledge there seems to be not a clear choice which
> swing docking library to select if any.
>

Anybody with the right combination of time and interest is welcome to
investigate and/or start putting prototypes together. :-)

> And I am not even sure that I would still choose Swing for a rewrite of the
> user interface. I would prefer something from the ajax/gwt/jquery et.al.
> world. This would ease migration to allow play on mobile devices and have the
> server part of the cloud (e.g. using the google AppEngine).
>

Eh. I'm not a fan of ajax and jquery. Unless there's a compelling
feature/function that add significant value, I see no reason to go
from a single language (Java) to multiple languages (Java +
ECMAScript). I've worked on projects that are split across several
languages, and it quickly becomes a larger maintenance burden than
it's really worth and makes it difficult for new people to contribute.

If we want to support Android, we're already using the right language.
It's really a matter of just adapting our code from the stock JVM to
Dalvik's API, and getting the APK builds going. The bulk of the work
would be presenting a UI that would work on a phone/tablet screen.

That said... Supporting running game servers in the cloud is a great
idea. I'd have no problems if we wanted to try hosting game servers
out of OpenShift (https://openshift.redhat.com/app/). Keeping the
OpenShift servers running is sort of my day job. ;-)

---Brett.

> >From my point of view google really replaced sun as the company which
> supports and encourages the java cross-platform idea most.
> And just in time before it was too late...
>
> But for now: I would like the idea of map and company panel separated.
>
> Stefan
>
>
> On Thursday, November 24, 2011 02:09:07 pm brett lentz wrote:
>> I'd like more layout options, especially the ability to configure what
>> is or isn't contained within a single window. However, I think that
>> this feature request could be considered pretty low priority.
>>
>> IMO, adding support for new games and networked play are probably far
>> higher on the "most wanted" list.
>>
>> ---Brett.
>>
>> On Thu, Nov 24, 2011 at 7:45 AM, Erik Vos <eri...@xs...> wrote:
>> > Today I found the following new feature request #3439190 in Sourceforge
>> > (by Anonymous, dated 2011-11-16):
>> >
>> > "Detach company list from map.
>> >
>> > Currently, the map window also contains the list of companies.
>> > While the motivation for having this is clear (user needs this
>> > information simultaneously), there are constellations for which this is
>> > not desired: I use two monitors (left-right) and have plenty of space
>> > horizontally. Therefore, I'd prefer to have the list of companies left
>> > or right of the map.
>> > The proposed solution would be to detach the company list and put it into
>> > a stand-alone window (or detach the map analogously)."
>> >
>> > I replied as follows:
>> >
>> > "Originally, Rails had separate windows for the map and the OR status
>> > panel. Brett Lentz has combined the two already in a pretty early stage.
>> >
>> > Personally, I would have left these apart. Sometimes (e.g. in 1835) it's
>> > really annoying having these two screens joined, because the whole OR
>> > Window now is too high, and always resizes that way at the start of a
>> > new OR (I don't know how to fix that).
>> > So I'm all for a split-up."
>> >
>> > Opinions?
>> >
>> > Erik.
>> >
>> >
>> > -------------------------------------------------------------------------
>> > ----- All the data continuously generated in your IT infrastructure
>> > contains a definitive record of customers, application performance,
>> > security threats, fraudulent activity, and more. Splunk takes this
>> > data and makes sense of it. IT sense. And common sense.
>> > http://p.sf.net/sfu/splunk-novd2d
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>> ---------------------------------------------------------------------------
>> --- All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Splitting up the OR window.

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

Comments inline...

On Thu, Nov 24, 2011 at 9:16 AM, Stefan Frey <ste...@we...> wrote:
> Erik & Brett:
> I support allowing to split up Map and Company window. If there is a valid
> reason to keep them together, add a configuration for that. I am wondering if
> we could add another yes/no option to combine the Player and Company window,
> that would be optimal for a two-screen setup, that I am using myself here.
>
> A more general approach is to add a docking framework, which would allow user
> to drag and drop panels as they like.

I would *far* prefer this over making a single arbitrary change.
There's a high probability that while some users may like the new
layout, some will prefer the current layout and we'd be upsetting that
portion of the userbase by forcing an unwanted change on them.

So, if we're going to do anything, it needs to *add* functionality,
not simply change it for something that's different, but not
objectively better.

I'd also remind you that dual monitors are *not* the norm, so we'd be
moving *away* from a layout that best accommodates the majority of
players. That just strikes me as moving in the wrong direction. We're
already a niche hobby, there's nothing to be gained by further
reducing our userbase.

> However from my (limited) knowledge there seems to be not a clear choice which
> swing docking library to select if any.
>

Anybody with the right combination of time and interest is welcome to
investigate and/or start putting prototypes together. :-)

> And I am not even sure that I would still choose Swing for a rewrite of the
> user interface. I would prefer something from the ajax/gwt/jquery et.al.
> world. This would ease migration to allow play on mobile devices and have the
> server part of the cloud (e.g. using the google AppEngine).
>

Eh. I'm not a fan of ajax and jquery. Unless there's a compelling
feature/function that add significant value, I see no reason to go
from a single language (Java) to multiple languages (Java +
ECMAScript). I've worked on projects that are split across several
languages, and it quickly becomes a larger maintenance burden than
it's really worth and makes it difficult for new people to contribute.

If we want to support Android, we're already using the right language.
It's really a matter of just adapting our code from the stock JVM to
Dalvik's API, and getting the APK builds going. The bulk of the work
would be presenting a UI that would work on a phone/tablet screen.

That said... Supporting running game servers in the cloud is a great
idea. I'd have no problems if we wanted to try hosting game servers
out of OpenShift (https://openshift.redhat.com/app/). Keeping the
OpenShift servers running is sort of my day job. ;-)

---Brett.

> >From my point of view google really replaced sun as the company which
> supports and encourages the java cross-platform idea most.
> And just in time before it was too late...
>
> But for now: I would like the idea of map and company panel separated.
>
> Stefan
>
>
> On Thursday, November 24, 2011 02:09:07 pm brett lentz wrote:
>> I'd like more layout options, especially the ability to configure what
>> is or isn't contained within a single window. However, I think that
>> this feature request could be considered pretty low priority.
>>
>> IMO, adding support for new games and networked play are probably far
>> higher on the "most wanted" list.
>>
>> ---Brett.
>>
>> On Thu, Nov 24, 2011 at 7:45 AM, Erik Vos <eri...@xs...> wrote:
>> > Today I found the following new feature request #3439190 in Sourceforge
>> > (by Anonymous, dated 2011-11-16):
>> >
>> > "Detach company list from map.
>> >
>> > Currently, the map window also contains the list of companies.
>> > While the motivation for having this is clear (user needs this
>> > information simultaneously), there are constellations for which this is
>> > not desired: I use two monitors (left-right) and have plenty of space
>> > horizontally. Therefore, I'd prefer to have the list of companies left
>> > or right of the map.
>> > The proposed solution would be to detach the company list and put it into
>> > a stand-alone window (or detach the map analogously)."
>> >
>> > I replied as follows:
>> >
>> > "Originally, Rails had separate windows for the map and the OR status
>> > panel. Brett Lentz has combined the two already in a pretty early stage.
>> >
>> > Personally, I would have left these apart. Sometimes (e.g. in 1835) it's
>> > really annoying having these two screens joined, because the whole OR
>> > Window now is too high, and always resizes that way at the start of a
>> > new OR (I don't know how to fix that).
>> > So I'm all for a split-up."
>> >
>> > Opinions?
>> >
>> > Erik.
>> >
>> >
>> > -------------------------------------------------------------------------
>> > ----- All the data continuously generated in your IT infrastructure
>> > contains a definitive record of customers, application performance,
>> > security threats, fraudulent activity, and more. Splunk takes this
>> > data and makes sense of it. IT sense. And common sense.
>> > http://p.sf.net/sfu/splunk-novd2d
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>> ---------------------------------------------------------------------------
>> --- All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Splitting up the OR window.

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

Erik & Brett:
I support allowing to split up Map and Company window. If there is a valid 
reason to keep them together, add a configuration for that. I am wondering if 
we could add another yes/no option to combine the Player and Company window, 
that would be optimal for a two-screen setup, that I am using myself here.

A more general approach is to add a docking framework, which would allow user 
to drag and drop panels as they like.
However from my (limited) knowledge there seems to be not a clear choice which 
swing docking library to select if any. 

And I am not even sure that I would still choose Swing for a rewrite of the 
user interface. I would prefer something from the ajax/gwt/jquery et.al. 
world. This would ease migration to allow play on mobile devices and have the 
server part of the cloud (e.g. using the google AppEngine). 

From my point of view google really replaced sun as the company which  
supports and encourages the java cross-platform idea most.
And just in time before it was too late...

But for now: I would like the idea of map and company panel separated.

Stefan


On Thursday, November 24, 2011 02:09:07 pm brett lentz wrote:
> I'd like more layout options, especially the ability to configure what
> is or isn't contained within a single window. However, I think that
> this feature request could be considered pretty low priority.
> 
> IMO, adding support for new games and networked play are probably far
> higher on the "most wanted" list.
> 
> ---Brett.
> 
> On Thu, Nov 24, 2011 at 7:45 AM, Erik Vos <eri...@xs...> wrote:
> > Today I found the following new feature request #3439190 in Sourceforge
> > (by Anonymous, dated 2011-11-16):
> > 
> > "Detach company list from map.
> > 
> > Currently, the map window also contains the list of companies.
> > While the motivation for having this is clear (user needs this
> > information simultaneously), there are constellations for which this is
> > not desired: I use two monitors (left-right) and have plenty of space
> > horizontally. Therefore, I'd prefer to have the list of companies left
> > or right of the map.
> > The proposed solution would be to detach the company list and put it into
> > a stand-alone window (or detach the map analogously)."
> > 
> > I replied as follows:
> > 
> > "Originally, Rails had separate windows for the map and the OR status
> > panel. Brett Lentz has combined the two already in a pretty early stage.
> > 
> > Personally, I would have left these apart. Sometimes (e.g. in 1835) it's
> > really annoying having these two screens joined, because the whole OR
> > Window now is too high, and always resizes that way at the start of a
> > new OR (I don't know how to fix that).
> > So I'm all for a split-up."
> > 
> > Opinions?
> > 
> > Erik.
> > 
> > 
> > -------------------------------------------------------------------------
> > ----- All the data continuously generated in your IT infrastructure
> > contains a definitive record of customers, application performance,
> > security threats, fraudulent activity, and more. Splunk takes this
> > data and makes sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-novd2d
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Splitting up the OR window.

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

I'd like more layout options, especially the ability to configure what
is or isn't contained within a single window. However, I think that
this feature request could be considered pretty low priority.

IMO, adding support for new games and networked play are probably far
higher on the "most wanted" list.

---Brett.



On Thu, Nov 24, 2011 at 7:45 AM, Erik Vos <eri...@xs...> wrote:
> Today I found the following new feature request #3439190 in Sourceforge (by
> Anonymous, dated 2011-11-16):
>
> "Detach company list from map.
>
> Currently, the map window also contains the list of companies.
> While the motivation for having this is clear (user needs this information
> simultaneously), there are constellations for which this is not desired:
> I use two monitors (left-right) and have plenty of space horizontally.
> Therefore, I'd prefer to have the list of companies left or right of the
> map.
> The proposed solution would be to detach the company list and put it into a
> stand-alone window (or detach the map analogously)."
>
> I replied as follows:
>
> "Originally, Rails had separate windows for the map and the OR status panel.
> Brett Lentz has combined the two already in a pretty early stage.
>
> Personally, I would have left these apart. Sometimes (e.g. in 1835) it's
> really annoying having these two screens joined, because the whole OR Window
> now is too high, and always resizes that way at the start of a new OR (I
> don't know how to fix that).
> So I'm all for a split-up."
>
> Opinions?
>
> Erik.
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

[Rails-devel] Splitting up the OR window.

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

Today I found the following new feature request #3439190 in Sourceforge (by
Anonymous, dated 2011-11-16):

"Detach company list from map.

Currently, the map window also contains the list of companies.
While the motivation for having this is clear (user needs this information
simultaneously), there are constellations for which this is not desired:
I use two monitors (left-right) and have plenty of space horizontally.
Therefore, I'd prefer to have the list of companies left or right of the
map.
The proposed solution would be to detach the company list and put it into a
stand-alone window (or detach the map analogously)."

I replied as follows:

"Originally, Rails had separate windows for the map and the OR status panel.
Brett Lentz has combined the two already in a pretty early stage.

Personally, I would have left these apart. Sometimes (e.g. in 1835) it's
really annoying having these two screens joined, because the whole OR Window
now is too high, and always resizes that way at the start of a new OR (I
don't know how to fix that).
So I'm all for a split-up."

Opinions?

Erik.

Re: [Rails-devel] More about track-laying annoyances

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

On 2011-11-22 15:45, Erik Vos wrote:
> The problem is that the BA had already floated and so, according to the
> rules, the BA token had already been laid on the BA home hex L6.
> Now that L6 is upgraded to green, that token must find a place.
> 
> The only easy way out of this problem I saw was to defer laying the BA home
> token until its first OR turn -  in all cases. I hope that's an acceptable
> workaround.

That's exactly what the rules say happens.

Re: [Rails-devel] Further 1835 testing

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

That's indeed a real bug.
I also discovered that the PR probably would never discard more than one
train if having more than one excess train.
Both bugs are fixed now.

Discarding multiple PR trains now takes separate player actions.  An obvious
improvement would be to enable the DiscardTrain action to require discarding
more than one train in the same player action.

Erik.

> -----Original Message-----
> From: John David Galt [mailto:jd...@di...]
> Sent: Sunday, November 20, 2011 4:18 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Further 1835 testing
> 
> I found one more real bug in 1835 on Rails 1.5.3:
> 
> After the 5-train purchase forces all minors to merge into PR, PR is
allowed to
> keep four trains.  (The rules say PR is allowed only three after the
5-train
> purchase, while all other companies are allowed two.)
> 
>
----------------------------------------------------------------------------
--
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security threats,
> fraudulent activity, and more. Splunk takes this data and makes sense of
it. IT
> sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] More about track-laying annoyances

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

The problem is that the BA had already floated and so, according to the
rules, the BA token had already been laid on the BA home hex L6.
Now that L6 is upgraded to green, that token must find a place.

The only easy way out of this problem I saw was to defer laying the BA home
token until its first OR turn -  in all cases. I hope that's an acceptable
workaround.

This change doesn't break any existing test cases, but your game will likely
be broken now, as well as any other 1835 games where a foreigner has laid a
tile on L6.

While testing this change, I found a problem with the earlier change to the
SellShares action, that caused some of my own test cases to be broken.
That's also fixed, and my new standard test cases had to be refreshed.

Erik.

> -----Original Message-----
> From: John David Galt [mailto:jd...@di...]
> Sent: Sunday, November 20, 2011 3:02 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] More about track-laying annoyances
> 
> A second minor track-laying annoyance:
> 
> At the point of this save file, Marcus (running SX) uses the Pfalz to lay
a tile in
> Ludwigshafen/Mannheim.
> 
> Result: Marcus is asked where BA's home station should be placed.
> 
> There are two things wrong with that.  Kent is president of BA, so he, not
> Marcus, should be asked.  And he should not be asked until BA's own turn
> (so Marcus should not be allowed to place a SX token there on this turn,
> even with Kent's approval).

Re: [Rails-devel] Rails 2.0 (was:Selling shares)

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

> 
> It sounds like it's time to focus our efforts on 2.x.

+1 

> 
> My recommendation:
> 
> Let's create a new public branch for doing 1.x maintenance work. Any
> bugfixes for the next few 1.x releases can go here and, if applicable,
> be merged or cherry-picked to master.
> 
> This will allow us to use master for 2.x (and beyond).
> 

I know this pure convention, however I prefer keeping the master for the 
stable branch.  The current setup is documented here:

https://sourceforge.net/apps/mediawiki/rails/index.php?title=Release_Management