rails-devel — List for discussion of Rails development

Re: [Rails-devel] 18GA "gray towns" not counted as cities (48aa0f)

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

Adam:
the current relevant definition of the stop type (City, Town etc.) stems from 
the definition in Tiles.xml. This is set to "town" for tile -1143.

The issue is now that Tiles.xml is automatically created and the tile actually 
shows a town. 

What is possible given the current redesign is that the properties of a tile 
can be overwritten for specific locations on Map.xml.

So the result looks like the following:
	<Hex name="J4" tile="-1143" value="20,50" city="Tallahassee">
		<Access score="major"/>		
	</Hex>
And similar for Montgomery.

I have committed the change.

Stefan


On Friday, October 07, 2011 11:43:42 pm Adam Badura wrote:
> In the attached save G&F is about to make its OR turn. Don’t lay any tile
> nor place any station. Just run. 6T (its only train) makes a route of 8
> stops. It seems the gray border towns are not counted as cities (while
> they should).
> 
> We noticed this effect (in other companies too) after entering phase 5. But
> its possible that either we just missed it earlier or the tracks and
> trains were setup so that such routes were not possible anyway.
> 
> I looked into tiles XML for 18GA and even tried to change those to Twons
> but it seemed it didn’t help. Yet I might have done it the wrong way.
> 
> Adam Badura

Re: [Rails-devel] 1880 intermediate features

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

Hi Martin,

 

1.       I think you are missing some Batik library.  On my PC, it compiles fine.

 

2.       It does not run, though. StartRoundWindow_1880 cannot be instantiated.  I can fix that by removing its two-argument constructor.  Please note, that the new construction process (after the classname had be made variable) needs the (default, empty) no-argument constructor.  A new method init(StartRound round, GameUIManager parent) is now called separately to initialise this window.  See the new StartRoundWindow class.

 

3.       In my opinion, you should put everything related to building rights into 1880-specific classes.  I think the only missing one is BuyStartItem_1880.  That should not be a problem, as you create this action object in StartRound_1880.

 

4.       Miscellaneous remarks:
-  To make your new capitalisation type more generic, I would suggest to replace its value “fiftyPercent” by “percentage” and add an attribute ‘percentage=”50”’.
- Similarly, I would propose to replace the revenue tags Revenue5 etc. by a single tag type (e.g. ExtraRevenue) and an ‘amount’ attribute.

 

Regards,
Erik.

 

 

 

From: Dr....@t-... [mailto:Dr....@t-...] 
Sent: Saturday, October 08, 2011 6:18 PM
To: Rails Development
Subject: [Rails-devel] 1880 intermediate features

 

Hi all,

 

this patch contains some of the needed alterations in regard to the Stockmarket in 1880 and the Startround should now function.

 

I currently get problems running the code, it says a transcoder is missing ? Did anybody lately compiled the code ?

 

Exact error message follows down below:

 

Exception in thread "AWT-EventQueue-0" java.lang.Error: Unresolved compilation problems: 
    The import org.apache.batik.transcoder cannot be resolved
    The import org.apache.batik.transcoder cannot be resolved
    ImageTranscoder cannot be resolved to a type
    The method createImage(int, int) of type ImageLoader.BufferedImageTranscoder must override a superclass method
    TranscoderOutput cannot be resolved to a type
    TranscoderException cannot be resolved to a type

    at rails.ui.swing.ImageLoader.<init>(ImageLoader.java:10)
    at rails.ui.swing.GameUIManager.gameUIInit(GameUIManager.java:185)
    at rails.ui.swing.GameSetupWindow.startNewGame(GameSetupWindow.java:509)
    at rails.ui.swing.GameSetupWindow.actionPerformed(GameSetupWindow.java:251)
    at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
    at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
    at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
    at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
    at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:236)
    at java.awt.Component.processMouseEvent(Component.java:6289)
    at javax.swing.JComponent.processMouseEvent(JComponent.java:3267)
    at java.awt.Component.processEvent(Component.java:6054)
    at java.awt.Container.processEvent(Container.java:2041)
    at java.awt.Component.dispatchEventImpl(Component.java:4652)
    at java.awt.Container.dispatchEventImpl(Container.java:2099)
    at java.awt.Component.dispatchEvent(Component.java:4482)
    at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4577)
    at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4238)
    at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4168)
    at java.awt.Container.dispatchEventImpl(Container.java:2085)
    at java.awt.Window.dispatchEventImpl(Window.java:2478)
    at java.awt.Component.dispatchEvent(Component.java:4482)
    at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:644)
    at java.awt.EventQueue.access$000(EventQueue.java:85)
    at java.awt.EventQueue$1.run(EventQueue.java:603)
    at java.awt.EventQueue$1.run(EventQueue.java:601)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
    at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:98)
    at java.awt.EventQueue$2.run(EventQueue.java:617)
    at java.awt.EventQueue$2.run(EventQueue.java:615)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
    at java.awt.EventQueue.dispatchEvent(EventQueue.java:614)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
    at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
    at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

 

This is on Windows using Eclipse.

 

I'll try and get a new clone later and see if the error still crops up or is just locally.

 

Regards,

Martin

Re: [Rails-devel] XML and Java file formatting

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

On Fri, Oct 7, 2011 at 10:02 AM, Erik Vos <eri...@xs...> wrote:
> In my previous mail I mentioned a Perl XML formatter that I have just
> written on the fly and committed to the repository (well, I had written such
> a script before, but could not find it).  I have used it to format some
> recreated Tiles.xml files, and will keep using it for that purpose (perhaps
> for other XML files too, if needed; but XMLBuddy seems to work the same).
>
> On the details, I have settled on the format of the generic Tiles.xml file,
> as it has recently been reformatted by Brett:
> - for indentation: tabs, no spaces (I loathe tabs, but see no point in
> starting an argument about that),
> - newlines only, no CRs (to achieve that on Windows, formatxml.pl uses
> binmode).
> Can we try to standardize this way? I often see redundant whitespace-only
> differences in commits, which is a waste.
>
> Redundant whitespace-only differences are also often seen in Java source
> code commits. Here I would also propose to standardize on the currently most
> frequent usage, which is:
> - for indentation: spaces, no tabs (after all, in this way I have written
> the majority of the code, and Stefan does it similarly.  I notice that Brett
> uses tabs).
> - newlines only (I don't think that it matters for Java compilers, but this
> is how Eclipse is doing it even on my Windows machine. Brett's machine is
> adding CRs, as it seems to me).
> Please note, that my Eclipse is set to convert all tabs to spaces on saving
> Rails Java files.
>
> This all is no problem as long as we work on different code packages, but
> some files have several contributors by now.
>
> I hope this helps.
>
> Erik.
>


In recent years, I've been using Windows, Mac, and Linux machines to
commit code. So, my formatting rules have been pretty inconsistent.
Apologies for my sloppiness.

I prefer spaces to tabs. I also prefer CR to CR/LF (I blame Windows
for the CR/LFs).

So, no arguments with any of that. :-)

---Brett.

[Rails-devel] XML and Java file formatting

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

In my previous mail I mentioned a Perl XML formatter that I have just
written on the fly and committed to the repository (well, I had written such
a script before, but could not find it).  I have used it to format some
recreated Tiles.xml files, and will keep using it for that purpose (perhaps
for other XML files too, if needed; but XMLBuddy seems to work the same).

On the details, I have settled on the format of the generic Tiles.xml file,
as it has recently been reformatted by Brett:
- for indentation: tabs, no spaces (I loathe tabs, but see no point in
starting an argument about that),
- newlines only, no CRs (to achieve that on Windows, formatxml.pl uses
binmode).
Can we try to standardize this way? I often see redundant whitespace-only
differences in commits, which is a waste.

Redundant whitespace-only differences are also often seen in Java source
code commits. Here I would also propose to standardize on the currently most
frequent usage, which is:
- for indentation: spaces, no tabs (after all, in this way I have written
the majority of the code, and Stefan does it similarly.  I notice that Brett
uses tabs).
- newlines only (I don't think that it matters for Java compilers, but this
is how Eclipse is doing it even on my Windows machine. Brett's machine is
adding CRs, as it seems to me).
Please note, that my Eclipse is set to convert all tabs to spaces on saving
Rails Java files. 

This all is no problem as long as we work on different code packages, but
some files have several contributors by now.

I hope this helps.

Erik.

Re: [Rails-devel] Tokens misplaced on tile #59?

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

It turns out that I had overlooked an earlier commit (417750, dated
28-2-2008) in which the reverse change (152/452 -> 052/352) had occurred.
That commit included changes to fix exactly this problem.  
The later commit you have found has reverted that. I'm pretty sure that the
Tiles.xml versions in this commit had been recreated from scratch (i.e.,
from TileDesigner output).  
So the Tiles.xml generation process must have been broken. It might not have
helped that for a long time we have had two versions of ConvertTilesXML.java
around.

I have finally found the root cause: the position codes of the corner-facing
cities in the currently remaining version of ConvertTilesXML.java were all
wrong.  Subtracting 100  (mod 600) from each one has now fixed that.
I have recreated the Tiles.xml files for 1825, 1830 and 1835, and the
generic version.  I'm not aware of other games where this problem might show
up and has not been fixed before. 

I have also added an XML-formatting Perl script, named formatxml.pl, that I
will use from now on in my Tiles.xml-creating scripts (actually .bat files).
I have put this Perl script into the repository (under tools) so others can
use it if wanted.  It should be platform- and machine-independent (and
therefore does not have a #! first line, and writes files in binmode).
Please keep it that way.
See also my next mail on formatting issues.

Erik.


> -----Original Message-----
> From: Bill Rosgen [mailto:ro...@gm...]
> Sent: Friday, October 07, 2011 7:44 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Tokens misplaced on tile #59?
> 
> 
> On 2011-10-07, at 4:08 , Erik Vos wrote:
> 
> >>> Using git bisect I am able to track the offending commit (at least
> >>> as
> > far as 1830 goes) to commit 0c69cf, which introduced the Coalfields
variant.
> > Digging further, the cities on tile #59 were at positions  052 and 352
> > before this commit, but at positions 152 and 452 following the commit.
> >>>
> >
> > This puzzles me. As far as I can see, the position values 152 and 452
> > for tile #59 exist since the introduction of these codes 6 years ago.
> 
> This may all be a waste of time, if the problem is simply in the display
code, or
> can be easily fixed in the display code, but git claims that tile #59
changed at
> commit 0c69cf on 13 Feb 2011.  Specifically, the following three
consecutive
> commits (of those commits that affect the file tiles/Tiles.xml ) are
relevant
> for what I describe below:
> 
> 30628c - 14 Mar 2011 - Extra off-map tiles for 18VA (and others) 0c69cf -
13
> Feb 2011 - Initial commit for 1830 Coalfields 98c5dd - 18 Dec 2010 -  1889
fixes:
> 
> When comparing it is easier for me to take diffs between 30628c and
98c5dd,
> as the file in 0c69cf doesn't seem to have any linebreaks in it that diff
will
> understand.  By visual inspection the code for tile #59 is identical in
both
> 0c69cf and 30628c (up to linebreaks).
> 
> When I do the following in the tiles/ subfolder of rails, I get the
following
> output:
> 
> rosgen@thales tiles $ git checkout 30628c5 HEAD is now at 30628c5... Extra
> off-map tiles for 18VA (and others)
> 
> rosgen@thales tiles $ git diff 98c5dd -- Tiles.xml | grep -A 7 id\=\"59\"
>     <Tile colour="green" id="59" name="59">
> -       <Station id="city1" position="052" slots="1" type="City"
value="40"/>
> -       <Station id="city2" position="352" slots="1" type="City"
value="40"/>
> +       <Station id="city1" position="152" slots="1" type="City"
value="40"/>
> +       <Station id="city2" position="452" slots="1" type="City"
> + value="40"/>
>         <Track from="city1" gauge="normal" to="side1"/>
>         <Track from="city2" gauge="normal" to="side3"/>
>     </Tile>
> 
> I can find no reason for this change.  The tile dictionary and the code
used to
> generate Tiles.xml (in utils/ ) shows no changes that look like they could
> cause this to happen.
> 
> When I hand-edit the Tiles.xml file for 1830 to revert to 052/352 in place
of
> 152/452, the tokens once more line up with the stops on the tile, but this
is
> not a good solution.
> 
> Bill
>
----------------------------------------------------------------------------
--
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of 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-d2dcopy2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Tokens misplaced on tile #59?

[Bill R. <ro...@gm...>]

On 2011-10-07, at 4:08 , Erik Vos wrote:

>>> Using git bisect I am able to track the offending commit (at least as
> far as 1830 goes) to commit 0c69cf, which introduced the Coalfields variant.
> Digging further, the cities on tile #59 were at positions  052 and 352
> before this commit, but at positions 152 and 452 following the commit.
>>> 
> 
> This puzzles me. As far as I can see, the position values 152 and 452 for
> tile #59 exist since the introduction of these codes 6 years ago.

This may all be a waste of time, if the problem is simply in the display code, or can be easily fixed in the display code, but git claims that tile #59 changed at commit 0c69cf on 13 Feb 2011.  Specifically, the following three consecutive commits (of those commits that affect the file tiles/Tiles.xml ) are relevant for what I describe below:

30628c - 14 Mar 2011 - Extra off-map tiles for 18VA (and others)
0c69cf - 13 Feb 2011 - Initial commit for 1830 Coalfields
98c5dd - 18 Dec 2010 -  1889 fixes:

When comparing it is easier for me to take diffs between 30628c and 98c5dd, as the file in 0c69cf doesn't seem to have any linebreaks in it that diff will understand.  By visual inspection the code for tile #59 is identical in both 0c69cf and 30628c (up to linebreaks).

When I do the following in the tiles/ subfolder of rails, I get the following output:

rosgen@thales tiles $ git checkout 30628c5
HEAD is now at 30628c5... Extra off-map tiles for 18VA (and others)

rosgen@thales tiles $ git diff 98c5dd -- Tiles.xml | grep -A 7 id\=\"59\"
    <Tile colour="green" id="59" name="59">
-       <Station id="city1" position="052" slots="1" type="City" value="40"/>
-       <Station id="city2" position="352" slots="1" type="City" value="40"/>
+       <Station id="city1" position="152" slots="1" type="City" value="40"/>
+       <Station id="city2" position="452" slots="1" type="City" value="40"/>
        <Track from="city1" gauge="normal" to="side1"/>
        <Track from="city2" gauge="normal" to="side3"/>
    </Tile>

I can find no reason for this change.  The tile dictionary and the code used to generate Tiles.xml (in utils/ ) shows no changes that look like they could cause this to happen.

When I hand-edit the Tiles.xml file for 1830 to revert to 052/352 in place of 152/452, the tokens once more line up with the stops on the tile, but this is not a good solution.

Bill

Re: [Rails-devel] Tokens misplaced on tile #59?

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

>>  Using git bisect I am able to track the offending commit (at least as
far as 1830 goes) to commit 0c69cf, which introduced the Coalfields variant.
Digging further, the cities on tile #59 were at positions  052 and 352
before this commit, but at positions 152 and 452 following the commit.
>>

This puzzles me. As far as I can see, the position values 152 and 452 for
tile #59 exist since the introduction of these codes 6 years ago.

It turns out, that this kind of token misplacement only occurs 
- in games with EW-oriented tiles
- for tokenable cities that are located off-center
- but only for cities located near a tile corner, not if located near a tile
edge.

Token locations are calculated in GUIHex.getTokenCenter(), and so far I
can't find anything that can explain why only corner-facing cities would
suffer from this problem.
I can't find anything irregular, neither in this code, nor in the
translations from the TileDesigner city location names  to my position codes
in ConvertTilesXML cityMap.

Erik.

> -----Original Message-----
> From: Erik Vos [mailto:eri...@xs...]
> Sent: Wednesday, October 05, 2011 11:39 PM
> To: 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] Tokens misplaced on tile #59?
> 
> It's actually a 30 degrees clockwise rotation.
> 
> I'll have a look tomorrow. One possibility is that some code has got
confused
> with respect to the hex orientation (NS or EW).  I know there have been
> changes around the hex orientation logic, and maybe some consequence of
> that has been missed.
> 
> Erik.
> 
> > -----Original Message-----
> > From: Bill Rosgen [mailto:ro...@gm...]
> > Sent: Wednesday, October 05, 2011 6:52 PM
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] Tokens misplaced on tile #59?
> >
> > This happens in new games created and played with 1.5, and it also
> > happens in games created and played in older versions.
> >
> > If the bug isn't universal, I can post screenshots that demonstrate
> > the problem.  It would be odd, however, if the change in the data
> > files was
> not
> > the source of the problem.  I cannot, however, find an explanation for
> > the changes to the (automatically generated) data files.
> >
> > Bill
> >
> > On 2011-10-05, at 22:08 , Phil Davies wrote:
> >
> > > I've not noticed this problem but does it occur if you replay a game
> > > from the start?  I wonder if this is an issue of using an old save
> > > with newer codebase?
> > >
> > > I'll try these out later and see
> > >
> > > Phil
> > >
> > > On 5 October 2011 14:56, Bill Rosgen <ro...@gm...> wrote:
> > >> Hello,
> > >>
> > >> Am I the only one who is seeing tokens misplaced on tile #59.
> (Actually, it
> > seems to be any station with position x5y for arbitrary x and y.)
> Specifically,
> > they appear one 60 degree rotation from the correct place.  I've
> > attached
> a
> > savegame that shows this for the Erie's home hex.  This also appears
> > in
> the
> > 1830 Reading variant, with the preprinted PRR and the RDG home tiles.
> > >>
> > >> I have spent some time this evening trying to find the problem, but
> > >> I
> am
> > largely at a loss.  Using git bisect I am able to track the offending
> commit (at
> > least as far as 1830 goes) to commit 0c69cf, which introduced the
> Coalfields
> > variant.  Digging further, the cities on tile #59 were at positions
> > 052
> and 352
> > before this commit, but at positions 152 and 452 following the commit.
> > >>
> > >> This, one would think, could be easily found in the data files, or
> > >> in
> the
> > code that generates data/Tiles.xml from data/TileDictionary.xml.  I
> > have looked at the previous commit that modified Tiles.xml: I can see
> > the
> change
> > in tile #59 (and presumably other tiles also), but I cannot find any
> changes to
> > the tile database or the program that generates Tiles.xml that look
> > like
> they
> > would cause this change.
> > >>
> > >> I can (and will) continue to try to find the source of the problem,
> > >> as
> clearly
> > hand-editing the generated Tiles.xml files is not a solution, but I
> thought I
> > would ask to see if anyone knows how/why such a change might have
> been
> > introduced.
> > >>
> > >> The two attached savegames show the problem (at least on my end).
> > >> The
> > 1830 savegame has the Erie's home token out of place, and the 1830R
> > savegame has the RDG's token (among others) in the wrong place.  If
> > you
> are
> > checking out old code, note that only the 1830 savegame is likely to
> > work,
> as
> > the 1830 Reading savegame requires fixes that were only released in
> > Rails 1.5.
> > >>
> > >> Bill
> > >>
> > >> -------------------------------------------------------------------
> > >> --
> > >> --------- 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. Business sense.
IT
> sense.
> > >> Common sense.
> > >> http://p.sf.net/sfu/splunk-d2dcopy1
> > >> _______________________________________________
> > >> 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. Business sense. IT
> sense. Common sense.
> > > http://p.sf.net/sfu/splunk-d2dcopy1
> > > _______________________________________________
> > > 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.
> > Business sense. IT sense. Common sense.
> > http://p.sf.net/sfu/splunk-d2dcopy1
> > _______________________________________________
> > 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.
> Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Tokens misplaced on tile #59?

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

It's actually a 30 degrees clockwise rotation. 

I'll have a look tomorrow. One possibility is that some code has got
confused with respect to the hex orientation (NS or EW).  I know there have
been changes around the hex orientation logic, and maybe some consequence of
that has been missed. 

Erik.

> -----Original Message-----
> From: Bill Rosgen [mailto:ro...@gm...]
> Sent: Wednesday, October 05, 2011 6:52 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Tokens misplaced on tile #59?
> 
> This happens in new games created and played with 1.5, and it also happens
> in games created and played in older versions.
> 
> If the bug isn't universal, I can post screenshots that demonstrate the
> problem.  It would be odd, however, if the change in the data files was
not
> the source of the problem.  I cannot, however, find an explanation for the
> changes to the (automatically generated) data files.
> 
> Bill
> 
> On 2011-10-05, at 22:08 , Phil Davies wrote:
> 
> > I've not noticed this problem but does it occur if you replay a game
> > from the start?  I wonder if this is an issue of using an old save
> > with newer codebase?
> >
> > I'll try these out later and see
> >
> > Phil
> >
> > On 5 October 2011 14:56, Bill Rosgen <ro...@gm...> wrote:
> >> Hello,
> >>
> >> Am I the only one who is seeing tokens misplaced on tile #59.
(Actually, it
> seems to be any station with position x5y for arbitrary x and y.)
Specifically,
> they appear one 60 degree rotation from the correct place.  I've attached
a
> savegame that shows this for the Erie's home hex.  This also appears in
the
> 1830 Reading variant, with the preprinted PRR and the RDG home tiles.
> >>
> >> I have spent some time this evening trying to find the problem, but I
am
> largely at a loss.  Using git bisect I am able to track the offending
commit (at
> least as far as 1830 goes) to commit 0c69cf, which introduced the
Coalfields
> variant.  Digging further, the cities on tile #59 were at positions  052
and 352
> before this commit, but at positions 152 and 452 following the commit.
> >>
> >> This, one would think, could be easily found in the data files, or in
the
> code that generates data/Tiles.xml from data/TileDictionary.xml.  I have
> looked at the previous commit that modified Tiles.xml: I can see the
change
> in tile #59 (and presumably other tiles also), but I cannot find any
changes to
> the tile database or the program that generates Tiles.xml that look like
they
> would cause this change.
> >>
> >> I can (and will) continue to try to find the source of the problem, as
clearly
> hand-editing the generated Tiles.xml files is not a solution, but I
thought I
> would ask to see if anyone knows how/why such a change might have been
> introduced.
> >>
> >> The two attached savegames show the problem (at least on my end).  The
> 1830 savegame has the Erie's home token out of place, and the 1830R
> savegame has the RDG's token (among others) in the wrong place.  If you
are
> checking out old code, note that only the 1830 savegame is likely to work,
as
> the 1830 Reading savegame requires fixes that were only released in Rails
> 1.5.
> >>
> >> Bill
> >>
> >> ---------------------------------------------------------------------
> >> --------- 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. Business sense. IT sense.
> >> Common sense.
> >> http://p.sf.net/sfu/splunk-d2dcopy1
> >> _______________________________________________
> >> 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. Business sense. IT sense. Common sense.
> > http://p.sf.net/sfu/splunk-d2dcopy1
> > _______________________________________________
> > 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.
> Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Tokens misplaced on tile #59?

[Bill R. <ro...@gm...>]

This happens in new games created and played with 1.5, and it also happens in games created and played in older versions.

If the bug isn't universal, I can post screenshots that demonstrate the problem.  It would be odd, however, if the change in the data files was not the source of the problem.  I cannot, however, find an explanation for the changes to the (automatically generated) data files.

Bill

On 2011-10-05, at 22:08 , Phil Davies wrote:

> I've not noticed this problem but does it occur if you replay a game
> from the start?  I wonder if this is an issue of using an old save
> with newer codebase?
> 
> I'll try these out later and see
> 
> Phil
> 
> On 5 October 2011 14:56, Bill Rosgen <ro...@gm...> wrote:
>> Hello,
>> 
>> Am I the only one who is seeing tokens misplaced on tile #59.  (Actually, it seems to be any station with position x5y for arbitrary x and y.)  Specifically, they appear one 60 degree rotation from the correct place.  I've attached a savegame that shows this for the Erie's home hex.  This also appears in the 1830 Reading variant, with the preprinted PRR and the RDG home tiles.
>> 
>> I have spent some time this evening trying to find the problem, but I am largely at a loss.  Using git bisect I am able to track the offending commit (at least as far as 1830 goes) to commit 0c69cf, which introduced the Coalfields variant.  Digging further, the cities on tile #59 were at positions  052 and 352 before this commit, but at positions 152 and 452 following the commit.
>> 
>> This, one would think, could be easily found in the data files, or in the code that generates data/Tiles.xml from data/TileDictionary.xml.  I have looked at the previous commit that modified Tiles.xml: I can see the change in tile #59 (and presumably other tiles also), but I cannot find any changes to the tile database or the program that generates Tiles.xml that look like they would cause this change.
>> 
>> I can (and will) continue to try to find the source of the problem, as clearly hand-editing the generated Tiles.xml files is not a solution, but I thought I would ask to see if anyone knows how/why such a change might have been introduced.
>> 
>> The two attached savegames show the problem (at least on my end).  The 1830 savegame has the Erie's home token out of place, and the 1830R savegame has the RDG's token (among others) in the wrong place.  If you are checking out old code, note that only the 1830 savegame is likely to work, as the 1830 Reading savegame requires fixes that were only released in Rails 1.5.
>> 
>> Bill
>> 
>> ------------------------------------------------------------------------------
>> 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. Business sense. IT sense. Common sense.
>> http://p.sf.net/sfu/splunk-d2dcopy1
>> _______________________________________________
>> 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. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Tokens misplaced on tile #59?

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

I've not noticed this problem but does it occur if you replay a game
from the start?  I wonder if this is an issue of using an old save
with newer codebase?

I'll try these out later and see

Phil

On 5 October 2011 14:56, Bill Rosgen <ro...@gm...> wrote:
> Hello,
>
> Am I the only one who is seeing tokens misplaced on tile #59.  (Actually, it seems to be any station with position x5y for arbitrary x and y.)  Specifically, they appear one 60 degree rotation from the correct place.  I've attached a savegame that shows this for the Erie's home hex.  This also appears in the 1830 Reading variant, with the preprinted PRR and the RDG home tiles.
>
> I have spent some time this evening trying to find the problem, but I am largely at a loss.  Using git bisect I am able to track the offending commit (at least as far as 1830 goes) to commit 0c69cf, which introduced the Coalfields variant.  Digging further, the cities on tile #59 were at positions  052 and 352 before this commit, but at positions 152 and 452 following the commit.
>
> This, one would think, could be easily found in the data files, or in the code that generates data/Tiles.xml from data/TileDictionary.xml.  I have looked at the previous commit that modified Tiles.xml: I can see the change in tile #59 (and presumably other tiles also), but I cannot find any changes to the tile database or the program that generates Tiles.xml that look like they would cause this change.
>
> I can (and will) continue to try to find the source of the problem, as clearly hand-editing the generated Tiles.xml files is not a solution, but I thought I would ask to see if anyone knows how/why such a change might have been introduced.
>
> The two attached savegames show the problem (at least on my end).  The 1830 savegame has the Erie's home token out of place, and the 1830R savegame has the RDG's token (among others) in the wrong place.  If you are checking out old code, note that only the 1830 savegame is likely to work, as the 1830 Reading savegame requires fixes that were only released in Rails 1.5.
>
> Bill
>
> ------------------------------------------------------------------------------
> 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. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

[Rails-devel] Tokens misplaced on tile #59?

[Bill R. <ro...@gm...>]

Hello,

Am I the only one who is seeing tokens misplaced on tile #59.  (Actually, it seems to be any station with position x5y for arbitrary x and y.)  Specifically, they appear one 60 degree rotation from the correct place.  I've attached a savegame that shows this for the Erie's home hex.  This also appears in the 1830 Reading variant, with the preprinted PRR and the RDG home tiles.

I have spent some time this evening trying to find the problem, but I am largely at a loss.  Using git bisect I am able to track the offending commit (at least as far as 1830 goes) to commit 0c69cf, which introduced the Coalfields variant.  Digging further, the cities on tile #59 were at positions  052 and 352 before this commit, but at positions 152 and 452 following the commit.

This, one would think, could be easily found in the data files, or in the code that generates data/Tiles.xml from data/TileDictionary.xml.  I have looked at the previous commit that modified Tiles.xml: I can see the change in tile #59 (and presumably other tiles also), but I cannot find any changes to the tile database or the program that generates Tiles.xml that look like they would cause this change.

I can (and will) continue to try to find the source of the problem, as clearly hand-editing the generated Tiles.xml files is not a solution, but I thought I would ask to see if anyone knows how/why such a change might have been introduced.

The two attached savegames show the problem (at least on my end).  The 1830 savegame has the Erie's home token out of place, and the 1830R savegame has the RDG's token (among others) in the wrong place.  If you are checking out old code, note that only the 1830 savegame is likely to work, as the 1830 Reading savegame requires fixes that were only released in Rails 1.5.

Bill

Re: [Rails-devel] StartRoundWindow class ?

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

Hi Eric,

Thanks i'll test it tonight and i'll send out my current development in a patch out also.

Von meinem iPad gesendet

Am 04.10.2011 um 19:52 schrieb "Erik Vos" <eri...@xs...>:

> Martin,
> 
>  
> 
> I have added the option to specify a game-specific StartRoundWindow subclass, and added the empty class StartRoundWindow_1880.
> 
> I couldn’t test it, because I’m missing another class, so I have to leave that to you.
> 
>  
> 
> Erik.
> 
>  
> 
> From: Erik Vos [mailto:eri...@xs...] 
> Sent: Tuesday, October 04, 2011 2:58 PM
> To: Dr....@t-...
> Cc: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] StartRoundWindow class ?
> 
>  
> 
> Exactly.  I meant that the mechanism to invoke a game-specific StartRoundWindow (if needed at all) would be very similar.  It has to be coded first, of course, but that would be just more-of-the-same. 
> 
>  
> 
> I understand you don’t want to try it yourself, so I’ll put it on my to-do list.
> 
>  
> 
> Erik.
> 
>  
> 
> From: Dr....@t-... [mailto:Dr....@t-...] 
> Sent: Tuesday, October 04, 2011 1:56 PM
> To: Erik Vos
> Subject: Re: [Rails-devel] StartRoundWindow class ?
> 
>  
> 
> Hi Erik,
>  
> we are not talking about StatusWindows :)
>  
> We are talking about StartRoundWindow and theres no example yet.
>  
> Von: "Erik Vos" <eri...@xs...>
> An: <Dr....@t-...>, "'Development list for Rails: an 18xx game'" <rai...@li...>
> Betreff: Re: [Rails-devel] StartRoundWindow class ?
> Datum: Mon, 03 Oct 2011 18:25:05 +0200
>  
>  
> I suppose not, because all varieties could so far be fitted into the standard version.
> 
> Adding such an option should be pretty simple, similar to StatusWindow_1835.
> 
>  
> 
> Please note that new dialogs should preferably be non-modal. GameUIManager has some hooks to handle such dialogs.
> 
>  
> 
> Erik.
> 
>  
> 
> From: Dr....@t-... [mailto:Dr....@t-...] 
> Sent: Monday, October 03, 2011 5:18 PM
> To: Rails Development
> Subject: [Rails-devel] StartRoundWindow class ?
> 
>  
> 
> Hi Eric, Brett & Stefan,
>  
> do i understand the Code right that there is currently no mechanismn to detect, load and use a different StartRoundWindow GuiClass ?
>  
> I was trying to use a specific StartRoundWindow for 1880 to handle the player order display and introduce the BuildingRightDialog.
>  
> Regards,
> Martin
>  
> ------------------------------------------------------------------------------
> 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. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] StartRoundWindow class ?

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

Martin,

 

I have added the option to specify a game-specific StartRoundWindow subclass, and added the empty class StartRoundWindow_1880.

I couldn’t test it, because I’m missing another class, so I have to leave that to you.

 

Erik.

 

From: Erik Vos [mailto:eri...@xs...] 
Sent: Tuesday, October 04, 2011 2:58 PM
To: Dr....@t-...
Cc: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] StartRoundWindow class ?

 

Exactly.  I meant that the mechanism to invoke a game-specific StartRoundWindow (if needed at all) would be very similar.  It has to be coded first, of course, but that would be just more-of-the-same.  

 

I understand you don’t want to try it yourself, so I’ll put it on my to-do list.

 

Erik.

 

From: Dr....@t-... [mailto:Dr....@t-...] 
Sent: Tuesday, October 04, 2011 1:56 PM
To: Erik Vos
Subject: Re: [Rails-devel] StartRoundWindow class ?

 

Hi Erik,

 

we are not talking about StatusWindows :)

 

We are talking about StartRoundWindow and theres no example yet. 

 

Von: "Erik Vos" <eri...@xs...>

An: <Dr....@t-...>, "'Development list for Rails: an 18xx game'" <rai...@li...>

Betreff: Re: [Rails-devel] StartRoundWindow class ?

Datum: Mon, 03 Oct 2011 18:25:05 +0200

 

 

I suppose not, because all varieties could so far be fitted into the standard version.

Adding such an option should be pretty simple, similar to StatusWindow_1835.

 

Please note that new dialogs should preferably be non-modal. GameUIManager has some hooks to handle such dialogs. 

 

Erik.

 

From: Dr....@t-... [mailto:Dr....@t-...] 
Sent: Monday, October 03, 2011 5:18 PM
To: Rails Development
Subject: [Rails-devel] StartRoundWindow class ?

 

Hi Eric, Brett & Stefan,

 

do i understand the Code right that there is currently no mechanismn to detect, load and use a different StartRoundWindow GuiClass ?

 

I was trying to use a specific StartRoundWindow for 1880 to handle the player order display and introduce the BuildingRightDialog.

 

Regards,
Martin

 

Re: [Rails-devel] Bug in 1856

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

Bill, your fix did the job, but in a way that is not so easy to understand -
at least, it took me a while.

The underlying problem is, that one (the just bought) share was
unconditionally subtracted *after* the check was done if there is enough
space in the Pool.
Buying from the Pool creates space for two shares, buying from IPO leaves
one space. In the latter case, no further deduction should have happened.

I have now reversed the sequence of these two checks, and all is fine.  Your
fix essentially did the same thing, but now *I* can understand the code...:)

The test set also succeeds, apart from the usual KKÖB Unicode mismatch in
18EU.

Erik.

> -----Original Message-----
> From: Bill Rosgen [mailto:ro...@gm...]
> Sent: Tuesday, October 04, 2011 11:32 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Bug in 1856
> 
> Since I already have a fix sitting in a dev-branch, here is an Eclipse
patch to fix
> the current problem.  If you'd rather fix it in some other way, please
feel free
> :)
> 
> The result is that if you buy a share in a company in a stock turn, then
at the
> end of the stock turn you must hold at least one share of that company.
This
> changes the way Rails behaves regarding presidencies.  It is now legal to
start
> the turn with only the presidency of a company and buy and sell a single
> share.
> 
> I agree that this is the most reasonable interpretation, and it seems to
> correspond to the intent of the designer, but I wanted to be explicit that
a
> change in behaviour is being made, even if no change in intent is present.
> 
> Bill

Re: [Rails-devel] StartRoundWindow class ?

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

Exactly.  I meant that the mechanism to invoke a game-specific StartRoundWindow (if needed at all) would be very similar.  It has to be coded first, of course, but that would be just more-of-the-same.  

 

I understand you don’t want to try it yourself, so I’ll put it on my to-do list.

 

Erik.

 

From: Dr....@t-... [mailto:Dr....@t-...] 
Sent: Tuesday, October 04, 2011 1:56 PM
To: Erik Vos
Subject: Re: [Rails-devel] StartRoundWindow class ?

 

Hi Erik,

 

we are not talking about StatusWindows :)

 

We are talking about StartRoundWindow and theres no example yet. 

 

Von: "Erik Vos" <eri...@xs...>

An: <Dr....@t-...>, "'Development list for Rails: an 18xx game'" <rai...@li...>

Betreff: Re: [Rails-devel] StartRoundWindow class ?

Datum: Mon, 03 Oct 2011 18:25:05 +0200

 

 

I suppose not, because all varieties could so far be fitted into the standard version.

Adding such an option should be pretty simple, similar to StatusWindow_1835.

 

Please note that new dialogs should preferably be non-modal. GameUIManager has some hooks to handle such dialogs. 

 

Erik.

 

From: Dr....@t-... [mailto:Dr....@t-...] 
Sent: Monday, October 03, 2011 5:18 PM
To: Rails Development
Subject: [Rails-devel] StartRoundWindow class ?

 

Hi Eric, Brett & Stefan,

 

do i understand the Code right that there is currently no mechanismn to detect, load and use a different StartRoundWindow GuiClass ?

 

I was trying to use a specific StartRoundWindow for 1880 to handle the player order display and introduce the BuildingRightDialog.

 

Regards,
Martin

 

Re: [Rails-devel] Bug in 1856

[Bill R. <ro...@gm...>]

Since I already have a fix sitting in a dev-branch, here is an Eclipse patch to fix the current problem.  If you'd rather fix it in some other way, please feel free :)

The result is that if you buy a share in a company in a stock turn, then at the end of the stock turn you must hold at least one share of that company.  This changes the way Rails behaves regarding presidencies.  It is now legal to start the turn with only the presidency of a company and buy and sell a single share.

I agree that this is the most reasonable interpretation, and it seems to correspond to the intent of the designer, but I wanted to be explicit that a change in behaviour is being made, even if no change in intent is present.

Bill

Re: [Rails-devel] Bug in 1856

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

In the context of stock rounds, I have always interpreted 'share' as to mean
a certain percentage of ownership (usually 10%), not a physical share.

The Rails implementation of this rule intends to follow that view: a player
may, at the end of a turn, not own less shares than he has bought in that
turn.
It seems to me that this corresponds to Steve's interpretation (because you
can only buy one share in a turn, you must retain at least one share if you
bought one).

Now the rules talk about 'certificates', which are physical shares, and I
suppose that's where a contradiction is seen. But if the designer has
(implicitly or explicitly) made clear that he actually meant 'shares', I see
no problem in following that clarification, which to me correctly catches
the spirit, if not the letter, of the rule as written.

Whether or not Rails had *correctly* implemented this all, is another
matter.  Certainly the source of a bought share (IPO or Pool) should not
matter, but it currently does, and that is what I need to sort out first.

Erik.

> -----Original Message-----
> From: Bill Rosgen [mailto:ro...@gm...]
> Sent: Tuesday, October 04, 2011 6:50 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Bug in 1856
> 
> Erik,
> 
> As you may already have discovered, the problem is an interaction with the
> code that checks if a share fits into the pool and the code that checks if
we
> can sell a just bought share.  In this case both of these checks are
reducing
> the number of shares we can sell, i.e. the code is double counting in this
> case.  The easy fix is to add the check that 'number ==
shareCountPerUnit[i]'
> on line 442.
> 
> The problem is that this introduces another problem.  With this check
added
> a player who owns only the presidency of a company may buy and then
> immediately sell a 10% certificate, which is currently forbidden by Rails.
A
> reading of the rulebook supports the way that Rails currently handles
things:
> 
> "A certificate cannot be sold during the stock turn it was purchased."
> 
> Steve Thomas's list of 1856 clarifications (at
> http://www.18xx.net/1856/1856f.htm) contradicts this, saying that:
> 
> {p12} A player may sell stock in a Corporation bought earlier in the same
turn
> of a stock round but must retain at least one share in the Corporation
just
> bought. If necessary the same certificate may be bought then sold
> immediately. For example, a player owning just the President's certificate
of
> a Corporation may buy and then sell a share of that Corporation. [This
ruling
> directly contradicts the statement on p12, but accurately reflects the
> intentions of Bill Dixon.]
> 
> This clarification agrees with the simple fix suggested above, but it
disagrees
> with the rules.  The more complicated fix that agrees with the rules as
> written is to check if either 'number == shareCountPerUnit[i]' or in the
case
> that the current player is the president and the company is *not* dumpable
> that 'number == shareCountPerUnit[i] - 2'.  It may also be simpler just to
> check if the space in the pool has reduced maxShareToSell and not
> decrement the number of shares available for sale if this is the case.
> 
> I'd have included a patch, but it's not clear to me what the best solution
is.  If
> the implementation follows Steve Thomas's clarification list, then the fix
is
> relatively simple and I am happy with it, but this would be a change in
how
> Rails behaves.  If Rails is to follow the rulebook as written, then I'm
not really
> happy with the fix listed above as it requires testing for things like
> dumpability well outside of where the code for that currently resides.
> 
> Bill
> 
> 
> On 2011-10-04, at 0:44 , Erik Vos wrote:
> 
> > This only seems to occur if the second buy is from the IPO, not if from
the
> Pool.  Strange.
> > I'll investigate. There might be a connection with the
don't-sell-a-just-
> bought certificate rule.
> >
> > Erik.
> >
> >> -----Original Message-----
> >> From: ar...@gl... [mailto:ar...@gl...]
> >> Sent: Monday, October 03, 2011 8:25 AM
> >> To: rai...@li...
> >> Subject: [Rails-devel] Bug in 1856
> >>
> >>
> >> There is a bug in 1856.
> >>
> >> I own 10% of CPR and buys another 10%. Then I want to sell my
> >> previously owned share, but I can't. Save file attached. I run Rails
1.5.
> >>
> >> /Arne Östlund
> >
> >
> > ----------------------------------------------------------------------
> > -------- 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. Business sense. IT sense. Common sense.
> > http://p.sf.net/sfu/splunk-d2dcopy1
> > _______________________________________________
> > 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.
> Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Bug in 1856

[Bill R. <ro...@gm...>]

Erik,

As you may already have discovered, the problem is an interaction with the code that checks if a share fits into the pool and the code that checks if we can sell a just bought share.  In this case both of these checks are reducing the number of shares we can sell, i.e. the code is double counting in this case.  The easy fix is to add the check that 'number == shareCountPerUnit[i]' on line 442.

The problem is that this introduces another problem.  With this check added a player who owns only the presidency of a company may buy and then immediately sell a 10% certificate, which is currently forbidden by Rails.  A reading of the rulebook supports the way that Rails currently handles things: 

"A certificate cannot be sold during the stock turn it was purchased."

Steve Thomas's list of 1856 clarifications (at http://www.18xx.net/1856/1856f.htm) contradicts this, saying that:

{p12} A player may sell stock in a Corporation bought earlier in the same turn of a stock round but must retain at least one share in the Corporation just bought. If necessary the same certificate may be bought then sold immediately. For example, a player owning just the President's certificate of a Corporation may buy and then sell a share of that Corporation. [This ruling directly contradicts the statement on p12, but accurately reflects the intentions of Bill Dixon.]

This clarification agrees with the simple fix suggested above, but it disagrees with the rules.  The more complicated fix that agrees with the rules as written is to check if either 'number == shareCountPerUnit[i]' or in the case that the current player is the president and the company is *not* dumpable that 'number == shareCountPerUnit[i] - 2'.  It may also be simpler just to check if the space in the pool has reduced maxShareToSell and not decrement the number of shares available for sale if this is the case.

I'd have included a patch, but it's not clear to me what the best solution is.  If the implementation follows Steve Thomas's clarification list, then the fix is relatively simple and I am happy with it, but this would be a change in how Rails behaves.  If Rails is to follow the rulebook as written, then I'm not really happy with the fix listed above as it requires testing for things like dumpability well outside of where the code for that currently resides.

Bill


On 2011-10-04, at 0:44 , Erik Vos wrote:

> This only seems to occur if the second buy is from the IPO, not if from the Pool.  Strange.
> I'll investigate. There might be a connection with the don't-sell-a-just-bought certificate rule.
> 
> Erik.
> 
>> -----Original Message-----
>> From: ar...@gl... [mailto:ar...@gl...]
>> Sent: Monday, October 03, 2011 8:25 AM
>> To: rai...@li...
>> Subject: [Rails-devel] Bug in 1856
>> 
>> 
>> There is a bug in 1856.
>> 
>> I own 10% of CPR and buys another 10%. Then I want to sell my  previously
>> owned share, but I can't. Save file attached. I run Rails  1.5.
>> 
>> /Arne Östlund
> 
> 
> ------------------------------------------------------------------------------
> 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. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] StartRoundWindow class ?

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

Erik & Martin,
I will try to merge all new commits from Rails 1.x into the Rails 2.0 branch.
However over time it will get more difficult to do so.

Currently it only effects code that uses state or model mechanisms.
The next major step after that will cover all the  Round classes and related 
parts of the GameManager class.

Things I will not touch in the near future are the actions classes and all of 
the UI. A more detailed roadmap will follow.

Stefan

On Monday, October 03, 2011 06:25:05 pm Erik Vos wrote:
> I suppose not, because all varieties could so far be fitted into the
> standard version.
> 
> Adding such an option should be pretty simple, similar to
> StatusWindow_1835.
> 
> 
> 
> Please note that new dialogs should preferably be non-modal. GameUIManager
> has some hooks to handle such dialogs.
> 
> 
> 
> Erik.
> 
> 
> 
> From: Dr....@t-... [mailto:Dr....@t-...]
> Sent: Monday, October 03, 2011 5:18 PM
> To: Rails Development
> Subject: [Rails-devel] StartRoundWindow class ?
> 
> 
> 
> Hi Eric, Brett & Stefan,
> 
> 
> 
> do i understand the Code right that there is currently no mechanismn to
> detect, load and use a different StartRoundWindow GuiClass ?
> 
> 
> 
> I was trying to use a specific StartRoundWindow for 1880 to handle the
> player order display and introduce the BuildingRightDialog.
> 
> 
> 
> Regards,
> Martin

Re: [Rails-devel] Bug in 1856

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

Erik:
I will wait with a bug-fix release until you solved that one too.
Stefan

On Monday, October 03, 2011 06:44:22 pm Erik Vos wrote:
> This only seems to occur if the second buy is from the IPO, not if from the
> Pool.  Strange. I'll investigate. There might be a connection with the
> don't-sell-a-just-bought certificate rule.
> 
> Erik.
> 
> > -----Original Message-----
> > From: ar...@gl... [mailto:ar...@gl...]
> > Sent: Monday, October 03, 2011 8:25 AM
> > To: rai...@li...
> > Subject: [Rails-devel] Bug in 1856
> > 
> >  There is a bug in 1856.
> >  
> >  I own 10% of CPR and buys another 10%. Then I want to sell my 
> >  previously
> > 
> > owned share, but I can't. Save file attached. I run Rails  1.5.
> > 
> >  /Arne Östlund
> 
> ---------------------------------------------------------------------------
> --- 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. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Bug in 1856

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

This only seems to occur if the second buy is from the IPO, not if from the Pool.  Strange.
I'll investigate. There might be a connection with the don't-sell-a-just-bought certificate rule.

Erik.

> -----Original Message-----
> From: ar...@gl... [mailto:ar...@gl...]
> Sent: Monday, October 03, 2011 8:25 AM
> To: rai...@li...
> Subject: [Rails-devel] Bug in 1856
> 
> 
>  There is a bug in 1856.
> 
>  I own 10% of CPR and buys another 10%. Then I want to sell my  previously
> owned share, but I can't. Save file attached. I run Rails  1.5.
> 
>  /Arne Östlund

Re: [Rails-devel] StartRoundWindow class ?

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

I suppose not, because all varieties could so far be fitted into the standard version.

Adding such an option should be pretty simple, similar to StatusWindow_1835.

 

Please note that new dialogs should preferably be non-modal. GameUIManager has some hooks to handle such dialogs. 

 

Erik.

 

From: Dr....@t-... [mailto:Dr....@t-...] 
Sent: Monday, October 03, 2011 5:18 PM
To: Rails Development
Subject: [Rails-devel] StartRoundWindow class ?

 

Hi Eric, Brett & Stefan,

 

do i understand the Code right that there is currently no mechanismn to detect, load and use a different StartRoundWindow GuiClass ?

 

I was trying to use a specific StartRoundWindow for 1880 to handle the player order display and introduce the BuildingRightDialog.

 

Regards,
Martin

[Rails-devel] StartRoundWindow class ?

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

Hi Eric, Brett & Stefan, 

	do i understand the Code right that there is currently no mechanismn
to detect, load and use a different StartRoundWindow GuiClass ? 

	I was trying to use a specific StartRoundWindow for 1880 to handle
the player order display and introduce the BuildingRightDialog. 

	Regards,
Martin

Re: [Rails-devel] Bug (and patch): THB cannot lay home token with track already in hex

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

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
>
> As soon as Erik give his go that the patch does not other side-effects, I
will
> publish 1.5.1 with this fix.

Yes, I'm fine with this patch.

I have considered to decouple location multiplicity from action type in the
LayBaseToken constructors, by adding a second 'type' argument, but I have
finally decided to leave it as is, in order to maintain consistency with the
superclass constructors. To clarify usage, I have added Javadoc comments to
the three LayBaseToken constructors.

Erik.

[Rails-devel] Bug in 1856

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

 There is a bug in 1856.

 I own 10% of CPR and buys another 10%. Then I want to sell my 
 previously owned share, but I can't. Save file attached. I run Rails 
 1.5.

 /Arne Östlund