rails-devel — List for discussion of Rails development

[Rails-devel] 1844 implementation and some general thoughts on Rails coding

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

Martin:

now that I have hopefully all changes for 2.0 done, I will focus on 
1844/1854.

One thing I would like to avoid this time is the code duplication in 
sub-classes of major Rails classes (like OperatingRound, StockRound, 
PublicCompany etc.). This is a nightmare to support and debug.

What really makes this difficult is to find the differences to the 
standard implementation and checking if the difference is by chance 
(e.g. bug fixes not implemented there) or required due to a rule change.

Take for example StockRound:

In addition to the general class, there are 7 game specific sub-classes, 
4 more general sub-classes that itself contain another 5 game specific 
sub-classes.

If all of them copy the general code of share selling to change a minor 
detail how shares are sold, there are close to 20 implementations of 
share selling, which have to be maintained.

The general guidelines should be:

* Game specific code should only contain code that is relevant to 
implement a delta specific to that game. It should not copy general code.

* If this is not possible, comments on what was copied and what is the 
intended change is a MUST.

So Martin (and everyone else writing code for Rails) please think hard 
or ask for help BEFORE copying code from methods in general classes.

I know the problem is that many methods, especially in the Round 
classes, have been written in a fashion that reusing them is difficult 
and code copying easy.

However the better solution is: Refactor the general method FIRST to 
allow re-use and than call the re-factored method from the game specific 
class.

To increase co-operation for 1844 and 1854 development, I have added 
wiki pages for those games, that allow to share a list of things to do 
and what is already implemented.

http://github.com/freystef/Rails/wiki/1844
http://github.com/freystef/Rails/wiki/1854

Sorry for sounding harsh, that is not my intention. My intention is to 
make all our life in the future easier.

Stefan

Re: [Rails-devel] 1835 presidency swap: Bug fix required (typos corrected)

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

Volker,
I agree that in the end it does not change the game a lot.

However the results are not 100% identical.

Yes I remember that Lemmi moderator asks, the issue is mainly whom to 
ask and when. The devil is in the details. ;-)

What is easier and also on my wish-list is a certificate correction mode 
that allows moving around certificates between players.

Implementing that is easier and helps in more cases than adding more 
options how the president exchange should be handled. ;-)

Thanks for your input,

Stefan


On 08/30/2015 10:43 AM, Schnell, Volker wrote:
> Hi Stefan,
>
> in the end it should be the same result.
>
> Lemmis moderator: when in doubt about the certificates, there is a
> popup, where the user has to decide.
> This is for me the best way, because the decision has an impact on the
> certificate limit.
>
> greetings
>
> Volker
>
> Am 29.08.2015 um 12:58 schrieb Stefan Frey:
>> Hi Volker,
>>
>> I agree that there is a difference between buying and selling and that
>> in the case of another player buying more is different and is and will
>> be handled as you described.
>>
>> Caveat: There is no mechanism yet in Rails to ask the old director for
>> his choice in the case of another player getting more shares. (e.g.
>> buying or during share exchange of the Prussian minors/privates).
>> However I changed the current implementation that the old director
>> receives the multiple share if possible.
>>
>> The difference in understanding the rules is what happens exactly
>> during share selling: Selling to the Pool or Exchanging the Presidency?
>>
>> It is clear that the president certificate cannot end-up in the Pool
>> in non-pure-Tresham 18xx. However in my view is that if you sell more
>> than needed for dumping, your president certificate ends up for a
>> "virtual" second in the Pool and then the new president receives the
>>
>> There are technical reasons (ease of implementation, generalization to
>> 30% director shares, etc.), but in addition it is my view that selling
>> the director to the Pool (even it it cannot stay there in the end) is
>> more fundamental than the specific interpretation that the old
>> director "always" chooses what he receives in return. Especially if he
>> ends up with nothing in his portfolio in the end.
>>
>> I hope that you can live with that rule interpreation. And
>> unfortunately I will not add a game option to play it differently, as
>> this would require drastic changes how share selling is implemented in
>> Rails.
>>
>> The current algorithm is much more robust to (potential future) share
>> structures than a specific solution for 1835 only.
>>
>> By the way: Do you know how Lemmis moderator handles those cases?
>>
>> Stefan
>>
>> Those are the examples where our view differs:
>>
>> ** The result differs mainly for examples of that structure:
>>
>> X has 40% [d, 2*n]
>> Y has 40% [m, 2*n]
>>
>> Pool has 10 [n]
>>
>> I understand that you prefer the outcome for those cases where X sells
>> 10% or 20%, where in your interpretation the old president X is
>> allowed to choose the m certificate in exchange.
>>
>> However in those cases where X sells 30% or 40%, the m certificate
>> possibly ends in the pool, which I think is counter-intuitive.
>>
>> ** But a more extreme example:
>>
>> X has 20% [d]
>> Y has 20% [m]
>>
>> Pool has 40% [4*n]
>>
>> How does X sell 10% here? In standard 18xx this no problem: Sell d to
>> the pool, receive one n in exchange and the d moves to Y in exchange
>> for 20%.
>>
>> But in your interpretation X first exchanges d with m and then puts m
>> into the pool and receives one n from the pool?
>>
>>
>>
>>
>>
>>
>>
>>
>> On 08/29/2015 12:14 PM, Schnell, Volker wrote:
>>> Hi Stefan,
>>>
>>> I don't agree with your opinion, that the exchange of the directors
>>> certificate works with the bank pool.
>>> in all 18xx games, except with receivership like 1829, 1853, the
>>> certificates are exchanged between players.
>>> The Change of director is also possible, when buying shares.
>>>
>>> 1835 cases.
>>>
>>> Nominal certificate 10%
>>> Director certificate d=2 20% share
>>> Multiple certificate m=2 20% share
>>>
>>> X has 40%, x = 4 [d, n, n]
>>> Y has 40%, y = 4 [m, 2*n]
>>>
>>> X sells one share, the old director decides about the make up of the
>>> percentages (english rules IV.3 last sentence), he receives 1m or 2n
>>> from Y.
>>>
>>> Same situation but Y buys n, he has now 50% and receives the
>>> directors certificate (d). the new director now hands 1m or 2n to the
>>> old director, while the old directer decides about the make up.
>>>
>>> Greetings
>>> Volker
>>> Am 28.08.2015 um 22:47 schrieb Stefan Frey:
>>>> Follow-up to my proposal below:
>>>>
>>>> * Remark first: "Certificate" versus "Share"
>>>>
>>>> To be precise I use "certificate" to the physical representation of
>>>> shares in 18xx. I use "share" is the smallest unit of the division of
>>>> the share capital in 18xx.
>>>>
>>>> So the president certificate in 1830 represents 2 shares, the other
>>>> certificates are single shares. Each share represents 10% of share
>>>> capital.
>>>>
>>>> In 1835 the companies of the second group (BA, WT, HE) feature a
>>>> double-share certificate at the bottom of their IPO stack.
>>>>
>>>> The new mechanism is implemented now. As far as it possible and/or
>>>> technical feasible at the moment.
>>>>
>>>> * What are the current limitations on selling shares/certificates?
>>>>
>>>> - Selling certificates can only be done in groups that represent the
>>>> same number of shares.
>>>>
>>>> - As the president certificate can be sold in "parts" (and the old
>>>> president receives Pool certificates in return), it belongs to the
>>>> single share group.
>>>>
>>>> Example: In some cases in 1835 the double share certificates have to be
>>>> sold before it is possible to dump the president.
>>>>
>>>> - Exchanges to the Pool for the new president are executed by returning
>>>> certificates which represent minimal shares. Thus the new president
>>>> prefers to give up two single share certificates instead of one double
>>>> shares certificate.
>>>>
>>>> * What is the long-run target?
>>>>
>>>> Players first select what percentage they want to sell. For Example:
>>>> "40% of BY". If there are several combinations of certificates that
>>>> allow 40% the next step allows to select which certificates to sell.
>>>>
>>>> If the new president has choices what to return to the Pool in exchange
>>>> for the president certificate he is asked to choose.
>>>>
>>>>
>>>> * Reason for this limitation:
>>>> I am reluctant to change the action definitions of selling shares just
>>>> before the Rails 2.0 release.
>>>>
>>>> However behind the scene the code has been changed substantially and is
>>>> already based on the long-run goals.
>>>>
>>>> The automated test games run again and I have added a few new specific
>>>> test cases. However I am still a little bit reluctant and will
>>>> release a
>>>> new Rails 2.0 beta 5 tomorrow based on the new implementation.
>>>>
>>>> As before feedback welcome and thanks again to John David Galts ideas I
>>>> have based my implementation on.
>>>>
>>>> Stefan
>>>>
>>>>
>>>> On 08/23/2015 04:37 PM, Stefan Frey wrote:
>>>>> John:
>>>>> I really like your suggestion. I think it is a good way to handle
>>>>> those
>>>>> cases in a rigorous way. In addition it is fully compatible with the
>>>>> standard way of how standard 18xx treat the change of director in such
>>>>> cases.
>>>>>
>>>>> I adapted your proposal to include that it is not allowed to sell
>>>>> multiple certificates such that you are able to get a nominal share in
>>>>> exchange, which Volker and Erik referred to.
>>>>>
>>>>> However it is still possible for the director share, which I
>>>>> believe is
>>>>> important. (The second edition of the German rules claim that this is
>>>>> not possible, however I do not agree with that ruling).
>>>>>
>>>>> And Dave is fully right, game rules are not written as algorithms.
>>>>> It is
>>>>> our task to transform those rules into an algorithm which most people
>>>>> can agree on that the algorithm is a good representation of the
>>>>> game rules.
>>>>>
>>>>> So my proposed algorithm (based on John David Galts suggestion) is
>>>>> found
>>>>> below.
>>>>>
>>>>> Again feedback is very welcome.
>>>>>
>>>>> Stefan
>>>>>
>>>>>
>>>>> * Algorithm for Change of Director after Sale of Stock:
>>>>>
>>>>> ** Definitions:
>>>>>
>>>>> Share nominal n%
>>>>>
>>>>> Nominal (n) certificate 1 times n%
>>>>> Director (d) certificate has d times n%
>>>>> Multiple (m) certificate has m times n%
>>>>>
>>>>> Director X  has x times n% of stock
>>>>> Potential director Y has y times n% of stock
>>>>>
>>>>> Pool P has p times n% of stock
>>>>> Pool limit p_max times n%
>>>>>
>>>>> ** Steps:
>>>>>
>>>>> 1. Director can trigger change of director if he sells s >= (x-y) + 1
>>>>>
>>>>> 2. Only allowed if (s + p) <= p_max
>>>>>
>>>>> 3. Director puts d and other certificates (total o) into the pool,
>>>>> such
>>>>> that (d + o) >= s. Choose o such that o is minimal.
>>>>>
>>>>> 4. Potential (new) director exchanges certificates (of his choice, but
>>>>> see below) of total size e = d with the pool for the director
>>>>> certificate
>>>>>
>>>>> 5. (Old) director receives [(d+o) - s] (of his choice) from the
>>>>> pool, if
>>>>> this is not possible the previous step is repeated with a different
>>>>> choice until the old director receives the required amount of shares
>>>>>
>>>>> 6. If the last step cannot be executed in any way, selling s is not
>>>>> possible
>>>>>
>>>>> ** Remarks:
>>>>> - The program only offers choices in step 4 that allow step 5/6 to be
>>>>> succesfull
>>>>> - The program only offers transaction of size s that can be executed
>>>>>
>>>>> ** Examples:
>>>>>
>>>>> A) 1830 standard case
>>>>>
>>>>> Nominal certificate 10%
>>>>> Director certificate d=2 20% share
>>>>>
>>>>> X has 40%, x = 4 [d, 2*n]
>>>>> Y has 30%, y = 3 [3*n]
>>>>>
>>>>> Pool has 30%, p = 3
>>>>>
>>>>> Director sells 20%  (s=2)
>>>>>
>>>>> 1. Yes: s= 2;  (x-y) + 1 = (4- 3) + 1 = 2
>>>>>
>>>>> 2. Yes: s + p = 2 + 3 <= 5 = p_max
>>>>>
>>>>> 3. Director puts the director certificate, but no other into the
>>>>> pool (o
>>>>> = 0). (d + o) =  2 >= 2, minimal o
>>>>>
>>>>> 4. Potential director exchanges 2 10% shares with the pool
>>>>>
>>>>> 5. Old director gets nothing in return, transaction finished
>>>>>
>>>>> B) 1830 selling the director partially
>>>>>
>>>>> Certificates as above in A)
>>>>>
>>>>> X has 20%, x = 2 [d]
>>>>> Y has 20%, y = 2 [2*n]
>>>>>
>>>>> Pool is empty, p = 0
>>>>>
>>>>> Director sells 10%  (s=1)
>>>>>
>>>>> 1. Yes: s = 1; (x - y) + 1 = 1
>>>>>
>>>>> 2. Yes: s + p = 1 + 0  <= 5 = p_max
>>>>>
>>>>> 3. Director puts the director certificate, but no other into the
>>>>> pool (o
>>>>> = 0) d + o = 2 >= 1, minimal o
>>>>>
>>>>> 4. Potential director exchanges 2 10% shares with the pool
>>>>>
>>>>> 5. Old director receives 1 10% share from the pool
>>>>>
>>>>> C) 1835 case
>>>>>
>>>>> Nominal certificate 10%
>>>>> Director certificate d=2 20% share
>>>>> Multiple certificate m=2 20% share
>>>>>
>>>>> X has 50%, x = 5 [d, m, n]
>>>>> Y has 40%, y = 4 [m, 2*n]
>>>>>
>>>>> Pool is empty, p = 0
>>>>>
>>>>> Director sells 30% (s=3)
>>>>>
>>>>> 1. Yes
>>>>> 2. Yes
>>>>> 3. Director puts director certificate d the pool and a 10% share.
>>>>> It is
>>>>> not allowed to choose the 20% share here, as o has to be chosen to be
>>>>> minimal
>>>>> 4. Potential director chooses to exchange the director certificate
>>>>> from
>>>>> the pool with either the multiple certificate m or the two nominal
>>>>> certificates
>>>>> 5. Old director gets nothing in return, transaction is finished
>>>>>
>>>>> D) Another 1835 case
>>>>>
>>>>> Certificates as above in C)
>>>>>
>>>>> X has 40%, x = 4 [d, m]
>>>>> Y has 40%, y = 4 [m, 2*n]
>>>>>
>>>>> Pool is empty, p = 0
>>>>>
>>>>> Director sells 10% (s=1)
>>>>>
>>>>> 1. Yes
>>>>> 2. Yes
>>>>> 3. Director puts director certificate d the pool, but no other
>>>>> 4. Potential director can only exchange the 2 nominal certificates, as
>>>>> otherwise the director cannot receive the 10% share in step 5. If Pool
>>>>> contains a nominal certificate it is his choice
>>>>> 5. Old director receives 1 10% share from the pool
>>>>>
>>>>> On 08/21/2015 11:59 PM, John David Galt wrote:
>>>>>> Please use this version, I hit send too soon.
>>>>>>
>>>>>> On 2015-08-21 13:18, Stefan Frey wrote:
>>>>>>> Another 1835 implementation issue:
>>>>>>>
>>>>>>> President swaps are not easy to understand for newbies in any
>>>>>>> 18xx (you
>>>>>>> are not allowed to sell the president share, however you are
>>>>>>> allowed to
>>>>>>> tear it apart, virtually sell one half of it to the pool and then
>>>>>>> receive two shares by the new director, who gets the fixed director
>>>>>>> certificate, then the old director puts one of received shares
>>>>>>> into the
>>>>>>> pool and keeps the other).
>>>>>>>
>>>>>>> In 1835 the 20% shares make selling the presidency even more
>>>>>>> interesting.
>>>>>>>
>>>>>>> Selling the president certificate involves two steps of share
>>>>>>> movements:
>>>>>>>
>>>>>>> A) Exchange the president certificate with shares from the new
>>>>>>> president
>>>>>>>
>>>>>>> B) Move the remaining sold shares into the pool
>>>>>> I do not agree that these are separate steps.
>>>>>>
>>>>>>> In 1835 both steps could include either 10% or 20% shares (PR: 5%
>>>>>>> or 10%
>>>>>>> shares)
>>>>>>>
>>>>>>> Depending on what the president received in A) this might even
>>>>>>> change
>>>>>>> the possible options for B.
>>>>>>>
>>>>>>> However it implies that the current president has to choose both A)
>>>>>>> which certificate to exchange with the new president and B) which
>>>>>>> certificate to put into the pool.
>>>>>>>
>>>>>>> The current implementation only asks for A) and has some serious
>>>>>>> bugs in
>>>>>>> executing the share transfers.
>>>>>>>
>>>>>>> I intend to fix those bugs before the next release, however I
>>>>>>> would ask
>>>>>>> if anyone has a different opinion on how it works for 1835?
>>>>>> I have not seen any case in which the current program gets it
>>>>>> wrong (in
>>>>>> my view) -- however, I have not exhaustively tried every single case.
>>>>>>
>>>>>> The following is the exact sequence of events I expect to happen
>>>>>> in any
>>>>>> purchase or sale of stock (after any starting packet). This
>>>>>> applies to
>>>>>> all games, not just 1835.
>>>>>>
>>>>>> In a purchase of stock:
>>>>>>
>>>>>> (1) The player buys a certificate, not share(s).
>>>>>>
>>>>>> (2) If the purchase causes a change of president, then the new
>>>>>> president
>>>>>> exchanges one or more certificates (totaling the same number of
>>>>>> shares
>>>>>> of that company) for the president's certificate, wherever it is.
>>>>>> (This
>>>>>> is a direct exchange between two players, unless the president's
>>>>>> certificate is in the bank pool, as it might be in 1829
>>>>>> (receivership)
>>>>>> or 1853v1 (when the company hasn't floated yet).)
>>>>>>
>>>>>> (In 1835, if there is a choice, the outgoing president chooses which
>>>>>> certificate(s) he receives from among those in the new president's
>>>>>> hand.
>>>>>>      I would follow this principle in any other game where any
>>>>>> company has
>>>>>> non-presidential certificates of more than one size, if the rules
>>>>>> do not
>>>>>> address the question.)
>>>>>>
>>>>>> In a sale of stock:
>>>>>>
>>>>>> (1) A sale that is going to cause a change of president may only
>>>>>> be made
>>>>>> if some other player holds at least the number of shares that the
>>>>>> president's certificate contains.
>>>>>>
>>>>>> (2) Except for the special case given in point (5), the player sells
>>>>>> certificate(s), not share(s).
>>>>>>
>>>>>> (3) If the sale will cause a change of president, then one of the
>>>>>> certificate(s) sold must be the president's certificate. Otherwise
>>>>>> the
>>>>>> seller must retain the president's certificate.
>>>>>>
>>>>>> (4) If the sale causes a change of presidency, then the new president
>>>>>> exchanges one or more certificates (totaling the same number of
>>>>>> shares
>>>>>> of that company) for the president's certificate in the bank
>>>>>> pool.  (The
>>>>>> outgoing president does not participate in this swap and does not
>>>>>> have
>>>>>> any right to claim a certificate from the new president's hand.)
>>>>>>
>>>>>> (5) A special case is where a player who holds only certificate(s) of
>>>>>> two or more shares each in that company wishes to sell a number or
>>>>>> shares that is not divisible by one of his certificates. (For this
>>>>>> purpose "one share" is defined as the amount of the smallest
>>>>>> certificate
>>>>>> that exists for that company.)
>>>>>>
>>>>>> In this case the "fractional sale" may only be made if one of the
>>>>>> following is true in addition to point (1):
>>>>>>
>>>>>>        A: The bank pool contains certificate(s) of the company in
>>>>>> the right
>>>>>> sizes such that the seller can be given the correct number of shares
>>>>>> from the bank pool.  In this case the seller exchanges
>>>>>> certificates with
>>>>>> the bank pool, and then point (4) applies.
>>>>>>
>>>>>>        B: Statement A above is not true, but, the sale will cause
>>>>>> a change
>>>>>> of presidency, and the bank pool and the old and new presidents'
>>>>>> hands
>>>>>> together contain enough certificates of the company to give both
>>>>>> the old
>>>>>> and new presidents the correct numbers of shares, with the new
>>>>>> president
>>>>>> holding the president's certificate.  In this case a three-way
>>>>>> swap of
>>>>>> certificates is performed.  If there is more than one correct way to
>>>>>> perform the swap, first the outgoing president chooses which
>>>>>> certificate(s) he gives up; then the new president chooses which
>>>>>> certificate(s) he gives up.
>>>>>>
>>>>>>> Example:
>>>>>>>
>>>>>>> In the attached save file OL has the following share distribution:
>>>>>>>
>>>>>>> (Remark: this is from a replay of one of Bill Stoll's 1835 pbem
>>>>>>> games -
>>>>>>> see http://askwaltstollmd.com/bill/archive/1835zwolf/index.html
>>>>>>> Fun fact is that I played 1835 ftf with one of the players before he
>>>>>>> moved to the US)
>>>>>>>
>>>>>>> Eyal: 50% (1 20% director, 1 20% share, 1 10% share)
>>>>>>> Marco: 40% (1 20% share, 2 10% share)
>>>>>>> Nick: 10% (1 10% share)
>>>>>>>
>>>>>>> What are the possible scenarios for Eyal to sell his directorship?
>>>>>> If Eyal sells 10% (which does not change the presidency), he just
>>>>>> moves
>>>>>> his 10% certificate to the bank pool.  Done.
>>>>>>
>>>>>> If Eyal sells 20%, he moves the president's certificate to the bank
>>>>>> pool.  Then Marco takes it and chooses 20% (either one 20% or two 10%
>>>>>> certificates) to place in the bank pool.
>>>>>>
>>>>>> If Eyal sells 30%, he moves the president's certificate and the 10%
>>>>>> certificate to the bank pool.  Then Marco takes the president's
>>>>>> certificate and chooses 20% (either one 20% or two 10%
>>>>>> certificates) to
>>>>>> place in the bank pool.
>>>>>>
>>>>>> If Eyal sells 40%, he moves the president's certificate and the 20%
>>>>>> certificate to the bank pool.  Then Marco takes the president's
>>>>>> certificate and chooses 20% (either one 20% or two 10%
>>>>>> certificates) to
>>>>>> place in the bank pool.
>>>>>>
>>>>>> If Eyal sells 50%, he moves all three of his certificates to the bank
>>>>>> pool.  Then Marco takes the president's certificate and chooses 20%
>>>>>> (either one 20% or two 10% certificates) to place in the bank pool.
>>>>>>
>>>>>> [snip]
>>>>>>> Some special (hypothetical) cases:
>>>>>>>
>>>>>>> A) No shares in Pool
>>>>>>>
>>>>>>> Eyal: 40% (20%P + 20%)
>>>>>>> Marco: 20% (20%)
>>>>>>>
>>>>>>> IPO: 40% (4 10%)
>>>>>>>
>>>>>>> Is it possible for Eyal to sell 30%?
>>>>>>> Answer: No, as it not possible to get a 10% share out of IPO to
>>>>>>> Eyal.
>>>>>>> Eyal has to sell all 40%.
>>>>>> Agreed.
>>>>>>
>>>>>>> B) 10% shares in Pool
>>>>>>>
>>>>>>> Eyal: 40% (20%P + 20%)
>>>>>>> Marco: 20% (20%)
>>>>>>>
>>>>>>> Pool: 40% (4 10%)
>>>>>>>
>>>>>>> Is it possible for Eyal to sell 30%?
>>>>>>> Answer: Likely yes? Is it possible for Eyal to swap the received 20%
>>>>>>> share from Marco with a 10% of the Pool?
>>>>>> In most games (and I think this includes 1835), Eyal is prevented
>>>>>> from
>>>>>> selling 30% because this would cause 70% to be in the bank pool.
>>>>>>
>>>>>> But let's change the example by having the pool hold two 10%
>>>>>> certificates and a third player hold the other two.  Then Eyal may
>>>>>> sell
>>>>>> 30% by placing both his certificates in the bank pool and taking a
>>>>>> 10%
>>>>>> certificate from the bank pool.  Marco must then trade his 20%
>>>>>> certificate for the president's certificate.
>>>>>>
>>>>>> Eyal may also sell 10%.  In this case he just places his 20%
>>>>>> non-president certificate in the bank pool and takes a 10%
>>>>>> certificate.
>>>>>>
>>>>>> -end-
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>>
>>>>>> _______________________________________________
>>>>>> Rails-devel mailing list
>>>>>> Rai...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> Rails-devel mailing list
>>>>> Rai...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Rails-devel mailing list
>>>> Rai...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>
>

[Rails-devel] Rails 2.0 beta 5 available

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

Hopefully this time the final one.

A new game is supported:
Helmut Ohley's 18NL is a 1830 with new map/companies based in the 
Netherlands.

And changes/fixes mainly for 1835, details see below.

Stefan

Current Roadmap:
http://github.com/freystef/Rails/wiki/Roadmap


## Installing

* Webstart the beta release (all users)

http://rails.sf.net/webstart/rails.jnlp

* Download single exe launcher (Windows users)

Download the single exe file and start it directly.

http://sourceforge.net/projects/rails/files/Rails/2.0/


* Download single jar (Mac and *nix users)

Download the single jar and start it directly (by double-click or
command line "java -jar" command).

http://sourceforge.net/projects/rails/files/Rails/2.0/

**********************
Copy of the readme.txt
**********************

# Rails 2.0 Beta 5 release:

## Beta 5 Improvements

### 18NL supported

For details of the game see <a 
href="http://www.ohley.de/18nl/start.htm">18NL documentation</a>.

### Tile and Token lays

Implementation of edge cases / rules ambiguities, see [document on 
special tiles and token lays.](PrivatesTileToken)

### 1835
* New implementation to exchange the president certificate, for details 
see [document on selling the president certificate.](SellingPresident)

* A new game option allows to select the Westermann ruling that NF/PfB 
token powers are restricted to the token lay step

## Bugs fixed in Beta 5 Release

### Fixed UI Bugs
* fixed display of tokens in hex tooltip
* fixed display of tokens of map for 4-slots cities (e.g. NYC in 1830 
Coalfields)
* in StartRoundWindow the priority player indication is updated

### Fixed 1830 (and derivatives) Bugs
* fixed bug during auction that zero price private was bought by wrong 
player

### Fixed 1835 bugs:
* (partial) fix for 1835: swap of presidency after prussian merger 
round: exchange 10% before 5% shares

Re: [Rails-devel] 1835 presidency swap: Bug fix required (typos corrected)

[Schnell, V. <vol...@ar...>]

Hi Stefan,

in the end it should be the same result.

Lemmis moderator: when in doubt about the certificates, there is a 
popup, where the user has to decide.
This is for me the best way, because the decision has an impact on the 
certificate limit.

greetings

Volker

Am 29.08.2015 um 12:58 schrieb Stefan Frey:
> Hi Volker,
>
> I agree that there is a difference between buying and selling and that 
> in the case of another player buying more is different and is and will 
> be handled as you described.
>
> Caveat: There is no mechanism yet in Rails to ask the old director for 
> his choice in the case of another player getting more shares. (e.g. 
> buying or during share exchange of the Prussian minors/privates). 
> However I changed the current implementation that the old director 
> receives the multiple share if possible.
>
> The difference in understanding the rules is what happens exactly 
> during share selling: Selling to the Pool or Exchanging the Presidency?
>
> It is clear that the president certificate cannot end-up in the Pool 
> in non-pure-Tresham 18xx. However in my view is that if you sell more 
> than needed for dumping, your president certificate ends up for a 
> "virtual" second in the Pool and then the new president receives the
>
> There are technical reasons (ease of implementation, generalization to 
> 30% director shares, etc.), but in addition it is my view that selling 
> the director to the Pool (even it it cannot stay there in the end) is 
> more fundamental than the specific interpretation that the old 
> director "always" chooses what he receives in return. Especially if he 
> ends up with nothing in his portfolio in the end.
>
> I hope that you can live with that rule interpreation. And 
> unfortunately I will not add a game option to play it differently, as 
> this would require drastic changes how share selling is implemented in 
> Rails.
>
> The current algorithm is much more robust to (potential future) share 
> structures than a specific solution for 1835 only.
>
> By the way: Do you know how Lemmis moderator handles those cases?
>
> Stefan
>
> Those are the examples where our view differs:
>
> ** The result differs mainly for examples of that structure:
>
> X has 40% [d, 2*n]
> Y has 40% [m, 2*n]
>
> Pool has 10 [n]
>
> I understand that you prefer the outcome for those cases where X sells 
> 10% or 20%, where in your interpretation the old president X is 
> allowed to choose the m certificate in exchange.
>
> However in those cases where X sells 30% or 40%, the m certificate 
> possibly ends in the pool, which I think is counter-intuitive.
>
> ** But a more extreme example:
>
> X has 20% [d]
> Y has 20% [m]
>
> Pool has 40% [4*n]
>
> How does X sell 10% here? In standard 18xx this no problem: Sell d to 
> the pool, receive one n in exchange and the d moves to Y in exchange 
> for 20%.
>
> But in your interpretation X first exchanges d with m and then puts m 
> into the pool and receives one n from the pool?
>
>
>
>
>
>
>
>
> On 08/29/2015 12:14 PM, Schnell, Volker wrote:
>> Hi Stefan,
>>
>> I don't agree with your opinion, that the exchange of the directors
>> certificate works with the bank pool.
>> in all 18xx games, except with receivership like 1829, 1853, the
>> certificates are exchanged between players.
>> The Change of director is also possible, when buying shares.
>>
>> 1835 cases.
>>
>> Nominal certificate 10%
>> Director certificate d=2 20% share
>> Multiple certificate m=2 20% share
>>
>> X has 40%, x = 4 [d, n, n]
>> Y has 40%, y = 4 [m, 2*n]
>>
>> X sells one share, the old director decides about the make up of the 
>> percentages (english rules IV.3 last sentence), he receives 1m or 2n 
>> from Y.
>>
>> Same situation but Y buys n, he has now 50% and receives the 
>> directors certificate (d). the new director now hands 1m or 2n to the 
>> old director, while the old directer decides about the make up.
>>
>> Greetings
>> Volker
>> Am 28.08.2015 um 22:47 schrieb Stefan Frey:
>>> Follow-up to my proposal below:
>>>
>>> * Remark first: "Certificate" versus "Share"
>>>
>>> To be precise I use "certificate" to the physical representation of
>>> shares in 18xx. I use "share" is the smallest unit of the division of
>>> the share capital in 18xx.
>>>
>>> So the president certificate in 1830 represents 2 shares, the other
>>> certificates are single shares. Each share represents 10% of share 
>>> capital.
>>>
>>> In 1835 the companies of the second group (BA, WT, HE) feature a
>>> double-share certificate at the bottom of their IPO stack.
>>>
>>> The new mechanism is implemented now. As far as it possible and/or
>>> technical feasible at the moment.
>>>
>>> * What are the current limitations on selling shares/certificates?
>>>
>>> - Selling certificates can only be done in groups that represent the
>>> same number of shares.
>>>
>>> - As the president certificate can be sold in "parts" (and the old
>>> president receives Pool certificates in return), it belongs to the
>>> single share group.
>>>
>>> Example: In some cases in 1835 the double share certificates have to be
>>> sold before it is possible to dump the president.
>>>
>>> - Exchanges to the Pool for the new president are executed by returning
>>> certificates which represent minimal shares. Thus the new president
>>> prefers to give up two single share certificates instead of one double
>>> shares certificate.
>>>
>>> * What is the long-run target?
>>>
>>> Players first select what percentage they want to sell. For Example:
>>> "40% of BY". If there are several combinations of certificates that
>>> allow 40% the next step allows to select which certificates to sell.
>>>
>>> If the new president has choices what to return to the Pool in exchange
>>> for the president certificate he is asked to choose.
>>>
>>>
>>> * Reason for this limitation:
>>> I am reluctant to change the action definitions of selling shares just
>>> before the Rails 2.0 release.
>>>
>>> However behind the scene the code has been changed substantially and is
>>> already based on the long-run goals.
>>>
>>> The automated test games run again and I have added a few new specific
>>> test cases. However I am still a little bit reluctant and will 
>>> release a
>>> new Rails 2.0 beta 5 tomorrow based on the new implementation.
>>>
>>> As before feedback welcome and thanks again to John David Galts ideas I
>>> have based my implementation on.
>>>
>>> Stefan
>>>
>>>
>>> On 08/23/2015 04:37 PM, Stefan Frey wrote:
>>>> John:
>>>> I really like your suggestion. I think it is a good way to handle 
>>>> those
>>>> cases in a rigorous way. In addition it is fully compatible with the
>>>> standard way of how standard 18xx treat the change of director in such
>>>> cases.
>>>>
>>>> I adapted your proposal to include that it is not allowed to sell
>>>> multiple certificates such that you are able to get a nominal share in
>>>> exchange, which Volker and Erik referred to.
>>>>
>>>> However it is still possible for the director share, which I 
>>>> believe is
>>>> important. (The second edition of the German rules claim that this is
>>>> not possible, however I do not agree with that ruling).
>>>>
>>>> And Dave is fully right, game rules are not written as algorithms. 
>>>> It is
>>>> our task to transform those rules into an algorithm which most people
>>>> can agree on that the algorithm is a good representation of the 
>>>> game rules.
>>>>
>>>> So my proposed algorithm (based on John David Galts suggestion) is 
>>>> found
>>>> below.
>>>>
>>>> Again feedback is very welcome.
>>>>
>>>> Stefan
>>>>
>>>>
>>>> * Algorithm for Change of Director after Sale of Stock:
>>>>
>>>> ** Definitions:
>>>>
>>>> Share nominal n%
>>>>
>>>> Nominal (n) certificate 1 times n%
>>>> Director (d) certificate has d times n%
>>>> Multiple (m) certificate has m times n%
>>>>
>>>> Director X  has x times n% of stock
>>>> Potential director Y has y times n% of stock
>>>>
>>>> Pool P has p times n% of stock
>>>> Pool limit p_max times n%
>>>>
>>>> ** Steps:
>>>>
>>>> 1. Director can trigger change of director if he sells s >= (x-y) + 1
>>>>
>>>> 2. Only allowed if (s + p) <= p_max
>>>>
>>>> 3. Director puts d and other certificates (total o) into the pool, 
>>>> such
>>>> that (d + o) >= s. Choose o such that o is minimal.
>>>>
>>>> 4. Potential (new) director exchanges certificates (of his choice, but
>>>> see below) of total size e = d with the pool for the director 
>>>> certificate
>>>>
>>>> 5. (Old) director receives [(d+o) - s] (of his choice) from the 
>>>> pool, if
>>>> this is not possible the previous step is repeated with a different
>>>> choice until the old director receives the required amount of shares
>>>>
>>>> 6. If the last step cannot be executed in any way, selling s is not 
>>>> possible
>>>>
>>>> ** Remarks:
>>>> - The program only offers choices in step 4 that allow step 5/6 to be
>>>> succesfull
>>>> - The program only offers transaction of size s that can be executed
>>>>
>>>> ** Examples:
>>>>
>>>> A) 1830 standard case
>>>>
>>>> Nominal certificate 10%
>>>> Director certificate d=2 20% share
>>>>
>>>> X has 40%, x = 4 [d, 2*n]
>>>> Y has 30%, y = 3 [3*n]
>>>>
>>>> Pool has 30%, p = 3
>>>>
>>>> Director sells 20%  (s=2)
>>>>
>>>> 1. Yes: s= 2;  (x-y) + 1 = (4- 3) + 1 = 2
>>>>
>>>> 2. Yes: s + p = 2 + 3 <= 5 = p_max
>>>>
>>>> 3. Director puts the director certificate, but no other into the 
>>>> pool (o
>>>> = 0). (d + o) =  2 >= 2, minimal o
>>>>
>>>> 4. Potential director exchanges 2 10% shares with the pool
>>>>
>>>> 5. Old director gets nothing in return, transaction finished
>>>>
>>>> B) 1830 selling the director partially
>>>>
>>>> Certificates as above in A)
>>>>
>>>> X has 20%, x = 2 [d]
>>>> Y has 20%, y = 2 [2*n]
>>>>
>>>> Pool is empty, p = 0
>>>>
>>>> Director sells 10%  (s=1)
>>>>
>>>> 1. Yes: s = 1; (x - y) + 1 = 1
>>>>
>>>> 2. Yes: s + p = 1 + 0  <= 5 = p_max
>>>>
>>>> 3. Director puts the director certificate, but no other into the 
>>>> pool (o
>>>> = 0) d + o = 2 >= 1, minimal o
>>>>
>>>> 4. Potential director exchanges 2 10% shares with the pool
>>>>
>>>> 5. Old director receives 1 10% share from the pool
>>>>
>>>> C) 1835 case
>>>>
>>>> Nominal certificate 10%
>>>> Director certificate d=2 20% share
>>>> Multiple certificate m=2 20% share
>>>>
>>>> X has 50%, x = 5 [d, m, n]
>>>> Y has 40%, y = 4 [m, 2*n]
>>>>
>>>> Pool is empty, p = 0
>>>>
>>>> Director sells 30% (s=3)
>>>>
>>>> 1. Yes
>>>> 2. Yes
>>>> 3. Director puts director certificate d the pool and a 10% share. 
>>>> It is
>>>> not allowed to choose the 20% share here, as o has to be chosen to be
>>>> minimal
>>>> 4. Potential director chooses to exchange the director certificate 
>>>> from
>>>> the pool with either the multiple certificate m or the two nominal
>>>> certificates
>>>> 5. Old director gets nothing in return, transaction is finished
>>>>
>>>> D) Another 1835 case
>>>>
>>>> Certificates as above in C)
>>>>
>>>> X has 40%, x = 4 [d, m]
>>>> Y has 40%, y = 4 [m, 2*n]
>>>>
>>>> Pool is empty, p = 0
>>>>
>>>> Director sells 10% (s=1)
>>>>
>>>> 1. Yes
>>>> 2. Yes
>>>> 3. Director puts director certificate d the pool, but no other
>>>> 4. Potential director can only exchange the 2 nominal certificates, as
>>>> otherwise the director cannot receive the 10% share in step 5. If Pool
>>>> contains a nominal certificate it is his choice
>>>> 5. Old director receives 1 10% share from the pool
>>>>
>>>> On 08/21/2015 11:59 PM, John David Galt wrote:
>>>>> Please use this version, I hit send too soon.
>>>>>
>>>>> On 2015-08-21 13:18, Stefan Frey wrote:
>>>>>> Another 1835 implementation issue:
>>>>>>
>>>>>> President swaps are not easy to understand for newbies in any 
>>>>>> 18xx (you
>>>>>> are not allowed to sell the president share, however you are 
>>>>>> allowed to
>>>>>> tear it apart, virtually sell one half of it to the pool and then
>>>>>> receive two shares by the new director, who gets the fixed director
>>>>>> certificate, then the old director puts one of received shares 
>>>>>> into the
>>>>>> pool and keeps the other).
>>>>>>
>>>>>> In 1835 the 20% shares make selling the presidency even more 
>>>>>> interesting.
>>>>>>
>>>>>> Selling the president certificate involves two steps of share 
>>>>>> movements:
>>>>>>
>>>>>> A) Exchange the president certificate with shares from the new 
>>>>>> president
>>>>>>
>>>>>> B) Move the remaining sold shares into the pool
>>>>> I do not agree that these are separate steps.
>>>>>
>>>>>> In 1835 both steps could include either 10% or 20% shares (PR: 5% 
>>>>>> or 10%
>>>>>> shares)
>>>>>>
>>>>>> Depending on what the president received in A) this might even 
>>>>>> change
>>>>>> the possible options for B.
>>>>>>
>>>>>> However it implies that the current president has to choose both A)
>>>>>> which certificate to exchange with the new president and B) which
>>>>>> certificate to put into the pool.
>>>>>>
>>>>>> The current implementation only asks for A) and has some serious 
>>>>>> bugs in
>>>>>> executing the share transfers.
>>>>>>
>>>>>> I intend to fix those bugs before the next release, however I 
>>>>>> would ask
>>>>>> if anyone has a different opinion on how it works for 1835?
>>>>> I have not seen any case in which the current program gets it 
>>>>> wrong (in
>>>>> my view) -- however, I have not exhaustively tried every single case.
>>>>>
>>>>> The following is the exact sequence of events I expect to happen 
>>>>> in any
>>>>> purchase or sale of stock (after any starting packet). This 
>>>>> applies to
>>>>> all games, not just 1835.
>>>>>
>>>>> In a purchase of stock:
>>>>>
>>>>> (1) The player buys a certificate, not share(s).
>>>>>
>>>>> (2) If the purchase causes a change of president, then the new 
>>>>> president
>>>>> exchanges one or more certificates (totaling the same number of 
>>>>> shares
>>>>> of that company) for the president's certificate, wherever it is.  
>>>>> (This
>>>>> is a direct exchange between two players, unless the president's
>>>>> certificate is in the bank pool, as it might be in 1829 
>>>>> (receivership)
>>>>> or 1853v1 (when the company hasn't floated yet).)
>>>>>
>>>>> (In 1835, if there is a choice, the outgoing president chooses which
>>>>> certificate(s) he receives from among those in the new president's 
>>>>> hand.
>>>>>      I would follow this principle in any other game where any 
>>>>> company has
>>>>> non-presidential certificates of more than one size, if the rules 
>>>>> do not
>>>>> address the question.)
>>>>>
>>>>> In a sale of stock:
>>>>>
>>>>> (1) A sale that is going to cause a change of president may only 
>>>>> be made
>>>>> if some other player holds at least the number of shares that the
>>>>> president's certificate contains.
>>>>>
>>>>> (2) Except for the special case given in point (5), the player sells
>>>>> certificate(s), not share(s).
>>>>>
>>>>> (3) If the sale will cause a change of president, then one of the
>>>>> certificate(s) sold must be the president's certificate. Otherwise 
>>>>> the
>>>>> seller must retain the president's certificate.
>>>>>
>>>>> (4) If the sale causes a change of presidency, then the new president
>>>>> exchanges one or more certificates (totaling the same number of 
>>>>> shares
>>>>> of that company) for the president's certificate in the bank 
>>>>> pool.  (The
>>>>> outgoing president does not participate in this swap and does not 
>>>>> have
>>>>> any right to claim a certificate from the new president's hand.)
>>>>>
>>>>> (5) A special case is where a player who holds only certificate(s) of
>>>>> two or more shares each in that company wishes to sell a number or
>>>>> shares that is not divisible by one of his certificates. (For this
>>>>> purpose "one share" is defined as the amount of the smallest 
>>>>> certificate
>>>>> that exists for that company.)
>>>>>
>>>>> In this case the "fractional sale" may only be made if one of the
>>>>> following is true in addition to point (1):
>>>>>
>>>>>        A: The bank pool contains certificate(s) of the company in 
>>>>> the right
>>>>> sizes such that the seller can be given the correct number of shares
>>>>> from the bank pool.  In this case the seller exchanges 
>>>>> certificates with
>>>>> the bank pool, and then point (4) applies.
>>>>>
>>>>>        B: Statement A above is not true, but, the sale will cause 
>>>>> a change
>>>>> of presidency, and the bank pool and the old and new presidents' 
>>>>> hands
>>>>> together contain enough certificates of the company to give both 
>>>>> the old
>>>>> and new presidents the correct numbers of shares, with the new 
>>>>> president
>>>>> holding the president's certificate.  In this case a three-way 
>>>>> swap of
>>>>> certificates is performed.  If there is more than one correct way to
>>>>> perform the swap, first the outgoing president chooses which
>>>>> certificate(s) he gives up; then the new president chooses which
>>>>> certificate(s) he gives up.
>>>>>
>>>>>> Example:
>>>>>>
>>>>>> In the attached save file OL has the following share distribution:
>>>>>>
>>>>>> (Remark: this is from a replay of one of Bill Stoll's 1835 pbem 
>>>>>> games -
>>>>>> see http://askwaltstollmd.com/bill/archive/1835zwolf/index.html
>>>>>> Fun fact is that I played 1835 ftf with one of the players before he
>>>>>> moved to the US)
>>>>>>
>>>>>> Eyal: 50% (1 20% director, 1 20% share, 1 10% share)
>>>>>> Marco: 40% (1 20% share, 2 10% share)
>>>>>> Nick: 10% (1 10% share)
>>>>>>
>>>>>> What are the possible scenarios for Eyal to sell his directorship?
>>>>> If Eyal sells 10% (which does not change the presidency), he just 
>>>>> moves
>>>>> his 10% certificate to the bank pool.  Done.
>>>>>
>>>>> If Eyal sells 20%, he moves the president's certificate to the bank
>>>>> pool.  Then Marco takes it and chooses 20% (either one 20% or two 10%
>>>>> certificates) to place in the bank pool.
>>>>>
>>>>> If Eyal sells 30%, he moves the president's certificate and the 10%
>>>>> certificate to the bank pool.  Then Marco takes the president's
>>>>> certificate and chooses 20% (either one 20% or two 10% 
>>>>> certificates) to
>>>>> place in the bank pool.
>>>>>
>>>>> If Eyal sells 40%, he moves the president's certificate and the 20%
>>>>> certificate to the bank pool.  Then Marco takes the president's
>>>>> certificate and chooses 20% (either one 20% or two 10% 
>>>>> certificates) to
>>>>> place in the bank pool.
>>>>>
>>>>> If Eyal sells 50%, he moves all three of his certificates to the bank
>>>>> pool.  Then Marco takes the president's certificate and chooses 20%
>>>>> (either one 20% or two 10% certificates) to place in the bank pool.
>>>>>
>>>>> [snip]
>>>>>> Some special (hypothetical) cases:
>>>>>>
>>>>>> A) No shares in Pool
>>>>>>
>>>>>> Eyal: 40% (20%P + 20%)
>>>>>> Marco: 20% (20%)
>>>>>>
>>>>>> IPO: 40% (4 10%)
>>>>>>
>>>>>> Is it possible for Eyal to sell 30%?
>>>>>> Answer: No, as it not possible to get a 10% share out of IPO to 
>>>>>> Eyal.
>>>>>> Eyal has to sell all 40%.
>>>>> Agreed.
>>>>>
>>>>>> B) 10% shares in Pool
>>>>>>
>>>>>> Eyal: 40% (20%P + 20%)
>>>>>> Marco: 20% (20%)
>>>>>>
>>>>>> Pool: 40% (4 10%)
>>>>>>
>>>>>> Is it possible for Eyal to sell 30%?
>>>>>> Answer: Likely yes? Is it possible for Eyal to swap the received 20%
>>>>>> share from Marco with a 10% of the Pool?
>>>>> In most games (and I think this includes 1835), Eyal is prevented 
>>>>> from
>>>>> selling 30% because this would cause 70% to be in the bank pool.
>>>>>
>>>>> But let's change the example by having the pool hold two 10%
>>>>> certificates and a third player hold the other two.  Then Eyal may 
>>>>> sell
>>>>> 30% by placing both his certificates in the bank pool and taking a 
>>>>> 10%
>>>>> certificate from the bank pool.  Marco must then trade his 20%
>>>>> certificate for the president's certificate.
>>>>>
>>>>> Eyal may also sell 10%.  In this case he just places his 20%
>>>>> non-president certificate in the bank pool and takes a 10% 
>>>>> certificate.
>>>>>
>>>>> -end-
>>>>>
>>>>> ------------------------------------------------------------------------------ 
>>>>>
>>>>> _______________________________________________
>>>>> Rails-devel mailing list
>>>>> Rai...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>>>
>>>> ------------------------------------------------------------------------------ 
>>>>
>>>> _______________________________________________
>>>> Rails-devel mailing list
>>>> Rai...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>>
>>> ------------------------------------------------------------------------------ 
>>>
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>

-- 
Volker Schnell
email: vol...@ar...
homepage: home.arcor.de\volker_schnell

Re: [Rails-devel] 1835 presidency swap: Bug fix required (typos corrected)

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

Hi Volker,

I agree that there is a difference between buying and selling and that 
in the case of another player buying more is different and is and will 
be handled as you described.

Caveat: There is no mechanism yet in Rails to ask the old director for 
his choice in the case of another player getting more shares. (e.g. 
buying or during share exchange of the Prussian minors/privates). 
However I changed the current implementation that the old director 
receives the multiple share if possible.

The difference in understanding the rules is what happens exactly during 
share selling: Selling to the Pool or Exchanging the Presidency?

It is clear that the president certificate cannot end-up in the Pool in 
non-pure-Tresham 18xx. However in my view is that if you sell more than 
needed for dumping, your president certificate ends up for a "virtual" 
second in the Pool and then the new president receives the

There are technical reasons (ease of implementation, generalization to 
30% director shares, etc.), but in addition it is my view that selling 
the director to the Pool (even it it cannot stay there in the end) is 
more fundamental than the specific interpretation that the old director 
"always" chooses what he receives in return. Especially if he ends up 
with nothing in his portfolio in the end.

I hope that you can live with that rule interpreation. And unfortunately 
I will not add a game option to play it differently, as this would 
require drastic changes how share selling is implemented in Rails.

The current algorithm is much more robust to (potential future) share 
structures than a specific solution for 1835 only.

By the way: Do you know how Lemmis moderator handles those cases?

Stefan

Those are the examples where our view differs:

** The result differs mainly for examples of that structure:

X has 40% [d, 2*n]
Y has 40% [m, 2*n]

Pool has 10 [n]

I understand that you prefer the outcome for those cases where X sells 
10% or 20%, where in your interpretation the old president X is allowed 
to choose the m certificate in exchange.

However in those cases where X sells 30% or 40%, the m certificate 
possibly ends in the pool, which I think is counter-intuitive.

** But a more extreme example:

X has 20% [d]
Y has 20% [m]

Pool has 40% [4*n]

How does X sell 10% here? In standard 18xx this no problem: Sell d to 
the pool, receive one n in exchange and the d moves to Y in exchange for 
20%.

But in your interpretation X first exchanges d with m and then puts m 
into the pool and receives one n from the pool?








On 08/29/2015 12:14 PM, Schnell, Volker wrote:
> Hi Stefan,
>
> I don't agree with your opinion, that the exchange of the directors
> certificate works with the bank pool.
> in all 18xx games, except with receivership like 1829, 1853, the
> certificates are exchanged between players.
> The Change of director is also possible, when buying shares.
>
> 1835 cases.
>
> Nominal certificate 10%
> Director certificate d=2 20% share
> Multiple certificate m=2 20% share
>
> X has 40%, x = 4 [d, n, n]
> Y has 40%, y = 4 [m, 2*n]
>
> X sells one share, the old director decides about the make up of the percentages (english rules IV.3 last sentence), he receives 1m or 2n from Y.
>
> Same situation but Y buys n, he has now 50% and receives the directors certificate (d). the new director now hands 1m or 2n to the old director, while the old directer decides about the make up.
>
> Greetings
> Volker
> Am 28.08.2015 um 22:47 schrieb Stefan Frey:
>> Follow-up to my proposal below:
>>
>> * Remark first: "Certificate" versus "Share"
>>
>> To be precise I use "certificate" to the physical representation of
>> shares in 18xx. I use "share" is the smallest unit of the division of
>> the share capital in 18xx.
>>
>> So the president certificate in 1830 represents 2 shares, the other
>> certificates are single shares. Each share represents 10% of share capital.
>>
>> In 1835 the companies of the second group (BA, WT, HE) feature a
>> double-share certificate at the bottom of their IPO stack.
>>
>> The new mechanism is implemented now. As far as it possible and/or
>> technical feasible at the moment.
>>
>> * What are the current limitations on selling shares/certificates?
>>
>> - Selling certificates can only be done in groups that represent the
>> same number of shares.
>>
>> - As the president certificate can be sold in "parts" (and the old
>> president receives Pool certificates in return), it belongs to the
>> single share group.
>>
>> Example: In some cases in 1835 the double share certificates have to be
>> sold before it is possible to dump the president.
>>
>> - Exchanges to the Pool for the new president are executed by returning
>> certificates which represent minimal shares. Thus the new president
>> prefers to give up two single share certificates instead of one double
>> shares certificate.
>>
>> * What is the long-run target?
>>
>> Players first select what percentage they want to sell. For Example:
>> "40% of BY". If there are several combinations of certificates that
>> allow 40% the next step allows to select which certificates to sell.
>>
>> If the new president has choices what to return to the Pool in exchange
>> for the president certificate he is asked to choose.
>>
>>
>> * Reason for this limitation:
>> I am reluctant to change the action definitions of selling shares just
>> before the Rails 2.0 release.
>>
>> However behind the scene the code has been changed substantially and is
>> already based on the long-run goals.
>>
>> The automated test games run again and I have added a few new specific
>> test cases. However I am still a little bit reluctant and will release a
>> new Rails 2.0 beta 5 tomorrow based on the new implementation.
>>
>> As before feedback welcome and thanks again to John David Galts ideas I
>> have based my implementation on.
>>
>> Stefan
>>
>>
>> On 08/23/2015 04:37 PM, Stefan Frey wrote:
>>> John:
>>> I really like your suggestion. I think it is a good way to handle those
>>> cases in a rigorous way. In addition it is fully compatible with the
>>> standard way of how standard 18xx treat the change of director in such
>>> cases.
>>>
>>> I adapted your proposal to include that it is not allowed to sell
>>> multiple certificates such that you are able to get a nominal share in
>>> exchange, which Volker and Erik referred to.
>>>
>>> However it is still possible for the director share, which I believe is
>>> important. (The second edition of the German rules claim that this is
>>> not possible, however I do not agree with that ruling).
>>>
>>> And Dave is fully right, game rules are not written as algorithms. It is
>>> our task to transform those rules into an algorithm which most people
>>> can agree on that the algorithm is a good representation of the game rules.
>>>
>>> So my proposed algorithm (based on John David Galts suggestion) is found
>>> below.
>>>
>>> Again feedback is very welcome.
>>>
>>> Stefan
>>>
>>>
>>> * Algorithm for Change of Director after Sale of Stock:
>>>
>>> ** Definitions:
>>>
>>> Share nominal n%
>>>
>>> Nominal (n) certificate 1 times n%
>>> Director (d) certificate has d times n%
>>> Multiple (m) certificate has m times n%
>>>
>>> Director X  has x times n% of stock
>>> Potential director Y has y times n% of stock
>>>
>>> Pool P has p times n% of stock
>>> Pool limit p_max times n%
>>>
>>> ** Steps:
>>>
>>> 1. Director can trigger change of director if he sells s >= (x-y) + 1
>>>
>>> 2. Only allowed if (s + p) <= p_max
>>>
>>> 3. Director puts d and other certificates (total o) into the pool, such
>>> that (d + o) >= s. Choose o such that o is minimal.
>>>
>>> 4. Potential (new) director exchanges certificates (of his choice, but
>>> see below) of total size e = d with the pool for the director certificate
>>>
>>> 5. (Old) director receives [(d+o) - s] (of his choice) from the pool, if
>>> this is not possible the previous step is repeated with a different
>>> choice until the old director receives the required amount of shares
>>>
>>> 6. If the last step cannot be executed in any way, selling s is not possible
>>>
>>> ** Remarks:
>>> - The program only offers choices in step 4 that allow step 5/6 to be
>>> succesfull
>>> - The program only offers transaction of size s that can be executed
>>>
>>> ** Examples:
>>>
>>> A) 1830 standard case
>>>
>>> Nominal certificate 10%
>>> Director certificate d=2 20% share
>>>
>>> X has 40%, x = 4 [d, 2*n]
>>> Y has 30%, y = 3 [3*n]
>>>
>>> Pool has 30%, p = 3
>>>
>>> Director sells 20%  (s=2)
>>>
>>> 1. Yes: s= 2;  (x-y) + 1 = (4- 3) + 1 = 2
>>>
>>> 2. Yes: s + p = 2 + 3 <= 5 = p_max
>>>
>>> 3. Director puts the director certificate, but no other into the pool (o
>>> = 0). (d + o) =  2 >= 2, minimal o
>>>
>>> 4. Potential director exchanges 2 10% shares with the pool
>>>
>>> 5. Old director gets nothing in return, transaction finished
>>>
>>> B) 1830 selling the director partially
>>>
>>> Certificates as above in A)
>>>
>>> X has 20%, x = 2 [d]
>>> Y has 20%, y = 2 [2*n]
>>>
>>> Pool is empty, p = 0
>>>
>>> Director sells 10%  (s=1)
>>>
>>> 1. Yes: s = 1; (x - y) + 1 = 1
>>>
>>> 2. Yes: s + p = 1 + 0  <= 5 = p_max
>>>
>>> 3. Director puts the director certificate, but no other into the pool (o
>>> = 0) d + o = 2 >= 1, minimal o
>>>
>>> 4. Potential director exchanges 2 10% shares with the pool
>>>
>>> 5. Old director receives 1 10% share from the pool
>>>
>>> C) 1835 case
>>>
>>> Nominal certificate 10%
>>> Director certificate d=2 20% share
>>> Multiple certificate m=2 20% share
>>>
>>> X has 50%, x = 5 [d, m, n]
>>> Y has 40%, y = 4 [m, 2*n]
>>>
>>> Pool is empty, p = 0
>>>
>>> Director sells 30% (s=3)
>>>
>>> 1. Yes
>>> 2. Yes
>>> 3. Director puts director certificate d the pool and a 10% share. It is
>>> not allowed to choose the 20% share here, as o has to be chosen to be
>>> minimal
>>> 4. Potential director chooses to exchange the director certificate from
>>> the pool with either the multiple certificate m or the two nominal
>>> certificates
>>> 5. Old director gets nothing in return, transaction is finished
>>>
>>> D) Another 1835 case
>>>
>>> Certificates as above in C)
>>>
>>> X has 40%, x = 4 [d, m]
>>> Y has 40%, y = 4 [m, 2*n]
>>>
>>> Pool is empty, p = 0
>>>
>>> Director sells 10% (s=1)
>>>
>>> 1. Yes
>>> 2. Yes
>>> 3. Director puts director certificate d the pool, but no other
>>> 4. Potential director can only exchange the 2 nominal certificates, as
>>> otherwise the director cannot receive the 10% share in step 5. If Pool
>>> contains a nominal certificate it is his choice
>>> 5. Old director receives 1 10% share from the pool
>>>
>>> On 08/21/2015 11:59 PM, John David Galt wrote:
>>>> Please use this version, I hit send too soon.
>>>>
>>>> On 2015-08-21 13:18, Stefan Frey wrote:
>>>>> Another 1835 implementation issue:
>>>>>
>>>>> President swaps are not easy to understand for newbies in any 18xx (you
>>>>> are not allowed to sell the president share, however you are allowed to
>>>>> tear it apart, virtually sell one half of it to the pool and then
>>>>> receive two shares by the new director, who gets the fixed director
>>>>> certificate, then the old director puts one of received shares into the
>>>>> pool and keeps the other).
>>>>>
>>>>> In 1835 the 20% shares make selling the presidency even more interesting.
>>>>>
>>>>> Selling the president certificate involves two steps of share movements:
>>>>>
>>>>> A) Exchange the president certificate with shares from the new president
>>>>>
>>>>> B) Move the remaining sold shares into the pool
>>>> I do not agree that these are separate steps.
>>>>
>>>>> In 1835 both steps could include either 10% or 20% shares (PR: 5% or 10%
>>>>> shares)
>>>>>
>>>>> Depending on what the president received in A) this might even change
>>>>> the possible options for B.
>>>>>
>>>>> However it implies that the current president has to choose both A)
>>>>> which certificate to exchange with the new president and B) which
>>>>> certificate to put into the pool.
>>>>>
>>>>> The current implementation only asks for A) and has some serious bugs in
>>>>> executing the share transfers.
>>>>>
>>>>> I intend to fix those bugs before the next release, however I would ask
>>>>> if anyone has a different opinion on how it works for 1835?
>>>> I have not seen any case in which the current program gets it wrong (in
>>>> my view) -- however, I have not exhaustively tried every single case.
>>>>
>>>> The following is the exact sequence of events I expect to happen in any
>>>> purchase or sale of stock (after any starting packet).  This applies to
>>>> all games, not just 1835.
>>>>
>>>> In a purchase of stock:
>>>>
>>>> (1) The player buys a certificate, not share(s).
>>>>
>>>> (2) If the purchase causes a change of president, then the new president
>>>> exchanges one or more certificates (totaling the same number of shares
>>>> of that company) for the president's certificate, wherever it is.  (This
>>>> is a direct exchange between two players, unless the president's
>>>> certificate is in the bank pool, as it might be in 1829 (receivership)
>>>> or 1853v1 (when the company hasn't floated yet).)
>>>>
>>>> (In 1835, if there is a choice, the outgoing president chooses which
>>>> certificate(s) he receives from among those in the new president's hand.
>>>>      I would follow this principle in any other game where any company has
>>>> non-presidential certificates of more than one size, if the rules do not
>>>> address the question.)
>>>>
>>>> In a sale of stock:
>>>>
>>>> (1) A sale that is going to cause a change of president may only be made
>>>> if some other player holds at least the number of shares that the
>>>> president's certificate contains.
>>>>
>>>> (2) Except for the special case given in point (5), the player sells
>>>> certificate(s), not share(s).
>>>>
>>>> (3) If the sale will cause a change of president, then one of the
>>>> certificate(s) sold must be the president's certificate.  Otherwise the
>>>> seller must retain the president's certificate.
>>>>
>>>> (4) If the sale causes a change of presidency, then the new president
>>>> exchanges one or more certificates (totaling the same number of shares
>>>> of that company) for the president's certificate in the bank pool.  (The
>>>> outgoing president does not participate in this swap and does not have
>>>> any right to claim a certificate from the new president's hand.)
>>>>
>>>> (5) A special case is where a player who holds only certificate(s) of
>>>> two or more shares each in that company wishes to sell a number or
>>>> shares that is not divisible by one of his certificates.  (For this
>>>> purpose "one share" is defined as the amount of the smallest certificate
>>>> that exists for that company.)
>>>>
>>>> In this case the "fractional sale" may only be made if one of the
>>>> following is true in addition to point (1):
>>>>
>>>>        A: The bank pool contains certificate(s) of the company in the right
>>>> sizes such that the seller can be given the correct number of shares
>>>> from the bank pool.  In this case the seller exchanges certificates with
>>>> the bank pool, and then point (4) applies.
>>>>
>>>>        B: Statement A above is not true, but, the sale will cause a change
>>>> of presidency, and the bank pool and the old and new presidents' hands
>>>> together contain enough certificates of the company to give both the old
>>>> and new presidents the correct numbers of shares, with the new president
>>>> holding the president's certificate.  In this case a three-way swap of
>>>> certificates is performed.  If there is more than one correct way to
>>>> perform the swap, first the outgoing president chooses which
>>>> certificate(s) he gives up; then the new president chooses which
>>>> certificate(s) he gives up.
>>>>
>>>>> Example:
>>>>>
>>>>> In the attached save file OL has the following share distribution:
>>>>>
>>>>> (Remark: this is from a replay of one of Bill Stoll's 1835 pbem games -
>>>>> see http://askwaltstollmd.com/bill/archive/1835zwolf/index.html
>>>>> Fun fact is that I played 1835 ftf with one of the players before he
>>>>> moved to the US)
>>>>>
>>>>> Eyal: 50% (1 20% director, 1 20% share, 1 10% share)
>>>>> Marco: 40% (1 20% share, 2 10% share)
>>>>> Nick: 10% (1 10% share)
>>>>>
>>>>> What are the possible scenarios for Eyal to sell his directorship?
>>>> If Eyal sells 10% (which does not change the presidency), he just moves
>>>> his 10% certificate to the bank pool.  Done.
>>>>
>>>> If Eyal sells 20%, he moves the president's certificate to the bank
>>>> pool.  Then Marco takes it and chooses 20% (either one 20% or two 10%
>>>> certificates) to place in the bank pool.
>>>>
>>>> If Eyal sells 30%, he moves the president's certificate and the 10%
>>>> certificate to the bank pool.  Then Marco takes the president's
>>>> certificate and chooses 20% (either one 20% or two 10% certificates) to
>>>> place in the bank pool.
>>>>
>>>> If Eyal sells 40%, he moves the president's certificate and the 20%
>>>> certificate to the bank pool.  Then Marco takes the president's
>>>> certificate and chooses 20% (either one 20% or two 10% certificates) to
>>>> place in the bank pool.
>>>>
>>>> If Eyal sells 50%, he moves all three of his certificates to the bank
>>>> pool.  Then Marco takes the president's certificate and chooses 20%
>>>> (either one 20% or two 10% certificates) to place in the bank pool.
>>>>
>>>> [snip]
>>>>> Some special (hypothetical) cases:
>>>>>
>>>>> A) No shares in Pool
>>>>>
>>>>> Eyal: 40% (20%P + 20%)
>>>>> Marco: 20% (20%)
>>>>>
>>>>> IPO: 40% (4 10%)
>>>>>
>>>>> Is it possible for Eyal to sell 30%?
>>>>> Answer: No, as it not possible to get a 10% share out of IPO to Eyal.
>>>>> Eyal has to sell all 40%.
>>>> Agreed.
>>>>
>>>>> B) 10% shares in Pool
>>>>>
>>>>> Eyal: 40% (20%P + 20%)
>>>>> Marco: 20% (20%)
>>>>>
>>>>> Pool: 40% (4 10%)
>>>>>
>>>>> Is it possible for Eyal to sell 30%?
>>>>> Answer: Likely yes? Is it possible for Eyal to swap the received 20%
>>>>> share from Marco with a 10% of the Pool?
>>>> In most games (and I think this includes 1835), Eyal is prevented from
>>>> selling 30% because this would cause 70% to be in the bank pool.
>>>>
>>>> But let's change the example by having the pool hold two 10%
>>>> certificates and a third player hold the other two.  Then Eyal may sell
>>>> 30% by placing both his certificates in the bank pool and taking a 10%
>>>> certificate from the bank pool.  Marco must then trade his 20%
>>>> certificate for the president's certificate.
>>>>
>>>> Eyal may also sell 10%.  In this case he just places his 20%
>>>> non-president certificate in the bank pool and takes a 10% certificate.
>>>>
>>>> -end-
>>>>
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> Rails-devel mailing list
>>>> Rai...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 1835 presidency swap: Bug fix required (typos corrected)

[Schnell, V. <vol...@ar...>]

Hi Stefan,

I don't agree with your opinion, that the exchange of the directors 
certificate works with the bank pool.
in all 18xx games, except with receivership like 1829, 1853, the 
certificates are exchanged between players.
The Change of director is also possible, when buying shares.

1835 cases.

Nominal certificate 10%
Director certificate d=2 20% share
Multiple certificate m=2 20% share

X has 40%, x = 4 [d, n, n]
Y has 40%, y = 4 [m, 2*n]

X sells one share, the old director decides about the make up of the percentages (english rules IV.3 last sentence), he receives 1m or 2n from Y.

Same situation but Y buys n, he has now 50% and receives the directors certificate (d). the new director now hands 1m or 2n to the old director, while the old directer decides about the make up.

Greetings
Volker
Am 28.08.2015 um 22:47 schrieb Stefan Frey:
> Follow-up to my proposal below:
>
> * Remark first: "Certificate" versus "Share"
>
> To be precise I use "certificate" to the physical representation of
> shares in 18xx. I use "share" is the smallest unit of the division of
> the share capital in 18xx.
>
> So the president certificate in 1830 represents 2 shares, the other
> certificates are single shares. Each share represents 10% of share capital.
>
> In 1835 the companies of the second group (BA, WT, HE) feature a
> double-share certificate at the bottom of their IPO stack.
>
> The new mechanism is implemented now. As far as it possible and/or
> technical feasible at the moment.
>
> * What are the current limitations on selling shares/certificates?
>
> - Selling certificates can only be done in groups that represent the
> same number of shares.
>
> - As the president certificate can be sold in "parts" (and the old
> president receives Pool certificates in return), it belongs to the
> single share group.
>
> Example: In some cases in 1835 the double share certificates have to be
> sold before it is possible to dump the president.
>
> - Exchanges to the Pool for the new president are executed by returning
> certificates which represent minimal shares. Thus the new president
> prefers to give up two single share certificates instead of one double
> shares certificate.
>
> * What is the long-run target?
>
> Players first select what percentage they want to sell. For Example:
> "40% of BY". If there are several combinations of certificates that
> allow 40% the next step allows to select which certificates to sell.
>
> If the new president has choices what to return to the Pool in exchange
> for the president certificate he is asked to choose.
>
>
> * Reason for this limitation:
> I am reluctant to change the action definitions of selling shares just
> before the Rails 2.0 release.
>
> However behind the scene the code has been changed substantially and is
> already based on the long-run goals.
>
> The automated test games run again and I have added a few new specific
> test cases. However I am still a little bit reluctant and will release a
> new Rails 2.0 beta 5 tomorrow based on the new implementation.
>
> As before feedback welcome and thanks again to John David Galts ideas I
> have based my implementation on.
>
> Stefan
>
>
> On 08/23/2015 04:37 PM, Stefan Frey wrote:
>> John:
>> I really like your suggestion. I think it is a good way to handle those
>> cases in a rigorous way. In addition it is fully compatible with the
>> standard way of how standard 18xx treat the change of director in such
>> cases.
>>
>> I adapted your proposal to include that it is not allowed to sell
>> multiple certificates such that you are able to get a nominal share in
>> exchange, which Volker and Erik referred to.
>>
>> However it is still possible for the director share, which I believe is
>> important. (The second edition of the German rules claim that this is
>> not possible, however I do not agree with that ruling).
>>
>> And Dave is fully right, game rules are not written as algorithms. It is
>> our task to transform those rules into an algorithm which most people
>> can agree on that the algorithm is a good representation of the game rules.
>>
>> So my proposed algorithm (based on John David Galts suggestion) is found
>> below.
>>
>> Again feedback is very welcome.
>>
>> Stefan
>>
>>
>> * Algorithm for Change of Director after Sale of Stock:
>>
>> ** Definitions:
>>
>> Share nominal n%
>>
>> Nominal (n) certificate 1 times n%
>> Director (d) certificate has d times n%
>> Multiple (m) certificate has m times n%
>>
>> Director X  has x times n% of stock
>> Potential director Y has y times n% of stock
>>
>> Pool P has p times n% of stock
>> Pool limit p_max times n%
>>
>> ** Steps:
>>
>> 1. Director can trigger change of director if he sells s >= (x-y) + 1
>>
>> 2. Only allowed if (s + p) <= p_max
>>
>> 3. Director puts d and other certificates (total o) into the pool, such
>> that (d + o) >= s. Choose o such that o is minimal.
>>
>> 4. Potential (new) director exchanges certificates (of his choice, but
>> see below) of total size e = d with the pool for the director certificate
>>
>> 5. (Old) director receives [(d+o) - s] (of his choice) from the pool, if
>> this is not possible the previous step is repeated with a different
>> choice until the old director receives the required amount of shares
>>
>> 6. If the last step cannot be executed in any way, selling s is not possible
>>
>> ** Remarks:
>> - The program only offers choices in step 4 that allow step 5/6 to be
>> succesfull
>> - The program only offers transaction of size s that can be executed
>>
>> ** Examples:
>>
>> A) 1830 standard case
>>
>> Nominal certificate 10%
>> Director certificate d=2 20% share
>>
>> X has 40%, x = 4 [d, 2*n]
>> Y has 30%, y = 3 [3*n]
>>
>> Pool has 30%, p = 3
>>
>> Director sells 20%  (s=2)
>>
>> 1. Yes: s= 2;  (x-y) + 1 = (4- 3) + 1 = 2
>>
>> 2. Yes: s + p = 2 + 3 <= 5 = p_max
>>
>> 3. Director puts the director certificate, but no other into the pool (o
>> = 0). (d + o) =  2 >= 2, minimal o
>>
>> 4. Potential director exchanges 2 10% shares with the pool
>>
>> 5. Old director gets nothing in return, transaction finished
>>
>> B) 1830 selling the director partially
>>
>> Certificates as above in A)
>>
>> X has 20%, x = 2 [d]
>> Y has 20%, y = 2 [2*n]
>>
>> Pool is empty, p = 0
>>
>> Director sells 10%  (s=1)
>>
>> 1. Yes: s = 1; (x - y) + 1 = 1
>>
>> 2. Yes: s + p = 1 + 0  <= 5 = p_max
>>
>> 3. Director puts the director certificate, but no other into the pool (o
>> = 0) d + o = 2 >= 1, minimal o
>>
>> 4. Potential director exchanges 2 10% shares with the pool
>>
>> 5. Old director receives 1 10% share from the pool
>>
>> C) 1835 case
>>
>> Nominal certificate 10%
>> Director certificate d=2 20% share
>> Multiple certificate m=2 20% share
>>
>> X has 50%, x = 5 [d, m, n]
>> Y has 40%, y = 4 [m, 2*n]
>>
>> Pool is empty, p = 0
>>
>> Director sells 30% (s=3)
>>
>> 1. Yes
>> 2. Yes
>> 3. Director puts director certificate d the pool and a 10% share. It is
>> not allowed to choose the 20% share here, as o has to be chosen to be
>> minimal
>> 4. Potential director chooses to exchange the director certificate from
>> the pool with either the multiple certificate m or the two nominal
>> certificates
>> 5. Old director gets nothing in return, transaction is finished
>>
>> D) Another 1835 case
>>
>> Certificates as above in C)
>>
>> X has 40%, x = 4 [d, m]
>> Y has 40%, y = 4 [m, 2*n]
>>
>> Pool is empty, p = 0
>>
>> Director sells 10% (s=1)
>>
>> 1. Yes
>> 2. Yes
>> 3. Director puts director certificate d the pool, but no other
>> 4. Potential director can only exchange the 2 nominal certificates, as
>> otherwise the director cannot receive the 10% share in step 5. If Pool
>> contains a nominal certificate it is his choice
>> 5. Old director receives 1 10% share from the pool
>>
>> On 08/21/2015 11:59 PM, John David Galt wrote:
>>> Please use this version, I hit send too soon.
>>>
>>> On 2015-08-21 13:18, Stefan Frey wrote:
>>>> Another 1835 implementation issue:
>>>>
>>>> President swaps are not easy to understand for newbies in any 18xx (you
>>>> are not allowed to sell the president share, however you are allowed to
>>>> tear it apart, virtually sell one half of it to the pool and then
>>>> receive two shares by the new director, who gets the fixed director
>>>> certificate, then the old director puts one of received shares into the
>>>> pool and keeps the other).
>>>>
>>>> In 1835 the 20% shares make selling the presidency even more interesting.
>>>>
>>>> Selling the president certificate involves two steps of share movements:
>>>>
>>>> A) Exchange the president certificate with shares from the new president
>>>>
>>>> B) Move the remaining sold shares into the pool
>>> I do not agree that these are separate steps.
>>>
>>>> In 1835 both steps could include either 10% or 20% shares (PR: 5% or 10%
>>>> shares)
>>>>
>>>> Depending on what the president received in A) this might even change
>>>> the possible options for B.
>>>>
>>>> However it implies that the current president has to choose both A)
>>>> which certificate to exchange with the new president and B) which
>>>> certificate to put into the pool.
>>>>
>>>> The current implementation only asks for A) and has some serious bugs in
>>>> executing the share transfers.
>>>>
>>>> I intend to fix those bugs before the next release, however I would ask
>>>> if anyone has a different opinion on how it works for 1835?
>>> I have not seen any case in which the current program gets it wrong (in
>>> my view) -- however, I have not exhaustively tried every single case.
>>>
>>> The following is the exact sequence of events I expect to happen in any
>>> purchase or sale of stock (after any starting packet).  This applies to
>>> all games, not just 1835.
>>>
>>> In a purchase of stock:
>>>
>>> (1) The player buys a certificate, not share(s).
>>>
>>> (2) If the purchase causes a change of president, then the new president
>>> exchanges one or more certificates (totaling the same number of shares
>>> of that company) for the president's certificate, wherever it is.  (This
>>> is a direct exchange between two players, unless the president's
>>> certificate is in the bank pool, as it might be in 1829 (receivership)
>>> or 1853v1 (when the company hasn't floated yet).)
>>>
>>> (In 1835, if there is a choice, the outgoing president chooses which
>>> certificate(s) he receives from among those in the new president's hand.
>>>     I would follow this principle in any other game where any company has
>>> non-presidential certificates of more than one size, if the rules do not
>>> address the question.)
>>>
>>> In a sale of stock:
>>>
>>> (1) A sale that is going to cause a change of president may only be made
>>> if some other player holds at least the number of shares that the
>>> president's certificate contains.
>>>
>>> (2) Except for the special case given in point (5), the player sells
>>> certificate(s), not share(s).
>>>
>>> (3) If the sale will cause a change of president, then one of the
>>> certificate(s) sold must be the president's certificate.  Otherwise the
>>> seller must retain the president's certificate.
>>>
>>> (4) If the sale causes a change of presidency, then the new president
>>> exchanges one or more certificates (totaling the same number of shares
>>> of that company) for the president's certificate in the bank pool.  (The
>>> outgoing president does not participate in this swap and does not have
>>> any right to claim a certificate from the new president's hand.)
>>>
>>> (5) A special case is where a player who holds only certificate(s) of
>>> two or more shares each in that company wishes to sell a number or
>>> shares that is not divisible by one of his certificates.  (For this
>>> purpose "one share" is defined as the amount of the smallest certificate
>>> that exists for that company.)
>>>
>>> In this case the "fractional sale" may only be made if one of the
>>> following is true in addition to point (1):
>>>
>>>       A: The bank pool contains certificate(s) of the company in the right
>>> sizes such that the seller can be given the correct number of shares
>>> from the bank pool.  In this case the seller exchanges certificates with
>>> the bank pool, and then point (4) applies.
>>>
>>>       B: Statement A above is not true, but, the sale will cause a change
>>> of presidency, and the bank pool and the old and new presidents' hands
>>> together contain enough certificates of the company to give both the old
>>> and new presidents the correct numbers of shares, with the new president
>>> holding the president's certificate.  In this case a three-way swap of
>>> certificates is performed.  If there is more than one correct way to
>>> perform the swap, first the outgoing president chooses which
>>> certificate(s) he gives up; then the new president chooses which
>>> certificate(s) he gives up.
>>>
>>>> Example:
>>>>
>>>> In the attached save file OL has the following share distribution:
>>>>
>>>> (Remark: this is from a replay of one of Bill Stoll's 1835 pbem games -
>>>> see http://askwaltstollmd.com/bill/archive/1835zwolf/index.html
>>>> Fun fact is that I played 1835 ftf with one of the players before he
>>>> moved to the US)
>>>>
>>>> Eyal: 50% (1 20% director, 1 20% share, 1 10% share)
>>>> Marco: 40% (1 20% share, 2 10% share)
>>>> Nick: 10% (1 10% share)
>>>>
>>>> What are the possible scenarios for Eyal to sell his directorship?
>>> If Eyal sells 10% (which does not change the presidency), he just moves
>>> his 10% certificate to the bank pool.  Done.
>>>
>>> If Eyal sells 20%, he moves the president's certificate to the bank
>>> pool.  Then Marco takes it and chooses 20% (either one 20% or two 10%
>>> certificates) to place in the bank pool.
>>>
>>> If Eyal sells 30%, he moves the president's certificate and the 10%
>>> certificate to the bank pool.  Then Marco takes the president's
>>> certificate and chooses 20% (either one 20% or two 10% certificates) to
>>> place in the bank pool.
>>>
>>> If Eyal sells 40%, he moves the president's certificate and the 20%
>>> certificate to the bank pool.  Then Marco takes the president's
>>> certificate and chooses 20% (either one 20% or two 10% certificates) to
>>> place in the bank pool.
>>>
>>> If Eyal sells 50%, he moves all three of his certificates to the bank
>>> pool.  Then Marco takes the president's certificate and chooses 20%
>>> (either one 20% or two 10% certificates) to place in the bank pool.
>>>
>>> [snip]
>>>> Some special (hypothetical) cases:
>>>>
>>>> A) No shares in Pool
>>>>
>>>> Eyal: 40% (20%P + 20%)
>>>> Marco: 20% (20%)
>>>>
>>>> IPO: 40% (4 10%)
>>>>
>>>> Is it possible for Eyal to sell 30%?
>>>> Answer: No, as it not possible to get a 10% share out of IPO to Eyal.
>>>> Eyal has to sell all 40%.
>>> Agreed.
>>>
>>>> B) 10% shares in Pool
>>>>
>>>> Eyal: 40% (20%P + 20%)
>>>> Marco: 20% (20%)
>>>>
>>>> Pool: 40% (4 10%)
>>>>
>>>> Is it possible for Eyal to sell 30%?
>>>> Answer: Likely yes? Is it possible for Eyal to swap the received 20%
>>>> share from Marco with a 10% of the Pool?
>>> In most games (and I think this includes 1835), Eyal is prevented from
>>> selling 30% because this would cause 70% to be in the bank pool.
>>>
>>> But let's change the example by having the pool hold two 10%
>>> certificates and a third player hold the other two.  Then Eyal may sell
>>> 30% by placing both his certificates in the bank pool and taking a 10%
>>> certificate from the bank pool.  Marco must then trade his 20%
>>> certificate for the president's certificate.
>>>
>>> Eyal may also sell 10%.  In this case he just places his 20%
>>> non-president certificate in the bank pool and takes a 10% certificate.
>>>
>>> -end-
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

-- 
Volker Schnell
email: vol...@ar...
homepage: home.arcor.de\volker_schnell

Re: [Rails-devel] 1835 presidency swap: Bug fix required (typos corrected)

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

Follow-up to my proposal below:

* Remark first: "Certificate" versus "Share"

To be precise I use "certificate" to the physical representation of 
shares in 18xx. I use "share" is the smallest unit of the division of 
the share capital in 18xx.

So the president certificate in 1830 represents 2 shares, the other 
certificates are single shares. Each share represents 10% of share capital.

In 1835 the companies of the second group (BA, WT, HE) feature a 
double-share certificate at the bottom of their IPO stack.

The new mechanism is implemented now. As far as it possible and/or 
technical feasible at the moment.

* What are the current limitations on selling shares/certificates?

- Selling certificates can only be done in groups that represent the 
same number of shares.

- As the president certificate can be sold in "parts" (and the old 
president receives Pool certificates in return), it belongs to the 
single share group.

Example: In some cases in 1835 the double share certificates have to be 
sold before it is possible to dump the president.

- Exchanges to the Pool for the new president are executed by returning 
certificates which represent minimal shares. Thus the new president 
prefers to give up two single share certificates instead of one double 
shares certificate.

* What is the long-run target?

Players first select what percentage they want to sell. For Example: 
"40% of BY". If there are several combinations of certificates that 
allow 40% the next step allows to select which certificates to sell.

If the new president has choices what to return to the Pool in exchange 
for the president certificate he is asked to choose.


* Reason for this limitation:
I am reluctant to change the action definitions of selling shares just 
before the Rails 2.0 release.

However behind the scene the code has been changed substantially and is 
already based on the long-run goals.

The automated test games run again and I have added a few new specific 
test cases. However I am still a little bit reluctant and will release a 
new Rails 2.0 beta 5 tomorrow based on the new implementation.

As before feedback welcome and thanks again to John David Galts ideas I 
have based my implementation on.

Stefan


On 08/23/2015 04:37 PM, Stefan Frey wrote:
> John:
> I really like your suggestion. I think it is a good way to handle those
> cases in a rigorous way. In addition it is fully compatible with the
> standard way of how standard 18xx treat the change of director in such
> cases.
>
> I adapted your proposal to include that it is not allowed to sell
> multiple certificates such that you are able to get a nominal share in
> exchange, which Volker and Erik referred to.
>
> However it is still possible for the director share, which I believe is
> important. (The second edition of the German rules claim that this is
> not possible, however I do not agree with that ruling).
>
> And Dave is fully right, game rules are not written as algorithms. It is
> our task to transform those rules into an algorithm which most people
> can agree on that the algorithm is a good representation of the game rules.
>
> So my proposed algorithm (based on John David Galts suggestion) is found
> below.
>
> Again feedback is very welcome.
>
> Stefan
>
>
> * Algorithm for Change of Director after Sale of Stock:
>
> ** Definitions:
>
> Share nominal n%
>
> Nominal (n) certificate 1 times n%
> Director (d) certificate has d times n%
> Multiple (m) certificate has m times n%
>
> Director X  has x times n% of stock
> Potential director Y has y times n% of stock
>
> Pool P has p times n% of stock
> Pool limit p_max times n%
>
> ** Steps:
>
> 1. Director can trigger change of director if he sells s >= (x-y) + 1
>
> 2. Only allowed if (s + p) <= p_max
>
> 3. Director puts d and other certificates (total o) into the pool, such
> that (d + o) >= s. Choose o such that o is minimal.
>
> 4. Potential (new) director exchanges certificates (of his choice, but
> see below) of total size e = d with the pool for the director certificate
>
> 5. (Old) director receives [(d+o) - s] (of his choice) from the pool, if
> this is not possible the previous step is repeated with a different
> choice until the old director receives the required amount of shares
>
> 6. If the last step cannot be executed in any way, selling s is not possible
>
> ** Remarks:
> - The program only offers choices in step 4 that allow step 5/6 to be
> succesfull
> - The program only offers transaction of size s that can be executed
>
> ** Examples:
>
> A) 1830 standard case
>
> Nominal certificate 10%
> Director certificate d=2 20% share
>
> X has 40%, x = 4 [d, 2*n]
> Y has 30%, y = 3 [3*n]
>
> Pool has 30%, p = 3
>
> Director sells 20%  (s=2)
>
> 1. Yes: s= 2;  (x-y) + 1 = (4- 3) + 1 = 2
>
> 2. Yes: s + p = 2 + 3 <= 5 = p_max
>
> 3. Director puts the director certificate, but no other into the pool (o
> = 0). (d + o) =  2 >= 2, minimal o
>
> 4. Potential director exchanges 2 10% shares with the pool
>
> 5. Old director gets nothing in return, transaction finished
>
> B) 1830 selling the director partially
>
> Certificates as above in A)
>
> X has 20%, x = 2 [d]
> Y has 20%, y = 2 [2*n]
>
> Pool is empty, p = 0
>
> Director sells 10%  (s=1)
>
> 1. Yes: s = 1; (x - y) + 1 = 1
>
> 2. Yes: s + p = 1 + 0  <= 5 = p_max
>
> 3. Director puts the director certificate, but no other into the pool (o
> = 0) d + o = 2 >= 1, minimal o
>
> 4. Potential director exchanges 2 10% shares with the pool
>
> 5. Old director receives 1 10% share from the pool
>
> C) 1835 case
>
> Nominal certificate 10%
> Director certificate d=2 20% share
> Multiple certificate m=2 20% share
>
> X has 50%, x = 5 [d, m, n]
> Y has 40%, y = 4 [m, 2*n]
>
> Pool is empty, p = 0
>
> Director sells 30% (s=3)
>
> 1. Yes
> 2. Yes
> 3. Director puts director certificate d the pool and a 10% share. It is
> not allowed to choose the 20% share here, as o has to be chosen to be
> minimal
> 4. Potential director chooses to exchange the director certificate from
> the pool with either the multiple certificate m or the two nominal
> certificates
> 5. Old director gets nothing in return, transaction is finished
>
> D) Another 1835 case
>
> Certificates as above in C)
>
> X has 40%, x = 4 [d, m]
> Y has 40%, y = 4 [m, 2*n]
>
> Pool is empty, p = 0
>
> Director sells 10% (s=1)
>
> 1. Yes
> 2. Yes
> 3. Director puts director certificate d the pool, but no other
> 4. Potential director can only exchange the 2 nominal certificates, as
> otherwise the director cannot receive the 10% share in step 5. If Pool
> contains a nominal certificate it is his choice
> 5. Old director receives 1 10% share from the pool
>
> On 08/21/2015 11:59 PM, John David Galt wrote:
>> Please use this version, I hit send too soon.
>>
>> On 2015-08-21 13:18, Stefan Frey wrote:
>>> Another 1835 implementation issue:
>>>
>>> President swaps are not easy to understand for newbies in any 18xx (you
>>> are not allowed to sell the president share, however you are allowed to
>>> tear it apart, virtually sell one half of it to the pool and then
>>> receive two shares by the new director, who gets the fixed director
>>> certificate, then the old director puts one of received shares into the
>>> pool and keeps the other).
>>>
>>> In 1835 the 20% shares make selling the presidency even more interesting.
>>>
>>> Selling the president certificate involves two steps of share movements:
>>>
>>> A) Exchange the president certificate with shares from the new president
>>>
>>> B) Move the remaining sold shares into the pool
>>
>> I do not agree that these are separate steps.
>>
>>> In 1835 both steps could include either 10% or 20% shares (PR: 5% or 10%
>>> shares)
>>>
>>> Depending on what the president received in A) this might even change
>>> the possible options for B.
>>>
>>> However it implies that the current president has to choose both A)
>>> which certificate to exchange with the new president and B) which
>>> certificate to put into the pool.
>>>
>>> The current implementation only asks for A) and has some serious bugs in
>>> executing the share transfers.
>>>
>>> I intend to fix those bugs before the next release, however I would ask
>>> if anyone has a different opinion on how it works for 1835?
>>
>> I have not seen any case in which the current program gets it wrong (in
>> my view) -- however, I have not exhaustively tried every single case.
>>
>> The following is the exact sequence of events I expect to happen in any
>> purchase or sale of stock (after any starting packet).  This applies to
>> all games, not just 1835.
>>
>> In a purchase of stock:
>>
>> (1) The player buys a certificate, not share(s).
>>
>> (2) If the purchase causes a change of president, then the new president
>> exchanges one or more certificates (totaling the same number of shares
>> of that company) for the president's certificate, wherever it is.  (This
>> is a direct exchange between two players, unless the president's
>> certificate is in the bank pool, as it might be in 1829 (receivership)
>> or 1853v1 (when the company hasn't floated yet).)
>>
>> (In 1835, if there is a choice, the outgoing president chooses which
>> certificate(s) he receives from among those in the new president's hand.
>>    I would follow this principle in any other game where any company has
>> non-presidential certificates of more than one size, if the rules do not
>> address the question.)
>>
>> In a sale of stock:
>>
>> (1) A sale that is going to cause a change of president may only be made
>> if some other player holds at least the number of shares that the
>> president's certificate contains.
>>
>> (2) Except for the special case given in point (5), the player sells
>> certificate(s), not share(s).
>>
>> (3) If the sale will cause a change of president, then one of the
>> certificate(s) sold must be the president's certificate.  Otherwise the
>> seller must retain the president's certificate.
>>
>> (4) If the sale causes a change of presidency, then the new president
>> exchanges one or more certificates (totaling the same number of shares
>> of that company) for the president's certificate in the bank pool.  (The
>> outgoing president does not participate in this swap and does not have
>> any right to claim a certificate from the new president's hand.)
>>
>> (5) A special case is where a player who holds only certificate(s) of
>> two or more shares each in that company wishes to sell a number or
>> shares that is not divisible by one of his certificates.  (For this
>> purpose "one share" is defined as the amount of the smallest certificate
>> that exists for that company.)
>>
>> In this case the "fractional sale" may only be made if one of the
>> following is true in addition to point (1):
>>
>>      A: The bank pool contains certificate(s) of the company in the right
>> sizes such that the seller can be given the correct number of shares
>> from the bank pool.  In this case the seller exchanges certificates with
>> the bank pool, and then point (4) applies.
>>
>>      B: Statement A above is not true, but, the sale will cause a change
>> of presidency, and the bank pool and the old and new presidents' hands
>> together contain enough certificates of the company to give both the old
>> and new presidents the correct numbers of shares, with the new president
>> holding the president's certificate.  In this case a three-way swap of
>> certificates is performed.  If there is more than one correct way to
>> perform the swap, first the outgoing president chooses which
>> certificate(s) he gives up; then the new president chooses which
>> certificate(s) he gives up.
>>
>>> Example:
>>>
>>> In the attached save file OL has the following share distribution:
>>>
>>> (Remark: this is from a replay of one of Bill Stoll's 1835 pbem games -
>>> see http://askwaltstollmd.com/bill/archive/1835zwolf/index.html
>>> Fun fact is that I played 1835 ftf with one of the players before he
>>> moved to the US)
>>>
>>> Eyal: 50% (1 20% director, 1 20% share, 1 10% share)
>>> Marco: 40% (1 20% share, 2 10% share)
>>> Nick: 10% (1 10% share)
>>>
>>> What are the possible scenarios for Eyal to sell his directorship?
>>
>> If Eyal sells 10% (which does not change the presidency), he just moves
>> his 10% certificate to the bank pool.  Done.
>>
>> If Eyal sells 20%, he moves the president's certificate to the bank
>> pool.  Then Marco takes it and chooses 20% (either one 20% or two 10%
>> certificates) to place in the bank pool.
>>
>> If Eyal sells 30%, he moves the president's certificate and the 10%
>> certificate to the bank pool.  Then Marco takes the president's
>> certificate and chooses 20% (either one 20% or two 10% certificates) to
>> place in the bank pool.
>>
>> If Eyal sells 40%, he moves the president's certificate and the 20%
>> certificate to the bank pool.  Then Marco takes the president's
>> certificate and chooses 20% (either one 20% or two 10% certificates) to
>> place in the bank pool.
>>
>> If Eyal sells 50%, he moves all three of his certificates to the bank
>> pool.  Then Marco takes the president's certificate and chooses 20%
>> (either one 20% or two 10% certificates) to place in the bank pool.
>>
>> [snip]
>>> Some special (hypothetical) cases:
>>>
>>> A) No shares in Pool
>>>
>>> Eyal: 40% (20%P + 20%)
>>> Marco: 20% (20%)
>>>
>>> IPO: 40% (4 10%)
>>>
>>> Is it possible for Eyal to sell 30%?
>>> Answer: No, as it not possible to get a 10% share out of IPO to Eyal.
>>> Eyal has to sell all 40%.
>>
>> Agreed.
>>
>>> B) 10% shares in Pool
>>>
>>> Eyal: 40% (20%P + 20%)
>>> Marco: 20% (20%)
>>>
>>> Pool: 40% (4 10%)
>>>
>>> Is it possible for Eyal to sell 30%?
>>> Answer: Likely yes? Is it possible for Eyal to swap the received 20%
>>> share from Marco with a 10% of the Pool?
>>
>> In most games (and I think this includes 1835), Eyal is prevented from
>> selling 30% because this would cause 70% to be in the bank pool.
>>
>> But let's change the example by having the pool hold two 10%
>> certificates and a third player hold the other two.  Then Eyal may sell
>> 30% by placing both his certificates in the bank pool and taking a 10%
>> certificate from the bank pool.  Marco must then trade his 20%
>> certificate for the president's certificate.
>>
>> Eyal may also sell 10%.  In this case he just places his 20%
>> non-president certificate in the bank pool and takes a 10% certificate.
>>
>> -end-
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Bug in StartRound Code for reducing prices

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

Erik:
most likely in the beginning of Rails the PD was neither during 
StockRounds nor during the auction updated after each action.

I added a PlayerNameModel now that is a very instructive application of 
the new core mechanism:

Each players PlayerNameModel adds itself to the PlayerOrderModel of the 
PlayerManager. The PlayerOrderModel itself contains various state 
variables, including the PriorityPlayer state.

So as soon as the PriorityPlayer variable changes this indicates that 
the PlayerOrderModel has changed and this implies that the 
PlayerNameModel could have changed. A Field in the UI observes the 
PlayerNameModel and gets updated accordingly. This mechanism is highly 
reliable and so only a few lines of code had to be added/changed to make 
the Player captions changing with the PriorityPlayer changing.

This is now much easier in 2.0 compared to the beginning of 1.x coding.

Stefan


On 08/28/2015 06:26 PM, Erik Vos wrote:
>> The next bug to fix is that the priority deal is not updated during the
>> StartRound. This was also true in Rails 1.x.
>
>   I think the historic reason was that the 1830 rules only talk about
> assigning the Priority Deal at each _closure_ of a stock round (including
> the initial one).
> And thinking about that, I concluded that the priority does not yet matter
> in the initial round. Other games may differ.
> As things have developed, in Rails there now indeed is a discrepancy between
> StartRounds and StockRounds in continuously keeping track of the (virtual)
> priority during a round.
>
> Erik
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Bug in StartRound Code for reducing prices

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

> The next bug to fix is that the priority deal is not updated during the
> StartRound. This was also true in Rails 1.x.

 I think the historic reason was that the 1830 rules only talk about
assigning the Priority Deal at each _closure_ of a stock round (including
the initial one). 
And thinking about that, I concluded that the priority does not yet matter
in the initial round. Other games may differ.
As things have developed, in Rails there now indeed is a discrepancy between
StartRounds and StockRounds in continuously keeping track of the (virtual)
priority during a round.

Erik

Re: [Rails-devel] Bug in StartRound Code for reducing prices

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

Yes you are correct. There is some legacy mechanism that updates the 
player captions in the Game Status panel.

I will add a PlayerNameModel that provides automatic updates.

Thanks,
Stefan

On 08/28/2015 01:20 PM, Dr. Martin Brumm wrote:
> Hi Stefan,
>
> regarding the priority not working i think thats a bug of the "static"
> StartRoundWIndow internally rails keeps track of the priority and
> everything is ok.
>
> Regards,
> Martin
> Am 28.08.15 um 12:49 schrieb Stefan Frey:
>> Martin:
>> good catch!
>>
>> Yes, this does not work correctly. Interestingly this bug is also in
>> Rails 1.x, thus most likely it never worked. :-(
>>
>> A fix is in that does the following:
>>
>> * The last player passed, first stock round finished
>>
>> * The first player has to purchase the first private for free, however
>> this counts as a purchase (see 1830 rules), thus the next player to act
>> is the second player.
>>
>> The next bug to fix is that the priority deal is not updated during the
>> StartRound. This was also true in Rails 1.x.
>>
>>
>> Stefan
>>
>> PS: I always assume now that bug reports etc. refer to rails_2_develop,
>> unless you specify a different branch.
>>
>>
>> On 08/28/2015 08:11 AM, Dr. Martin Brumm wrote:
>>> Good morning,
>>> the current StartRound Code for 1830 with the price reducing contains a
>>> slight flaw.
>>>
>>> If all participants pass enough times that the price of the object in
>>> question drops to zero the object will be assigned to the last person
>>> that passed and not to the first person that faces the object with price
>>> 0 in the new round. Apparently rails doesnt handle the
>>> setcurrenttonextplayer-part in that context correctly. See the attached
>>> save game.
>>>
>>> Player Erik was the last one to pass the price dropped to zero, he got
>>> the private, but still has to pass anew for the next item in the
>>> StartRound ?...
>>>
>>> Regards,
>>> Martin
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>>
>>>
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Bug in StartRound Code for reducing prices

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

Hi Stefan,

regarding the priority not working i think thats a bug of the "static" 
StartRoundWIndow internally rails keeps track of the priority and 
everything is ok.

Regards,
Martin
Am 28.08.15 um 12:49 schrieb Stefan Frey:
> Martin:
> good catch!
>
> Yes, this does not work correctly. Interestingly this bug is also in
> Rails 1.x, thus most likely it never worked. :-(
>
> A fix is in that does the following:
>
> * The last player passed, first stock round finished
>
> * The first player has to purchase the first private for free, however
> this counts as a purchase (see 1830 rules), thus the next player to act
> is the second player.
>
> The next bug to fix is that the priority deal is not updated during the
> StartRound. This was also true in Rails 1.x.
>
>
> Stefan
>
> PS: I always assume now that bug reports etc. refer to rails_2_develop,
> unless you specify a different branch.
>
>
> On 08/28/2015 08:11 AM, Dr. Martin Brumm wrote:
>> Good morning,
>> the current StartRound Code for 1830 with the price reducing contains a
>> slight flaw.
>>
>> If all participants pass enough times that the price of the object in
>> question drops to zero the object will be assigned to the last person
>> that passed and not to the first person that faces the object with price
>> 0 in the new round. Apparently rails doesnt handle the
>> setcurrenttonextplayer-part in that context correctly. See the attached
>> save game.
>>
>> Player Erik was the last one to pass the price dropped to zero, he got
>> the private, but still has to pass anew for the next item in the
>> StartRound ?...
>>
>> Regards,
>> Martin
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>>
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Bug in StartRound Code for reducing prices

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

Martin:
good catch!

Yes, this does not work correctly. Interestingly this bug is also in 
Rails 1.x, thus most likely it never worked. :-(

A fix is in that does the following:

* The last player passed, first stock round finished

* The first player has to purchase the first private for free, however 
this counts as a purchase (see 1830 rules), thus the next player to act 
is the second player.

The next bug to fix is that the priority deal is not updated during the 
StartRound. This was also true in Rails 1.x.


Stefan

PS: I always assume now that bug reports etc. refer to rails_2_develop, 
unless you specify a different branch.


On 08/28/2015 08:11 AM, Dr. Martin Brumm wrote:
> Good morning,
> the current StartRound Code for 1830 with the price reducing contains a
> slight flaw.
>
> If all participants pass enough times that the price of the object in
> question drops to zero the object will be assigned to the last person
> that passed and not to the first person that faces the object with price
> 0 in the new round. Apparently rails doesnt handle the
> setcurrenttonextplayer-part in that context correctly. See the attached
> save game.
>
> Player Erik was the last one to pass the price dropped to zero, he got
> the private, but still has to pass anew for the next item in the
> StartRound ?...
>
> Regards,
> Martin
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

[Rails-devel] Bug in StartRound Code for reducing prices

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

Good morning,
the current StartRound Code for 1830 with the price reducing contains a 
slight flaw.

If all participants pass enough times that the price of the object in 
question drops to zero the object will be assigned to the last person 
that passed and not to the first person that faces the object with price 
0 in the new round. Apparently rails doesnt handle the 
setcurrenttonextplayer-part in that context correctly. See the attached 
save game.

Player Erik was the last one to pass the price dropped to zero, he got 
the private, but still has to pass anew for the next item in the 
StartRound ?...

Regards,
Martin

Re: [Rails-devel] Move to github

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

Added.

On 08/24/2015 09:34 PM, John David Galt wrote:
> I'm jdgalt on github.
>
> On 2015-08-23 23:50, Stefan Frey wrote:
>> Erik:
>> hope that will there will be a case some day. Adding new games is easier
>> than ever before and it will get better. I am working on a replacement
>> of TileDesigner.
>>
>> Added you to github.
>>
>> Plus: Added Brett, Chris and Martin to github.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Move to github

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

I'm jdgalt on github.

On 2015-08-23 23:50, Stefan Frey wrote:
> Erik:
> hope that will there will be a case some day. Adding new games is easier 
> than ever before and it will get better. I am working on a replacement 
> of TileDesigner.
> 
> Added you to github.
> 
> Plus: Added Brett, Chris and Martin to github.

Re: [Rails-devel] 1835: Rick Westermann ruling on Pfb/NF as default?

[Rick W. <wes...@pu...>]

Thanks for making it an option.   Since it is an option then the default is not that important (IMO) but because the rules are silent on the issue I would make the default “Anytime”.

--
Rick Westerman
wes...@pu...




> On Aug 24, 2015, at 3:42 AM, Stefan Frey <ste...@we...> wrote:
> 
> I will add a GameOption for 1835 to select between the Rick Westermann 
> ruling on when to use the PfB and NF private token power.
> 
> The Westermann ruling is that can only be used during the standard token 
> phase.
> See http://home.earthlink.net/~gamecorner/1835hrv4.html
> 
> The alternative interpretation is that the PfB and NF power can be used 
> anytime (especially before a tile lay).
> 
> Question is what should be the default setting?
> 
> My own preference is to set the default to anytime.
> 
> Stefan
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1844: Mountain Cable Car -Grey Tiles with flexible value

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

Am 24.08.15 um 09:09 schrieb Stefan Frey:
> Most likely not confused, but the station will be lost (similar to a
> 1856 downgrade). Why is there the need of a station on those hexes?

Maybe there isnt but from what i understood rails expect a starting 
point and an endpoint to see if a tile upgrade is valid ? So the 
startpoint for the track would be the edge(side) but whats the endpoint 
? We cant do the tracks from side to side on the initial map or rails 
would deam them viable routes ? Is there a flag to prevent a route that 
leads from edge to edge ? (Besides an inaccessible station in the middle 
of the tile ?).

Regards,
Martin
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] 1835: Rick Westermann ruling on Pfb/NF as default?

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

I will add a GameOption for 1835 to select between the Rick Westermann 
ruling on when to use the PfB and NF private token power.

The Westermann ruling is that can only be used during the standard token 
phase.
See http://home.earthlink.net/~gamecorner/1835hrv4.html

The alternative interpretation is that the PfB and NF power can be used 
anytime (especially before a tile lay).

Question is what should be the default setting?

My own preference is to set the default to anytime.

Stefan

Re: [Rails-devel] 1844: Mountain Cable Car -Grey Tiles with flexible value

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

> Other than the colour and the late, or early or no activation at all ?
> No. I am pretty sure that the run determination algorythmn will adapt :)
>>
>> In my understanding no and thus there is no strict need for a different
>> type of stop. However be aware that creation of stops is "cheap" now, as
>> they can be setup in xml. So yes that can be done easily.
>
> Do you by chance have an example ? :)

Yep see 1844 map.xml:

<Access type="offMap" runTo="yes" runThrough="no" loop="no" score="major"/>

An Access defines a type of stop.

> Antscd:
> I was thinking about setting up the mountain hexes that can be tunnel as
> cities with the value of 0 (or like Birmingham in 1851 as unacessible)
> and links running from the edges to the virtual city. Does rails
> recognise this setup and will not get confused if we place the tunnels
> (straight or curved links) over the city ? Any insights ?
>
>>

Most likely not confused, but the station will be lost (similar to a 
1856 downgrade). Why is there the need of a station on those hexes?

Re: [Rails-devel] Move to github

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

Erik:
hope that will there will be a case some day. Adding new games is easier 
than ever before and it will get better. I am working on a replacement 
of TileDesigner.

Added you to github.

Plus: Added Brett, Chris and Martin to github.


On 08/21/2015 08:35 PM, Erik Vos wrote:
> Stefan,
> I have opened an account named erik-vos (just in case).
> Erik
>
>
>> -----Original Message-----
>> From: Stefan Frey [mailto:ste...@we...]
>> Sent: Friday, August 21, 2015 6:17 PM
>> To: Development list for Rails: an 18xx game
>> Subject: [Rails-devel] Move to github (was: Test of Install4j and
>> MacAppBundle in the next Beta/RC)
>>
>> I need your github usernames to add you as collaborators.
>> Brett, Erik, Martin, Michael, anyone else?
>>
>> Let us make the move at the time of the official Rails 2.0 release, which
> is
>> most likely very soon ;-)
>>
>>
>>
>> On 08/21/2015 06:02 PM, brett lentz wrote:
>>> Sweet! Let's make the jump!
>>>
>>> ---Brett.
>>>
>>> On Fri, Aug 21, 2015 at 11:57 AM, Stefan Frey <ste...@we...
>>> <mailto:ste...@we...>> wrote:
>>>
>>>      Okay, I have no strong opinion on that, as I use Linux myself and
> prefer
>>>      jar/webstart ;-)
>>>
>>>      Another topic: I realized recently that github now supports binary
>>>      releases, so a full move to github is possible.
>>>
>>>      Stefan
>>>
>>>
>>>      On 08/21/2015 03:15 PM, brett lentz wrote:
>>>      >
>>>      > Let's continue with launch4j and MacAppBundle.
>>>      >
>>>      > I'd like to keep Rails entirely open source.
>>>      >
>>>      > ---Brett.
>>>      >
>>>      > On Fri, Aug 21, 2015 at 5:38 AM, Stefan Frey <ste...@we...
>> <mailto:ste...@we...>
>>>       > <mailto:ste...@we... <mailto:ste...@we...>>> wrote:
>>>       >
>>>       >     For the next beta/RC I will add test files that are created
>>>      by Install4j
>>>       >
>>>
> (https://www.ej-technologies.com/products/install4j/overview.html).
>>>       >
>>>       >     Install4j is a commercial product, however offers free
>>>      licenses for
>>>       >     OpenSource projects for a link on the homepage. I hope that
>>>      is okay for
>>>       >     Rails (Brett?).
>>>       >
>>>       >     Install4j would provide an installer for both native
>>>      Windows/Mac OS.
>>>       >
>>>       >     I have not received any feedback on the launch4j
>>>      wrapper/installer so
>>>       >     far. As there have been some downloads, I assume that is a
>>>      good sign.
>>>       >
>>>       >     In addition I intend to test a Mac OS bundle created by
>>>      MacAppBundle
>>>       > https://github.com/crotwell/gradle-macappbundle
>>>       >
>>>       >     So either there will be packages by
>>>       >     * launch4j and macappbundle
>>>       >     or
>>>       >     * install4j
>>>       >
>>>       >     That is in addition to the existing one-jar release and
> Webstart
>>>       >     support.
>>>       >
>>>       >     A big thanks to gradle that allows supporting all of that
>>>      with much more
>>>       >     ease than ever before. :-)
>>>       >
>>>       >     Stefan
>>>       >
>>>       >
>>>
> ----------------------------------------------------------------------------
> --
>>>       >     _______________________________________________
>>>       >     Rails-devel mailing list
>>>       > Rai...@li...
>>>      <mailto:Rai...@li...>
>>>       >     <mailto:Rai...@li...
>>>      <mailto:Rai...@li...>>
>>>       > https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>       >
>>>       >
>>>       >
>>>       >
>>>       >
>>>
> ----------------------------------------------------------------------------
> --
>>>       >
>>>       >
>>>       >
>>>       > _______________________________________________
>>>       > Rails-devel mailing list
>>>       > Rai...@li...
>>>      <mailto:Rai...@li...>
>>>       > https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>       >
>>>
>>>
> ----------------------------------------------------------------------------
> --
>>>      _______________________________________________
>>>      Rails-devel mailing list
>>>      Rai...@li...
>>>      <mailto:Rai...@li...>
>>>      https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>
>>>
>>>
>>>
>>>
> ----------------------------------------------------------------------------
> --
>>>
>>>
>>>
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>
>>
>>
> ----------------------------------------------------------------------------
> --
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 1844: Mountain Cable Car -Grey Tiles with flexible value

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

Am 23.08.15 um 20:59 schrieb Stefan Frey:
> Martin:
> is there a difference between mountain railway hexes and
> standard-off-board maps except the method of creation/activation?

Other than the colour and the late, or early or no activation at all ? 
No. I am pretty sure that the run determination algorythmn will adapt :)
>
> In my understanding no and thus there is no strict need for a different
> type of stop. However be aware that creation of stops is "cheap" now, as
> they can be setup in xml. So yes that can be done easily.

Do you by chance have an example ? :)
>
> The other implications of the mountain railway hexes have to be coded
> anyway, but it might be a little help if they can be identified by the
> stop type.
I do think so too, thats why i was asking, so one can avoid working with 
"hardcoded hexes" but rely on the type.

>
> Stefan
>
> PS: I have added some debug/message code in the 1844 branch for errors
> occurring during game creation. Might help to find existing problems.
>
Yep will be pretty much necessary i am afraid.

Antscd:
I was thinking about setting up the mountain hexes that can be tunnel as 
cities with the value of 0 (or like Birmingham in 1851 as unacessible) 
and links running from the edges to the virtual city. Does rails 
recognise this setup and will not get confused if we place the tunnels 
(straight or curved links) over the city ? Any insights ?

>
> On 08/23/2015 08:38 PM, Dr. Martin Brumm wrote:
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1844: Mountain Cable Car -Grey Tiles with flexible value

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

Martin:
is there a difference between mountain railway hexes and 
standard-off-board maps except the method of creation/activation?

In my understanding no and thus there is no strict need for a different 
type of stop. However be aware that creation of stops is "cheap" now, as 
they can be setup in xml. So yes that can be done easily.

The other implications of the mountain railway hexes have to be coded 
anyway, but it might be a little help if they can be identified by the 
stop type.

Stefan

PS: I have added some debug/message code in the 1844 branch for errors 
occurring during game creation. Might help to find existing problems.



On 08/23/2015 08:38 PM, Dr. Martin Brumm wrote:
> Good evening,
>
> do we want to introduce a new tpe of stop that handles those types
> specifically or do we want to alter the existing Offmap-cities with a
> function that can set the value according to phase/game actions ?
>
> Whats your opinion on that ?
>
> Explanation: In 1844 a player can buy a paper "Bergbahn"/"Mountain
> Railway-Cable Car" that enables him to place a marker on a previously
> unaccessible gray maphex (with access markers like a red offboard hex)
> and give that hex a value. If that hex has been "activated" (a train has
> hit the station as stop or start hex on its run) the corresponding
> Certificate will keep its value at the game end otherwise its value
> drops to 0.
>
>
> Kind regards,
> Martin
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

[Rails-devel] 1844: Mountain Cable Car -Grey Tiles with flexible value

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

Good evening,

do we want to introduce a new tpe of stop that handles those types 
specifically or do we want to alter the existing Offmap-cities with a 
function that can set the value according to phase/game actions ?

Whats your opinion on that ?

Explanation: In 1844 a player can buy a paper "Bergbahn"/"Mountain 
Railway-Cable Car" that enables him to place a marker on a previously 
unaccessible gray maphex (with access markers like a red offboard hex) 
and give that hex a value. If that hex has been "activated" (a train has 
hit the station as stop or start hex on its run) the corresponding 
Certificate will keep its value at the game end otherwise its value 
drops to 0.


Kind regards,
Martin

Re: [Rails-devel] 1835 presidency swap: Bug fix required (typos corrected)

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

John:
I really like your suggestion. I think it is a good way to handle those 
cases in a rigorous way. In addition it is fully compatible with the 
standard way of how standard 18xx treat the change of director in such 
cases.

I adapted your proposal to include that it is not allowed to sell 
multiple certificates such that you are able to get a nominal share in 
exchange, which Volker and Erik referred to.

However it is still possible for the director share, which I believe is 
important. (The second edition of the German rules claim that this is 
not possible, however I do not agree with that ruling).

And Dave is fully right, game rules are not written as algorithms. It is 
our task to transform those rules into an algorithm which most people 
can agree on that the algorithm is a good representation of the game rules.

So my proposed algorithm (based on John David Galts suggestion) is found 
below.

Again feedback is very welcome.

Stefan


* Algorithm for Change of Director after Sale of Stock:

** Definitions:

Share nominal n%

Nominal (n) certificate 1 times n%
Director (d) certificate has d times n%
Multiple (m) certificate has m times n%

Director X  has x times n% of stock
Potential director Y has y times n% of stock

Pool P has p times n% of stock
Pool limit p_max times n%

** Steps:

1. Director can trigger change of director if he sells s >= (x-y) + 1

2. Only allowed if (s + p) <= p_max

3. Director puts d and other certificates (total o) into the pool, such 
that (d + o) >= s. Choose o such that o is minimal.

4. Potential (new) director exchanges certificates (of his choice, but 
see below) of total size e = d with the pool for the director certificate

5. (Old) director receives [(d+o) - s] (of his choice) from the pool, if 
this is not possible the previous step is repeated with a different 
choice until the old director receives the required amount of shares

6. If the last step cannot be executed in any way, selling s is not possible

** Remarks:
- The program only offers choices in step 4 that allow step 5/6 to be 
succesfull
- The program only offers transaction of size s that can be executed

** Examples:

A) 1830 standard case

Nominal certificate 10%
Director certificate d=2 20% share

X has 40%, x = 4 [d, 2*n]
Y has 30%, y = 3 [3*n]

Pool has 30%, p = 3

Director sells 20%  (s=2)

1. Yes: s= 2;  (x-y) + 1 = (4- 3) + 1 = 2

2. Yes: s + p = 2 + 3 <= 5 = p_max

3. Director puts the director certificate, but no other into the pool (o 
= 0). (d + o) =  2 >= 2, minimal o

4. Potential director exchanges 2 10% shares with the pool

5. Old director gets nothing in return, transaction finished

B) 1830 selling the director partially

Certificates as above in A)

X has 20%, x = 2 [d]
Y has 20%, y = 2 [2*n]

Pool is empty, p = 0

Director sells 10%  (s=1)

1. Yes: s = 1; (x - y) + 1 = 1

2. Yes: s + p = 1 + 0  <= 5 = p_max

3. Director puts the director certificate, but no other into the pool (o 
= 0) d + o = 2 >= 1, minimal o

4. Potential director exchanges 2 10% shares with the pool

5. Old director receives 1 10% share from the pool

C) 1835 case

Nominal certificate 10%
Director certificate d=2 20% share
Multiple certificate m=2 20% share

X has 50%, x = 5 [d, m, n]
Y has 40%, y = 4 [m, 2*n]

Pool is empty, p = 0

Director sells 30% (s=3)

1. Yes
2. Yes
3. Director puts director certificate d the pool and a 10% share. It is 
not allowed to choose the 20% share here, as o has to be chosen to be 
minimal
4. Potential director chooses to exchange the director certificate from 
the pool with either the multiple certificate m or the two nominal 
certificates
5. Old director gets nothing in return, transaction is finished

D) Another 1835 case

Certificates as above in C)

X has 40%, x = 4 [d, m]
Y has 40%, y = 4 [m, 2*n]

Pool is empty, p = 0

Director sells 10% (s=1)

1. Yes
2. Yes
3. Director puts director certificate d the pool, but no other
4. Potential director can only exchange the 2 nominal certificates, as 
otherwise the director cannot receive the 10% share in step 5. If Pool 
contains a nominal certificate it is his choice
5. Old director receives 1 10% share from the pool

On 08/21/2015 11:59 PM, John David Galt wrote:
> Please use this version, I hit send too soon.
>
> On 2015-08-21 13:18, Stefan Frey wrote:
>> Another 1835 implementation issue:
>>
>> President swaps are not easy to understand for newbies in any 18xx (you
>> are not allowed to sell the president share, however you are allowed to
>> tear it apart, virtually sell one half of it to the pool and then
>> receive two shares by the new director, who gets the fixed director
>> certificate, then the old director puts one of received shares into the
>> pool and keeps the other).
>>
>> In 1835 the 20% shares make selling the presidency even more interesting.
>>
>> Selling the president certificate involves two steps of share movements:
>>
>> A) Exchange the president certificate with shares from the new president
>>
>> B) Move the remaining sold shares into the pool
>
> I do not agree that these are separate steps.
>
>> In 1835 both steps could include either 10% or 20% shares (PR: 5% or 10%
>> shares)
>>
>> Depending on what the president received in A) this might even change
>> the possible options for B.
>>
>> However it implies that the current president has to choose both A)
>> which certificate to exchange with the new president and B) which
>> certificate to put into the pool.
>>
>> The current implementation only asks for A) and has some serious bugs in
>> executing the share transfers.
>>
>> I intend to fix those bugs before the next release, however I would ask
>> if anyone has a different opinion on how it works for 1835?
>
> I have not seen any case in which the current program gets it wrong (in
> my view) -- however, I have not exhaustively tried every single case.
>
> The following is the exact sequence of events I expect to happen in any
> purchase or sale of stock (after any starting packet).  This applies to
> all games, not just 1835.
>
> In a purchase of stock:
>
> (1) The player buys a certificate, not share(s).
>
> (2) If the purchase causes a change of president, then the new president
> exchanges one or more certificates (totaling the same number of shares
> of that company) for the president's certificate, wherever it is.  (This
> is a direct exchange between two players, unless the president's
> certificate is in the bank pool, as it might be in 1829 (receivership)
> or 1853v1 (when the company hasn't floated yet).)
>
> (In 1835, if there is a choice, the outgoing president chooses which
> certificate(s) he receives from among those in the new president's hand.
>   I would follow this principle in any other game where any company has
> non-presidential certificates of more than one size, if the rules do not
> address the question.)
>
> In a sale of stock:
>
> (1) A sale that is going to cause a change of president may only be made
> if some other player holds at least the number of shares that the
> president's certificate contains.
>
> (2) Except for the special case given in point (5), the player sells
> certificate(s), not share(s).
>
> (3) If the sale will cause a change of president, then one of the
> certificate(s) sold must be the president's certificate.  Otherwise the
> seller must retain the president's certificate.
>
> (4) If the sale causes a change of presidency, then the new president
> exchanges one or more certificates (totaling the same number of shares
> of that company) for the president's certificate in the bank pool.  (The
> outgoing president does not participate in this swap and does not have
> any right to claim a certificate from the new president's hand.)
>
> (5) A special case is where a player who holds only certificate(s) of
> two or more shares each in that company wishes to sell a number or
> shares that is not divisible by one of his certificates.  (For this
> purpose "one share" is defined as the amount of the smallest certificate
> that exists for that company.)
>
> In this case the "fractional sale" may only be made if one of the
> following is true in addition to point (1):
>
>     A: The bank pool contains certificate(s) of the company in the right
> sizes such that the seller can be given the correct number of shares
> from the bank pool.  In this case the seller exchanges certificates with
> the bank pool, and then point (4) applies.
>
>     B: Statement A above is not true, but, the sale will cause a change
> of presidency, and the bank pool and the old and new presidents' hands
> together contain enough certificates of the company to give both the old
> and new presidents the correct numbers of shares, with the new president
> holding the president's certificate.  In this case a three-way swap of
> certificates is performed.  If there is more than one correct way to
> perform the swap, first the outgoing president chooses which
> certificate(s) he gives up; then the new president chooses which
> certificate(s) he gives up.
>
>> Example:
>>
>> In the attached save file OL has the following share distribution:
>>
>> (Remark: this is from a replay of one of Bill Stoll's 1835 pbem games -
>> see http://askwaltstollmd.com/bill/archive/1835zwolf/index.html
>> Fun fact is that I played 1835 ftf with one of the players before he
>> moved to the US)
>>
>> Eyal: 50% (1 20% director, 1 20% share, 1 10% share)
>> Marco: 40% (1 20% share, 2 10% share)
>> Nick: 10% (1 10% share)
>>
>> What are the possible scenarios for Eyal to sell his directorship?
>
> If Eyal sells 10% (which does not change the presidency), he just moves
> his 10% certificate to the bank pool.  Done.
>
> If Eyal sells 20%, he moves the president's certificate to the bank
> pool.  Then Marco takes it and chooses 20% (either one 20% or two 10%
> certificates) to place in the bank pool.
>
> If Eyal sells 30%, he moves the president's certificate and the 10%
> certificate to the bank pool.  Then Marco takes the president's
> certificate and chooses 20% (either one 20% or two 10% certificates) to
> place in the bank pool.
>
> If Eyal sells 40%, he moves the president's certificate and the 20%
> certificate to the bank pool.  Then Marco takes the president's
> certificate and chooses 20% (either one 20% or two 10% certificates) to
> place in the bank pool.
>
> If Eyal sells 50%, he moves all three of his certificates to the bank
> pool.  Then Marco takes the president's certificate and chooses 20%
> (either one 20% or two 10% certificates) to place in the bank pool.
>
> [snip]
>> Some special (hypothetical) cases:
>>
>> A) No shares in Pool
>>
>> Eyal: 40% (20%P + 20%)
>> Marco: 20% (20%)
>>
>> IPO: 40% (4 10%)
>>
>> Is it possible for Eyal to sell 30%?
>> Answer: No, as it not possible to get a 10% share out of IPO to Eyal.
>> Eyal has to sell all 40%.
>
> Agreed.
>
>> B) 10% shares in Pool
>>
>> Eyal: 40% (20%P + 20%)
>> Marco: 20% (20%)
>>
>> Pool: 40% (4 10%)
>>
>> Is it possible for Eyal to sell 30%?
>> Answer: Likely yes? Is it possible for Eyal to swap the received 20%
>> share from Marco with a 10% of the Pool?
>
> In most games (and I think this includes 1835), Eyal is prevented from
> selling 30% because this would cause 70% to be in the bank pool.
>
> But let's change the example by having the pool hold two 10%
> certificates and a third player hold the other two.  Then Eyal may sell
> 30% by placing both his certificates in the bank pool and taking a 10%
> certificate from the bank pool.  Marco must then trade his 20%
> certificate for the president's certificate.
>
> Eyal may also sell 10%.  In this case he just places his 20%
> non-president certificate in the bank pool and takes a 10% certificate.
>
> -end-
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 1844 and 1854 Tunnel Tile setup and handling

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

Martin:
quick answer for now. It seems that for 1844 tunnels can be handled in 
the standard approach.

1854 will most likely require the addition of "overlay"-tiles for hexes 
and code that handles the issues with UI/tile laying/route algorithms.
However nothing impossible.

My recommendation is to start with 1844 first and I prefer to handle it 
as regular as possible. Even if both are called "tunnels".

In general I believe that 1844 is easier to finalize and thus let us 
focus on 1844 first.

Stefan


On 08/22/2015 10:37 AM, Dr. Martin Brumm wrote:
> Good morning,
>
> how do we want to handle the Tunnel Tiles and their ability in 1844 to
> be added on top or below other tiles already on the board ?
>
> For 1844 one could build additional tiles (since only the
> Furka-Oberalp-Tiles not on the board itself can be tunneled additionaly
> before or after the FOs have been placed).
>
> But in 1854 this is a bit more complex. Any ideas ?
>
> Regards,
> Martin
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>