rails-devel — List for discussion of Rails development

Re: [Rails-devel] Push request: Enforcement of forced train purchases

[Frederick W. <fre...@go...>]

You are right that parts of the route calculation might be performed
twice. However:

(1) This only occurs if all other necessary conditions for forced
train purchases apply (see lazy route calculation in
OperatingRound.isForcedTrainPurchase).

(2) Even then, this duplication only applies to the initialization of
the network graph, as the second route determination is parameterized
differently with respect to trains (publicly available train types vs.
company owned ones (=zero) for triggering by the UI layer).

For the target design, I fully agree with you. The tricky part would
consist of avoiding duplication during graph construction and route
calculation, given that each OR-step is potentially based on a
different graph (eg., lay tile changes graph for lay token) and works
with different train sets (set revenue vs. forced train purchase).

Re: [Rails-devel] Push request: Enforcement of forced train purchases

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

OK, so at least part of the route determination calculations are now done
twice.  No big deal, probably.  
The long-term goal is to make the game engine fully aware of routes, so that
it can prescribe to the UI which tile and token lays are legal;  perhaps
this is a good first step.

Erik.

> -----Original Message-----
> From: Frederick Weld [mailto:fre...@go...]
> Sent: Friday, December 30, 2011 7:07 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Push request: Enforcement of forced train
> purchases
> 
> The new code complies to the layered architecture. This was achieved by
> calling the routing algorithms directly from the game engine instead of
relying
> on the UI layer for doing so (look for
OperatingRound.isValidRouteAvailable).
> 
> --- Frederick
> 
> On Thu, Dec 29, 2011 at 9:36 PM, Erik Vos <eri...@xs...> wrote:
> > So far, the game engine (OperatingRound etc.) was not aware of the
> > existence routes, because routes are currently only determined in the
> > UI code, and in the current architecture it is not allowed to use such
> > information directly in the game engine.  Some transfer mechanism
> > would be used, or the route determination would have to be repeated in
> the game engine.
> >
> > >From a first quick look it is not clear to me how you achieved route
> > existence in the game engine.  Could you please clarify that?
> >
> > Erik
> >
> >> -----Original Message-----
> >> From: Frederick Weld [mailto:fre...@go...]
> >> Sent: Thursday, December 29, 2011 8:46 PM
> >> To: rai...@li...
> >> Subject: [Rails-devel] Push request: Enforcement of forced train
> >> purchases
> >>
> >> Would you please push this into origin/master?
> >>
> >> ---Frederick
> >>
> >> commit 6acf6d95385c57d74a39781f5e14440f7eeb143c
> >>
> >>     Added enforcement of forced train purchases
> >>
> >>     Provides for functionality demanded by Feature Request 3040250
> >> (and
> >>     beyond).
> >>
> >>     Built on existing preliminary code (associated todos /
> >> temp-comments
> >>     are removed).
> >>
> >>     Expanded company config for requirement on owning trains (yes /
> >> only
> >>     if has route / no) according to
> >>     http://www.fwtwr.com/18xx/rules_difference_list/9_2.htm
> >>
> >>     Legacy save games remain usable as enforcement is turned off
> >> during
> >>     game loading.
> >>
> >>     No provision of automated test cases due to this turning off and
> >>     because current test infrastructure does not support negative
> >> tests
> >>     (ie., check for expected errors during game replay upon load).
> >
> >
> > ----------------------------------------------------------------------
> > -------- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't
> > need a complex infrastructure or vast IT resources to deliver
> > seamless, secure access to virtual desktops. With this all-in-one
> > solution, easily deploy virtual desktops for less than the cost of PCs
> > and save 60% on VDI infrastructure costs. Try it free!
> > http://p.sf.net/sfu/Citrix-VDIinabox
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
>
----------------------------------------------------------------------------
--
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
desktops
> for less than the cost of PCs and save 60% on VDI infrastructure costs.
Try it
> free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Why ist menu item Info->Network disabled for release versions?

[Frederick W. <fre...@go...>]

Wouldn't this also be interesting for the end-users (eg., see feature
request 3064835)?

--- Frederick

Re: [Rails-devel] Push request: Enforcement of forced train purchases

[Frederick W. <fre...@go...>]

The new code complies to the layered architecture. This was achieved
by calling the routing algorithms directly from the game engine
instead of relying on the UI layer for doing so (look for
OperatingRound.isValidRouteAvailable).

--- Frederick

On Thu, Dec 29, 2011 at 9:36 PM, Erik Vos <eri...@xs...> wrote:
> So far, the game engine (OperatingRound etc.) was not aware of the existence
> routes, because routes are currently only determined in the UI code, and in
> the current architecture it is not allowed to use such information directly
> in the game engine.  Some transfer mechanism would be used, or the route
> determination would have to be repeated in the game engine.
>
> >From a first quick look it is not clear to me how you achieved route
> existence in the game engine.  Could you please clarify that?
>
> Erik
>
>> -----Original Message-----
>> From: Frederick Weld [mailto:fre...@go...]
>> Sent: Thursday, December 29, 2011 8:46 PM
>> To: rai...@li...
>> Subject: [Rails-devel] Push request: Enforcement of forced train purchases
>>
>> Would you please push this into origin/master?
>>
>> ---Frederick
>>
>> commit 6acf6d95385c57d74a39781f5e14440f7eeb143c
>>
>>     Added enforcement of forced train purchases
>>
>>     Provides for functionality demanded by Feature Request 3040250 (and
>>     beyond).
>>
>>     Built on existing preliminary code (associated todos / temp-comments
>>     are removed).
>>
>>     Expanded company config for requirement on owning trains (yes / only
>>     if has route / no) according to
>>     http://www.fwtwr.com/18xx/rules_difference_list/9_2.htm
>>
>>     Legacy save games remain usable as enforcement is turned off during
>>     game loading.
>>
>>     No provision of automated test cases due to this turning off and
>>     because current test infrastructure does not support negative tests
>>     (ie., check for expected errors during game replay upon load).
>
>
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Question regarding PublicCompany.getNumberOfTileLays()

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

Hi Martin,

“Extra tiles” in this context means “more than one *normal* tile lay”.  If only one tile can be laid, there are by definition no “extra tiles”.
Frankly, I don’t see your problem, but maybe I’m misunderstanding your point (it is possible that playing 18VA today has completely dumbed me).

This code was written to cope with 18EU, where a minor can lay 2 tiles in its very first OR turn only. 

> P.s. I plan to add a Conf-Option ExtraTileLay with a Phase, Colour and number attribute, to make an "Phase permanent" extra tile Lay an configurable option for a public Company. Should it be done in PublicCompany (there might be another game besides 1880 using that feature) or should i pull it down to PublicCompany_1880 ?
 
Please have a look at 18EU/Game.xml line 105, where the once-only extra tile lay is defined for the 18EU minors, as described  above.  
Without the "occurrences" attribute, the extra tile lay should be permanent.  
Could you give BCR its own, unique company type, so that you can use this <Lay> tag the way it is? 
Another (slightly less desirable) option could be to add a new attribute company="BCR" to the <Lay> tag.  That would obviously require some extra code, and perhaps refactoring.

If this all doesn't work or is too cumbersome, you might indeed consider to put it as a special into PublicCompany_1880.

Erik.

Re: [Rails-devel] Push request: Enforcement of forced train purchases

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

So far, the game engine (OperatingRound etc.) was not aware of the existence
routes, because routes are currently only determined in the UI code, and in
the current architecture it is not allowed to use such information directly
in the game engine.  Some transfer mechanism would be used, or the route
determination would have to be repeated in the game engine.

>From a first quick look it is not clear to me how you achieved route
existence in the game engine.  Could you please clarify that?  

Erik

> -----Original Message-----
> From: Frederick Weld [mailto:fre...@go...]
> Sent: Thursday, December 29, 2011 8:46 PM
> To: rai...@li...
> Subject: [Rails-devel] Push request: Enforcement of forced train purchases
> 
> Would you please push this into origin/master?
> 
> ---Frederick
> 
> commit 6acf6d95385c57d74a39781f5e14440f7eeb143c
> 
>     Added enforcement of forced train purchases
> 
>     Provides for functionality demanded by Feature Request 3040250 (and
>     beyond).
> 
>     Built on existing preliminary code (associated todos / temp-comments
>     are removed).
> 
>     Expanded company config for requirement on owning trains (yes / only
>     if has route / no) according to
>     http://www.fwtwr.com/18xx/rules_difference_list/9_2.htm
> 
>     Legacy save games remain usable as enforcement is turned off during
>     game loading.
> 
>     No provision of automated test cases due to this turning off and
>     because current test infrastructure does not support negative tests
>     (ie., check for expected errors during game replay upon load).

[Rails-devel] Push request: Enforcement of forced train purchases

[Frederick W. <fre...@go...>]

Would you please push this into origin/master?

---Frederick

commit 6acf6d95385c57d74a39781f5e14440f7eeb143c

    Added enforcement of forced train purchases

    Provides for functionality demanded by Feature Request 3040250 (and
    beyond).

    Built on existing preliminary code (associated todos / temp-comments
    are removed).

    Expanded company config for requirement on owning trains (yes / only
    if has route / no) according to
    http://www.fwtwr.com/18xx/rules_difference_list/9_2.htm

    Legacy save games remain usable as enforcement is turned off during
    game loading.

    No provision of automated test cases due to this turning off and
    because current test infrastructure does not support negative tests
    (ie., check for expected errors during game replay upon load).

[Rails-devel] Question regarding PublicCompany.getNumberOfTileLays()

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

Hi Erik et al. 

	trying to implement an additional standard tile lay (yellow) for one
company i stumbled upon the following code. 

	Either i misunderstand the mechanismn or theres a bug in there ? 

	Original Code following: 

	public int getNumberOfTileLays(String tileColour) {

        PhaseI phase =
gameManager.getPhaseManager().getCurrentPhase();

        // New style
        int tileLays = phase.getTileLaysPerColour(getTypeName(),
tileColour);
        if (tileLays <= 1)  {
            extraTileLays = null;
            return tileLays;
        }
 --- So if theres a phase with one tile only defined this will never
lead to an extratile being available ??? because the latter part isnt
checked ?    

        // More than one tile lay allowed.
        // Check if there is a limitation on the number of turns that
this is valid.
        if (turnsWithExtraTileLays != null) {
            extraTiles = turnsWithExtraTileLays.get(tileColour);
        }

        if (extraTiles != null) {
            if (extraTiles.intValue() == 0) {
                extraTiles = null;
                return 1;
            }
        }

        return tileLays;
    } 

	I think it should be done like the following ? But maybe i am
mistaken and someone can show me what i missed ? :) 

	public int getNumberOfTileLays(String tileColour) {

        PhaseI phase =
gameManager.getPhaseManager().getCurrentPhase();

        // New style
        int tileLays = phase.getTileLaysPerColour(getTypeName(),
tileColour);

        // More than one tile lay allowed.
        // Check if there is a limitation on the number of turns that
this is valid.
        if (turnsWithExtraTileLays != null) {
            extraTiles = turnsWithExtraTileLays.get(tileColour);
        }
        if ((tileLays <= 1) && (extraTiles == null)) {
            extraTileLays = null;
            return tileLays;
        }

        if (extraTiles != null) {
            if (extraTiles.intValue() == 0) {
                extraTiles = null;
                return 1;
            }
        }

        return tileLays;
    }  

	Regards, 

	Martin 

	P.s. I plan to add a Conf-Option ExtraTileLay with a Phase, Colour
and number attribute, to make an "Phase permanent" extra tile Lay an
configurable option for a public Company. Should it be done in
PublicCompany (there might be another game besides 1880 using that
feature) or should i pull it down to PublicCompany_1880 ?

Re: [Rails-devel] Push request: 2 minor bug fixes (autosave handling and defaulting of game options)

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

> From: Frederick Weld [mailto:fre...@go...]
> 
>     Fixed retrieval of default game options (if options pane was not
opened)
> 
>     Game options have to be read from GamesList.xml and not from the
>     respective game's Games.xml GameOption tags.
>     Before the fix, this was not the case if the options pane had not been
>     opened (which is the moment at which the GamesList's default options
>     were loaded).
> 
>     This fix also solves Bug 3448429, as the reported missing 18EU route
>     calculation was due to inconsistent defaulting between GamesList
>     (default=suggest) and Games (default=deactivate). Now, the defaults
>     are always taken from GamesList.

I vaguely remember that Stefan had a good reason why it was implemented with
different defaults.  
Or was that only for backward compatibility at some point?

Erik.

Re: [Rails-devel] Push request: 2 minor bug fixes (autosave handling and defaulting of game options)

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

Looks good.  Applied.

Thanks!

---Brett.



On Tue, Dec 27, 2011 at 1:59 PM, Frederick Weld
<fre...@go...> wrote:
> Would you please push these patches into origin/master?
>
> --- Frederick
>
> commit 6144b4c35787a884be65a11d08f662f9f5b3ca7a
>
>    Fixed retrieval of default game options (if options pane was not opened)
>
>    Game options have to be read from GamesList.xml and not from the
>    respective game's Games.xml GameOption tags.
>    Before the fix, this was not the case if the options pane had not been
>    opened (which is the moment at which the GamesList's default options
>    were loaded).
>
>    This fix also solves Bug 3448429, as the reported missing 18EU route
>    calculation was due to inconsistent defaulting between GamesList
>    (default=suggest) and Games (default=deactivate). Now, the defaults
>    are always taken from GamesList.
>
> commit f8a0b7eaf7334fd36973df9e82e6dd1d1e76dea0
>
>    Fixed autosave functionality (handling of 18xx_autosave.xxx files)
>
>    Target design is that
>    (1) new temp file (.tmp) is created
>    (2) former autosave (.rails) becomes the backup autosave (.rails.bak)
>    (3) temp file (.tmp) becomes the new autosave (.rails)
>
>    Prior to the fix, the implementation did not process step (2) correctly,
>    as backup autosaves were never dropped. This meant that autosave resulted
>    in an error message and three files in the autosave folder (.tmp , .rails ,
>    .rails.bak). That's why autosave had never worked for me (and I doubt that
>    it could have worked for others).
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

[Rails-devel] Push request: 2 minor bug fixes (autosave handling and defaulting of game options)

[Frederick W. <fre...@go...>]

Would you please push these patches into origin/master?

--- Frederick

commit 6144b4c35787a884be65a11d08f662f9f5b3ca7a

    Fixed retrieval of default game options (if options pane was not opened)

    Game options have to be read from GamesList.xml and not from the
    respective game's Games.xml GameOption tags.
    Before the fix, this was not the case if the options pane had not been
    opened (which is the moment at which the GamesList's default options
    were loaded).

    This fix also solves Bug 3448429, as the reported missing 18EU route
    calculation was due to inconsistent defaulting between GamesList
    (default=suggest) and Games (default=deactivate). Now, the defaults
    are always taken from GamesList.

commit f8a0b7eaf7334fd36973df9e82e6dd1d1e76dea0

    Fixed autosave functionality (handling of 18xx_autosave.xxx files)

    Target design is that
    (1) new temp file (.tmp) is created
    (2) former autosave (.rails) becomes the backup autosave (.rails.bak)
    (3) temp file (.tmp) becomes the new autosave (.rails)

    Prior to the fix, the implementation did not process step (2) correctly,
    as backup autosaves were never dropped. This meant that autosave resulted
    in an error message and three files in the autosave folder (.tmp , .rails ,
    .rails.bak). That's why autosave had never worked for me (and I doubt that
    it could have worked for others).

Re: [Rails-devel] Push request: New fit-to-xyz zoom options, 1889 background map, 2-player 18AL

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

Committed and pushed.
Thanks!
---Brett.



On Mon, Dec 26, 2011 at 3:46 AM, Frederick Weld
<fre...@go...> wrote:
> Would you please git push these patches to origin/master?
>
> --Frederick
>
> commit 5b1e6f88421cd54246af9463c28d75a578ad16dc
>
>    Added background map for 1889
>
> commit 010d549bce2beb95d3692683a9afdfd63d1fd34c
>
>    Added zoom options fit-to-window/width/height
>
>    The current zoom step concept has not been altered. The
>    new zoom options are not pixel based  but, instead of that, the code
>    determines the appropriate zoom step and triggers the existing zoom logic.
>    Minor refactoring was needed in order to avoid code duplication.
>
> commit 49406f24edd329628b4f9bd8404d75c817e9461a
>
>    Added option to start 2-player 18AL games
>
>    Although the 18AL rules do not state that 2-player games are allowed,
>    there is no reason why rails should prohibit this setup if the rails
>    user has chosen so.
>    The initial cash / certificate limit was set in accordance to the
>    ones of 18GA.
>
> commit b28acd66343645635a3c40e1f9eacfda398c0851
>
>    1889: Aligned hex tooltip with style of background map
>
>    The background map displays all names in Kanji and Romaji (latin
>    alphabet). However, the hex tooltip only displayed the Romaji.
>    Hence, the Kanji have been added to the Map.xml.
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Fixed (push request): Major annoyance re. the Game Report (history) window

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

Committed and pushed.

Thanks!

---Brett.



On Mon, Dec 26, 2011 at 8:42 AM, Frederick Weld
<fre...@go...> wrote:
> @John David:
> I fixed the annoyance that the report window does not stay on top when
> selecting where to play from in the report window. Hopefully, this
> also alleviates the other annoyance (other windows are dead).
> If more was needed here, it would get really difficult as the other
> windows could not be deactivated on a global basis (but on a
> case-by-case decision on action level).
>
> @Project Members:
> Could you take care of pushing the attached patch?
>
> --Frederick
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

[Rails-devel] Fixed (push request): Major annoyance re. the Game Report (history) window

[Frederick W. <fre...@go...>]

@John David:
I fixed the annoyance that the report window does not stay on top when
selecting where to play from in the report window. Hopefully, this
also alleviates the other annoyance (other windows are dead).
If more was needed here, it would get really difficult as the other
windows could not be deactivated on a global basis (but on a
case-by-case decision on action level).

@Project Members:
Could you take care of pushing the attached patch?

--Frederick

[Rails-devel] Push request: New fit-to-xyz zoom options, 1889 background map, 2-player 18AL

[Frederick W. <fre...@go...>]

Would you please git push these patches to origin/master?

--Frederick

commit 5b1e6f88421cd54246af9463c28d75a578ad16dc

    Added background map for 1889

commit 010d549bce2beb95d3692683a9afdfd63d1fd34c

    Added zoom options fit-to-window/width/height

    The current zoom step concept has not been altered. The
    new zoom options are not pixel based  but, instead of that, the code
    determines the appropriate zoom step and triggers the existing zoom logic.
    Minor refactoring was needed in order to avoid code duplication.

commit 49406f24edd329628b4f9bd8404d75c817e9461a

    Added option to start 2-player 18AL games

    Although the 18AL rules do not state that 2-player games are allowed,
    there is no reason why rails should prohibit this setup if the rails
    user has chosen so.
    The initial cash / certificate limit was set in accordance to the
    ones of 18GA.

commit b28acd66343645635a3c40e1f9eacfda398c0851

    1889: Aligned hex tooltip with style of background map

    The background map displays all names in Kanji and Romaji (latin
    alphabet). However, the hex tooltip only displayed the Romaji.
    Hence, the Kanji have been added to the Map.xml.

[Rails-devel] Major annoyance re. the Game Report (history) window

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

I don't know if this is new to 1.6.0 but I did just run across it.

When I click on a blue link in the "Game Report" window to select a past
action, the "Map" or "Game Status" window in which that action occurred
immediately pops to the front.  This is moderately annoying because it
hides the "Game Report" window, thus forcing me to manually pop it to
the front again (from the Windows menu bar) before I can click "Play
from here" as I was about to do.  This pop-to-the-front should only
occur AFTER I click on "Play from here" or "Leave history".

But what's REALLY annoying is that, until I've returned to the "Game
Report" window and hit either "Leave history" or "Play from here", the
other Rails windows refuse to respond to anything in any way -- I'm not
even allowed to minimize, move, or resize them, select one so that it
will pop in front of another, or look at tooltips or "Info", and no
explanation is offered as to why.  This is going to frustrate newbies
all to hell because they won't have any idea why the game suddenly
froze up.

Sometimes I have to use Ctrl/Alt/Del and Windows Task Manager just to
get back to the "Game Report" window and unlock the game, though the
icon on the menu bar, if not hidden, will also work.

Re: [Rails-devel] Players total value

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

Great analysis, and I believe I agree with all of John Galt's decisions
regarding how to count prospective net worth.

--
Chris

Please consider the environment before printing this e-mail.


On Thu, Dec 22, 2011 at 2:02 PM, John David Galt <
jd...@di...> wrote:

> Stefan Frey wrote:
> > Chris:
> > could you please help me with some details about the companies in the
> games
> > you mention below? I have not played those so I have no extensive
> knowledge
> > and I admit I am too lazy to look up rules now. Why are the better
> examples
> > for worthless companies than those minors and privates we have in other
> games
> > already?
> >
> > A more general reply:
> >
> > If you think all of the type B assets are worthless use the still
> existing
> > current value. If you think only some are worthless or you assign a
> different
> > value make your own back-of-the envelope calculation.
> >
> > I have never claimed that my valuation for type B company gives you the
> true
> > (fundamental) value of the company.
> >
> > However I led myself guide from real-world accounting principle.
> >
> > You could value assets on the balance sheet in several ways, some are
> put down
> > below:
> >
> > 1) Value at termination (liquidation value)
> >
> > 2) Market price
> >
> > 3) Purchase price which is actually a historical (market) price if
> available
> >
> > 4) Model based value
> >
> > So you prefer the end-of-game value guided by the first principle.
> > I prefer using the purchase price for those items which do not have an
> end-of-
> > game value, but which are usually not worthless in 18xx (think about the
> > minors in 18EU).
> >
> > Consequently I believe that the on-going player values give a better
> picture
> > of the current ranking of players than the end-of-game player value in
> the
> > opening phase of 18EU.
> >
> > Stefan
>
> To illustrate the principle, let's look at the common classes of private
> companies, beginning with the six in 1830.
>
> *  SVN&RR, C&StL, and D&H, each comes by itself.  (Each produces income,
> each
> blocks a space on the board, and two of them have build powers once
> purchased
> by a company, but I don't think any of us wants to assign a value to any of
> those facts in computing a player's net worth.)  So:
> -  If the game ends immediately in bankruptcy, the private is worth face
> value.
> -  If the game plays out to the end, a company will probably buy in the
> private
> for (2xface) in mid-game, and until then the private will produce income.
>  (If
> no company ever buys in the private, it will eventually close for $0.)
> -  Both Stefan and I would count these as their face value (type A).
>
> *  M&H comes by itself, but can be traded in for a share of NYC.
> -  If the game ends immediately in bankruptcy, the private is worth face
> value.
> -  If the game plays out to the end, then as above, a company will
> probably buy
> it in for (2xface).  The NYC trade-in is an option, but not often used (and
> like the buy-in, it makes sense not to consider it until it happens).
> -  Again, both Stefan and I would count this as face value (type A).
>
> *  C&A comes with a 10% share of PRR.
> -  If the game ends immediately in bankruptcy, the private is worth face
> value,
> but the share is worth zero because no one has bought the presidency yet.
> -  If the game plays out to the end, then like the first three, a company
> will
> probably buy in the private for (2xface), while PRR will probably float,
> giving
> the share a market value.  Again, I prefer not to consider these events
> until
> they happen since both are optional.
> -  Stefan would count the C&A as $160 (type A) and the share as the actual
> price paid minus $160 until someone buys the presidency of PRR.  Then the
> share
> becomes worth market value.
> -  I would count the C&A as $160, but the share as zero until someone buys
> the
> presidency of PRR.
>
> *  B&O comes with the presidency of B&O, but the private cannot be bought
> by a
> company and closes when B&O buys a train.
> -  If the game ends immediately in bankruptcy, the private is worth face
> value,
> and the two shares are also worth market value!
> -  If the game plays out to the end, B&O will almost certainly float and
> buy a
> train, causing the private to close for $0, while the two shares will
> certainly
> have a market value.
> -  Stefan would count the two shares as market value and the private as the
> price paid minus the par value of the two shares.
> -  I would count the two shares as market value and the private as zero.
>
> **  1835 has two major rules differences that affect all privates: none of
> them
> can be bought in by a company, and none of them count if the game ends
> early in
> a bankruptcy.
> *  NF, OBB, and PfB come with 10% shares of BY.
> -  If the game ends immediately in bankruptcy, the private is worth zero.
> -  If the game plays out to the end, the private will produce income but
> will
> eventually close for 0M.
> -  Stefan would count the share at market value and the private at the
> price
> paid minus the par value of the share (so NF = 8, OBB = 28, PfB = 58).
> -  I would count the share at market value and the private at zero.
>
> *  LD comes with the presidency of SX.  It closes when SX buys a train.
> -  If the game ends immediately in bankruptcy, the private is worth zero.
> -  If the game plays out to the end, the private will produce income for a
> few
> rounds but then will close for 0M.
> -  Stefan would count the two shares at market value and the private at the
> price paid minus the par value of the two shares (14).
> -  I would count the two shares at market value and the private at zero.
>
> *  BB and HB come by themselves but will eventually have to trade for 10%
> shares of PR.
> -  If the game ends immediately in bankruptcy, the private is worth zero.
> -  If the game plays out to the end, the private will produce income for a
> few
> rounds but then will merge and become a PR share which will certainly have
> a
> market value.
> -  Stefan would count the private at face value.
> -  I would count the private as the market value of the trade-in share
> (and at
> its par value if it has not yet floated).
>
> *  1835's minor companies come by themselves but eventually will have to
> trade
> for 5% or 10% shares of PR.
> -  Same analysis and results as BB and HB.
>
> *  18EU's minor companies come by themselves but eventually will trade in
> for
> major company shares or close.
> -  If the game ends immediately, the minor company is worth zero.
> -  If the game plays out to the end, it will probably merge (but could end
> up
> closing for $0 if not connected), and until then the minor will produce
> income.
> -  Stefan would count the minor at the actual purchase price.
> -  My principle says it is worth zero, but here I would depart from
> principles
> and arbitrarily count the minor as worth $100, regardless of which minor
> it is
> or the actual purchase price.
> I use $100 because it is the value of the train that comes with the minor,
> and
> because it is a reasonable estimate of the value of an eventual trade-in
> share.
>
> *  Two of 1837's private (mountain) companies come by themselves; the
> others
> each come with one of the minor companies S1-S5.
> -  If the game ends immediately, both the private and the minor (if any)
> are
> worth zero.
> -  If the game plays out to the end, the minor will certainly merge (and
> as in
> 1835, the national companies have predetermined par values, so the share
> will
> certainly have a market value).
> -  Stefan would count the two privates that come by themselves at the
> actual
> purchase price.  For the ones that come with a minor, he would divide the
> actual purchase price equally between the private and the minor.
> -  I would count the privates as zero and the minors as the market value
> of the
> trade-in share (and at its par value if it has not yet floated).
>
> *  1837's coal companies come by themselves.  Each will eventually trade
> for a
> 10% share of a known major company (but the par values are not yet set,
> and the
> trade is not forced unless the major company sells out the rest of its
> shares).
> -  If the game ends immediately, the coal company is worth zero.
> -  If the game plays out to the end, the coal company will probably merge,
> but
> even the par value of the trade-in share is not yet known, and the trade-in
> does not have to occur (and if it doesn't, the coal company is worth zero).
> -  Stefan would count the coal company as the actual purchase price.
> -  I would arbitrarily count each coal company as 100K, the amount of
> treasury
> cash it starts with, until someone purchases the presidency of the trade-in
> company.  Once that happens I would count the coal company as the market
> value
> of the trade-in share.
>
> *  1837's minor companies come by themselves (except that U1 and U3 each
> come
> as two 50% shares) but all eventually will have to trade for 10% shares of
> the
> three national companies, which have predetermined par values.
> -  Same analysis and results as 1835's minors.
>
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

[Rails-devel] Rails 1.6.0 available

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

This release celebrates that 1835 is declared fully playable.

Warning this release might not work with existing save files (see below).

Contributors: Martin Brumm, Stefan Frey, Erik Vos, Frederick Weld

List of bugs fixed and further changes:
- 18EU: Fixed that share price could raise at the end of the merger round
- 1825: Update to Minors
- Background map: Fixed glitches at 18GA display
- All games: Fixes to make entering special tile lays more efficient
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 1856, 18EU, 18GA (incl. Cotton Port) 
and 18AL so far.

Re: [Rails-devel] Players total value

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

> John David Galt wrote:
>> This makes no sense to me.  Only type A values should count (and then only for
>> permanent certificates, or the trade-in shares in the case of privates/minors
>> that will be forced to trade for something else).
>>
>> What you call the "present values" of privates/minors that will close without
>> compensation are simply sunk costs, and in accounting terms they should simply
>> be expensed immediately, because: (1) their salvage values are known to be
>> zero; (2) forecasting depreciation without also forecasting the income that
>> will be matched with it is futile; and (3) it's rare for most 18xx games to
>> end before the next-to-last train type, with or without a bankruptcy.

John A. Tamplin wrote:
> I assume the rationale here is so that early in the game you have some
> indication of the relative positions of players.

Right.

> A player that spent all their money on private companies would otherwise show
> near-zero net worth, while one who bought nothing would show their initial
> starting value.

That's the way it is now.

> If you could accurately predict when they were going to close, you could
> pro-rate them or show the NPV of the future stream of revenue, but alas that
> isn't going to be feasible.

Even if I could predict that, I wouldn't do it, because all 18xx games have a
built-in "inflation factor": money you have early is worth a LOT more (in
expected final standing, if invested well) than the same amount received later.
There is also the "growth factor" (real ROI = income + increased share value),
which means that, as in real life, fixed-income investments are usually much
worse than they seem on paper in comparison to other investments.

(And I agree with you on the rest, too: predicting player actions is too big
a can of worms to open, unless we were writing the "Deep Blue" of 18xx games.)

Re: [Rails-devel] Open 1835 bugs (was: Some questions regarding a new release)

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

Stefan Frey wrote:
> Erik,
> you are right: I have only checked that I have enough money available to buy 
> the 20% shares, forgot about the 50% markup.
> 
> Sorry for insisting on this, you were right both bugs are fixed.
> 
> Looking at test case B again  I realize that I do not really know how this
> case is correctly handled, so I am asking the 1835 rule lawyers:
> 
> This test case features player T3 is president of WT with 50% (20% president + 
> 3 10% shares) and player T1 has 50% too (20% double share + 3 10% shares).
> 
> It is T3 turn in a SR:
> 
> A) T3 sells 10, 20 or 30%:
> Here T3 swaps his president share with either 2 10% or 1 20% share of T1.
> All is correctly offered in Rails.
> 
> B) T3 sells 40 or 50%:
> T3 ends up with 10% or no share of WT.
> But what is the final portfolio of T1? Will the 20% share
> stay in his portfolio? 
> 
> This is the only available option in Rails for selling that amount in 
> ONE action.
> 
> However it is easy for player T3 to strip T1 of his 20% certificate if he uses 
> TWO actions in sequence.
> 
> First T3 sells 10% and swaps the president share for the 20% certificate and 
> then sells the remaining shares in a separate action.
> 
> Is that an allowed maneuver in 1835?
> 
> Stefan

Good question.  I would rule that it is not allowed, unless the sales take place
on two separate stock turns.

Re: [Rails-devel] Players total value

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

Stefan Frey wrote:
> Chris:
> could you please help me with some details about the companies in the games 
> you mention below? I have not played those so I have no extensive knowledge 
> and I admit I am too lazy to look up rules now. Why are the better examples
> for worthless companies than those minors and privates we have in other games 
> already?
> 
> A more general reply:
> 
> If you think all of the type B assets are worthless use the still existing 
> current value. If you think only some are worthless or you assign a different 
> value make your own back-of-the envelope calculation.
> 
> I have never claimed that my valuation for type B company gives you the true 
> (fundamental) value of the company. 
> 
> However I led myself guide from real-world accounting principle.
> 
> You could value assets on the balance sheet in several ways, some are put down 
> below:
> 
> 1) Value at termination (liquidation value)
> 
> 2) Market price
> 
> 3) Purchase price which is actually a historical (market) price if available
> 
> 4) Model based value
> 
> So you prefer the end-of-game value guided by the first principle. 
> I prefer using the purchase price for those items which do not have an end-of-
> game value, but which are usually not worthless in 18xx (think about the 
> minors in 18EU).
> 
> Consequently I believe that the on-going player values give a better picture 
> of the current ranking of players than the end-of-game player value in the 
> opening phase of 18EU.
> 
> Stefan

To illustrate the principle, let's look at the common classes of private
companies, beginning with the six in 1830.

*  SVN&RR, C&StL, and D&H, each comes by itself.  (Each produces income, each
blocks a space on the board, and two of them have build powers once purchased
by a company, but I don't think any of us wants to assign a value to any of
those facts in computing a player's net worth.)  So:
-  If the game ends immediately in bankruptcy, the private is worth face value.
-  If the game plays out to the end, a company will probably buy in the private
for (2xface) in mid-game, and until then the private will produce income.  (If
no company ever buys in the private, it will eventually close for $0.)
-  Both Stefan and I would count these as their face value (type A).

*  M&H comes by itself, but can be traded in for a share of NYC.
-  If the game ends immediately in bankruptcy, the private is worth face value.
-  If the game plays out to the end, then as above, a company will probably buy
it in for (2xface).  The NYC trade-in is an option, but not often used (and
like the buy-in, it makes sense not to consider it until it happens).
-  Again, both Stefan and I would count this as face value (type A).

*  C&A comes with a 10% share of PRR.
-  If the game ends immediately in bankruptcy, the private is worth face value,
but the share is worth zero because no one has bought the presidency yet.
-  If the game plays out to the end, then like the first three, a company will
probably buy in the private for (2xface), while PRR will probably float, giving
the share a market value.  Again, I prefer not to consider these events until
they happen since both are optional.
-  Stefan would count the C&A as $160 (type A) and the share as the actual
price paid minus $160 until someone buys the presidency of PRR.  Then the share
becomes worth market value.
-  I would count the C&A as $160, but the share as zero until someone buys the
presidency of PRR.

*  B&O comes with the presidency of B&O, but the private cannot be bought by a
company and closes when B&O buys a train.
-  If the game ends immediately in bankruptcy, the private is worth face value,
and the two shares are also worth market value!
-  If the game plays out to the end, B&O will almost certainly float and buy a
train, causing the private to close for $0, while the two shares will certainly
have a market value.
-  Stefan would count the two shares as market value and the private as the
price paid minus the par value of the two shares.
-  I would count the two shares as market value and the private as zero.

**  1835 has two major rules differences that affect all privates: none of them
can be bought in by a company, and none of them count if the game ends early in
a bankruptcy.
*  NF, OBB, and PfB come with 10% shares of BY.
-  If the game ends immediately in bankruptcy, the private is worth zero.
-  If the game plays out to the end, the private will produce income but will
eventually close for 0M.
-  Stefan would count the share at market value and the private at the price
paid minus the par value of the share (so NF = 8, OBB = 28, PfB = 58).
-  I would count the share at market value and the private at zero.

*  LD comes with the presidency of SX.  It closes when SX buys a train.
-  If the game ends immediately in bankruptcy, the private is worth zero.
-  If the game plays out to the end, the private will produce income for a few
rounds but then will close for 0M.
-  Stefan would count the two shares at market value and the private at the
price paid minus the par value of the two shares (14).
-  I would count the two shares at market value and the private at zero.

*  BB and HB come by themselves but will eventually have to trade for 10%
shares of PR.
-  If the game ends immediately in bankruptcy, the private is worth zero.
-  If the game plays out to the end, the private will produce income for a few
rounds but then will merge and become a PR share which will certainly have a
market value.
-  Stefan would count the private at face value.
-  I would count the private as the market value of the trade-in share (and at
its par value if it has not yet floated).

*  1835's minor companies come by themselves but eventually will have to trade
for 5% or 10% shares of PR.
-  Same analysis and results as BB and HB.

*  18EU's minor companies come by themselves but eventually will trade in for
major company shares or close.
-  If the game ends immediately, the minor company is worth zero.
-  If the game plays out to the end, it will probably merge (but could end up
closing for $0 if not connected), and until then the minor will produce income.
-  Stefan would count the minor at the actual purchase price.
-  My principle says it is worth zero, but here I would depart from principles
and arbitrarily count the minor as worth $100, regardless of which minor it is
or the actual purchase price.
I use $100 because it is the value of the train that comes with the minor, and
because it is a reasonable estimate of the value of an eventual trade-in share.

*  Two of 1837's private (mountain) companies come by themselves; the others
each come with one of the minor companies S1-S5.
-  If the game ends immediately, both the private and the minor (if any) are
worth zero.
-  If the game plays out to the end, the minor will certainly merge (and as in
1835, the national companies have predetermined par values, so the share will
certainly have a market value).
-  Stefan would count the two privates that come by themselves at the actual
purchase price.  For the ones that come with a minor, he would divide the
actual purchase price equally between the private and the minor.
-  I would count the privates as zero and the minors as the market value of the
trade-in share (and at its par value if it has not yet floated).

*  1837's coal companies come by themselves.  Each will eventually trade for a
10% share of a known major company (but the par values are not yet set, and the
trade is not forced unless the major company sells out the rest of its shares).
-  If the game ends immediately, the coal company is worth zero.
-  If the game plays out to the end, the coal company will probably merge, but
even the par value of the trade-in share is not yet known, and the trade-in
does not have to occur (and if it doesn't, the coal company is worth zero).
-  Stefan would count the coal company as the actual purchase price.
-  I would arbitrarily count each coal company as 100K, the amount of treasury
cash it starts with, until someone purchases the presidency of the trade-in
company.  Once that happens I would count the coal company as the market value
of the trade-in share.

*  1837's minor companies come by themselves (except that U1 and U3 each come
as two 50% shares) but all eventually will have to trade for 10% shares of the
three national companies, which have predetermined par values.
-  Same analysis and results as 1835's minors.

Re: [Rails-devel] Players total value

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

On Thu, Dec 22, 2011 at 3:12 PM, John David Galt <
jd...@di...> wrote:

> This makes no sense to me.  Only type A values should count (and then only
> for
> permanent certificates, or the trade-in shares in the case of
> privates/minors
> that will be forced to trade for something else).
>
> What you call the "present values" of privates/minors that will close
> without
> compensation are simply sunk costs, and in accounting terms they should
> simply
> be expensed immediately, because: (1) their salvage values are known to be
> zero; (2) forecasting depreciation without also forecasting the income that
> will be matched with it is futile; and (3) it's rare for most 18xx games
> to end
> before the next-to-last train type, with or without a bankruptcy.
>

I assume the rationale here is so that early in the game you have some
indication of the relative positions of players.  A player that spent all
their money on private companies would otherwise show near-zero net worth,
while one who bought nothing would show their initial starting value.

If you could accurately predict when they were going to close, you could
pro-rate them or show the NPV of the future stream of revenue, but alas
that isn't going to be feasible.  You also say that the president's share
of a stock is actually negative, because it has no money and the president
is about to have to buy it a diesel out of pocket, but I don't think it is
useful to try and predict what the values will be -- that is the players'
job.  Instead, just let rails show the values separately (cash, stock,
other) and let the other category include the face value.  This would also
work for things like 1844's tunnel/mountain companies that only have value
at the end of the game if they have been activated.

-- 
John A. Tamplin

Re: [Rails-devel] Players total value

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

On 2011-12-19 23:07, Stefan Frey wrote:
> I thought about this, and used some ideas from accounting (however adopted to 
> the 18xx environment).
> 
> What do you think about the following definition to evaluate items for the 
> player value displayed in Rails:
> 
> A) Items that have an end game value use that.

I agree, but it's unclear whether this includes the face values of privates (in
games where they close at a certain phase change), since they will only count if
the game ends before that phase (and some games don't count them at all).

> B) Items that will close before end for sure will use the purchase value.
> 
> There is the issue how to evaluate items sold as a bundle:
> Here I would suggest the heuristic that items with value A are deducted [from]
> the purchase price first, if a positive value remains it get equally assigned 
> to all items of type B.

This makes no sense to me.  Only type A values should count (and then only for
permanent certificates, or the trade-in shares in the case of privates/minors
that will be forced to trade for something else).

What you call the "present values" of privates/minors that will close without
compensation are simply sunk costs, and in accounting terms they should simply
be expensed immediately, because: (1) their salvage values are known to be
zero; (2) forecasting depreciation without also forecasting the income that
will be matched with it is futile; and (3) it's rare for most 18xx games to end
before the next-to-last train type, with or without a bankruptcy.

Re: [Rails-devel] Open 1835 bugs (was: Some questions regarding a new release)

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

Erik,
you are right: I have only checked that I have enough money available to buy 
the 20% shares, forgot about the 50% markup.

Sorry for insisting on this, you were right both bugs are fixed.

Looking at test case B again  I realize that I do not really know how this
case is correctly handled, so I am asking the 1835 rule lawyers:

This test case features player T3 is president of WT with 50% (20% president + 
3 10% shares) and player T1 has 50% too (20% double share + 3 10% shares).

It is T3 turn in a SR:

A) T3 sells 10, 20 or 30%:
Here T3 swaps his president share with either 2 10% or 1 20% share of T1.
All is correctly offered in Rails.

B) T3 sells 40 or 50%:
T3 ends up with 10% or no share of WT.
But what is the final portfolio of T1? Will the 20% share
stay in his portfolio? 

This is the only available option in Rails for selling that amount in 
ONE action.

However it is easy for player T3 to strip T1 of his 20% certificate if he uses 
TWO actions in sequence.

First T3 sells 10% and swaps the president share for the 20% certificate and 
then sells the remaining shares in a separate action.

Is that an allowed maneuver in 1835?

Stefan

PS: An update version of test case B is attached.


On Thursday, December 22, 2011 03:38:04 pm you wrote:
> Stefan,
> 
> In your test case the BA doesn't have the cash to nationalise a 20% share.
> If you correct that, the choice will be possible.
> Sorry that I forgot to mention that I had to make this initial correction
> as well.  In this case, the elapsed time between starting and finishing
> the work was quite a bit longer than usual.
> 
> > And neither can I see the bug fixed in the attached e-mails, but maybe I
> 
> am
> 
> > off track today?
> 
> Maybe - I did mention bugs A and B in those emails.
> Perhaps you missed the (admittedly, not too clear) implication of "fixed"
> where I said "overhauled".
> 
> Erik.

Re: [Rails-devel] Open 1835 bugs (was: Some questions regarding a new release)

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

Stefan,

Bugs A and B should have been fixed by my commits of about a month ago.
See the attached emails.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Thursday, December 22, 2011 1:51 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Open 1835 bugs (was: Some questions regarding a
> new release)
> 
> Erik:
> I suspect that you might have missed that e-mail about the open 1835
bug(s).
> Or I missed your reply.
> However I would like to know if you intend to close that before Christmas,
> otherwise I would release 1.5.5 today.
> Stefan
> 
> 1835 bug:
> 
> I just retested bug A of my previous mail with subject "Further 1835
testing".
> 
> Seems that at least this bug is open:
> > A) Player T2 nationalizes BA from T3: There is no option to
> > nationalize the 20% certificate first.
> 
> I assume that similar bug B is still open too:
> > B) Player T3 sells 30% of WT: There is no selection to chosse either
> > one 20% or two 10% certificates for exchange of the president
certificate.
> >
> I had to fix the save file due to your removal of the special token lay
step
> requirement by removing the superfluous skip orders.
> 
> Attached that save file for bug A.
> Stefan
> 
> 
> 
> On Sunday, December 18, 2011 05:04:33 pm Erik Vos wrote:
> > Stefan,
> >
> > Only the following alleged-bug reports remain for 1835 (copied from my
> > personal to-do list):
> >
> > [1835] (Oddly enough, in a problem that resembles point 3 in reverse,
> > the five PR tokens that are supposed to be reserved for exchanging
> > minor company tokens *do* show up as available to be built.
> > Next time I'll try to build them in arbitrary locations and see what
> > happens -- both then and when the minor companies merge and there
> > aren't any PR tokens for them.)  [JDG 11-10-2011]
> >
> > [1835] Net worth calculation seems a little off, I think it's getting
> > confused particularly with the Prussian certs.  [Phil Davies
> > 17-6-2010]
> >
> > And then we have the (very old) issue that in some cases PfB and OBB
> > do not close where these (allegedly) should, necessitating a manual
> "Special"
> > private close action.
> >
> > JDG also had some requests and good ideas, such as showing what PR
> > share percentage is reserved. But that's not a bug.
> >
> > I may pick up some of these issues in the near future, but I don't
> > consider any of these as urgent, because correct play is not inhibited
> > (which is my main timing criterion).
> >
> > It's up to you to decide if these issues preclude stating that "all
> > remaining 1835 issues are fixed". In any case, I have no objections.
> >
> > Erik.
> >
> > > -----Original Message-----
> > > From: Stefan Frey [mailto:ste...@we...]
> > > Sent: Sunday, December 18, 2011 4:26 PM
> > > To: Development list for Rails: an 18xx game
> > > Subject: [Rails-devel] Some questions regarding a new release
> > >
> > > All:
> > > if nobody objects I will prepare a new release for tonight or
> > > sometime tomorrow (including the new background maps).
> > >
> > > I have been pretty busy recently (unfortunately not with Rails) so I
> > > am
> >
> > not
> >
> > > sure if all remaining 1835 issues are fixed now. Erik could you
> > > please
> >
> > advise
> >
> > > me on this: If all are done, the new release will be 1.6.0 with 1835
> >
> > promoted
> >
> > > to full playability, otherwise it will remain 1.5.5.
> > >
> > > What are the opinions to make the background maps the default option
> > > for Rails? A major advantage is that the look much nicer, however
> > > (at least
> > > currently) the seem take longer to be displayed on first appearance.
> > >
> > > Stefan
> >
> > ----------------------------------------------------------------------
> > -----
> > - --
> >
> > > Learn Windows Azure Live!  Tuesday, Dec 13, 2011 Microsoft is
> > > holding a special Learn Windows Azure training event for developers.
> > > It will provide
> >
> > a
> >
> > > great way to learn Windows Azure and what it provides. You can
> > > attend the event by watching it streamed LIVE online.
> > > Learn more at http://p.sf.net/sfu/ms-windowsazure
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > ----------------------------------------------------------------------
> > -----
> > --- Learn Windows Azure Live!  Tuesday, Dec 13, 2011 Microsoft is
> > holding a special Learn Windows Azure training event for developers.
> > It will provide a great way to learn Windows Azure and what it
> > provides. You can attend the event by watching it streamed LIVE online.
> > Learn more at http://p.sf.net/sfu/ms-windowsazure
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel