rails-devel — List for discussion of Rails development

Re: [Rails-devel] Further 1835 testing

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

I'll just note that your method doesn't solve the problem in any fewer
classes than mine does. You have CertType and Cert, where I have Cert
and Share. This appears to be the same bike shed, just painted a
different color.

Your way seems to work just fine, too. I've got no objections to it. :-)

---Brett.



On Fri, Nov 18, 2011 at 10:38 AM, Stefan Frey <ste...@we...> wrote:
> Brett,
> I agree and disagree with you at the same time:
>
> * I agree that the concepts of certificate and "share" should be clearly
> distinguished.
>
> * I disagree the concept of "share" should be objects in Rails. I prefer the
> nominal (percentage) being an attribute of the certificates.
>
> So my suggestion (derived from all input from the current discussion) is:
>
> A) Use one class that represents share certificates types. Use another class
> that represent concrete share certificates (similar to trains and train types,
> and this would be required for your proposal as well).
>
> B) Share certificate types have an attribute called nominal_percentage (or
> nominal percentage) which defines what their contribution to the total capital
> stock is and another boolean attribute which defines president or not.
>
> C) Each company defines an attribute called quotation_percentage which defines
> the percentage of stock ownership the stock market price corresponds to. The
> selling and purchase price for each certificate then equals
> (nominal_percentage / quotation_percentage) * stock_price.
>
>
> For 1835 the following certification types would be defined:
>
> Major PR:
> * One certification type "President share", nominal_percentage = 10% and
> president = yes
> * One certification type "10% share", nominal_percentage = 10%, president = no
> * One certification type "5%share", nominal_percentage = 5%
> And the quotation_percentage is 10%.
>
> For all other majors except BY,SX:
> * One certification type "President share", nominal_percentage = 20% and
> president = yes
> * One certification type "20% share", nominal_percentage = 20%, president = no
> * One certification type "10% share", nominal_percentage = 10%
> And the quotation_percentage is 10%.
>
> For BY and SX:
> * One certification type "President share", nominal_percentage = 20% and
> president = yes
> * One certification type "10% share", nominal_percentage = 10%, president = no
> And the quotation_percentage is 10%.
>
> The major advantage is now that we do not have even to fear a lunatic game
> designer who defines a company with share capital divided into shares with
> 9%, 11%, 21%, 28%, 31% participation, for which the stock price is quoted for
> the 9% nominal ;-)
>
>
> Stefan
>
>
> On Friday, November 18, 2011 03:51:44 pm brett lentz wrote:
>> On Fri, Nov 18, 2011 at 4:50 AM, Stefan Frey <ste...@we...> wrote:
>> > On Friday, November 18, 2011 10:39:01 am Erik Vos wrote:
>> >> > 3) Most people's definition of a "share" is such that the stock price
>> >>
>> >> chart gives
>> >>
>> >> > the price of one share.  Therefore, a "share" is 10%.
>> >
>> There are two basic concepts that my gaming circle uses for 18xx games
>> that I think are well-suited for clarifying this issue.
>>
>> There's the "pieces of cardboard" or "certificates", which is used for
>> things like maximum certificate limits.
>> Then there's "shares" which are the divisible denominations of the
>> company ownership.
>>
>> Each "share" is divided up into face-value percentages, the most
>> common being 10%. However, a single "piece of cardboard" may have
>> multiple "shares" represented (e.g. the president's "certificate" is
>> really 2 "shares")
>>
>> So, in terms of internal code representation, we (should) have two
>> classes and a few properties.
>>
>> Class 1: Certificate.
>> - property: share_array
>>
>> Class 2: Share.
>> - property: base_percentage
>>
>>
>> So, for situations like 1856's formation of the CNR, it's actually a
>> decision of whether we're creating 10 10% shares (using 9
>> certificates) or 20 5% shares (using 19 certificates). This is part of
>> the process of the CNR formation, because it requires calculating how
>> many companies are being folded in.
>>
>> >> Yes, that is a sensible point of view.  One problem is, though, that we
>> >> must rethink how to report selling multiple shares.
>> >
>> > Erik I even wondered how you got everything consistent with his
>> > definition PR's share unit being 5%?
>> > I suspect you created a variable that defines something like "stock is
>> > quoted in multiples of 2".
>>
>> But you never sell "shares", you always sell "certificates" (i.e. the
>> piece of cardboard).  So, your transaction is always with the
>> "container" for the shares.
>>
>> >> If a player sells two 5% certificates, what did he sell in terms of
>> >> shares? One share?  Two 5% shares? Two half-shares?
>> >
>> > I prefer two "5% certificates". All other definitions end up being
>> > ambiguous in some constellation. I would even use an ID for the
>> > certificate types instead of the 5% attribute, as there might come up a
>> > game with various certificates that have the same nominal but differ in
>> > some other properties.
>>
>> I'm a little unclear on the 1835 situation. My thought would be that
>> the base "share" value should be whatever the smallest denomination
>> being used is.
>>
>> So, if there's 2x 5% shares floating around and everything else is
>> 10%, we should use 5% as the base value, and the whole company's set
>> of (cardboard) certificates should contain a number of share objects
>> that adequately represents their total value. This means that the
>> whole company has 20 "shares" of stock, divided into 10 (cardboard)
>> certificates. (e.g. 2x certificates at 5%, 7x certificates at 10% each
>> containing 2 shares, and 1x certificate at 20% which contains 4
>> shares.)
>>
>> Having two separate objects makes all of the math and logic *so* much
>> simpler.
>>
>> > Stefan
>>
>> ---Brett.
>>
>> ---------------------------------------------------------------------------
>> --- All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Further 1835 testing

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

Brett,
I agree and disagree with you at the same time:

* I agree that the concepts of certificate and "share" should be clearly 
distinguished.

* I disagree the concept of "share" should be objects in Rails. I prefer the 
nominal (percentage) being an attribute of the certificates.

So my suggestion (derived from all input from the current discussion) is:

A) Use one class that represents share certificates types. Use another class 
that represent concrete share certificates (similar to trains and train types, 
and this would be required for your proposal as well).

B) Share certificate types have an attribute called nominal_percentage (or 
nominal percentage) which defines what their contribution to the total capital 
stock is and another boolean attribute which defines president or not.

C) Each company defines an attribute called quotation_percentage which defines 
the percentage of stock ownership the stock market price corresponds to. The 
selling and purchase price for each certificate then equals 
(nominal_percentage / quotation_percentage) * stock_price.


For 1835 the following certification types would be defined:

Major PR:
* One certification type "President share", nominal_percentage = 10% and 
president = yes
* One certification type "10% share", nominal_percentage = 10%, president = no
* One certification type "5%share", nominal_percentage = 5%
And the quotation_percentage is 10%.

For all other majors except BY,SX:
* One certification type "President share", nominal_percentage = 20% and 
president = yes
* One certification type "20% share", nominal_percentage = 20%, president = no
* One certification type "10% share", nominal_percentage = 10%
And the quotation_percentage is 10%.

For BY and SX: 
* One certification type "President share", nominal_percentage = 20% and 
president = yes
* One certification type "10% share", nominal_percentage = 10%, president = no
And the quotation_percentage is 10%.

The major advantage is now that we do not have even to fear a lunatic game 
designer who defines a company with share capital divided into shares with  
9%, 11%, 21%, 28%, 31% participation, for which the stock price is quoted for 
the 9% nominal ;-)


Stefan


On Friday, November 18, 2011 03:51:44 pm brett lentz wrote:
> On Fri, Nov 18, 2011 at 4:50 AM, Stefan Frey <ste...@we...> wrote:
> > On Friday, November 18, 2011 10:39:01 am Erik Vos wrote:
> >> > 3) Most people's definition of a "share" is such that the stock price
> >> 
> >> chart gives
> >> 
> >> > the price of one share.  Therefore, a "share" is 10%.
> > 
> There are two basic concepts that my gaming circle uses for 18xx games
> that I think are well-suited for clarifying this issue.
> 
> There's the "pieces of cardboard" or "certificates", which is used for
> things like maximum certificate limits.
> Then there's "shares" which are the divisible denominations of the
> company ownership.
> 
> Each "share" is divided up into face-value percentages, the most
> common being 10%. However, a single "piece of cardboard" may have
> multiple "shares" represented (e.g. the president's "certificate" is
> really 2 "shares")
> 
> So, in terms of internal code representation, we (should) have two
> classes and a few properties.
> 
> Class 1: Certificate.
> - property: share_array
> 
> Class 2: Share.
> - property: base_percentage
> 
> 
> So, for situations like 1856's formation of the CNR, it's actually a
> decision of whether we're creating 10 10% shares (using 9
> certificates) or 20 5% shares (using 19 certificates). This is part of
> the process of the CNR formation, because it requires calculating how
> many companies are being folded in.
> 
> >> Yes, that is a sensible point of view.  One problem is, though, that we
> >> must rethink how to report selling multiple shares.
> > 
> > Erik I even wondered how you got everything consistent with his
> > definition PR's share unit being 5%?
> > I suspect you created a variable that defines something like "stock is
> > quoted in multiples of 2".
> 
> But you never sell "shares", you always sell "certificates" (i.e. the
> piece of cardboard).  So, your transaction is always with the
> "container" for the shares.
> 
> >> If a player sells two 5% certificates, what did he sell in terms of
> >> shares? One share?  Two 5% shares? Two half-shares?
> > 
> > I prefer two "5% certificates". All other definitions end up being
> > ambiguous in some constellation. I would even use an ID for the
> > certificate types instead of the 5% attribute, as there might come up a
> > game with various certificates that have the same nominal but differ in
> > some other properties.
> 
> I'm a little unclear on the 1835 situation. My thought would be that
> the base "share" value should be whatever the smallest denomination
> being used is.
> 
> So, if there's 2x 5% shares floating around and everything else is
> 10%, we should use 5% as the base value, and the whole company's set
> of (cardboard) certificates should contain a number of share objects
> that adequately represents their total value. This means that the
> whole company has 20 "shares" of stock, divided into 10 (cardboard)
> certificates. (e.g. 2x certificates at 5%, 7x certificates at 10% each
> containing 2 shares, and 1x certificate at 20% which contains 4
> shares.)
> 
> Having two separate objects makes all of the math and logic *so* much
> simpler.
> 
> > Stefan
> 
> ---Brett.
> 
> ---------------------------------------------------------------------------
> --- All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Further 1835 testing

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

On Fri, Nov 18, 2011 at 9:59 AM, Phil Davies <de...@gm...> wrote:
> On 18 November 2011 14:51, brett lentz <bre...@gm...> wrote:
>> But you never sell "shares"
>
> Not always true, there are several cases where you can sell a share
> and receive change in the form of certificates of a different
> denomination.  I don't think that actually affects your suggestions
> but it isn't true that you can only sell certificates since you can
> change them in in the correct scenarios.
>


You're absolutely right.

This is what I get for trying to be coherent on 4 hours of sleep.  ;-)

---Brett.

Re: [Rails-devel] Further 1835 testing

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

On 18 November 2011 14:51, brett lentz <bre...@gm...> wrote:
> But you never sell "shares"

Not always true, there are several cases where you can sell a share
and receive change in the form of certificates of a different
denomination.  I don't think that actually affects your suggestions
but it isn't true that you can only sell certificates since you can
change them in in the correct scenarios.

Re: [Rails-devel] Further 1835 testing

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

On Fri, Nov 18, 2011 at 4:50 AM, Stefan Frey <ste...@we...> wrote:
> On Friday, November 18, 2011 10:39:01 am Erik Vos wrote:
>> > 3) Most people's definition of a "share" is such that the stock price
>>
>> chart gives
>>
>> > the price of one share.  Therefore, a "share" is 10%.
>>
>
> That is definitely the best argument. for PR's share unit being 10%.
> Could someone remind me (as a newbie to 1856) how does it work
> for the Candian government railway if it issues 20 shares? Does the share
> price reflects still 10% or does it refer to 5%?
>

There are two basic concepts that my gaming circle uses for 18xx games
that I think are well-suited for clarifying this issue.

There's the "pieces of cardboard" or "certificates", which is used for
things like maximum certificate limits.
Then there's "shares" which are the divisible denominations of the
company ownership.

Each "share" is divided up into face-value percentages, the most
common being 10%. However, a single "piece of cardboard" may have
multiple "shares" represented (e.g. the president's "certificate" is
really 2 "shares")

So, in terms of internal code representation, we (should) have two
classes and a few properties.

Class 1: Certificate.
- property: share_array

Class 2: Share.
- property: base_percentage


So, for situations like 1856's formation of the CNR, it's actually a
decision of whether we're creating 10 10% shares (using 9
certificates) or 20 5% shares (using 19 certificates). This is part of
the process of the CNR formation, because it requires calculating how
many companies are being folded in.


>> Yes, that is a sensible point of view.  One problem is, though, that we
>> must rethink how to report selling multiple shares.
>
> Erik I even wondered how you got everything consistent with his definition
> PR's share unit being 5%?
> I suspect you created a variable that defines something like "stock is quoted
> in multiples of 2".
>


But you never sell "shares", you always sell "certificates" (i.e. the
piece of cardboard).  So, your transaction is always with the
"container" for the shares.


>> If a player sells two 5% certificates, what did he sell in terms of shares?
>> One share?  Two 5% shares? Two half-shares?
>>
>
> I prefer two "5% certificates". All other definitions end up being ambiguous
> in some constellation. I would even use an ID for the certificate types
> instead of the 5% attribute, as there might come up a game with various
> certificates that have the same nominal but differ in some other properties.

I'm a little unclear on the 1835 situation. My thought would be that
the base "share" value should be whatever the smallest denomination
being used is.

So, if there's 2x 5% shares floating around and everything else is
10%, we should use 5% as the base value, and the whole company's set
of (cardboard) certificates should contain a number of share objects
that adequately represents their total value. This means that the
whole company has 20 "shares" of stock, divided into 10 (cardboard)
certificates. (e.g. 2x certificates at 5%, 7x certificates at 10% each
containing 2 shares, and 1x certificate at 20% which contains 4
shares.)

Having two separate objects makes all of the math and logic *so* much simpler.

>
> Stefan
>

---Brett.

Re: [Rails-devel] Further 1835 testing

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

Hi Guys, 

	keep in mind that there are games lurking in the wood that have
higher denominations and not even a fixed one for the portfolio at
start. 

	And yes of course prime example: 1880 -> The president share might be
a 20, 30 or 40 percent share and thus subsequently the number of
shares per company might not be known until the corporation has
started. 

	The german "Papier" comes to mind a "Papier" might be a Private
Company, but also a 5/10/20/30/40 percent certificate. The smalles
denomination currently is of course the 5% one but who knows what the
future will bring ? 

	So shouldnt we define a configurable "Denomination property" per game
? 

	Regards, 

	Martin  

	  Von: "Erik Vos" <eri...@xs...>
 An: "'Development list for Rails: an 18xx game'"
<rai...@li...>
 Betreff: Re: [Rails-devel] Further 1835 testing
 Datum: Fri, 18 Nov 2011 11:46:32 +0100

 > Works fine and I like that. However I would prefer not to show up
in games
 > where it does not matter (i.e. P are 20% and all others shares are
10%),
 but I
 > am open to other opinions here.

 That would require an extra company property.  But let's first see if
we get
 any complaints.

 > The only annoying bit is that a small rectangle (an empty tool-tip)
 appears for
 > those cells without any shares.

 Fixed (not yet pushed).

 Erik.

 ------------------------------------------------------------------------------
 All the data continuously generated in your IT infrastructure 
 contains a definitive record of customers, application performance, 
 security threats, fraudulent activity, and more. Splunk takes this 
 data and makes sense of it. IT sense. And common sense.
 http://p.sf.net/sfu/splunk-novd2d
 _______________________________________________
 Rails-devel mailing list
 Rai...@li...
 https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Further 1835 testing

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

> Works fine and I like that. However I would prefer not to show up in games
> where it does not matter (i.e. P are 20% and all others shares are 10%),
but I
> am open to other opinions here.

That would require an extra company property.  But let's first see if we get
any complaints.

> The only annoying bit is that a small rectangle (an empty tool-tip)
appears for
> those cells without any shares.

Fixed (not yet pushed).

Erik.

Re: [Rails-devel] Further 1835 testing

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

> > > 3) Most people's definition of a "share" is such that the stock
> > > price chart gives the price of one share.  Therefore, a "share" is
10%.
> 
> That is definitely the best argument. for PR's share unit being 10%.
> Could someone remind me (as a newbie to 1856) how does it work for the
> Candian government railway if it issues 20 shares? Does the share price
> reflects still 10% or does it refer to 5%?

5%.

> Erik I even wondered how you got everything consistent with his definition
> PR's share unit being 5%?
> I suspect you created a variable that defines something like "stock is
quoted
> in multiples of 2".

Exactly: that's the variable shareUnitsForSharePrice in PublicCompany. It's
configurable:
	<ShareUnit percentage="5" sharePriceUnits="2"/>
for the PR. 
 
> > If a player sells two 5% certificates, what did he sell in terms of
shares?
> > One share?  Two 5% shares? Two half-shares?
> >
> 
> I prefer two "5% certificates". All other definitions end up being
ambiguous in
> some constellation. 

Yes, that's probably the best approach. 

> I would even use an ID for the certificate types instead of
> the 5% attribute, as there might come up a game with various certificates
> that have the same nominal but differ in some other properties.

Hmm, that might even enable consistent sorting of the details in the new
portfolio composition tooltip.

Erik.

Re: [Rails-devel] Further 1835 testing

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

On Friday, November 18, 2011 10:39:01 am Erik Vos wrote:
> > 3) Most people's definition of a "share" is such that the stock price
> 
> chart gives
> 
> > the price of one share.  Therefore, a "share" is 10%.
> 

That is definitely the best argument. for PR's share unit being 10%.
Could someone remind me (as a newbie to 1856) how does it work
for the Candian government railway if it issues 20 shares? Does the share 
price reflects still 10% or does it refer to 5%?

> Yes, that is a sensible point of view.  One problem is, though, that we
> must rethink how to report selling multiple shares.

Erik I even wondered how you got everything consistent with his definition 
PR's share unit being 5%?
I suspect you created a variable that defines something like "stock is quoted 
in multiples of 2".

> If a player sells two 5% certificates, what did he sell in terms of shares?
> One share?  Two 5% shares? Two half-shares?
> 

I prefer two "5% certificates". All other definitions end up being ambiguous 
in some constellation. I would even use an ID for the certificate types 
instead of the 5% attribute, as there might come up a game with various 
certificates that have the same nominal but differ in some other properties.

Stefan

Re: [Rails-devel] Further 1835 testing

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

> 3) Most people's definition of a "share" is such that the stock price
chart gives
> the price of one share.  Therefore, a "share" is 10%.

Yes, that is a sensible point of view.  One problem is, though, that we must
rethink how to report selling multiple shares.
If a player sells two 5% certificates, what did he sell in terms of shares?
One share?  Two 5% shares? Two half-shares?

Erik.

Re: [Rails-devel] Further 1835 testing

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

> Erik Vos wrote:
>> The PR share unit size is 5%, so a 10% certificate is two shares.
>> The 1835 rules do not very clearly distinguish between certificates and
>> shares, but we have to.

Stefan Frey wrote:
> You are right from a logical and an implementation point of view. Still I find 
> the wording confusing, because of two reasons:
> 
> A) 1835 and PR specific
> For me (thus subjective) in 1835 the share unit for PR seems to be 10%. So if 
> I would use the word share (see below) the 5% shares are more like half a 
> share.  This also corresponds to the standard in 18xx, where most of the time 
> the 10% is the typical share unit.
> 
> A) The word in shares in this context
> For me a share is still more associated with the actual certificate than the 
> participation right. Due to this reason I would prefer the error message to 
> make this clear. Otherwise the user might get confused because he does not
> distinguish between share and certificate here. Example: "T3 cannot buy 1 
> certificate(s) with 10% of PR from IPO)".

3) Most people's definition of a "share" is such that the stock price chart
gives the price of one share.  Therefore, a "share" is 10%.

Re: [Rails-devel] 18AL map

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

Thanks! The 18AL map is committed to the public repo.
In addition John Tamplin offered to provide a SVG conversion of the 1889 map, 
so we will have 4 games (18GA, 18AL, 18EU, 1889) with background maps soon.
Hopefully others will follow.
Stefan


On Tuesday, November 15, 2011 08:34:57 pm John David Galt wrote:
> On 2011-11-15 07:06, Stefan Frey wrote:
> > I have added a conversion to svg of the publicly available 18GA gamekit
> > map to the current trunk of Rails 1.x development.
> > Again it only shows if the option for a map background image is
> > activated.
> > 
> > As John David Galt is a user of Rails, I assume that is ok, otherwise he
> > could indicate if he prefers removal of the map from the Rails
> > repository.
> 
> No problem, use any of my art that will help.
> 
> ---------------------------------------------------------------------------
> --- RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Further 1835 testing

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

see comment below.

On Wednesday, November 16, 2011 06:53:25 pm Erik Vos wrote:
> All correct, except for one remark (see below).
> > A) For Player T3 PR is shown as buyable (shares are highlighted), even if
> > funds are not sufficient.
> > However after selecting an error message says that "T3 cannot buy 2
> 
> share(s)
> 
> > of PR from IPO: Not enough money".
> > The message is correct, however it is not 2 shares, but the larger 10%
> > certificate.
> 
> The PR share unit size is 5%, so a 10% certificate is two shares.
> The 1835 rules do not very clearly distinguish between certificates and
> shares, but we have to.

You are right from a logical and an implementation point of view. Still I find 
the wording confusing, because of two reasons:

A) 1835 and PR specific
For me (thus subjective) in 1835 the share unit for PR seems to be 10%. So if 
I would use the word share (see below) the 5% shares are more like half a 
share.  This also corresponds to the standard in 18xx, where most of the time 
the 10% is the typical share unit.

A) The word in shares in this context
For me a share is still more associated with the actual certificate than the 
participation right. Due to this reason I would prefer the error message to 
make this clear. Otherwise the user might get confused because he does not
distinguish between share and certificate here. Example: "T3 cannot buy 1 
certificate(s) with 10% of PR from IPO)".

However this issue should be decided by native speakers as the usual 
translation for share in German is "Aktie" - which clearly refers to the 
certificate, the other translation  "Anteil" - which refers to the 
participation right is less common.

Stefan

Re: [Rails-devel] Further 1835 testing

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

Works fine and I like that. However I would prefer not to show up in games 
where it does not matter (i.e. P are 20% and all others shares are 10%), but I 
am open to other opinions here.

The only annoying bit is that a small rectangle (an empty tool-tip) appears 
for those cells without any shares.

Stefan


On Wednesday, November 16, 2011 11:11:05 pm Erik Vos wrote:
> Done. No extra classes.
> The portfolio composition tooltip is not sorted in any way.  I suspect
> that's not too annoying.
> 
> Erik.
> 
> > Another main annoyance with 1835 is that it's unclear to see which
> 
> portfolios
> 
> > contain non-president double shares.  Several people have already
> > complained about that, and I will try to address that first.
> > I'll probably add portfolio composition info to each %-field tooltip,
> 
> adding
> 
> > such info to the ShareModel update info.  We may need additional
> > ShareField/ShareClickField  classes to parse and hold that info.  This
> 
> will then
> 
> > be a generic feature.
> 
> ---------------------------------------------------------------------------
> --- All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Further 1835 testing

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

Done. No extra classes.
The portfolio composition tooltip is not sorted in any way.  I suspect
that's not too annoying.

Erik.

 
> Another main annoyance with 1835 is that it's unclear to see which
portfolios
> contain non-president double shares.  Several people have already
> complained about that, and I will try to address that first.
> I'll probably add portfolio composition info to each %-field tooltip,
adding
> such info to the ShareModel update info.  We may need additional
> ShareField/ShareClickField  classes to parse and hold that info.  This
will then
> be a generic feature.

Re: [Rails-devel] Further 1835 testing

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

All correct, except for one remark (see below).

Another main annoyance with 1835 is that it's unclear to see which
portfolios contain non-president double shares.  Several people have already
complained about that, and I will try to address that first.  
I'll probably add portfolio composition info to each %-field tooltip, adding
such info to the ShareModel update info.  We may need additional
ShareField/ShareClickField  classes to parse and hold that info.  This will
then be a generic feature.

Erik.

> List of Bugs and Annoyances, see attached game files.
> 
> Bugs:
> A) Player T2 nationalizes BA from T3: There is no option to nationalize
the
> 20% certificate first.
> 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.
> 
> Annoyances:
> A) For Player T3 PR is shown as buyable (shares are highlighted), even if
> funds are not sufficient.
> However after selecting an error message says that "T3 cannot buy 2
share(s)
> of PR from IPO: Not enough money".
> The message is correct, however it is not 2 shares, but the larger 10%
> certificate.

The PR share unit size is 5%, so a 10% certificate is two shares.
The 1835 rules do not very clearly distinguish between certificates and
shares, but we have to.

> B) After laying/upgrading one tile already, SX still has the option to use
the
> special property of Pfalzbahn. However on clicking on L6 an error message
> says that "At the moment there is not valid tile or upgrade for this
hex.", this
> is wrong.
> Same case can be shown for OBB (given a tile lay before). Reversing the
> sequence (first laying special property, then normal tile lay, works
however).

Re: [Rails-devel] 18AL map

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

On 2011-11-15 07:06, Stefan Frey wrote:
> I have added a conversion to svg of the publicly available 18GA gamekit map to
> the current trunk of Rails 1.x development.
> Again it only shows if the option for a map background image is activated.
> 
> As John David Galt is a user of Rails, I assume that is ok, otherwise he could 
> indicate if he prefers removal of the map from the Rails repository.

No problem, use any of my art that will help.

[Rails-devel] 18AL map

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

I have added a conversion to svg of the publicly available 18GA gamekit map to
the current trunk of Rails 1.x development.
Again it only shows if the option for a map background image is activated.

As John David Galt is a user of Rails, I assume that is ok, otherwise he could 
indicate if he prefers removal of the map from the Rails repository.

Stefan

[Rails-devel] Further 1835 testing

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

Erik:
there has been great progress on 1835 recently, so I took the opportunity to 
do some testing of 1835.

Seems that everything works fine, however there are at least two bugs 
concerning the handling of multiple share classes (10% and 20%, 5% and 10%) 
in 1835.

And I think that if there are several share classes there should be an 
indication how your portfolio is split into those. Otherwise it can be quite 
confusing. Unfortunately from a technical point of view I have already 
rewritten the share/certificate model for Rails 2.0, so I will not be able to 
forward-port those changes to that branch.

Stefan

List of Bugs and Annoyances, see attached game files.

Bugs:
A) Player T2 nationalizes BA from T3: There is no option to nationalize the 
20% certificate first.
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.

Annoyances:
A) For Player T3 PR is shown as buyable (shares are highlighted), even if 
funds are not sufficient.
However after selecting an error message says that "T3 cannot buy 2 share(s) 
of PR from IPO: Not enough money".
The message is correct, however it is not 2 shares, but the larger 10% 
certificate.

B) After laying/upgrading one tile already, SX still has the option to use the 
special property of Pfalzbahn. However on clicking
on L6 an error message says that "At the moment there is not valid tile or 
upgrade for this hex.", this is wrong.
Same case can be shown for OBB (given a tile lay before). Reversing the 
sequence (first laying special property, then normal tile lay, works however).

[Rails-devel] 1835

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

> -----Original Message-----
> From: John David Galt [mailto:jd...@di...]
> 
> I can't wait!  With Erik's fixes of 10/14, I would say 1835 is now fully
playable.

I agree, and I have updated GamesList.xml accordingly.

Erik.

[Rails-devel] Tiles for water hexes.

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

Following a suggestion by Stefan Frey, I have added a blue water tile #-4000
and two half tiles #-4004 and #-4005.
These tiles can be used to mark map edges that border on sea.

The water tiles have been applied to 1825, all units and regional kits.

Erik.

[Rails-devel] Rails 1.5.3 available

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

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

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

Thanks to all contributors: Bill Rosgen, Peter Mumford and Erik Vos.

Stefan Frey

List of Changes:

- Critical bug fixed: Game stops in auction phase after a player can only pass 
(18EU and other games)
- Fixed zooming bug allows usage of background maps (18EU and 18GA only)
- Added background map for 18GA supplied by Peter Mumford (thanks!)

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

Re: [Rails-devel] Water hex tile (was: Half-hexes for 1825)

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

I did create some water tiles before, but indeed different ones: ferries
(numbers -4007 through -4009).  One of these is used in 18Scan.
These tiles have a somewhat darker blue colour (#60A0FF), which I actually
prefer, and intend to use for empty water tiles as well.
Please run 18Scan for a comparison.

I have assigned -4000 to a full water tile, and -4004 and -4005 for half
tiles. I'll commit these tiles and update 1825 later.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Friday, November 11, 2011 11:51 AM
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] Water hex tile (was: Half-hexes for 1825)
> 
> Erik,
> there is no blue tile for 18EU ports defined: They use tile -800 which is
gray.
> 
> However on the svg background map, there are blueish port tiles: I picked
> that color (#00CCFF) and used that to define a blue equivalent to tile 0.
> 
> I will leave the honor to you to assign a tile number ;-)
> 
> If you need blue half-tiles, those are pretty easy to create, as you
simply take
> my previous one and simply edit the SVG-file in a text editor and replace
the
> color value for the fill attribute.
> 
> Stefan
> 
> 
> > Yes, I agree.  We already have a blue tile for the 18EU ports, I would
> > propose to align with that colour.
> >
> > Erik.
> >
> >
> > ----------------------------------------------------------------------
> > -----
> > --- RSA(R) Conference 2012
> > Save $700 by Nov 18
> > Register now
> > http://p.sf.net/sfu/rsa-sfdev2dev1
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Water hex tile (was: Half-hexes for 1825)

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

Erik,
there is no blue tile for 18EU ports defined: They use tile -800 which is 
gray. 

However on the svg background map, there are blueish port tiles: I picked 
that color (#00CCFF) and used that to define a blue equivalent to 
tile 0.

I will leave the honor to you to assign a tile number ;-)

If you need blue half-tiles, those are pretty easy to create, as you simply 
take my previous one and simply edit the SVG-file in a text editor and replace 
the color value for the fill attribute.

Stefan


> Yes, I agree.  We already have a blue tile for the 18EU ports, I would
> propose to align with that colour.
> 
> Erik.
> 
> 
> ---------------------------------------------------------------------------
> --- RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Background maps

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

Reverse zooming direction was wrong due to the 
Dimension variable assignment instead of cloning. So two variables shared the 
same instance of a dimension object. That was a little tricky to find.
Sometimes Eclipse has not finished rebuilding (compiling) the workspace before 
you run Rails, so that the version with the previous code starts.

On Friday, November 11, 2011 10:11:12 am Erik Vos wrote:
> > > Zooming now works fine (except the first time, strange enough, for
> > > both 18EU and 18GA).
> > 
> > I have not experienced the effect: What exactly is the bug (not zooming,
> > background and tile have deviate in zoom) and is it reproducible at any
> 
> start-
> 
> > up or was it really only the first time you have started a game of 18GA
> 
> and
> 
> > 18EU?
> 
> Before your changes it went wrong consistently and (I think) in a
> reproducible way.
> I don't understand why it still went wrong the first time after I pulled
> your changes; it was as if Rails was still running without these changes.
> 
> Anyway, what happened in the past was, that when I reversed the zooming
> direction (from in to out or vice versa), the map did not change scale once
> (or maybe twice).
> Something like:
> 1. Zoom in: all OK.
> 2. Zoom in: still OK.
> 3. Zoom out: tiles zoom out, map unchanged.
> 4 (or 5). Zoom out: both zoom out, but remain out of sync.
> 
> That misbehaviour seems to have been fixed now.
> 
> On your other remarks on SVG: obviously, the current code is a klu(d)ge.  I
> can't really comment on the best way to approach it, as I have no
> experience with real SVG programming, and very little with graphics
> programming in general. I'm leaving that to Adam and you (and Brett, if he
> feels up to it).
> 
> Erik.
> 
> 
> ---------------------------------------------------------------------------
> --- RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel