Thread: [Rails-devel] 1835 Prussian does not pay out (3014303)

Status: Beta

Brought to you by: neutronc, wakko666

rails-devel

[Rails-devel] 1835 Prussian does not pay out (3014303)

From: Phil D. <de...@gm...> - 2010-06-10 11:20:39

Just raised the above issue and having a peek to see if I could see
what was wrong.

It seems that when the Prussian pays out, rails does a check to see if
any players shouldn't get income from the payout, but I don't
understand why it is doing that check?  If the Prussian is formed such
that someone has already earned money from the minor or private that
is folded into the Prussian, then the Prussian shouldn't run on that
OR.  If it runs in the next OR...the minors/privates will have been
folded in at the beginning of that OR when they would not have had a
chance to earn their owners revenue prior to the Prussian operating.

Am I missing a nuance in the Prussian rules?

Phil

Re: [Rails-devel] 1835 Prussian does not pay out (3014303)

From: Phil D. <de...@gm...> - 2010-06-10 11:43:50

Thought about this further...I assume this is here for the specific OR
for when the 5 gets bought?  In that specific round, it's possible
(likely) that the Prussian will run after certs have been forceably
merged that have already earned income.  I'm guessing this code is
there to prevent a player earning from a cert twice in that specific
round, since it's the only round where the Prussian could run and
players have already earned from certs.

I can see what's wrong, in our game we have a player who has potential
Prussian certs in the form of minors 1,4 and 5.  But he currently
doesn't have any shares of the Prussian, so at line 128 in
OperatingRound_1835 it is trying to get the shares that this player
has in Pr and throwing a nullpointer exception.

On 10 June 2010 12:20, Phil Davies <de...@gm...> wrote:
> Just raised the above issue and having a peek to see if I could see
> what was wrong.
>
> It seems that when the Prussian pays out, rails does a check to see if
> any players shouldn't get income from the payout, but I don't
> understand why it is doing that check?  If the Prussian is formed such
> that someone has already earned money from the minor or private that
> is folded into the Prussian, then the Prussian shouldn't run on that
> OR.  If it runs in the next OR...the minors/privates will have been
> folded in at the beginning of that OR when they would not have had a
> chance to earn their owners revenue prior to the Prussian operating.
>
> Am I missing a nuance in the Prussian rules?
>
> Phil
>

Re: [Rails-devel] 1835 Prussian does not pay out (3014303)

From: Erik V. <eri...@xs...> - 2010-06-10 20:05:21

See below. 

-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Thursday 10 June 2010 13:44
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1835 Prussian does not pay out (3014303)

Thought about this further...I assume this is here for the specific OR
for when the 5 gets bought?  In that specific round, it's possible
(likely) that the Prussian will run after certs have been forceably
merged that have already earned income.  I'm guessing this code is
there to prevent a player earning from a cert twice in that specific
round, since it's the only round where the Prussian could run and
players have already earned from certs.

[EV] That's indeed the rule: the PR can run (except when M2 has run), but
players who have already earned income from merged preprussians don't get
their income. This the official interpretation from the author, see Q5.1 in
http://web.archive.org/web/20041024222224/http://www.geocities.com/TimesSqua
re/Arena/5276/depot/1835f.htm#5.0

I can see what's wrong, in our game we have a player who has potential
Prussian certs in the form of minors 1,4 and 5.  But he currently
doesn't have any shares of the Prussian, so at line 128 in
OperatingRound_1835 it is trying to get the shares that this player
has in Pr and throwing a nullpointer exception.

[EV] Ah, that's a bug. Now fixed; but I don't have a good test case, can you
test it?

Erik.

Re: [Rails-devel] 1835 Prussian does not pay out (3014303)

From: John D. G. <jd...@di...> - 2010-06-11 04:01:52

Erik Vos wrote:
> Thought about this further...I assume this is here for the specific OR
> for when the 5 gets bought?  In that specific round, it's possible
> (likely) that the Prussian will run after certs have been forceably
> merged that have already earned income.  I'm guessing this code is
> there to prevent a player earning from a cert twice in that specific
> round, since it's the only round where the Prussian could run and
> players have already earned from certs.
> 
> [EV] That's indeed the rule: the PR can run (except when M2 has run), but
> players who have already earned income from merged preprussians don't get
> their income. This the official interpretation from the author, see Q5.1 in
> http://web.archive.org/web/20041024222224/http://www.geocities.com/TimesSqua
> re/Arena/5276/depot/1835f.htm#5.0

Which means that if M1 buys the first 4 train, or the first 4+4, the PR can
run that round even though BS, HO, and M1 may have paid dividends and then
converted to PR shares.  In which case those shares don't pay out.  (It can
also happen on the first 5 train, as you said, but not *only* then.)

Re: [Rails-devel] 1835 Prussian does not pay out (3014303)

From: Phil D. <de...@gm...> - 2010-06-11 08:51:17

Attachments: 1835_20100610_1044.chris.rails

Huh, okay, that is 'slightly' different to my reading of the rules
itself, which seem to imply that if any prePrussian share has paid
dividends in that OR then the Prussian will not operate in that round
(meaning even if M1 bought the 4, it won't operate because the
privates have paid out).  Fair enough if this is the authors
clarification, that's definitely the way it should be handled.

Erik: apologies, I failed to attach my save file, I was throwing
thoughts at the list whilst trying to resolve the issue myself and
kinda forgot to give you my testcase :)  The save with the issue is
attached to this mail.  I've tried running it against the latest
revision and it does at least progress now, however, it's progressing
incorrectly:

Pr (Simon) operates.
Pr lays tile #3 at hex B14/SW
Pr earns 120M
Pr pays out full dividend of 120M
Phil gets no income for 10% Pr shares as precursors have operated <---
this is wrong
Phil receives 6M for 1 5% shares
Simon receives 18M for 3 5% shares
Pr price goes from 154M(I4) to 172M(J4).

I converted M3 and the BB in the last OR, when the Prussian didn't
run.  I currently hold the HB which is giving me my virtual 10%
'negative share' but this hasn't yet been converted into the Prussian.
 I believe the negative shares are being applied regardless of whether
the attached minor or private has been folded into the Prussian.  They
need to apply only if they have been folded in.

Phil

On 11 June 2010 06:00, John David Galt <jd...@di...> wrote:
> Erik Vos wrote:
>> Thought about this further...I assume this is here for the specific OR
>> for when the 5 gets bought?  In that specific round, it's possible
>> (likely) that the Prussian will run after certs have been forceably
>> merged that have already earned income.  I'm guessing this code is
>> there to prevent a player earning from a cert twice in that specific
>> round, since it's the only round where the Prussian could run and
>> players have already earned from certs.
>>
>> [EV] That's indeed the rule: the PR can run (except when M2 has run), but
>> players who have already earned income from merged preprussians don't get
>> their income. This the official interpretation from the author, see Q5.1 in
>> http://web.archive.org/web/20041024222224/http://www.geocities.com/TimesSqua
>> re/Arena/5276/depot/1835f.htm#5.0
>
> Which means that if M1 buys the first 4 train, or the first 4+4, the PR can
> run that round even though BS, HO, and M1 may have paid dividends and then
> converted to PR shares.  In which case those shares don't pay out.  (It can
> also happen on the first 5 train, as you said, but not *only* then.)
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>