rails-devel — List for discussion of Rails development

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

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

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

Re: [Rails-devel] Players total value (was: Some questions regarding a new release)

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

On Tue, Dec 20, 2011 at 3:00 PM, Chris Shaffer <chr...@gm...>wrote:

> The 5% NdM shares are worth 45 each, because the NdM is always parred at
> 90.
>

Plus the value of not counting against your cert limit.

-- 
John A. Tamplin

Re: [Rails-devel] Players total value (was: Some questions regarding a new release)

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

Private companies in 1826 and 18GL grant special powers, which the players
may assign to companies.  They also provide income to the players.  Some of
the companies close when the power is exercised, others are closed at the
start of the brown phase.  The private companies have no value whether open
or closed.  They can never be sold or traded.  I would argue that their
purchase price is not relevant to actual or projected net worth, and they
should always be listed at zero.

On the sale of a T5, two of the minor companies in 18MEX are exchanged for
5% shares of the NdM.  The third is exchanged for a 10% share of the UdY.
 The UdY share is valued at between 60 and 90.  The 5% NdM shares are worth
45 each, because the NdM is always parred at 90.

--
Chris

Please consider the environment before printing this e-mail.


On Tue, Dec 20, 2011 at 9:32 AM, Stefan Frey <ste...@we...> 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
>
>
> On Tuesday, December 20, 2011 06:05:24 pm Chris Shaffer wrote:
> > I think that using purchase price is fraught with complications.
> >
> > How will you account for the value of private companies in 1826 and 18GL?
> >  They cannot be sold or redeemed, and always end up with value zero,
> > whether the game ends immediately or at some later date.  By your
> algorithm
> > below, they will be included in the net worth calculation, which I would
> > argue is incorrect.  They have no current value, and will never have
> actual
> > value.
> >
> > I also disagree with this statement.  An example where this is obviously
> > untrue is the minor companies in 18MEX.
> >
> > a) Potential conversions (even automatic) are irrelevant until they
> occur.
> >
> >
> > --
> > Chris
> >
> > Please consider the environment before printing this e-mail.
> >
> > On Tue, Dec 20, 2011 at 8:08 AM, Stefan Frey <ste...@we...> wrote:
> > > All:
> > > sorry I submitted a version of the mail, which was an older one and was
> > > not fully edited to what it should have been:
> > >
> > > I first considered the question of sure (or almost sure) closure of an
> > > item before game end to be the relevant. But as many already complained
> > > this is ambiguous (in theory nearly all games can end before seeing the
> > > first tile
> > > laid, even without thinking about bankruptcy).
> > >
> > > For sure the on-going value can be configured to be an additional or
> > > optional
> > > replacement of the end-of-game value. It was already on my to-do-list
> to
> > > make
> > > the current end-of-game value.
> > >
> > > Feel free to suggest something better suited.
> > >
> > > Stefan
> > >
> > >
> > > So my fully finished proposal is for an ongoing player value is stated
> > > below:
> > >
> > > A) For items that have a value at game end unequal to zero use that.
> > >
> > > B) For items that have a value at game end equal to zero use the
> > > purchasing cost defined below.
> > >
> > > Purchasing price for type B items:
> > >
> > > 1) The actual price paid to the bank is relevant (e.g after a bidding
> > > process).
> > >
> > > 2) if a bundle is sold the value of all Items of type B purchased from
> > > bundles
> > > are evaluated by deducting first the current value of all type A items
> > > (at the
> > > time of purchase) from the purchase price and then the remaining amount
> > > is distributed equally to all type B items of the bundle.
> > >
> > > Some further remarks:
> > > a) Potential conversions (even automatic) are irrelevant until they
> > > occur.
> > >
> > > b) Items might change their type from B to A without conversion if
> their
> > > game
> > > end value changes from zero to a non-zero value. This has no retrograde
> > > effect
> > > of the value of other items sold in a bundle with the item.
> > >
> > > Remark b) covers the case of the C&A:
> > >
> > > The PRR share bundled with the C&A will be first assigned the
> difference
> > > between the purchase price of the C&A minus the value of the C&A. Later
> > > if a
> > > market price is available then the PRR share is valued by that.
> > >
> > > On Tuesday, December 20, 2011 08:07:14 am 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:
> > > >
> > > > B) Items that will close before end for sure will use the purchase
> > > > value.
> > > >
> > > >
> > > > For this we should internally however differentiate between game end
> > >
> > > player
> > >
> > > > value and ongoing current player value: This would allow us easily to
> > > > choose by game configuration to display end value or current value.
> > > >
> > > > However I suggest to defer implementation to the Rails 2.0 trunk.
> > > >
> > > > Stefan
> > > >
> > > > On Sunday, December 18, 2011 11:24:54 pm Erik Vos wrote:
> > > > > > -----Original Message-----
> > > > > > From: John David Galt [mailto:jd...@di...]
> > > > > > Sent: Sunday, December 18, 2011 11:00 PM
> > > > > > To: Development list for Rails: an 18xx game
> > > > > > Subject: Re: [Rails-devel] Some questions regarding a new release
> > > > > >
> > > > > > On 2011-12-18 08:04, Erik Vos wrote:
> > > > > > > [1835] Net worth calculation seems a little off, I think it's
> > >
> > > getting
> > >
> > > > > > > confused particularly with the Prussian certs.  [Phil Davies
> > > > > > > 17-6-2010]
> > > > > >
> > > > > > I noticed this recently, too.  What seems to be happening is that
> > > > > > in both 1835 and 18EU, the minor companies are counted as zero in
> > > > > > net worth.
> > > > >
> > > > > While
> > > > >
> > > > > > this may be correct in the rules, it's a distortion for players
> who
> > > > > > want
> > > > >
> > > > > to use
> > > > >
> > > > > > net worth as a way to predict final positions.
> > > > > >
> > > > > > I suggest that in 1835, the privates and minors should be counted
> > > > > > as the value of the PR shares they will eventually trade for (77M
> > > > > > per 5% if PR
> > > > >
> > > > > has
> > > > >
> > > > > > not yet formed), while for 18EU, I would just count them all as
> > > > > > $100 each
> > > > >
> > > > > (as
> > > > >
> > > > > > a ballpark estimate).
> > > > >
> > > > > Hmm, if we are going to count privates/minors to their expected
> > > > > future value rather than their official current value, shouldn't we
> > > > > then also count 1830 C&A for $320 rather than $160?
> > > > > I would prefer to stick to the rules, and leave it to the players
> to
> > >
> > > take
> > >
> > > > > note of (or forget about) any expected future gains.
> > > > >
> > > > > Erik.
> > >
> > >
> -------------------------------------------------------------------------
> > >
> > > > > -- --- 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
> > >
> > >
> -------------------------------------------------------------------------
> > > --
> > >
> > > > --- 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
> > >
> > >
> -------------------------------------------------------------------------
> > > ----- 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
>
>
> ------------------------------------------------------------------------------
> 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] Players total value (was: Some questions regarding a new release)

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

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


On Tuesday, December 20, 2011 06:05:24 pm Chris Shaffer wrote:
> I think that using purchase price is fraught with complications.
> 
> How will you account for the value of private companies in 1826 and 18GL?
>  They cannot be sold or redeemed, and always end up with value zero,
> whether the game ends immediately or at some later date.  By your algorithm
> below, they will be included in the net worth calculation, which I would
> argue is incorrect.  They have no current value, and will never have actual
> value.
> 
> I also disagree with this statement.  An example where this is obviously
> untrue is the minor companies in 18MEX.
> 
> a) Potential conversions (even automatic) are irrelevant until they occur.
> 
> 
> --
> Chris
> 
> Please consider the environment before printing this e-mail.
> 
> On Tue, Dec 20, 2011 at 8:08 AM, Stefan Frey <ste...@we...> wrote:
> > All:
> > sorry I submitted a version of the mail, which was an older one and was
> > not fully edited to what it should have been:
> > 
> > I first considered the question of sure (or almost sure) closure of an
> > item before game end to be the relevant. But as many already complained
> > this is ambiguous (in theory nearly all games can end before seeing the
> > first tile
> > laid, even without thinking about bankruptcy).
> > 
> > For sure the on-going value can be configured to be an additional or
> > optional
> > replacement of the end-of-game value. It was already on my to-do-list to
> > make
> > the current end-of-game value.
> > 
> > Feel free to suggest something better suited.
> > 
> > Stefan
> > 
> > 
> > So my fully finished proposal is for an ongoing player value is stated
> > below:
> > 
> > A) For items that have a value at game end unequal to zero use that.
> > 
> > B) For items that have a value at game end equal to zero use the
> > purchasing cost defined below.
> > 
> > Purchasing price for type B items:
> > 
> > 1) The actual price paid to the bank is relevant (e.g after a bidding
> > process).
> > 
> > 2) if a bundle is sold the value of all Items of type B purchased from
> > bundles
> > are evaluated by deducting first the current value of all type A items
> > (at the
> > time of purchase) from the purchase price and then the remaining amount
> > is distributed equally to all type B items of the bundle.
> > 
> > Some further remarks:
> > a) Potential conversions (even automatic) are irrelevant until they
> > occur.
> > 
> > b) Items might change their type from B to A without conversion if their
> > game
> > end value changes from zero to a non-zero value. This has no retrograde
> > effect
> > of the value of other items sold in a bundle with the item.
> > 
> > Remark b) covers the case of the C&A:
> > 
> > The PRR share bundled with the C&A will be first assigned the difference
> > between the purchase price of the C&A minus the value of the C&A. Later
> > if a
> > market price is available then the PRR share is valued by that.
> > 
> > On Tuesday, December 20, 2011 08:07:14 am 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:
> > > 
> > > B) Items that will close before end for sure will use the purchase
> > > value.
> > > 
> > > 
> > > For this we should internally however differentiate between game end
> > 
> > player
> > 
> > > value and ongoing current player value: This would allow us easily to
> > > choose by game configuration to display end value or current value.
> > > 
> > > However I suggest to defer implementation to the Rails 2.0 trunk.
> > > 
> > > Stefan
> > > 
> > > On Sunday, December 18, 2011 11:24:54 pm Erik Vos wrote:
> > > > > -----Original Message-----
> > > > > From: John David Galt [mailto:jd...@di...]
> > > > > Sent: Sunday, December 18, 2011 11:00 PM
> > > > > To: Development list for Rails: an 18xx game
> > > > > Subject: Re: [Rails-devel] Some questions regarding a new release
> > > > > 
> > > > > On 2011-12-18 08:04, Erik Vos wrote:
> > > > > > [1835] Net worth calculation seems a little off, I think it's
> > 
> > getting
> > 
> > > > > > confused particularly with the Prussian certs.  [Phil Davies
> > > > > > 17-6-2010]
> > > > > 
> > > > > I noticed this recently, too.  What seems to be happening is that
> > > > > in both 1835 and 18EU, the minor companies are counted as zero in
> > > > > net worth.
> > > > 
> > > > While
> > > > 
> > > > > this may be correct in the rules, it's a distortion for players who
> > > > > want
> > > > 
> > > > to use
> > > > 
> > > > > net worth as a way to predict final positions.
> > > > > 
> > > > > I suggest that in 1835, the privates and minors should be counted
> > > > > as the value of the PR shares they will eventually trade for (77M
> > > > > per 5% if PR
> > > > 
> > > > has
> > > > 
> > > > > not yet formed), while for 18EU, I would just count them all as
> > > > > $100 each
> > > > 
> > > > (as
> > > > 
> > > > > a ballpark estimate).
> > > > 
> > > > Hmm, if we are going to count privates/minors to their expected
> > > > future value rather than their official current value, shouldn't we
> > > > then also count 1830 C&A for $320 rather than $160?
> > > > I would prefer to stick to the rules, and leave it to the players to
> > 
> > take
> > 
> > > > note of (or forget about) any expected future gains.
> > > > 
> > > > Erik.
> > 
> > -------------------------------------------------------------------------
> > 
> > > > -- --- 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
> > 
> > -------------------------------------------------------------------------
> > --
> > 
> > > --- 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
> > 
> > -------------------------------------------------------------------------
> > ----- 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] Players total value (was: Some questions regarding a new release)

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

I think that using purchase price is fraught with complications.

How will you account for the value of private companies in 1826 and 18GL?
 They cannot be sold or redeemed, and always end up with value zero,
whether the game ends immediately or at some later date.  By your algorithm
below, they will be included in the net worth calculation, which I would
argue is incorrect.  They have no current value, and will never have actual
value.

I also disagree with this statement.  An example where this is obviously
untrue is the minor companies in 18MEX.

a) Potential conversions (even automatic) are irrelevant until they occur.


--
Chris

Please consider the environment before printing this e-mail.


On Tue, Dec 20, 2011 at 8:08 AM, Stefan Frey <ste...@we...> wrote:

> All:
> sorry I submitted a version of the mail, which was an older one and was not
> fully edited to what it should have been:
>
> I first considered the question of sure (or almost sure) closure of an item
> before game end to be the relevant. But as many already complained this
> is ambiguous (in theory nearly all games can end before seeing the first
> tile
> laid, even without thinking about bankruptcy).
>
> For sure the on-going value can be configured to be an additional or
> optional
> replacement of the end-of-game value. It was already on my to-do-list to
> make
> the current end-of-game value.
>
> Feel free to suggest something better suited.
>
> Stefan
>
>
> So my fully finished proposal is for an ongoing player value is stated
> below:
>
> A) For items that have a value at game end unequal to zero use that.
>
> B) For items that have a value at game end equal to zero use the purchasing
> cost defined below.
>
> Purchasing price for type B items:
>
> 1) The actual price paid to the bank is relevant (e.g after a bidding
> process).
>
> 2) if a bundle is sold the value of all Items of type B purchased from
> bundles
> are evaluated by deducting first the current value of all type A items (at
> the
> time of purchase) from the purchase price and then the remaining amount
> is distributed equally to all type B items of the bundle.
>
> Some further remarks:
> a) Potential conversions (even automatic) are irrelevant until they occur.
>
> b) Items might change their type from B to A without conversion if their
> game
> end value changes from zero to a non-zero value. This has no retrograde
> effect
> of the value of other items sold in a bundle with the item.
>
> Remark b) covers the case of the C&A:
>
> The PRR share bundled with the C&A will be first assigned the difference
> between the purchase price of the C&A minus the value of the C&A. Later if
> a
> market price is available then the PRR share is valued by that.
>
>
> On Tuesday, December 20, 2011 08:07:14 am 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:
> >
> > B) Items that will close before end for sure will use the purchase value.
> >
> >
> > For this we should internally however differentiate between game end
> player
> > value and ongoing current player value: This would allow us easily to
> > choose by game configuration to display end value or current value.
> >
> > However I suggest to defer implementation to the Rails 2.0 trunk.
> >
> > Stefan
> >
> > On Sunday, December 18, 2011 11:24:54 pm Erik Vos wrote:
> > > > -----Original Message-----
> > > > From: John David Galt [mailto:jd...@di...]
> > > > Sent: Sunday, December 18, 2011 11:00 PM
> > > > To: Development list for Rails: an 18xx game
> > > > Subject: Re: [Rails-devel] Some questions regarding a new release
> > > >
> > > > On 2011-12-18 08:04, Erik Vos wrote:
> > > > > [1835] Net worth calculation seems a little off, I think it's
> getting
> > > > > confused particularly with the Prussian certs.  [Phil Davies
> > > > > 17-6-2010]
> > > >
> > > > I noticed this recently, too.  What seems to be happening is that in
> > > > both 1835 and 18EU, the minor companies are counted as zero in net
> > > > worth.
> > >
> > > While
> > >
> > > > this may be correct in the rules, it's a distortion for players who
> > > > want
> > >
> > > to use
> > >
> > > > net worth as a way to predict final positions.
> > > >
> > > > I suggest that in 1835, the privates and minors should be counted as
> > > > the value of the PR shares they will eventually trade for (77M per 5%
> > > > if PR
> > >
> > > has
> > >
> > > > not yet formed), while for 18EU, I would just count them all as $100
> > > > each
> > >
> > > (as
> > >
> > > > a ballpark estimate).
> > >
> > > Hmm, if we are going to count privates/minors to their expected future
> > > value rather than their official current value, shouldn't we then also
> > > count 1830 C&A for $320 rather than $160?
> > > I would prefer to stick to the rules, and leave it to the players to
> take
> > > note of (or forget about) any expected future gains.
> > >
> > > Erik.
> > >
> > >
> > >
> > >
> -------------------------------------------------------------------------
> > > -- --- 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
> >
> >
> ---------------------------------------------------------------------------
> > --- 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
>
>
> ------------------------------------------------------------------------------
> 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] Players total value (was: Some questions regarding a new release)

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

Yes:
(current) end-of-game player value is the sum of all type A items
(current) on-going player value is the sum of all type A and B items

I suggest to make both values optional for the UI. Default could be as it is 
now, thus by default only the end-of-game player value is shown.

Some groups I know prefer not showing any total value during ftf-play.

Stefan

On Tuesday, December 20, 2011 05:18:45 pm Erik Vos wrote:
> I am with those who judge that A) is sufficient.
> If I understand Stefan correctly, it's B) that can be switched on and off,
> and that would be fine with me.
> 
> Erik.
> 
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Tuesday, December 20, 2011 5:09 PM
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] Players total value (was: Some questions
> 
> regarding
> 
> > a new release)
> > 
> > All:
> > sorry I submitted a version of the mail, which was an older one and was
> 
> not
> 
> > fully edited to what it should have been:
> > 
> > I first considered the question of sure (or almost sure) closure of an
> 
> item
> 
> > before game end to be the relevant. But as many already complained this
> > is ambiguous (in theory nearly all games can end before seeing the first
> > tile
> 
> laid,
> 
> > even without thinking about bankruptcy).
> > 
> > For sure the on-going value can be configured to be an additional or
> 
> optional
> 
> > replacement of the end-of-game value. It was already on my to-do-list to
> > make the current end-of-game value.
> > 
> > Feel free to suggest something better suited.
> > 
> > Stefan
> > 
> > 
> > So my fully finished proposal is for an ongoing player value is stated
> 
> below:
> > A) For items that have a value at game end unequal to zero use that.
> > 
> > B) For items that have a value at game end equal to zero use the
> 
> purchasing
> 
> > cost defined below.
> > 
> > Purchasing price for type B items:
> > 
> > 1) The actual price paid to the bank is relevant (e.g after a bidding
> 
> process).
> 
> > 2) if a bundle is sold the value of all Items of type B purchased from
> 
> bundles
> 
> > are evaluated by deducting first the current value of all type A items
> > (at
> 
> the
> 
> > time of purchase) from the purchase price and then the remaining amount
> > is distributed equally to all type B items of the bundle.
> > 
> > Some further remarks:
> > a) Potential conversions (even automatic) are irrelevant until they
> > occur.
> > 
> > b) Items might change their type from B to A without conversion if their
> > game end value changes from zero to a non-zero value. This has no
> > retrograde effect of the value of other items sold in a bundle with the
> 
> item.
> 
> > Remark b) covers the case of the C&A:
> > 
> > The PRR share bundled with the C&A will be first assigned the difference
> > between the purchase price of the C&A minus the value of the C&A. Later
> > if a market price is available then the PRR share is valued by that.
> > 
> > On Tuesday, December 20, 2011 08:07:14 am 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:
> > > 
> > > B) Items that will close before end for sure will use the purchase
> 
> value.
> 
> > > For this we should internally however differentiate between game end
> > > player value and ongoing current player value: This would allow us
> > > easily to choose by game configuration to display end value or current
> > 
> > value.
> > 
> > > However I suggest to defer implementation to the Rails 2.0 trunk.
> > > 
> > > Stefan
> > > 
> > > On Sunday, December 18, 2011 11:24:54 pm Erik Vos wrote:
> > > > > -----Original Message-----
> > > > > From: John David Galt [mailto:jd...@di...]
> > > > > Sent: Sunday, December 18, 2011 11:00 PM
> > > > > To: Development list for Rails: an 18xx game
> > > > > Subject: Re: [Rails-devel] Some questions regarding a new release
> > > > > 
> > > > > On 2011-12-18 08:04, Erik Vos wrote:
> > > > > > [1835] Net worth calculation seems a little off, I think it's
> > > > > > getting confused particularly with the Prussian certs.  [Phil
> > > > > > Davies 17-6-2010]
> > > > > 
> > > > > I noticed this recently, too.  What seems to be happening is that
> > > > > in both 1835 and 18EU, the minor companies are counted as zero in
> > > > > net worth.
> > > > 
> > > > While
> > > > 
> > > > > this may be correct in the rules, it's a distortion for players
> > > > > who want
> > > > 
> > > > to use
> > > > 
> > > > > net worth as a way to predict final positions.
> > > > > 
> > > > > I suggest that in 1835, the privates and minors should be counted
> > > > > as the value of the PR shares they will eventually trade for (77M
> > > > > per 5% if PR
> > > > 
> > > > has
> > > > 
> > > > > not yet formed), while for 18EU, I would just count them all as
> > > > > $100 each
> > > > 
> > > > (as
> > > > 
> > > > > a ballpark estimate).
> > > > 
> > > > Hmm, if we are going to count privates/minors to their expected
> > > > future value rather than their official current value, shouldn't we
> > > > then also count 1830 C&A for $320 rather than $160?
> > > > I would prefer to stick to the rules, and leave it to the players to
> > > > take note of (or forget about) any expected future gains.
> > > > 
> > > > Erik.
> > > > 
> > > > 
> > > > 
> > > > --------------------------------------------------------------------
> > > > -----
> > > > -- --- 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
> > > 
> > > ----------------------------------------------------------------------
> > > -----
> > > --- 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
> 
> ---------------------------------------------------------------------------
> - --
> 
> > 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
> 
> ---------------------------------------------------------------------------
> --- 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] Players total value (was: Some questions regarding a new release)

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

I am with those who judge that A) is sufficient.
If I understand Stefan correctly, it's B) that can be switched on and off,
and that would be fine with me.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Tuesday, December 20, 2011 5:09 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Players total value (was: Some questions
regarding
> a new release)
> 
> All:
> sorry I submitted a version of the mail, which was an older one and was
not
> fully edited to what it should have been:
> 
> I first considered the question of sure (or almost sure) closure of an
item
> before game end to be the relevant. But as many already complained this is
> ambiguous (in theory nearly all games can end before seeing the first tile
laid,
> even without thinking about bankruptcy).
> 
> For sure the on-going value can be configured to be an additional or
optional
> replacement of the end-of-game value. It was already on my to-do-list to
> make the current end-of-game value.
> 
> Feel free to suggest something better suited.
> 
> Stefan
> 
> 
> So my fully finished proposal is for an ongoing player value is stated
below:
> 
> A) For items that have a value at game end unequal to zero use that.
> 
> B) For items that have a value at game end equal to zero use the
purchasing
> cost defined below.
> 
> Purchasing price for type B items:
> 
> 1) The actual price paid to the bank is relevant (e.g after a bidding
process).
> 
> 2) if a bundle is sold the value of all Items of type B purchased from
bundles
> are evaluated by deducting first the current value of all type A items (at
the
> time of purchase) from the purchase price and then the remaining amount is
> distributed equally to all type B items of the bundle.
> 
> Some further remarks:
> a) Potential conversions (even automatic) are irrelevant until they occur.
> 
> b) Items might change their type from B to A without conversion if their
> game end value changes from zero to a non-zero value. This has no
> retrograde effect of the value of other items sold in a bundle with the
item.
> 
> Remark b) covers the case of the C&A:
> 
> The PRR share bundled with the C&A will be first assigned the difference
> between the purchase price of the C&A minus the value of the C&A. Later if
> a market price is available then the PRR share is valued by that.
> 
> 
> On Tuesday, December 20, 2011 08:07:14 am 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:
> >
> > B) Items that will close before end for sure will use the purchase
value.
> >
> >
> > For this we should internally however differentiate between game end
> > player value and ongoing current player value: This would allow us
> > easily to choose by game configuration to display end value or current
> value.
> >
> > However I suggest to defer implementation to the Rails 2.0 trunk.
> >
> > Stefan
> >
> > On Sunday, December 18, 2011 11:24:54 pm Erik Vos wrote:
> > > > -----Original Message-----
> > > > From: John David Galt [mailto:jd...@di...]
> > > > Sent: Sunday, December 18, 2011 11:00 PM
> > > > To: Development list for Rails: an 18xx game
> > > > Subject: Re: [Rails-devel] Some questions regarding a new release
> > > >
> > > > On 2011-12-18 08:04, Erik Vos wrote:
> > > > > [1835] Net worth calculation seems a little off, I think it's
> > > > > getting confused particularly with the Prussian certs.  [Phil
> > > > > Davies 17-6-2010]
> > > >
> > > > I noticed this recently, too.  What seems to be happening is that
> > > > in both 1835 and 18EU, the minor companies are counted as zero in
> > > > net worth.
> > >
> > > While
> > >
> > > > this may be correct in the rules, it's a distortion for players
> > > > who want
> > >
> > > to use
> > >
> > > > net worth as a way to predict final positions.
> > > >
> > > > I suggest that in 1835, the privates and minors should be counted
> > > > as the value of the PR shares they will eventually trade for (77M
> > > > per 5% if PR
> > >
> > > has
> > >
> > > > not yet formed), while for 18EU, I would just count them all as
> > > > $100 each
> > >
> > > (as
> > >
> > > > a ballpark estimate).
> > >
> > > Hmm, if we are going to count privates/minors to their expected
> > > future value rather than their official current value, shouldn't we
> > > then also count 1830 C&A for $320 rather than $160?
> > > I would prefer to stick to the rules, and leave it to the players to
> > > take note of (or forget about) any expected future gains.
> > >
> > > Erik.
> > >
> > >
> > >
> > > --------------------------------------------------------------------
> > > -----
> > > -- --- 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
> >
> > ----------------------------------------------------------------------
> > -----
> > --- 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
> 
>
----------------------------------------------------------------------------
--
> 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] Players total value (was: Some questions regarding a new release)

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

All:
sorry I submitted a version of the mail, which was an older one and was not 
fully edited to what it should have been:

I first considered the question of sure (or almost sure) closure of an item 
before game end to be the relevant. But as many already complained this 
is ambiguous (in theory nearly all games can end before seeing the first tile 
laid, even without thinking about bankruptcy).

For sure the on-going value can be configured to be an additional or optional 
replacement of the end-of-game value. It was already on my to-do-list to make 
the current end-of-game value.

Feel free to suggest something better suited.

Stefan


So my fully finished proposal is for an ongoing player value is stated below:

A) For items that have a value at game end unequal to zero use that.

B) For items that have a value at game end equal to zero use the purchasing 
cost defined below.

Purchasing price for type B items:

1) The actual price paid to the bank is relevant (e.g after a bidding 
process).

2) if a bundle is sold the value of all Items of type B purchased from bundles 
are evaluated by deducting first the current value of all type A items (at the 
time of purchase) from the purchase price and then the remaining amount
is distributed equally to all type B items of the bundle.
 
Some further remarks:
a) Potential conversions (even automatic) are irrelevant until they occur.

b) Items might change their type from B to A without conversion if their game 
end value changes from zero to a non-zero value. This has no retrograde effect 
of the value of other items sold in a bundle with the item.

Remark b) covers the case of the C&A:

The PRR share bundled with the C&A will be first assigned the difference 
between the purchase price of the C&A minus the value of the C&A. Later if a 
market price is available then the PRR share is valued by that.


On Tuesday, December 20, 2011 08:07:14 am 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:
> 
> B) Items that will close before end for sure will use the purchase value.
> 
> 
> For this we should internally however differentiate between game end player
> value and ongoing current player value: This would allow us easily to
> choose by game configuration to display end value or current value.
> 
> However I suggest to defer implementation to the Rails 2.0 trunk.
> 
> Stefan
> 
> On Sunday, December 18, 2011 11:24:54 pm Erik Vos wrote:
> > > -----Original Message-----
> > > From: John David Galt [mailto:jd...@di...]
> > > Sent: Sunday, December 18, 2011 11:00 PM
> > > To: Development list for Rails: an 18xx game
> > > Subject: Re: [Rails-devel] Some questions regarding a new release
> > > 
> > > On 2011-12-18 08:04, Erik Vos wrote:
> > > > [1835] Net worth calculation seems a little off, I think it's getting
> > > > confused particularly with the Prussian certs.  [Phil Davies
> > > > 17-6-2010]
> > > 
> > > I noticed this recently, too.  What seems to be happening is that in
> > > both 1835 and 18EU, the minor companies are counted as zero in net
> > > worth.
> > 
> > While
> > 
> > > this may be correct in the rules, it's a distortion for players who
> > > want
> > 
> > to use
> > 
> > > net worth as a way to predict final positions.
> > > 
> > > I suggest that in 1835, the privates and minors should be counted as
> > > the value of the PR shares they will eventually trade for (77M per 5%
> > > if PR
> > 
> > has
> > 
> > > not yet formed), while for 18EU, I would just count them all as $100
> > > each
> > 
> > (as
> > 
> > > a ballpark estimate).
> > 
> > Hmm, if we are going to count privates/minors to their expected future
> > value rather than their official current value, shouldn't we then also
> > count 1830 C&A for $320 rather than $160?
> > I would prefer to stick to the rules, and leave it to the players to take
> > note of (or forget about) any expected future gains.
> > 
> > Erik.
> > 
> > 
> > 
> > -------------------------------------------------------------------------
> > -- --- 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
> 
> ---------------------------------------------------------------------------
> --- 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] Players total value (was: Some questions regarding a new release)

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

I'd second Chris, net worth should always state net worth if the game
were to end right now.

On 20 December 2011 15:24, Chris Shaffer <chr...@gm...> wrote:
> On Mon, Dec 19, 2011 at 11:07 PM, Stefan Frey <ste...@we...> wrote:
>>
>> B) Items that will close before end for sure will use the purchase value.
>
>
> What if the item was purchased for $120 but is guaranteed to be exchanged
> for an item worth $80?
>
> I personally prefer actual end-game value, and listing things that will have
> an end game value of zero as their actual value - zero.  If there is a
> system to evaluate potential net worth, I hope you will have a game/engine
> option to disable it and display actual net worth instead.
>
> --
> Chris
>
> Please consider the environment before printing this e-mail.
>
> ------------------------------------------------------------------------------
> 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] Players total value (was: Some questions regarding a new release)

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

On Mon, Dec 19, 2011 at 11:07 PM, Stefan Frey <ste...@we...> wrote:

> B) Items that will close before end for sure will use the purchase value.


What if the item was purchased for $120 but is guaranteed to be exchanged
for an item worth $80?

I personally prefer actual end-game value, and listing things that will
have an end game value of zero as their actual value - zero.  If there is a
system to evaluate potential net worth, I hope you will have a game/engine
option to disable it and display actual net worth instead.

--
Chris

Please consider the environment before printing this e-mail.

Re: [Rails-devel] Some questions regarding a new release

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

> From: John David Galt [mailto:jd...@di...]
> I tried to test this, specifically the assertion that OBB doesn't close if
its hexes
> are built without using the private company power.  But I got a surprise:
> if you own OBB and build one of those hexes, the program doesn't ask
> whether you are using the private company power, it just assumes you are,
> even if you have a track connection to the hex.

Yes, that's a shortcut, of which I was aware.  
 
> This assumption doesn't seem to do any harm in 1835, since OBB is supposed
> to close if both hexes are built on, no matter how or by whom.  But it
will
> matter in games that have a private company with a tile-laying power which
> closes the private, or which reduces the cost of the tile (as in 1870 and
> 18C2C).

This should indeed be fixed.  Good point.

> The program correctly *does* ask whether or not you're using a private
> company power when placing a token in the NF or PfB hex.  There it does
> matter, since placing the token closes the private company only if it's
done
> using the private company's power.


Erik.

Re: [Rails-devel] Players total value (was: Some questions regarding a new release)

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

A few comments below.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Tuesday, December 20, 2011 8:07 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Players total value (was: Some questions
regarding
> a new release)
> 
> 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.

All items have an end game value, possibly zero. I understand you mean:
Items that have a non-zero end game value use that. 

> B) Items that will close before end for sure will use the purchase value.

Unless A) also applies?
One problem arises with bankruptcies. A player might think (for instance,
when engineering a bankruptcy) that he owns more end-game value than is
actually the case.

> 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
form
> the purchase price first, if a positive value remains it get equally
assigned to
> all items of type B.
> 
> For this we should internally however differentiate between game end
> player value and ongoing current player value: This would allow us easily
to
> choose by game configuration to display end value or current value.

Or both.  That would in any case fix the bankruptcy issue mentioned above.

Erik.

Re: [Rails-devel] Players total value (was: Some questions regarding a new release)

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

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.
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 form 
the purchase price first, if a positive value remains it get equally assigned 
to all items of type B.

For this we should internally however differentiate between game end player 
value and ongoing current player value: This would allow us easily to choose 
by game configuration to display end value or current value.

However I suggest to defer implementation to the Rails 2.0 trunk.

Stefan


On Sunday, December 18, 2011 11:24:54 pm Erik Vos wrote:
> > -----Original Message-----
> > From: John David Galt [mailto:jd...@di...]
> > Sent: Sunday, December 18, 2011 11:00 PM
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] Some questions regarding a new release
> > 
> > On 2011-12-18 08:04, Erik Vos wrote:
> > > [1835] Net worth calculation seems a little off, I think it's getting
> > > confused particularly with the Prussian certs.  [Phil Davies
> > > 17-6-2010]
> > 
> > I noticed this recently, too.  What seems to be happening is that in both
> > 1835 and 18EU, the minor companies are counted as zero in net worth.
> 
> While
> 
> > this may be correct in the rules, it's a distortion for players who want
> 
> to use
> 
> > net worth as a way to predict final positions.
> > 
> > I suggest that in 1835, the privates and minors should be counted as the
> > value of the PR shares they will eventually trade for (77M per 5% if PR
> 
> has
> 
> > not yet formed), while for 18EU, I would just count them all as $100 each
> 
> (as
> 
> > a ballpark estimate).
> 
> Hmm, if we are going to count privates/minors to their expected future
> value rather than their official current value, shouldn't we then also
> count 1830 C&A for $320 rather than $160?
> I would prefer to stick to the rules, and leave it to the players to take
> note of (or forget about) any expected future gains.
> 
> Erik.
> 
> 
> 
> ---------------------------------------------------------------------------
> --- 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

Re: [Rails-devel] Some questions regarding a new release

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

On 2011-12-18 08:04, Erik Vos mentioned:
> 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.

I tried to test this, specifically the assertion that OBB doesn't close if its
hexes are built without using the private company power.  But I got a surprise:
if you own OBB and build one of those hexes, the program doesn't ask whether
you are using the private company power, it just assumes you are, even if you
have a track connection to the hex.

This assumption doesn't seem to do any harm in 1835, since OBB is supposed to
close if both hexes are built on, no matter how or by whom.  But it will matter
in games that have a private company with a tile-laying power which closes the
private, or which reduces the cost of the tile (as in 1870 and 18C2C).

The program correctly *does* ask whether or not you're using a private company
power when placing a token in the NF or PfB hex.  There it does matter, since
placing the token closes the private company only if it's done using the
private company's power.

Re: [Rails-devel] Some questions regarding a new release

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

> [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]

Actually, I cannot find anywhere in the rules and FAQs that any PR tokens
are "reserved" for exchange, however logical that would be.
So I think that this is more a matter of taste (or house rules) than a bug,
which makes me conclude that there is insufficient reason to have Rails
enforce reserving PR tokens.
Players can play the way they like.

Erik.

Re: [Rails-devel] Bug in 18EU implementation in 1.54

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

> From: Stefan Frey [mailto:ste...@we...]
> are you sure that the FinalMinorExchangeRound is the only one effected?
>
> There are a few more Pseudo-StockRounds which all inherit from
> StockRound that might be effected:

I have checked these only visually.

> * PrussianFormationRound

... has its own finishRound() method that does not up the share price and
does not call super methods.

> * ShareSellingRound and ShareSellingRound_1856

... you're probably right on this one. I thought: share selling is forced
and will always end up with shares in the Pool, but of course that does not
apply to all companies.

> * TreasuryShareRound

... does not call finishRound().

On second thoughts, it's probably safer to set the new 'raiseIfSoldOut'
attribute to false by default, and move the true setting from the
constructor to the start() method. The latter method is only called by
"real" stock rounds; all other types have their own variety of this method.
I'll also add a warning comment.

Erik.

[Rails-devel] Background maps 18GA Cotton Port and 1856

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

as stated in the subject line:
New background maps for 18GA variant Cotton Port and 1856 are pushed to the 
repository: Thanks to Frederick Weld for his work (Cotton Port is a change of 
the design of Peter Mumford).
Stefan

Re: [Rails-devel] Bug in 18EU implementation in 1.54

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

Erik:
are you sure that the FinalMinorExchangeRound is the only one effected?

There are a few more Pseudo-StockRounds which all inherit from StockRound that 
might be effected:

* PrussianFormationRound
* ShareSellingRound and ShareSellingRound_1856
* TreasuryShareRound

I will wait with the new release until this is fixed.

We will have to add a warning for the users of 18EU that an upgrade might make 
loading their current save file impossible. Unfortunately that is also true 
for our (only) current test game of 18EU. 

Stefan


On Sunday, December 18, 2011 01:04:12 pm Erik Vos wrote:
> Martin,
> 
> 
> 
> You are quite correct on this bug and its cause.
> 
> I have added a new StockRound attribute 'raiseIfSoldOut' that is normally
> true, but is set false at the start of 18EU/FinalMinorExchangeRound.
> 
> 
> 
> I don't believe that any other pseudo-StockRounds are vulnerable to this
> problem, but if so, there is an easy fix now.
> 
> 
> 
> Erik.
> 
> 
> 
> From: Dr. Martin Brumm [mailto:dr....@t-...]
> Sent: Sunday, December 18, 2011 12:48 AM
> To: Rails Developer Liste
> Cc: Hans-Juergen Krupp
> Subject: [Rails-devel] Bug in 18EU implementation in 1.54
> 
> 
> 
> Hi all,
> 
> 
> 
> in a recent game i exchanged a minor for the last share of a major
> corporation in the Final Minor Exchange Round.
> 
> This caused the Stock price of that Corporation to Rise at the start of the
> Subsequent AR/End of Minor Exchange Round ?
> 
> 
> 
> I believe that this is not correct as the rules state it should only rise
> at the end of a Stock Round.
> 
> I suspect that this comes from the implementation of the Final Exchange
> Round as a Subclass of Stockround ?
> 
> 
> 
> Anybody can share light on that behavior, I deem this a not correct feature
> 
> :-) (even though I would profit from it :-)).
> 
> Regards, Martin
> 
> 
> 
> Enclosed the 3 Save Files from Minor Exchange and following SR.

Re: [Rails-devel] Some questions regarding a new release

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

> -----Original Message-----
> From: John David Galt [mailto:jd...@di...]
> Sent: Sunday, December 18, 2011 11:00 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Some questions regarding a new release
> 
> On 2011-12-18 08:04, Erik Vos wrote:
> > [1835] Net worth calculation seems a little off, I think it's getting
> > confused particularly with the Prussian certs.  [Phil Davies
> > 17-6-2010]
> 
> I noticed this recently, too.  What seems to be happening is that in both
> 1835 and 18EU, the minor companies are counted as zero in net worth.
While
> this may be correct in the rules, it's a distortion for players who want
to use
> net worth as a way to predict final positions.
> 
> I suggest that in 1835, the privates and minors should be counted as the
> value of the PR shares they will eventually trade for (77M per 5% if PR
has
> not yet formed), while for 18EU, I would just count them all as $100 each
(as
> a ballpark estimate).

Hmm, if we are going to count privates/minors to their expected future value
rather than their official current value, shouldn't we then also count 1830
C&A for $320 rather than $160? 
I would prefer to stick to the rules, and leave it to the players to take
note of (or forget about) any expected future gains.

Erik.

Re: [Rails-devel] Some questions regarding a new release

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

On 2011-12-18 08:04, Erik Vos wrote:
> [1835] Net worth calculation seems a little off, I think it's getting
> confused particularly with the Prussian certs.  [Phil Davies 17-6-2010]

I noticed this recently, too.  What seems to be happening is that in both
1835 and 18EU, the minor companies are counted as zero in net worth.  While
this may be correct in the rules, it's a distortion for players who want to
use net worth as a way to predict final positions.

I suggest that in 1835, the privates and minors should be counted as the
value of the PR shares they will eventually trade for (77M per 5% if PR has
not yet formed), while for 18EU, I would just count them all as $100 each
(as a ballpark estimate).

[Rails-devel] Feature 3454269 (background music) available - Some details on the design/implementation

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

Rails is now capable of playing background music depending on the
context (phase, round type). So, as for SimTex's 1830, if a new phase
begins (or in case of a OR-SR switch), rails plays a different mp3 in
the background. As a result, experiencing/triggering context changes
(eg, rusting others' trains) is now much more fun.

The end user can configure which mp3 track is used for which context
in the configuration window (new tab "Sound"). There, he can also
define assignment of mp3 tracks to several contexts (e.g., the same SR
music independent of the phase - as it is done in SimTex's 1830).

For copyright reasons, no default mp3 tracks are included in rails.
During testing, I had configured rails to access SimTex's mp3 files
but, as I understand, rails would not be allowed to redistribute them.
Therefore, the end user has to provide mp3 files on his own.

I've sent the patch files to Brett who will (hopefully) merge them
into origin/master.

==========================================
Some more details about the implementation
==========================================

Playing mp3 is based on the lib JLayer which is now added to the rails
lib. This should be ok for all of you as:
- lib licencse is LGPL
- lib size is only 100kb

All the logic regarding the background music is found in
rails.sound.BackgroundMusicManager. Some comments about the most
important design decisions:
- This is a static class - there may only be one background music at a time.
- The Manager is notified of context changes by adding notification
calls from the context-changing parts of the game:
   - rails.game.Phase
   - rails.game.StockRound
   - rails.game.OperatingRound
  (I would have loved to subscribe to such kind of information but,
since there are no such interfaces available and you apparently aim at
refactoring for 2.0, this was not possible.)
- The Manager is started/configured by calls from rails.game.Game

I hope this is ok for all of you. If you find bugs in the new code,
don't hesitate to contact me.

Regards,
Frederick

Re: [Rails-devel] Some questions regarding a new release

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

Erik:
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

Re: [Rails-devel] Some questions regarding a new release

[Edward S. R. <ed...@we...>]

On Sun, Dec 18, 2011 at 15:26, Stefan Frey <ste...@we...> wrote:
> 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.

For what little it's worth, I'd rather the background maps stay as
they are. Right now they're functional and I'm generally of the
opinion that having a prettier map does not make up for what you lose
in ability to read the map at a glance. Currently there a certain
elegance to the maps in their clean lines and lack of distraction.

Re: [Rails-devel] Some questions regarding a new release

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

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

[Rails-devel] Some questions regarding a new release

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

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