rails-devel — List for discussion of Rails development

Re: [Rails-devel] [Rails-users] How do i run Rails on Windows

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

Thanks for reporting that bug.
Only option you currently have is reverting the option to not show the 
background map in the configuration dialog.

I wonder if no other user ever tried using a background map before???

Seems that the map file is not correctly located in the jar, thus uses not the 
default Class/Resource-Loader. As we developers run from Eclipse
we have not seen the bug before. I will look into that.
I have changing the Classloader high on my priority-list for Rails 2.x for
several reasons anyway.

Stefan


On Tuesday, November 22, 2011 05:11:28 am Jerry Anderson wrote:
> Ok - i figured out what i was doing wrong. the game starts but I am not
> seeing the background map for 18GA. I am getting an error about the path.
> There is no "data" directory. This is the error 
> java.io.FileNotFoundException:
> C:\Personal\18XX\rails-1.5.3\rails-1.5.3\data\18GA\MapImage.svg (The
> system cannot find the path specified) at
> java.io.FileInputStream.open(Native Method)
>  at java.io.FileInputStream.<init>(Unknown Source)
>  at java.io.FileInputStream.<init>(Unknown Source)
>  at sun.net.www.protocol.file.FileURLConnection.connect(Unknown Source)
>  at sun.net.www.protocol.file.FileURLConnection.getInputStream(Unknown
> Source) at
> org.apache.batik.util.ParsedURLData.openStreamInternal(ParsedURLData.java:
> 547) at
> org.apache.batik.util.ParsedURLData.openStream(ParsedURLData.java:471) at
> org.apache.batik.util.ParsedURL.openStream(ParsedURL.java:417) at
> org.apache.batik.dom.svg.SAXSVGDocumentFactory.createDocument(SAXSVGDocume
> ntFactory.java:158) at
> org.apache.batik.dom.svg.SAXSVGDocumentFactory.createSVGDocument(SAXSVGDoc
> umentFactory.java:124) at
> org.apache.batik.bridge.DocumentLoader.loadDocument(DocumentLoader.java:10
> 6) at
> org.apache.batik.swing.svg.SVGDocumentLoader.run(SVGDocumentLoader.java:84
> )
> 
> 
> 
> ________________________________
>  From: Jerry Anderson <jer...@ya...>
> To: "rai...@li..." <rai...@li...>
> Sent: Monday, November 21, 2011 7:34 PM
> Subject: [Rails-users] How do i run Rails on Windows
> 
> 
> Are there instructions somewhere that explain how to run the game. I see
> the batch file but I have no idea what to supply as a command line
> parameter. %1.
> 
> ---------------------------------------------------------------------------
> --- All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Rails-users mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-users

Re: [Rails-devel] Selling shares (was: Further 1835 testing)

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

I have committed fixes, and also added 5 new test cases that address the
recent issues around nationalisation and selling certificates.

Erik.

> -----Original Message-----
> From: Erik Vos [mailto:eri...@xs...]
> Sent: Monday, November 21, 2011 3:43 PM
> To: 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] Selling shares (was: Further 1835 testing)
> 
> > > From: Stefan Frey [mailto:ste...@we...]
> > > 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.
> >
> > Not sure if this was an accidental or a deliberate oversight, but in
> > any
> case
> > the current share selling process was not prepared at all to allow
> > such a choice.
> > It's now overhauled to allow a selection of exchange certificates in
> > case
> of a
> > dump.  In all dump cases (in all games) the exchange certs are now
> > mentioned as well.  Where a choice is possible, the selling choice
> > list
> has
> > separate options to cover the different exchange certs.
> 
> It turned out that this was not the whole story. The above-mentioned fix
has
> disabled dumping half (or even whole) presidencies in some cases.
> 
> Actually, I found myself seriously entangled in a catch-22 situation with
> respect to the old question: do we sell shares (or better: a share, to be
> understood as a percentage of ownership), or do we sell certificates? It
turns
> out: we need to do bits of both.
> Originally, it was all about share(s).  1835 made it necessary to change
that to
> some extent, but selling 20% certificates remained a bolt-on feature.
> 
> Now Stefan has pointed out some deficiencies with 1835, which forced me to
> turn around and largely base the selling process on selling certificates.
> The wording has (on Stefan's request) also been changed that way.
> But on further testing I found that dumping (selling a presidency) did not
> always work any longer.
> The problem is, that if you can dump a presidency, you can sell a share
(half
> the presidency) that is not represented by a certificate.
> In other words, you sell a certificate that you don't own - that doesn't
even
> exist.
> 
> I think I have now fixed that as well, but the whole selling process has
> become pretty kludgey this way.
> Dumping a presidency is now represented in the sell option list as selling
one
> or two (additional) *single* (i.e. 10% or 5%) certificates.
> And I'm still not convinced that all possible cases are covered, so I'll
remain
> testing for a while.
> 
> I intend to add a number of relevant cases to the test set.  But the test
set
> cannot cover cases where invalid options are wrongly proposed, or chosen,
> or accepted.

Re: [Rails-devel] Selling shares (was: Further 1835 testing)

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

Actually, I think we can have it both ways. 
We'll have to change the SellShares action completely.  We can as well
create a new SellCertificates action, which works the new way, keeping the
old one for compatibility.
Only SellCertificates will be newly created in Rails, but both are still
accepted (in separate processing methods).
All existing saved files and test cases will only use the old one, though.
So we'll have to build an entire new collection of test cases - but we'll
have to do that anyhow.

Erik

> > The basic idea is that we no longer present a list of sell options to
> > the user, but just a list of certificates that he owns.
> > The UI inserts a checkbox next to each certificate, enabling the user
> > to select the certificates to be sold.
> > The president certificate should then have two (or more) checkboxes to
> > enable whole or partial selling, and to indicate what certificates
> > should be returned if the victim owns both 10% and 20% certificates in
> 1835.
> > (Possibly I'm not the first to suggest such an approach; if so, let
> > credit be where it is due).
> >
> 
> +1 to this.
> 
> 
> > Such a process would radically change the existing information
> > exchange between the UI and the game engine (which will be based upon
> > certificate IDs), and (as said above), old save files become
incompatible.
> >
> > So we'll perhaps have to keep this idea for Rails 2.x.
> >
> 
> It sounds like it's time to focus our efforts on 2.x.
> 
> My recommendation:
> 
> Let's create a new public branch for doing 1.x maintenance work. Any
> bugfixes for the next few 1.x releases can go here and, if applicable, be
> merged or cherry-picked to master.
> 
> This will allow us to use master for 2.x (and beyond).
> 
> > Erik.
> 
> ---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] Selling shares (was: Further 1835 testing)

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

On Mon, Nov 21, 2011 at 9:43 AM, Erik Vos <eri...@xs...> wrote:
>> > From: Stefan Frey [mailto:ste...@we...]
> The basic idea is that we no longer present a list of sell options to the
> user, but just a list of certificates that he owns.
> The UI inserts a checkbox next to each certificate, enabling the user to
> select the certificates to be sold.
> The president certificate should then have two (or more) checkboxes to
> enable whole or partial selling, and to indicate what certificates should be
> returned if the victim owns both 10% and 20% certificates in 1835.
> (Possibly I'm not the first to suggest such an approach; if so, let credit
> be where it is due).
>

+1 to this.


> Such a process would radically change the existing information exchange
> between the UI and the game engine (which will be based upon certificate
> IDs), and (as said above), old save files become incompatible.
>
> So we'll perhaps have to keep this idea for Rails 2.x.
>

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

My recommendation:

Let's create a new public branch for doing 1.x maintenance work. Any
bugfixes for the next few 1.x releases can go here and, if applicable,
be merged or cherry-picked to master.

This will allow us to use master for 2.x (and beyond).

> Erik.

---Brett.

Re: [Rails-devel] Selling shares (was: Further 1835 testing)

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

> > From: Stefan Frey [mailto:ste...@we...]
> > 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.
> 
> Not sure if this was an accidental or a deliberate oversight, but in any
case
> the current share selling process was not prepared at all to allow such a
> choice.
> It's now overhauled to allow a selection of exchange certificates in case
of a
> dump.  In all dump cases (in all games) the exchange certs are now
> mentioned as well.  Where a choice is possible, the selling choice list
has
> separate options to cover the different exchange certs.

It turned out that this was not the whole story. The above-mentioned fix has
disabled dumping half (or even whole) presidencies in some cases.

Actually, I found myself seriously entangled in a catch-22 situation with
respect to the old question: do we sell shares (or better: a share, to be
understood as a percentage of ownership), or do we sell certificates? It
turns out: we need to do bits of both.
Originally, it was all about share(s).  1835 made it necessary to change
that to some extent, but selling 20% certificates remained a bolt-on
feature.

Now Stefan has pointed out some deficiencies with 1835, which forced me to
turn around and largely base the selling process on selling certificates.
The wording has (on Stefan's request) also been changed that way.
But on further testing I found that dumping (selling a presidency) did not
always work any longer.
The problem is, that if you can dump a presidency, you can sell a share
(half the presidency) that is not represented by a certificate.
In other words, you sell a certificate that you don't own - that doesn't
even exist.

I think I have now fixed that as well, but the whole selling process has
become pretty kludgey this way. 
Dumping a presidency is now represented in the sell option list as selling
one or two (additional) *single* (i.e. 10% or 5%) certificates.
And I'm still not convinced that all possible cases are covered, so I'll
remain testing for a while.

I intend to add a number of relevant cases to the test set.  But the test
set cannot cover cases where invalid options are wrongly proposed, or
chosen, or accepted.

---

I think there is a way to improve the situation radically (but that will,
without much extra effort, invalidate all existing saved files, including
all test cases).
The basic idea is that we no longer present a list of sell options to the
user, but just a list of certificates that he owns. 
The UI inserts a checkbox next to each certificate, enabling the user to
select the certificates to be sold.
The president certificate should then have two (or more) checkboxes to
enable whole or partial selling, and to indicate what certificates should be
returned if the victim owns both 10% and 20% certificates in 1835.
(Possibly I'm not the first to suggest such an approach; if so, let credit
be where it is due). 

So the selection process will be completely handed over to the user, which I
think is more user-friendly, and which also simplifies the pre-selection
process by the game engine (although 1835 will still require much extra
preparation). Perhaps the greatest benefit is, that mixing 10% and 20%
certificates is no longer an issue.
The UI will have to do some pre-validation according to simple rules:
(1) the predefined maximum share that can be sold in total may not be
exceeded,
(2) the presidency can only be (partly) sold if all other certificates are
sold as well.

Such a process would radically change the existing information exchange
between the UI and the game engine (which will be based upon certificate
IDs), and (as said above), old save files become incompatible.

So we'll perhaps have to keep this idea for Rails 2.x.

Erik.

Re: [Rails-devel] Further 1835 testing

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

> From: Stefan Frey [mailto:ste...@we...]
> 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.

Not sure if this was an accidental or a deliberate oversight, but in any
case the current share selling process was not prepared at all to allow such
a choice.
It's now overhauled to allow a selection of exchange certificates in case of
a dump.  In all dump cases (in all games) the exchange certs are now
mentioned as well.  Where a choice is possible, the selling choice list has
separate options to cover the different exchange certs. 

> From: John David Galt [mailto:jd...@di...]
> This save file is a later one from the same game, and shows an amusing
> stock-market bug.
> 
> At the point of the save, John has three 20% certificates of OL.
> If I click to sell some of them, the program offers to let me sell either
one or
> two 10% certificates, or one or two 20% certs, but not three 20% certs.
(So
> apparently the game engine "thinks" I have two 20% and two 10% certs, but
> that is not possible -- with 30% still in the IPO, only one 10% cert has
ever
> been purchased.)

Obviously, three 20% certificates can never be sold to the Pool.
I don't know what caused the offer to sell one or two 10% certificates.
Anyhow, this is no longer the case, probably because of the above fix.

If another player had two 10% OL shares, one could argue that it would be
allowed to sell 50%, because a president share exchange would be possible.
This does not actually happen now.
If Kent buys another 10% OL cert, John in his next turn still does not get
another sell option after first selling 40%.  Not sure if that is correct...

> It gets even more interesting if I take the program up on its offer to let
me
> sell one 10% cert.  When I do this, I am credited with 86M and the share
price
> falls as if the sale had taken place -- but all holdings stay the
> same: I still own 60%.
> 
> It gets still weirder if I "Forced Undo" the sale: Undo does nothing, but
I can
> "sell" another 10%, again gaining the market price of one share and
dropping
> the price further while giving up nothing.  (The "Game Report"
> window does not reflect the Undo so maybe that is a no-op here.)

This all is no longer possible.

> (A possibly related annoyance I found earlier: If Marcus wants to sell
some of
> his 15% holding of PR, the interface allows him to sell either his 5%
certificate
> or his 10% cert, but not both at the same time.  I can sell one at a time,
but
> this causes the price to fall twice, which is not possible under the rules
of
> 1835.)

It works fine for me - two subsequent sell actions at the same price. 

Erik.

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

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

Thanks for your test reports.
Again (you reported that issue before already) I cannot reconstruct that issue 
neither with the trunk version nor with 1.5.3 or 1.5.2 here.

So there are two things you could to help resolving that issue.
A) Save the game file and the log-file (18xx.log in the working directory of 
the running rails) and send it to me directly.
and/or 
B) Check if you can get the hex highlighted by moving the mouse around the map 
or zooming-in or zooming-out.

In a few cases I observed that none of the hexes that are be able to built is 
highlighted first, even if I have checked by the log that the route algorithm 
worked correctly. After moving around the cursor and/or zooming the hexes were 
highlighted. This seems to be a graphical glitch. 

I also wonder if anyone else experienced that before and if there is a 
systematic cause for it.

The algorithm for tile laying is not complete yet, however it already knows 
that in 1835 you are able to visit HH twice and that rules are different in 
other games.

Stefan


On Sunday, November 20, 2011 01:51:08 am John David Galt wrote:
> I discovered this today from a game of 1835 in Rails 1.5.3.
> 
> Given track connecting M2 - Schwerin delta - NE Hamburg - Kiel - M6,
>    M2 will be shown a possible build on the "dit" hex NE of Schwerin.
>    M6 will not.
> 
> I suspect this is because the tile-suggesting logic assumes that a route
> which visits the same hex twice (as the route from M6 to Schwerin visits
> Hamburg again) is not considered a legal route for laying tiles.
> 
> I believe that is correct only in 18EU, so maybe it was written for that
> game.
> 
> At any rate it is one of many track-building rules which needs to be able
> to be switched on or off for different games.
> 
> ---------------------------------------------------------------------------
> --- 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...>]

I'm working on share selling right now because of bugs reported by Stefan,
and I'll will also pick up these problems.

One remark for now: selling any mixtures of 5% and 10% shares in one action
has been deliberately omitted for the sake of simplicity. Two separate
actions are required.
The default behaviour of Rails is (was? In any case: should be) that in 1835
the price will NOT fall again in such a case (and that the selling price
remains the same). 
I will check what actually happens.

Erik.

> -----Original Message-----
> From: John David Galt [mailto:jd...@di...]
> Sent: Sunday, November 20, 2011 5:23 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Further 1835 testing
> 
> This save file is a later one from the same game, and shows an amusing
> stock-market bug.
> 
> At the point of the save, John has three 20% certificates of OL.
> If I click to sell some of them, the program offers to let me sell either
one or
> two 10% certificates, or one or two 20% certs, but not three 20% certs.
(So
> apparently the game engine "thinks" I have two 20% and two 10% certs, but
> that is not possible -- with 30% still in the IPO, only one 10% cert has
ever
> been purchased.)
> 
> It gets even more interesting if I take the program up on its offer to let
me
> sell one 10% cert.  When I do this, I am credited with 86M and the share
price
> falls as if the sale had taken place -- but all holdings stay the
> same: I still own 60%.
> 
> It gets still weirder if I "Forced Undo" the sale: Undo does nothing, but
I can
> "sell" another 10%, again gaining the market price of one share and
dropping
> the price further while giving up nothing.  (The "Game Report"
> window does not reflect the Undo so maybe that is a no-op here.)
> 
> (A possibly related annoyance I found earlier: If Marcus wants to sell
some of
> his 15% holding of PR, the interface allows him to sell either his 5%
certificate
> or his 10% cert, but not both at the same time.  I can sell one at a time,
but
> this causes the price to fall twice, which is not possible under the rules
of
> 1835.)

Re: [Rails-devel] Further 1835 testing

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

This save file is a later one from the same game, and shows an amusing
stock-market bug.

At the point of the save, John has three 20% certificates of OL.
If I click to sell some of them, the program offers to let me sell either
one or two 10% certificates, or one or two 20% certs, but not three 20%
certs.  (So apparently the game engine "thinks" I have two 20% and two 10%
certs, but that is not possible -- with 30% still in the IPO, only one 10%
cert has ever been purchased.)

It gets even more interesting if I take the program up on its offer to let
me sell one 10% cert.  When I do this, I am credited with 86M and the share
price falls as if the sale had taken place -- but all holdings stay the
same: I still own 60%.

It gets still weirder if I "Forced Undo" the sale: Undo does nothing, but I
can "sell" another 10%, again gaining the market price of one share and
dropping the price further while giving up nothing.  (The "Game Report"
window does not reflect the Undo so maybe that is a no-op here.)

(A possibly related annoyance I found earlier: If Marcus wants to sell some
of his 15% holding of PR, the interface allows him to sell either his 5%
certificate or his 10% cert, but not both at the same time.  I can sell one
at a time, but this causes the price to fall twice, which is not possible
under the rules of 1835.)

Re: [Rails-devel] Further 1835 testing

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

On 2011-11-19 19:17, John David Galt wrote:
> I found one more real bug in 1835 on Rails 1.5.3:
> 
> After the 5-train purchase forces all minors to merge into PR, PR is allowed
> to keep four trains.  (The rules say PR is allowed only three after the
> 5-train purchase, while all other companies are allowed two.)

Follow-up: When the 6-train is purchased, then the program makes PR discard
down to the correct limit of three trains, so it just happens late.

Re: [Rails-devel] Further 1835 testing

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

I found one more real bug in 1835 on Rails 1.5.3:

After the 5-train purchase forces all minors to merge into PR, PR is allowed
to keep four trains.  (The rules say PR is allowed only three after the
5-train purchase, while all other companies are allowed two.)

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

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

On 2011-11-19 16:51, John David Galt wrote:
> I discovered this today from a game of 1835 in Rails 1.5.3.
> 
> Given track connecting M2 - Schwerin delta - NE Hamburg - Kiel - M6,
>    M2 will be shown a possible build on the "dit" hex NE of Schwerin.
>    M6 will not.
> 
> I suspect this is because the tile-suggesting logic assumes that a route which
> visits the same hex twice (as the route from M6 to Schwerin visits Hamburg
> again) is not considered a legal route for laying tiles.

Follow-up: This turns out not to be the real reason.  After laying tile 202 in
B12, the program still does not offer to let M6 build east of there.

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

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

A second minor track-laying annoyance:

At the point of this save file, Marcus (running SX) uses the Pfalz to lay
a tile in Ludwigshafen/Mannheim.

Result: Marcus is asked where BA's home station should be placed.

There are two things wrong with that.  Kent is president of BA, so he, not
Marcus, should be asked.  And he should not be asked until BA's own turn
(so Marcus should not be allowed to place a SX token there on this turn,
even with Kent's approval).

[Rails-devel] More about track-laying annoyances

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

I discovered this today from a game of 1835 in Rails 1.5.3.

Given track connecting M2 - Schwerin delta - NE Hamburg - Kiel - M6,
   M2 will be shown a possible build on the "dit" hex NE of Schwerin.
   M6 will not.

I suspect this is because the tile-suggesting logic assumes that a route which
visits the same hex twice (as the route from M6 to Schwerin visits Hamburg
again) is not considered a legal route for laying tiles.

I believe that is correct only in 18EU, so maybe it was written for that game.

At any rate it is one of many track-building rules which needs to be able to be
switched on or off for different games.

Re: [Rails-devel] Further 1835 testing

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

> Bugs:
> A) Player T2 nationalizes BA from T3: There is no option to nationalize
the
> 20% certificate first.

Fixed.  The nationalization code has been largely rewritten.
Also fixed the empty tooltips.

Erik.

Re: [Rails-devel] Rails 1.x

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

Stefan,

I clearly have expressed myself a bit too strongly.  Surely I will stop
maintaining Rails 1.x when it's clear that it would no longer serve any
purpose (although keeping myself busy is a potential purpose).

I just can't tell now to what extent I expect to be able to work with Rails
2.0 in the future.  Possible inhibitors include:
- old age (I'm 65 now),
- inability to grasp Rails 2.0 (unlikely at this time),
- don't like Rails 2.0 (unlikely but not unthinkable),
- my other hobbies and/or my grandchildren manage to move Rails to the
bottom of my priority list (no clue on this one).

Because of family matters, I currently don't have the time to do much else
on Rails than bug fixing and minor improvements.  I'm not following your
work (yet). 
I hope that all will change sometime in 2012.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Saturday, November 19, 2011 10:09 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Rails 1.x
> 
> On Saturday, November 19, 2011 09:09:42 am Erik Vos wrote:
> > It's my intention to keep maintaining and possibly even extending
> > Rails 1.x, until it has become absolutely clear to everyone that Rails
> > 2.0 is a worthy successor and Rails 1.x has become a dead end.  I'm
> > undecided about what I'm going to do after that point.
> 
> Erik,
> My fear is that by binding yourself to the definition "absolutely clear to
> everyone" you will never be able to stop maintaining Rails 1.x.
> You are handing out veto rights freely...  ;-) Maybe should stop
maintaining if
> you are yourself convinced of your condition, which will still very
difficult to
> achieve.
> I have and had no intention to maneuver you into a dead-end and it would
> be a pity is this happens. So if there is anything i can do (better) to
avoid that,
> please let me know.
> Stefan
> 
> >
> > Erik.
> >
> > > -----Original Message-----
> > > From: Stefan Frey [mailto:ste...@we...]
> > > Sent: Saturday, November 19, 2011 7:02 AM
> > > To: Development list for Rails: an 18xx game
> > > Subject: Re: [Rails-devel] Shares and certificates (was: Further
> > > 1835
> >
> > testing)
> >
> > > Erik:
> > > A general remark first regarding the Rails 2.0 development:
> > >
> > > It is already quite often not possible to automatic (=merge without
> > > manual intervention) rebase the 2.0 branch onto the Rails 1.x master
> > > as the
> >
> > changes
> >
> > > to the base elements (states, moves, portfolios) are too
> > > substantial. So I
> >
> > can
> >
> > > only merge commits one-by-one, which takes some effort.
> > >
> > > Most likely I will not be able (auto-)merge any of your changes
> > > regarding shares into the 2.0 branch. And due to the nature of
> > > changes it will be
> >
> > easier
> >
> > > to implement the changes directly instead of the trying to merge the
> > > 1.x commits.
> > >
> > > So from my point of view I recommend to keep your changes minimal in
> > > able to fix 1835. However your decision will mainly depend on how
> > > long you expect to keep developing in Rails 1.x.
> > >
> > > Unfortunately I am currently not able to give a clear commitment
> > > when
> >
> > Rails
> >
> > > 2.0 will run without errors.
> > > Of the design/refactoring changes for the initial 2.0 I think 90%
> > > are in
> >
> > place,
> >
> > > however from the testing/bug-hunting I guess only 10% are done, but
> > > the latter figure is difficult to predict.
> > >
> > > I will provide more feedback on your proposal later this weekend.
> > >
> > > Stefan
> >
> > ----------------------------------------------------------------------
> > -----
> > --- 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] Rails 1.x

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

On Saturday, November 19, 2011 09:09:42 am Erik Vos wrote:
> It's my intention to keep maintaining and possibly even extending Rails
> 1.x, until it has become absolutely clear to everyone that Rails 2.0 is a
> worthy successor and Rails 1.x has become a dead end.  I'm undecided about
> what I'm going to do after that point.

Erik,
My fear is that by binding yourself to the definition "absolutely clear to 
everyone" you will never be able to stop maintaining Rails 1.x.
You are handing out veto rights freely...  ;-)
Maybe should stop maintaining if you are yourself convinced of your condition, 
which will still very difficult to achieve.
I have and had no intention to maneuver you into a dead-end and it would be a 
pity is this happens. So if there is anything i can do (better) to avoid that, 
please let me know.
Stefan

> 
> Erik.
> 
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Saturday, November 19, 2011 7:02 AM
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] Shares and certificates (was: Further 1835
> 
> testing)
> 
> > Erik:
> > A general remark first regarding the Rails 2.0 development:
> > 
> > It is already quite often not possible to automatic (=merge without
> > manual intervention) rebase the 2.0 branch onto the Rails 1.x master as
> > the
> 
> changes
> 
> > to the base elements (states, moves, portfolios) are too substantial. So
> > I
> 
> can
> 
> > only merge commits one-by-one, which takes some effort.
> > 
> > Most likely I will not be able (auto-)merge any of your changes regarding
> > shares into the 2.0 branch. And due to the nature of changes it will be
> 
> easier
> 
> > to implement the changes directly instead of the trying to merge the 1.x
> > commits.
> > 
> > So from my point of view I recommend to keep your changes minimal in able
> > to fix 1835. However your decision will mainly depend on how long you
> > expect to keep developing in Rails 1.x.
> > 
> > Unfortunately I am currently not able to give a clear commitment when
> 
> Rails
> 
> > 2.0 will run without errors.
> > Of the design/refactoring changes for the initial 2.0 I think 90% are in
> 
> place,
> 
> > however from the testing/bug-hunting I guess only 10% are done, but the
> > latter figure is difficult to predict.
> > 
> > I will provide more feedback on your proposal later this weekend.
> > 
> > Stefan
> 
> ---------------------------------------------------------------------------
> --- 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] Rails 1.x

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

It's my intention to keep maintaining and possibly even extending Rails 1.x,
until it has become absolutely clear to everyone that Rails 2.0 is a worthy
successor and Rails 1.x has become a dead end.  I'm undecided about what I'm
going to do after that point.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Saturday, November 19, 2011 7:02 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Shares and certificates (was: Further 1835
testing)
> 
> Erik:
> A general remark first regarding the Rails 2.0 development:
> 
> It is already quite often not possible to automatic (=merge without manual
> intervention) rebase the 2.0 branch onto the Rails 1.x master as the
changes
> to the base elements (states, moves, portfolios) are too substantial. So I
can
> only merge commits one-by-one, which takes some effort.
> 
> Most likely I will not be able (auto-)merge any of your changes regarding
> shares into the 2.0 branch. And due to the nature of changes it will be
easier
> to implement the changes directly instead of the trying to merge the 1.x
> commits.
> 
> So from my point of view I recommend to keep your changes minimal in able
> to fix 1835. However your decision will mainly depend on how long you
> expect to keep developing in Rails 1.x.
> 
> Unfortunately I am currently not able to give a clear commitment when
Rails
> 2.0 will run without errors.
> Of the design/refactoring changes for the initial 2.0 I think 90% are in
place,
> however from the testing/bug-hunting I guess only 10% are done, but the
> latter figure is difficult to predict.
> 
> I will provide more feedback on your proposal later this weekend.
> 
> Stefan

Re: [Rails-devel] Shares and certificates (was: Further 1835 testing)

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

Erik:
A general remark first regarding the Rails 2.0 development:

It is already quite often not possible to automatic (=merge without manual 
intervention) rebase the 2.0 branch onto the Rails 1.x master as the changes 
to the base elements (states, moves, portfolios) are too substantial. So I can 
only merge commits one-by-one, which takes some effort.

Most likely I will not be able (auto-)merge any of your changes regarding 
shares into the 2.0 branch. And due to the nature of changes it will be easier 
to implement the changes directly instead of the trying to merge the 1.x 
commits.

So from my point of view I recommend to keep your changes minimal in able to 
fix 1835. However your decision will mainly depend on how long you expect to 
keep developing in Rails 1.x. 

Unfortunately I am currently not able to give a clear commitment when Rails 
2.0 will run without errors.
Of the design/refactoring changes for the initial 2.0 I think 90% are in 
place, however from the testing/bug-hunting I guess only 10% are done, but the 
latter figure is difficult to predict.

I will provide more feedback on your proposal later this weekend.

Stefan

On Friday, November 18, 2011 08:08:49 pm Erik Vos wrote:
> The below observation by Martin is also pertinent to our discussion:
> > From: Dr....@t-... [mailto:Dr....@t-...]
> > 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.
> 
> In 1880 there is no dispute what a share is: 10%.
> 
> However, for me the interesting aspect of this observation is, that in 1880
> we do not know beforehand how many certificates we have, and what number
> of shares at least one certificate represents.   The 1856 situation is
> very similar, but in this case the undefinedness applies to all CGR
> certificates.
> 
> In 1856 this is solved by initializing the CGR with 19 certs: 1 of 10% and
> 18 of 5%.  Should the CGR need only 10 shares, then Rails throws away ten
> 5% certificates, and doubles the share unit value of the company, which
> automatically converts the remaining nine certificates from 10% to 20% and
> from 5% to 10%, without need to affect the number of share units each cert
> represents.
> 
> In 1880 I would solve this by initializing with one 20% and eight 10%
> certificates.  Should the company start with a 30% or 40% president
> certificate, then the number of share units of that cert will be raised
> from 2 to 3 or 4, and one or two 10% certs will be discarded.
> 
> > From: Stefan Frey [mailto:ste...@we...]
> > * I disagree the concept of "share" should be objects in Rails. I prefer
> > the nominal (percentage) being an attribute of the certificates.
> 
> I'm with Stefan in this matter.
> 
> > 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.
> 
> What we currently have is:
> 
> CC) Companies have two attributes relevant to this discussion:
> - The "share unit", which is the size of its smallest share (which can vary
> from 5% to 100%), - the "share price unit", which is the number of share
> units that the share price applies to.  Always 1, except for the PR.
> 
> DD) Each cert has an attribute named "shares" that represents the number of
> share units represented by that certificate. In the light of the previous
> discussion it has become clear, that we should rename this attribute to
> "number of share units". (Of course there is also a "president" boolean).
> 
> A main difference with Stefan's proposal is the current existence of an
> additional "share unit" company attribute, which is the base percentage in
> which all share amounts are expressed.  I think I introduced this
> attribute with 1856 to facilitate the share conversion that may occur
> during the CGR formation (see above).  My strong preference is to retain
> this structure.
> 
> Do we really need certificate types as in B)?  I don't see a big need for
> such an additional type (whereby I realize that as yet we are not prepared
> for the "lunatic designer" syndrome that Stefan envisions).  But I'm not
> firmly against either. In any case, if we introduce such a concept, we
> must have a strategy for handling the 1880 and 1856 cases.  In these games
> we must be prepared to either: - define all possible cert types
> beforehand, and change the cert type of some or all certificates of a
> company, as needed, or - change the parameters of some cert types, as
> needed.
> In particular for 1880 the question then arises if cert types will be
> defined per company, or just once for all companies.
> 
> Also keep in mind that in Rails every persistent attribute that can change
> value must be a state variable.  Currently, shareUnit is an IntegerState,
> on behalf of 1856.  In hindsight, I could have chosen to leave it an
> integer, but to replace that in PublicCompany_CGR by an IntegerState,
> forcing all access to either to use a method.  I would suggest to use the
> latter approach in 1880, by overriding the integer "shares" (or rather
> "numberOfShareUnits") by an IntegerState in a specific class
> PublicCertificate_1880.
> 
> 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] Shares and certificates (was: Further 1835 testing)

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

On Fri, Nov 18, 2011 at 5:26 PM, Erik Vos <eri...@xs...> wrote:

> Yes, and that is exactly what we do behind the scenes. ****
>
> I have just added a moveover message (tooltip) that shows the split of the
> grand total share percentage that has so far been the only display per
> player per company.
>

Sorry, I read the message I replied to as suggesting a change that would
have broken that.

-- 
John A. Tamplin

Re: [Rails-devel] Shares and certificates (was: Further 1835 testing)

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

Yes, and that is exactly what we do behind the scenes. 

I have just added a moveover message (tooltip) that shows the split of the grand total share percentage that has so far been the only display per player per company.


Erik.

 

From: John A. Tamplin [mailto:ja...@ja...] 
Sent: Friday, November 18, 2011 9:05 PM
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Shares and certificates (was: Further 1835 testing)

 

Note that several games have particular certificates that have different sizes, such as 18TN having a 30% presidency for IC, several of Gary Mroczka's games have doubled non-director shares for the last share (I believe 1835 also does this).  So, you need to be able to order the certs available from the IPO specifically.  1844 also has 4 share companies, and many have 5-share companies that become 10-share companies.  18Dixie has preferred certificates which do not count against the 60% limit.

 

So, I think you do want to model particular certificates owned by a player, rather than just keeping track of share count / percentage.

 

-- 
John A. Tamplin

Re: [Rails-devel] Shares and certificates (was: Further 1835 testing)

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

Note that several games have particular certificates that have different
sizes, such as 18TN having a 30% presidency for IC, several of Gary
Mroczka's games have doubled non-director shares for the last share (I
believe 1835 also does this).  So, you need to be able to order the certs
available from the IPO specifically.  1844 also has 4 share companies, and
many have 5-share companies that become 10-share companies.  18Dixie has
preferred certificates which do not count against the 60% limit.

So, I think you do want to model particular certificates owned by a player,
rather than just keeping track of share count / percentage.

-- 
John A. Tamplin

Re: [Rails-devel] Shares and certificates (was: Further 1835 testing)

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

Oh, and don't forget that pretty soon we will be faced with companies that
convert from 5-share to 10-share companies (and even worse), as occurs in
several David Hecht games (e.g. 1826 and 18FL).  Again I think this is most
easily addressed by changing the share unit, and in addition changing the
owner of the additional five (as yet unavailable) certificates.  That's all
existing stuff.

> -----Original Message-----
> From: Erik Vos [mailto:eri...@xs...]
> Sent: Friday, November 18, 2011 8:09 PM
> To: 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] Shares and certificates (was: Further 1835
testing)
> 
> The below observation by Martin is also pertinent to our discussion:
> 
> > From: Dr....@t-... [mailto:Dr.Martin.Brumm@t-
> online.de]
> > 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.
> 
> In 1880 there is no dispute what a share is: 10%.
> 
> However, for me the interesting aspect of this observation is, that in
1880 we
> do not know beforehand how many certificates we have, and what number
> of shares at least one certificate represents.   The 1856 situation is
very
> similar, but in this case the undefinedness applies to all CGR
certificates.
> 
> In 1856 this is solved by initializing the CGR with 19 certs: 1 of 10% and
18 of
> 5%.  Should the CGR need only 10 shares, then Rails throws away ten 5%
> certificates, and doubles the share unit value of the company, which
> automatically converts the remaining nine certificates from 10% to 20% and
> from 5% to 10%, without need to affect the number of share units each cert
> represents.
> 
> In 1880 I would solve this by initializing with one 20% and eight 10%
> certificates.  Should the company start with a 30% or 40% president
> certificate, then the number of share units of that cert will be raised
from 2
> to 3 or 4, and one or two 10% certs will be discarded.
> 
> > From: Stefan Frey [mailto:ste...@we...]
> > * I disagree the concept of "share" should be objects in Rails. I
> > prefer the nominal (percentage) being an attribute of the certificates.
> 
> I'm with Stefan in this matter.
> 
> > 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.
> 
> What we currently have is:
> 
> CC) Companies have two attributes relevant to this discussion:
> - The "share unit", which is the size of its smallest share (which can
vary from
> 5% to 100%),
> - the "share price unit", which is the number of share units that the
share
> price applies to.  Always 1, except for the PR.
> 
> DD) Each cert has an attribute named "shares" that represents the number
> of share units represented by that certificate. In the light of the
previous
> discussion it has become clear, that we should rename this attribute to
> "number of share units". (Of course there is also a "president" boolean).
> 
> A main difference with Stefan's proposal is the current existence of an
> additional "share unit" company attribute, which is the base percentage in
> which all share amounts are expressed.  I think I introduced this
attribute
> with 1856 to facilitate the share conversion that may occur during the CGR
> formation (see above).  My strong preference is to retain this structure.
> 
> Do we really need certificate types as in B)?  I don't see a big need for
such an
> additional type (whereby I realize that as yet we are not prepared for the
> "lunatic designer" syndrome that Stefan envisions).  But I'm not firmly
against
> either. In any case, if we introduce such a concept, we must have a
strategy
> for handling the 1880 and 1856 cases.  In these games we must be prepared
> to either:
> - define all possible cert types beforehand, and change the cert type of
some
> or all certificates of a company, as needed, or
> - change the parameters of some cert types, as needed.
> In particular for 1880 the question then arises if cert types will be
defined per
> company, or just once for all companies.
> 
> Also keep in mind that in Rails every persistent attribute that can change
> value must be a state variable.  Currently, shareUnit is an IntegerState,
on
> behalf of 1856.  In hindsight, I could have chosen to leave it an integer,
but to
> replace that in PublicCompany_CGR by an IntegerState, forcing all access
to
> either to use a method.  I would suggest to use the latter approach in
1880,
> by overriding the integer "shares" (or rather "numberOfShareUnits") by an
> IntegerState in a specific class PublicCertificate_1880.
> 
> 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] Shares and certificates (was: Further 1835 testing)

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

The below observation by Martin is also pertinent to our discussion:

> From: Dr....@t-... [mailto:Dr....@t-...] 
> 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.

In 1880 there is no dispute what a share is: 10%.

However, for me the interesting aspect of this observation is, that in 1880 we do not know beforehand how many certificates we have, and what number of shares at least one certificate represents.   The 1856 situation is very similar, but in this case the undefinedness applies to all CGR certificates.

In 1856 this is solved by initializing the CGR with 19 certs: 1 of 10% and 18 of 5%.  Should the CGR need only 10 shares, then Rails throws away ten 5% certificates, and doubles the share unit value of the company, which automatically converts the remaining nine certificates from 10% to 20% and from 5% to 10%, without need to affect the number of share units each cert represents.

In 1880 I would solve this by initializing with one 20% and eight 10% certificates.  Should the company start with a 30% or 40% president certificate, then the number of share units of that cert will be raised from 2 to 3 or 4, and one or two 10% certs will be discarded.

> From: Stefan Frey [mailto:ste...@we...]
> * I disagree the concept of "share" should be objects in Rails. I prefer the
> nominal (percentage) being an attribute of the certificates.

I'm with Stefan in this matter.

> 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.

What we currently have is:

CC) Companies have two attributes relevant to this discussion:
- The "share unit", which is the size of its smallest share (which can vary from 5% to 100%),
- the "share price unit", which is the number of share units that the share price applies to.  Always 1, except for the PR.

DD) Each cert has an attribute named "shares" that represents the number of share units represented by that certificate. In the light of the previous discussion it has become clear, that we should rename this attribute to "number of share units". (Of course there is also a "president" boolean).

A main difference with Stefan's proposal is the current existence of an additional "share unit" company attribute, which is the base percentage in which all share amounts are expressed.  I think I introduced this attribute with 1856 to facilitate the share conversion that may occur during the CGR formation (see above).  My strong preference is to retain this structure.

Do we really need certificate types as in B)?  I don't see a big need for such an additional type (whereby I realize that as yet we are not prepared for the "lunatic designer" syndrome that Stefan envisions).  But I'm not firmly against either. In any case, if we introduce such a concept, we must have a strategy for handling the 1880 and 1856 cases.  In these games we must be prepared to either:
- define all possible cert types beforehand, and change the cert type of some or all certificates of a company, as needed, or
- change the parameters of some cert types, as needed. 
In particular for 1880 the question then arises if cert types will be defined per company, or just once for all companies.

Also keep in mind that in Rails every persistent attribute that can change value must be a state variable.  Currently, shareUnit is an IntegerState, on behalf of 1856.  In hindsight, I could have chosen to leave it an integer, but to replace that in PublicCompany_CGR by an IntegerState, forcing all access to either to use a method.  I would suggest to use the latter approach in 1880, by overriding the integer "shares" (or rather "numberOfShareUnits") by an IntegerState in a specific class PublicCertificate_1880.  

Erik.

 

Re: [Rails-devel] Further 1835 testing

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

Brett,
... first some nit-picking: Your proposal would still need corresponding type 
classes at least for certificates, most likely for shares too, so you got at 
least 3 or 4 classes ;-)
But anyway minimizing the number of classes was not the design goal of the 
proposal, however its great if you can live with it.

In any case my proposal is still very close to what the current implementation 
is, it only removes the restriction that shares have to be a (integer) 
multiple of something like a "base percentage". I thinks this was the 
(historical) reason for Erik to decide that PR has a base unit of 5% as 1/2 
unfortunately is not an Integer... 
So let us wait for Erik's opinion.

Stefan



On Friday, November 18, 2011 05:11:44 pm brett lentz wrote:
> 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
> 
> ---------------------------------------------------------------------------
> --- 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