rails-devel — List for discussion of Rails development

Re: [Rails-devel] 1851 - Operating Company can't sell a share twice in one turn

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

On Tue, Jul 20, 2010 at 8:10 PM, John David Galt
<jd...@di...> wrote:
> Phil Davies wrote:
>> I don't believe there is a general consensus among all players but I
>> would like to think that the prevailing opinion is that in games where
>> selling a 'block' of shares causes a price drop, you cannot sell 1,
>> then sell 1, then sell 1 without passing in between and allowing other
>> people to react.  If you specifically want to sell to drop the price
>> and are happy to take the hit then you have to sell, let the other
>> players have a turn each to react, then sell again.
>
> Bruce Shelley's errata for 1830 (published in The General) specifically
> allows this "multiple separate sales on same turn" if the player wants to
> do it.  About the only reason for doing so is to go deliberately bankrupt.
>
> I would allow it in most 1830-derived games (those with 2-D stock markets).
> In particular I would allow it in 18AL and 18GA because their rules were
> derived from 1830.
>
> I would not allow it in 1835 (because "drop only once per turn" should take
> precedence in that game) or 1870 (because prices in that game never drop
> until the president of each company sold decides not to price protect).


Other reasons to do it, especially in 1870, also include things like
deliberately avoiding dropping the stock value below a "shelf" or
purposely taking advantage of the price protection mechanics to
manipulate the number of stock purchasing turns a player does or
doesn't get.

In some games I've played, players also want to have exact dollar
amounts in hand for various reasons, but most of the time this is for
'56 or '70, not '30. Whether it's a "good" strategy or not is
debatable, but is also irrelevant when discussing what the software
should do. The software should not judge the validity of a strategy or
prevent you from throwing the game just because taking a certain
action achieves a loss 9 times out of 10. As long as the UI clearly
allows you to sell N number of shares in M number of actions with no
confusion as to what the outcome will be, then each action should be a
separate transaction and trigger a separate evaluation of the rules
for dropping the stock price.


---Brett.

Re: [Rails-devel] 1851 - Operating Company can't sell a share twice in one turn

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

Phil Davies wrote:
> I don't believe there is a general consensus among all players but I
> would like to think that the prevailing opinion is that in games where
> selling a 'block' of shares causes a price drop, you cannot sell 1,
> then sell 1, then sell 1 without passing in between and allowing other
> people to react.  If you specifically want to sell to drop the price
> and are happy to take the hit then you have to sell, let the other
> players have a turn each to react, then sell again.

Bruce Shelley's errata for 1830 (published in The General) specifically
allows this "multiple separate sales on same turn" if the player wants to
do it.  About the only reason for doing so is to go deliberately bankrupt.

I would allow it in most 1830-derived games (those with 2-D stock markets).
In particular I would allow it in 18AL and 18GA because their rules were
derived from 1830.

I would not allow it in 1835 (because "drop only once per turn" should take
precedence in that game) or 1870 (because prices in that game never drop
until the president of each company sold decides not to price protect).

[Rails-devel] Bug: 18EU issue with starting a new minor after phase 5

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

Save file 18EU_20100720_1336_Chris.rails

Load up and start KBS at 100, base city Berlin.  Processes this action
totally fine.

Now save the game, and reload it (or just load
18EU_20100720_1602_Bug.rails).  Load error.

I traced the execution of the startCompany action and it gets
processed and logged with the correct selectedHomeCity. The
selectedHomeCity gets written to the executedActions log happily as
well.  Yet for some reason when you reload the game, the
selectedHomeCity object for that action is a null value.  It looks
like the ObjectOutputStream is, for some reason, failing to write the
selectedHomeCity object to the save file, causing the reload to fail.

Any thoughts??

You will have to load this on 1.3 by the way, I can't load this file
at all against the current head revision of the code.

Phil

Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo duringCGRformation hangs game

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

Yes, I agree that finding the seller is the catch.
MoveableHolder requires all portfolios (potential sellers) to have a name,
so perhaps what we need is a Map to link names to portfolios.

Thinking about it: identifying the seller and the share type bought is only
role currently fulfilled by passing the cert (ID), because after extracting
that info the cert ID itself is ignored. So why not pass seller name and
share type explicitly? Detecting the wrong seller is exactly the problem we
face.

One other issue then is to make the old and new version of BuyCertificate
compatible for deserialization, because I would hate to invalidate all my
test cases. But that should be doable.

Erik.

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Sunday 18 July 2010 20:04
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo duringCGRformation
hangs game

Sorry: I did not disregard your observation, I forgot to go deeper into the 
details of the buy process:

You are right that you select the actual shares by type from the portfolio
of 
the seller.
But how do you define the seller ("from")?
	PublicCertificateI cert = action.getCertificate();
        Portfolio from = cert.getPortfolio();

This is the owner of the certificate used in the action, which was stored by

the ID.

ACTION: Player B buys a 10% share, Rails select #2 (buys are stored by id),
this moves the 10% share from A to B, leaving 10% in the pool!

For the case below, what happens exactly is that you have stored certificate

#2. The owner is still A. Thus you have wrongly defined from and then you 
select one the shares from the wrong owner.

Thus another fix would have been to use the from field of the action instead

of the from of certificate, but this does not go to the root of the problem:

The real problem is that in general you have to decide either to use
reference 
by ID or reference by type, but not a mixture of both (at least for the 
storage of actions).

I am not really decided, which direction I prefer, in general I would prefer

IDs, but this is not by a wide margin. You will know better, which method is

more widespread in Rails so far, thus I follow your decision.

The good thing will be that in both cases the ordering of interchangeable 
objects will play no role anymore. By type the ordering is meaningless, by
ID 
there is always an order defined. 

Stefan



On Sunday 18 July 2010 19:26:06 Erik Vos wrote:
> OK, it's getting clear to me now.
>
> You disregard my observation that the certificate ID specified in a buy
> action is NOT used, but that the certificate transferred is selected
> afresh. It's not so easy to sort out if this second certificate selection
> process will give the same result as the first, or not. Neither is it
clear
> to me if this detail makes the situation better or worse.
>
> In any case, I'm getting more and more convinced that the use of unique
IDs
> is the weak spot here, and that BuyCertificate should be modified to
> specify shares in a similar way as SellShares does.
>
> Erik.
>
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Sunday 18 July 2010 00:07
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during
> CGRformation hangs game
>
> Erik:
> as a follow up to your current fixes:
> Maybe it is my fault that I am not able to fully explain the issue.
> I do NOT claim that there is anything wrong with your fixes, thus
> I will try to focus on why I think removing the mixture of referring by
> type
>
> and by id protects against several cases of (future) potential problems.
>
> There are two (main) cases two distinguish:
> A) The interchangable objects (like 10% shares) are stored in an ordered
> collection (like an arraylist).
>
> Then the mixing of actions that refer by ID and by type is a (necessary,
> but
>
> not sufficient) condition to the undo/reload-related problems we had.
> The additional conditions are that the ordering of the storage collection
> is
>
> not observed during undos and that undos are not stored in the save files.
>
> I will give a simple example for that:
> START: Player A has two 10% shares of company B&O (order in the portfolio
> #1
>
> and #2). The pool is empty.
> ACTION: Player A sells a 10% share, Rails selects #1
> UNDO: order in the portfoliio is now (#2, #1)
> ACTION: Player A sells a 10% share, Rails selects #2
> ACTION: Player B buys a 10% share from the Pool, Rails selects #2
>
> On Reload the sequence is:
> ACTION: Player A sells a 10% share, Rails selects #1 (sells are stored by
> type)
> ACTION: Player B buys a 10% share, Rails select #2 (buys are stored by
id),
> this moves the 10% share from A to B, leaving 10% in the pool!
>
> Thus fixing of any of the three conditions (mixing reference type,
ordering
> of
> portfolios, non-saving of undos) above potentially prevents the problem.
>
> B) The interchangable objects are stored in an un-ordered collection (liek
> a
>
> HashSet or HashMap)
>
> Here the problem arises much simpler: Here mixing of id and type
> referencing
>
> alone is sufficient to cause a reload problem. Now not even a undo is
> necessary.
>
> Again a simple example:
> START: Player A has two 10% shares of company B&O (unordered portfolio #1
> and
> #2). The pool is empty.
> ACTION: Player A sells a 10% share, Rails selects (randomly) #2
> ACTION: Player B buys a 10% share, Rails selects #2
>
> On Reload the sequence can be (in 50% of the cases):
> ACTION: Player A sells a 10% share, Rails selects (randomly) #1 (sells are
> stored by type)
> ACTION: Player B buys a 10% share, Rails selects #2  (buys are stored by
> id),
> this moves a 10% share from A to B, leaving 10% in the pool!
>
> This problem does not occur (at least it was not observed so far), but it
> can
> only be avoided by either not mixing referencing by id and by type or
never
> use an unordered collection.
>
> It is mainly case B) that I want to protects us from, as an unordered
> collection seems a valid choice for interchangable objects.
>
> But I agree that it might be the best to wait for the time, where the
> downward
> compatibility will be broken anyway.
>
> Stefan
>
> On Saturday 17 July 2010 13:55:35 you wrote:
> > Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during CGR
> > formation
> > hangs game
> > Date: Monday 21 June 2010
> > From: Stefan Frey <ste...@we...>
> > To: "Development list for Rails: an 18xx game"
> > <rai...@li...>
> >
> > 1) The BuyCertificates action stores certificate by id
> > 2) The SellShares action only stores percentages sold
> >
> > The main issue is mixing addressing interchangeable objects once by ids
>
> and
>
> > in
> > the other case by type. This can only work, if evey selection by type
>
> works
>
> > deterministically (thus never from unordered collections etc.) and the
>
> undo
>
> > mechanism strictly restores the previous ordering.
> >
> > Stefan
> >
> > [EV] IIRC, in a follow-up you suggested to always use certificate IDs in
> > the share buying and selling action.
> >
> > However, there is a reason behind this difference. Whereas you always
buy
> > *certificates* (normally one), you don't sell certificates but *shares*.
> > The share/certificate distinction makes no difference except in the case
> > where you sell half a president's certificate.
> > Say player A has a 20% presidency and player B has 2 10% shares. Player
A
> > can then sell a 10% share - even if he does not own a 10% certificate.
> > That's why I think selling can be done in no other way than by selling
> > *shares*.
> >
> > Although certificates are normally bought one by one, the 1830 brown
zone
> > case requires enabling more than one cert at a time. As you say, the
cert
> > type is passed around via its ID, but this ID is not actually used when
>
> the
>
> > purchase is executed: one (or more) certs are then searched afresh in
the
> > selling portfolio.
> >
> > I have not yet fully grasped why you conclude that this difference
> > between selling and buying logic did contribute to the Undo-caused
> > save/restore problem that has (hopefully) just been fixed. Could it be
> > the possibility that a share offered for buying is not the share
actually
> > bought (as explained above)? If so, that should be easy to fix: just buy
> > the share with the ID that has been passed around, and then (in the
brown
> > case) search for additional shares if requested.
> > (It might even have been that way originally; I vaguely remember having
> > changed this to simplify the code - that might then have been a
misguided
> > simplification.)
> >
> > If there would be a real need (or strong wish) to align buying and
> > selling on this aspect, I think we should go for using shares (rather
> > than certificates) all the way. But I'm not yet convinced that there is
a
>
> strong
>
> > case for such a change. In any case, such a change would need careful
> > precautions to avoid invalidating all current saved files.
> >
> > Erik
>
>
---------------------------------------------------------------------------
>- --
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
---------------------------------------------------------------------------
>--- This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel



----------------------------------------------------------------------------
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during CGRformation hangs game

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

Sorry: I did not disregard your observation, I forgot to go deeper into the 
details of the buy process:

You are right that you select the actual shares by type from the portfolio of 
the seller.
But how do you define the seller ("from")?
	PublicCertificateI cert = action.getCertificate();
        Portfolio from = cert.getPortfolio();

This is the owner of the certificate used in the action, which was stored by 
the ID.

ACTION: Player B buys a 10% share, Rails select #2 (buys are stored by id),
this moves the 10% share from A to B, leaving 10% in the pool!

For the case below, what happens exactly is that you have stored certificate 
#2. The owner is still A. Thus you have wrongly defined from and then you 
select one the shares from the wrong owner.

Thus another fix would have been to use the from field of the action instead 
of the from of certificate, but this does not go to the root of the problem:

The real problem is that in general you have to decide either to use reference 
by ID or reference by type, but not a mixture of both (at least for the 
storage of actions).

I am not really decided, which direction I prefer, in general I would prefer 
IDs, but this is not by a wide margin. You will know better, which method is 
more widespread in Rails so far, thus I follow your decision.

The good thing will be that in both cases the ordering of interchangeable 
objects will play no role anymore. By type the ordering is meaningless, by ID 
there is always an order defined. 

Stefan



On Sunday 18 July 2010 19:26:06 Erik Vos wrote:
> OK, it's getting clear to me now.
>
> You disregard my observation that the certificate ID specified in a buy
> action is NOT used, but that the certificate transferred is selected
> afresh. It's not so easy to sort out if this second certificate selection
> process will give the same result as the first, or not. Neither is it clear
> to me if this detail makes the situation better or worse.
>
> In any case, I'm getting more and more convinced that the use of unique IDs
> is the weak spot here, and that BuyCertificate should be modified to
> specify shares in a similar way as SellShares does.
>
> Erik.
>
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Sunday 18 July 2010 00:07
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during
> CGRformation hangs game
>
> Erik:
> as a follow up to your current fixes:
> Maybe it is my fault that I am not able to fully explain the issue.
> I do NOT claim that there is anything wrong with your fixes, thus
> I will try to focus on why I think removing the mixture of referring by
> type
>
> and by id protects against several cases of (future) potential problems.
>
> There are two (main) cases two distinguish:
> A) The interchangable objects (like 10% shares) are stored in an ordered
> collection (like an arraylist).
>
> Then the mixing of actions that refer by ID and by type is a (necessary,
> but
>
> not sufficient) condition to the undo/reload-related problems we had.
> The additional conditions are that the ordering of the storage collection
> is
>
> not observed during undos and that undos are not stored in the save files.
>
> I will give a simple example for that:
> START: Player A has two 10% shares of company B&O (order in the portfolio
> #1
>
> and #2). The pool is empty.
> ACTION: Player A sells a 10% share, Rails selects #1
> UNDO: order in the portfoliio is now (#2, #1)
> ACTION: Player A sells a 10% share, Rails selects #2
> ACTION: Player B buys a 10% share from the Pool, Rails selects #2
>
> On Reload the sequence is:
> ACTION: Player A sells a 10% share, Rails selects #1 (sells are stored by
> type)
> ACTION: Player B buys a 10% share, Rails select #2 (buys are stored by id),
> this moves the 10% share from A to B, leaving 10% in the pool!
>
> Thus fixing of any of the three conditions (mixing reference type, ordering
> of
> portfolios, non-saving of undos) above potentially prevents the problem.
>
> B) The interchangable objects are stored in an un-ordered collection (liek
> a
>
> HashSet or HashMap)
>
> Here the problem arises much simpler: Here mixing of id and type
> referencing
>
> alone is sufficient to cause a reload problem. Now not even a undo is
> necessary.
>
> Again a simple example:
> START: Player A has two 10% shares of company B&O (unordered portfolio #1
> and
> #2). The pool is empty.
> ACTION: Player A sells a 10% share, Rails selects (randomly) #2
> ACTION: Player B buys a 10% share, Rails selects #2
>
> On Reload the sequence can be (in 50% of the cases):
> ACTION: Player A sells a 10% share, Rails selects (randomly) #1 (sells are
> stored by type)
> ACTION: Player B buys a 10% share, Rails selects #2  (buys are stored by
> id),
> this moves a 10% share from A to B, leaving 10% in the pool!
>
> This problem does not occur (at least it was not observed so far), but it
> can
> only be avoided by either not mixing referencing by id and by type or never
> use an unordered collection.
>
> It is mainly case B) that I want to protects us from, as an unordered
> collection seems a valid choice for interchangable objects.
>
> But I agree that it might be the best to wait for the time, where the
> downward
> compatibility will be broken anyway.
>
> Stefan
>
> On Saturday 17 July 2010 13:55:35 you wrote:
> > Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during CGR
> > formation
> > hangs game
> > Date: Monday 21 June 2010
> > From: Stefan Frey <ste...@we...>
> > To: "Development list for Rails: an 18xx game"
> > <rai...@li...>
> >
> > 1) The BuyCertificates action stores certificate by id
> > 2) The SellShares action only stores percentages sold
> >
> > The main issue is mixing addressing interchangeable objects once by ids
>
> and
>
> > in
> > the other case by type. This can only work, if evey selection by type
>
> works
>
> > deterministically (thus never from unordered collections etc.) and the
>
> undo
>
> > mechanism strictly restores the previous ordering.
> >
> > Stefan
> >
> > [EV] IIRC, in a follow-up you suggested to always use certificate IDs in
> > the share buying and selling action.
> >
> > However, there is a reason behind this difference. Whereas you always buy
> > *certificates* (normally one), you don't sell certificates but *shares*.
> > The share/certificate distinction makes no difference except in the case
> > where you sell half a president's certificate.
> > Say player A has a 20% presidency and player B has 2 10% shares. Player A
> > can then sell a 10% share - even if he does not own a 10% certificate.
> > That's why I think selling can be done in no other way than by selling
> > *shares*.
> >
> > Although certificates are normally bought one by one, the 1830 brown zone
> > case requires enabling more than one cert at a time. As you say, the cert
> > type is passed around via its ID, but this ID is not actually used when
>
> the
>
> > purchase is executed: one (or more) certs are then searched afresh in the
> > selling portfolio.
> >
> > I have not yet fully grasped why you conclude that this difference
> > between selling and buying logic did contribute to the Undo-caused
> > save/restore problem that has (hopefully) just been fixed. Could it be
> > the possibility that a share offered for buying is not the share actually
> > bought (as explained above)? If so, that should be easy to fix: just buy
> > the share with the ID that has been passed around, and then (in the brown
> > case) search for additional shares if requested.
> > (It might even have been that way originally; I vaguely remember having
> > changed this to simplify the code - that might then have been a misguided
> > simplification.)
> >
> > If there would be a real need (or strong wish) to align buying and
> > selling on this aspect, I think we should go for using shares (rather
> > than certificates) all the way. But I'm not yet convinced that there is a
>
> strong
>
> > case for such a change. In any case, such a change would need careful
> > precautions to avoid invalidating all current saved files.
> >
> > Erik
>
> ---------------------------------------------------------------------------
>- --
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ---------------------------------------------------------------------------
>--- This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Added prototype configuration UI

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

 
-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Sunday 18 July 2010 19:35
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Added prototype configuration UI

Unfortunately the 
merge mechanism was totally confused by some other changes (import 
statements, white space) from your side, 

[EV]. Yes, I have noticed that the commit messages I'm getting from SVN
abound of unnecessary formatting and import-collapsing differences.
Not sure what the cause is. I did change my Eclipse version recently,
together with the change to SVN, but I have transferred the formatting
rules. In any case, I always have collapsed imports when there are >=3
classes of the same package, and have used spaces in stead of tabs. Not sure
what went wrong.

Two remarks:
* Please replace the -Dlog4j= option with -Dlog4j.configuration= 
to set your user-defined log4j configuration file.
Does not make much sense to use one system property to write it to another 
already defined by log4j. 

[EV] Yes, that makes sense! Works fine.

Erik.

Re: [Rails-devel] Added prototype configuration UI

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

Erik,
sorry for the confusion. The explanation is below.

I did a few changes on Config at the same time of your fix. Unfortunately the 
merge mechanism was totally confused by some other changes (import 
statements, white space) from your side, thus I had to integrate the fix 
manually. Could you please check that it still works.

Two remarks:
* Please replace the -Dlog4j= option with -Dlog4j.configuration= 
to set your user-defined log4j configuration file.
Does not make much sense to use one system property to write it to another 
already defined by log4j. 

* Unfortunately I only tested mine with a copy of log4j.properties, but did 
not change anything the file content.
The program worked before, but only by chance:
I have used the default name for a log4j configuration file, thus even if 
log4j.configuration was not set, it fell back automatically to that file.

Thanks,
Stefan


On Sunday 18 July 2010 19:07:23 Erik Vos wrote:
> Stefan,
>
> Your fix didn't work yet, because logging was initialised (by creating a
> logger in Config) before the relevant system property was set. I have
> changed Config by deferring logger initialisation until just after the
> system property is set, and now I'm fine.
>
> Erik.
>
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Sunday 18 July 2010 00:38
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Added prototype configuration UI
>
> I have added a -Dlog4j option that can specify a file, which contains the
> log4j settings. It can point to the same file as -Dconfigfile.
>
>
>
> ---------------------------------------------------------------------------
>--- This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during CGRformation hangs game

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

OK, it's getting clear to me now. 

You disregard my observation that the certificate ID specified in a buy
action is NOT used, but that the certificate transferred is selected afresh.
It's not so easy to sort out if this second certificate selection process
will give the same result as the first, or not. Neither is it clear to me if
this detail makes the situation better or worse.

In any case, I'm getting more and more convinced that the use of unique IDs
is the weak spot here, and that BuyCertificate should be modified to specify
shares in a similar way as SellShares does.

Erik.

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Sunday 18 July 2010 00:07
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during
CGRformation hangs game

Erik:
as a follow up to your current fixes:
Maybe it is my fault that I am not able to fully explain the issue.
I do NOT claim that there is anything wrong with your fixes, thus
I will try to focus on why I think removing the mixture of referring by type

and by id protects against several cases of (future) potential problems. 

There are two (main) cases two distinguish: 
A) The interchangable objects (like 10% shares) are stored in an ordered 
collection (like an arraylist).

Then the mixing of actions that refer by ID and by type is a (necessary, but

not sufficient) condition to the undo/reload-related problems we had.
The additional conditions are that the ordering of the storage collection is

not observed during undos and that undos are not stored in the save files.

I will give a simple example for that:
START: Player A has two 10% shares of company B&O (order in the portfolio #1

and #2). The pool is empty.
ACTION: Player A sells a 10% share, Rails selects #1
UNDO: order in the portfoliio is now (#2, #1)
ACTION: Player A sells a 10% share, Rails selects #2
ACTION: Player B buys a 10% share from the Pool, Rails selects #2

On Reload the sequence is:
ACTION: Player A sells a 10% share, Rails selects #1 (sells are stored by 
type)
ACTION: Player B buys a 10% share, Rails select #2 (buys are stored by id), 
this moves the 10% share from A to B, leaving 10% in the pool!

Thus fixing of any of the three conditions (mixing reference type, ordering
of 
portfolios, non-saving of undos) above potentially prevents the problem. 

B) The interchangable objects are stored in an un-ordered collection (liek a

HashSet or HashMap)

Here the problem arises much simpler: Here mixing of id and type referencing

alone is sufficient to cause a reload problem. Now not even a undo is 
necessary.

Again a simple example:
START: Player A has two 10% shares of company B&O (unordered portfolio #1
and 
#2). The pool is empty.
ACTION: Player A sells a 10% share, Rails selects (randomly) #2
ACTION: Player B buys a 10% share, Rails selects #2

On Reload the sequence can be (in 50% of the cases):
ACTION: Player A sells a 10% share, Rails selects (randomly) #1 (sells are 
stored by type)
ACTION: Player B buys a 10% share, Rails selects #2  (buys are stored by
id), 
this moves a 10% share from A to B, leaving 10% in the pool!

This problem does not occur (at least it was not observed so far), but it
can 
only be avoided by either not mixing referencing by id and by type or never 
use an unordered collection. 

It is mainly case B) that I want to protects us from, as an unordered 
collection seems a valid choice for interchangable objects.

But I agree that it might be the best to wait for the time, where the
downward 
compatibility will be broken anyway.

Stefan



On Saturday 17 July 2010 13:55:35 you wrote:
> Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during CGR
> formation
> hangs game
> Date: Monday 21 June 2010
> From: Stefan Frey <ste...@we...>
> To: "Development list for Rails: an 18xx game"
> <rai...@li...>
>
> 1) The BuyCertificates action stores certificate by id
> 2) The SellShares action only stores percentages sold
>
> The main issue is mixing addressing interchangeable objects once by ids
and
> in
> the other case by type. This can only work, if evey selection by type
works
> deterministically (thus never from unordered collections etc.) and the
undo
> mechanism strictly restores the previous ordering.
>
> Stefan
>
> [EV] IIRC, in a follow-up you suggested to always use certificate IDs in
> the share buying and selling action.
>
> However, there is a reason behind this difference. Whereas you always buy
> *certificates* (normally one), you don't sell certificates but *shares*.
> The share/certificate distinction makes no difference except in the case
> where you sell half a president's certificate.
> Say player A has a 20% presidency and player B has 2 10% shares. Player A
> can then sell a 10% share - even if he does not own a 10% certificate.
> That's why I think selling can be done in no other way than by selling
> *shares*.
>
> Although certificates are normally bought one by one, the 1830 brown zone
> case requires enabling more than one cert at a time. As you say, the cert
> type is passed around via its ID, but this ID is not actually used when
the
> purchase is executed: one (or more) certs are then searched afresh in the
> selling portfolio.
>
> I have not yet fully grasped why you conclude that this difference between
> selling and buying logic did contribute to the Undo-caused save/restore
> problem that has (hopefully) just been fixed. Could it be the possibility
> that a share offered for buying is not the share actually bought (as
> explained above)? If so, that should be easy to fix: just buy the share
> with the ID that has been passed around, and then (in the brown case)
> search for additional shares if requested.
> (It might even have been that way originally; I vaguely remember having
> changed this to simplify the code - that might then have been a misguided
> simplification.)
>
> If there would be a real need (or strong wish) to align buying and selling
> on this aspect, I think we should go for using shares (rather than
> certificates) all the way. But I'm not yet convinced that there is a
strong
> case for such a change. In any case, such a change would need careful
> precautions to avoid invalidating all current saved files.
>
> Erik



----------------------------------------------------------------------------
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Added prototype configuration UI

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

Stefan,

Your fix didn't work yet, because logging was initialised (by creating a
logger in Config) before the relevant system property was set. I have
changed Config by deferring logger initialisation until just after the
system property is set, and now I'm fine.

Erik.

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Sunday 18 July 2010 00:38
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Added prototype configuration UI

I have added a -Dlog4j option that can specify a file, which contains the 
log4j settings. It can point to the same file as -Dconfigfile.

[Rails-devel] BUG: 1889, 2p, Rails 1.3, Java errors

[Aliza P. <ali...@gm...>]

I've been playing a 2p 1889 with Jim Black over Dropbox, and about
half the time, when I go to operate a company I get Java errors
drawing the map.  I've been going back to a previous savefile and
re-entering Jim's moves, which works, but is getting VERY tedious.

Other times the map only displays partially when I pull it up, and
sometimes I can clear that by doing a stock action.

Here's the latest example:
=========================

C:\Documents and Settings\apanitz\My Documents\My Dropbox\1889 Tudor>cd C:\Aliza
\Gaming\18xx\Rails\rails-1.3\rails-1.3

C:\Aliza\Gaming\18xx\Rails\rails-1.3\rails-1.3>java -Duser.timezone=UTC -Dsave.f
ilename.suffix=NEXT_PLAYER -jar rails-1.3.jar "C:\Documents and Settings\apanitz
\My Documents\My Dropbox\1889 Tudor\1889_20100718_1505 Aliza.rails"
Cmdline configfile setting = null
Configuration file = my.properties
Number of args: 1
Arg: C:\Documents and Settings\apanitz\My Documents\My Dropbox\1889 Tudor\1889_2
0100718_1505 Aliza.rails
Starting game from saved file C:\Documents and Settings\apanitz\My Documents\My
Dropbox\1889 Tudor\1889_20100718_1505 Aliza.rails
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
        at rails.ui.swing.hexmap.GUITile.<init>(GUITile.java:54)
        at rails.ui.swing.hexmap.GUIHex.dropTile(GUIHex.java:726)
        at rails.ui.swing.ORUIManager.tileSelected(ORUIManager.java:691)
        at rails.ui.swing.UpgradesPanel.mouseClicked(UpgradesPanel.java:415)
        at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source)
        at java.awt.Component.processMouseEvent(Unknown Source)
        at javax.swing.JComponent.processMouseEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Container.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
        at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
        at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
=========================

Windows XP, fully patched, latest Java update.

Savefile attached, previous iterations available on request.

Re: [Rails-devel] Added prototype configuration UI

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

Erik,
I used (and still do) the same and this (should) still be supported by
the -Dconfigfile option.

I have added a -Dlog4j option that can specify a file, which contains the 
log4j settings. It can point to the same file as -Dconfigfile.


Going forward the -Dprofile option will allow to switch between different 
configuration profiles, which are ajdustable by the GUI.

I hope it works now.
Stefan


On Sunday 18 July 2010 00:17:24 Erik Vos wrote:
> Stefan,
>
> No, I use a separate properties file (called my_my.properties), because
> my.properties is linked to Subversion so I cannot tweak it.
> That's why I need the -Dconfigfile option.
>
> Now I find to my dismay that log4j.properties has been split off. But for
> the same reason I cannot tweak log4j.properties either, so I would need an
> additional command-line parameter to select my specific version of
> log4j.properties (which, by the way, contains an absolute path to the log
> file).
>
> I have tried to fix that by changing Config to set the log4j.configuration
> system property back to the configfile setting (i.e. my_my.properties) in
> case configfile is set, but that didn't remove the use of log4j.properties.
> But that's the way I would like to have it.
>
> Erik.
>
>
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Saturday 17 July 2010 23:17
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Added prototype configuration UI
>
> Erik:
> this seems to be an example of the Java paradigm:
> write once, debug everywhere...
>
> So the first questions are:
> * What was your configured setup? Did you use specific config file or did
> you
> use the standard my.properties?
>
> * Is the 18xx.log created in the current working directory as specified in
> the
> log4j.properties. Maybe you have different settings for the
> log4j.properties
>
> part than in default my.properties:
>
> Short explanation:
> - I separated the log4j settings from all the other Rails settings, as I
> assume that the log4j should not be edited by the user via a GUI.
> I can add a command line argument, that allows to pipe in a different log4j
> settings file.
>
> Next questions:
> * In my.properties the report options are all deactivated, thus on my PC
> the
>
> report file is not saved. It again seems that the
>
> Further explanation on the config mechanism:
> * The attributes, helptext etc. of the config options are defined in
> data/properties.xml
>
> * Configuration settings are collected as profiles, which are still
> Properties
> objects. There is a two layer structure: Default profiles, which ship with
> Rails .jar (which provides standard settings for pbem and ftp play) and
> user
>
> profiles, which collect user adjustments of the default profiles.
>
> * (A list of) Available user and default profiles are stored in
> default.profiles (stored in the jar) and user.profiles (which are itself
> Properties objects)
>
> I have updated the repo to my current setup, which works well on my PC.
> Keep me updated, what is the current state for you.
>
> Sorry for the unconvience, but I think it is better to find problems early,
> than implementing something for a long time, which will not work on the
> other
> OSs
>
> Stefan
>
> On Saturday 17 July 2010 22:18:59 Erik Vos wrote:
> > Apart from the recovery error message that I mentioned earlier today, I'm
> > noticing a few more oddities since this morning:
> >
> > - the 18xx.log file suddenly appears in a different location than before.
> >
> > - during initialisation, the log shows an exception like:
> > 2010-07-17 09:44:45 DEBUG  Report pathname is log/1889_01_20100717.log
> > (ReportBuffer openReportFile 120)
> > 2010-07-17 09:44:45 ERROR  Cannot open file log/1889_01_20100717.log
> > (ReportBuffer openReportFile 126)
> > java.io.FileNotFoundException: log\1889_01_20100717.log (The system
> > cannot find the path specified)
> > 	at java.io.FileOutputStream.open(Native Method)
> > 	at java.io.FileOutputStream.<init>(Unknown Source)
> > 	at java.io.FileOutputStream.<init>(Unknown Source)
> > 	at java.io.FileWriter.<init>(Unknown Source)
> > 	at rails.game.ReportBuffer.openReportFile(ReportBuffer.java:124)
> >
> > >From the above 2 points. it looks like the working directory has changed
> > > or
> >
> > something.
> >
> > - my.properties suddenly appears to be declared legacy (well, that must
> > be intentional ;)
> >
> > - I found a new file log4j.properties, which (if I understand the current
> > Config code right) is now mandatory to get logging started. Or not so?
> >
> > BTW So far I have always run Rails via GameTest (now that's legacy!).
> > Just checked RunGame, which seems to do the job as well for me.  But that
> > doesn't change the above findings.
> >
> > Erik.
> >
> >
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Friday 16 July 2010 23:18
> > To: Development list for Rails: an 18xx game
> > Subject: [Rails-devel] Added prototype configuration UI
> >
> > I have added some bits of an initial configuration user interface.
> > It should support the requirements discussed (it will allow to define
> > both default profiles and user ajdusted profiles) and the UI will be
> > adjustable via a xml file.
> > It can be accessed from the Status Window => Config.
> > Be aware that there is not much to see yet, but Rails still supports the
> > definition of a user provided configfile via -Dconfigfile.
> > I hope that everything else still works fine.
> > Stefan
>
> ---------------------------------------------------------------------------
>
> >- --
> > This SF.net email is sponsored by Sprint
> > What will you do first with EVO, the first 4G phone?
> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ---------------------------------------------------------------------------
>
> >--- This SF.net email is sponsored by Sprint
> > What will you do first with EVO, the first 4G phone?
> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ---------------------------------------------------------------------------
>- --
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ---------------------------------------------------------------------------
>--- This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Added prototype configuration UI

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

Stefan,

No, I use a separate properties file (called my_my.properties), because
my.properties is linked to Subversion so I cannot tweak it.
That's why I need the -Dconfigfile option.

Now I find to my dismay that log4j.properties has been split off. But for
the same reason I cannot tweak log4j.properties either, so I would need an
additional command-line parameter to select my specific version of
log4j.properties (which, by the way, contains an absolute path to the log
file).

I have tried to fix that by changing Config to set the log4j.configuration
system property back to the configfile setting (i.e. my_my.properties) in
case configfile is set, but that didn't remove the use of log4j.properties.
But that's the way I would like to have it.

Erik.


-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Saturday 17 July 2010 23:17
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Added prototype configuration UI

Erik:
this seems to be an example of the Java paradigm: 
write once, debug everywhere...

So the first questions are:
* What was your configured setup? Did you use specific config file or did
you 
use the standard my.properties?

* Is the 18xx.log created in the current working directory as specified in
the 
log4j.properties. Maybe you have different settings for the log4j.properties

part than in default my.properties: 

Short explanation:
- I separated the log4j settings from all the other Rails settings, as I 
assume that the log4j should not be edited by the user via a GUI.
I can add a command line argument, that allows to pipe in a different log4j 
settings file.

Next questions:
* In my.properties the report options are all deactivated, thus on my PC the

report file is not saved. It again seems that the 

Further explanation on the config mechanism:
* The attributes, helptext etc. of the config options are defined in 
data/properties.xml

* Configuration settings are collected as profiles, which are still
Properties 
objects. There is a two layer structure: Default profiles, which ship with 
Rails .jar (which provides standard settings for pbem and ftp play) and user

profiles, which collect user adjustments of the default profiles.

* (A list of) Available user and default profiles are stored in 
default.profiles (stored in the jar) and user.profiles (which are itself 
Properties objects)

I have updated the repo to my current setup, which works well on my PC.
Keep me updated, what is the current state for you.

Sorry for the unconvience, but I think it is better to find problems early, 
than implementing something for a long time, which will not work on the
other 
OSs

Stefan

On Saturday 17 July 2010 22:18:59 Erik Vos wrote:
> Apart from the recovery error message that I mentioned earlier today, I'm
> noticing a few more oddities since this morning:
>
> - the 18xx.log file suddenly appears in a different location than before.
>
> - during initialisation, the log shows an exception like:
> 2010-07-17 09:44:45 DEBUG  Report pathname is log/1889_01_20100717.log
> (ReportBuffer openReportFile 120)
> 2010-07-17 09:44:45 ERROR  Cannot open file log/1889_01_20100717.log
> (ReportBuffer openReportFile 126)
> java.io.FileNotFoundException: log\1889_01_20100717.log (The system cannot
> find the path specified)
> 	at java.io.FileOutputStream.open(Native Method)
> 	at java.io.FileOutputStream.<init>(Unknown Source)
> 	at java.io.FileOutputStream.<init>(Unknown Source)
> 	at java.io.FileWriter.<init>(Unknown Source)
> 	at rails.game.ReportBuffer.openReportFile(ReportBuffer.java:124)
>
> >From the above 2 points. it looks like the working directory has changed
> > or
>
> something.
>
> - my.properties suddenly appears to be declared legacy (well, that must be
> intentional ;)
>
> - I found a new file log4j.properties, which (if I understand the current
> Config code right) is now mandatory to get logging started. Or not so?
>
> BTW So far I have always run Rails via GameTest (now that's legacy!). Just
> checked RunGame, which seems to do the job as well for me.  But that
> doesn't change the above findings.
>
> Erik.
>
>
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Friday 16 July 2010 23:18
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] Added prototype configuration UI
>
> I have added some bits of an initial configuration user interface.
> It should support the requirements discussed (it will allow to define both
> default profiles and user ajdusted profiles) and the UI will be adjustable
> via a xml file.
> It can be accessed from the Status Window => Config.
> Be aware that there is not much to see yet, but Rails still supports the
> definition of a user provided configfile via -Dconfigfile.
> I hope that everything else still works fine.
> Stefan
>
>
---------------------------------------------------------------------------
>- --
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
---------------------------------------------------------------------------
>--- This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel



----------------------------------------------------------------------------
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during CGR formation hangs game

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

Erik:
as a follow up to your current fixes:
Maybe it is my fault that I am not able to fully explain the issue.
I do NOT claim that there is anything wrong with your fixes, thus
I will try to focus on why I think removing the mixture of referring by type 
and by id protects against several cases of (future) potential problems. 

There are two (main) cases two distinguish: 
A) The interchangable objects (like 10% shares) are stored in an ordered 
collection (like an arraylist).

Then the mixing of actions that refer by ID and by type is a (necessary, but 
not sufficient) condition to the undo/reload-related problems we had.
The additional conditions are that the ordering of the storage collection is 
not observed during undos and that undos are not stored in the save files.

I will give a simple example for that:
START: Player A has two 10% shares of company B&O (order in the portfolio #1 
and #2). The pool is empty.
ACTION: Player A sells a 10% share, Rails selects #1
UNDO: order in the portfoliio is now (#2, #1)
ACTION: Player A sells a 10% share, Rails selects #2
ACTION: Player B buys a 10% share from the Pool, Rails selects #2

On Reload the sequence is:
ACTION: Player A sells a 10% share, Rails selects #1 (sells are stored by 
type)
ACTION: Player B buys a 10% share, Rails select #2 (buys are stored by id), 
this moves the 10% share from A to B, leaving 10% in the pool!

Thus fixing of any of the three conditions (mixing reference type, ordering of 
portfolios, non-saving of undos) above potentially prevents the problem. 

B) The interchangable objects are stored in an un-ordered collection (liek a 
HashSet or HashMap)

Here the problem arises much simpler: Here mixing of id and type referencing 
alone is sufficient to cause a reload problem. Now not even a undo is 
necessary.

Again a simple example:
START: Player A has two 10% shares of company B&O (unordered portfolio #1 and 
#2). The pool is empty.
ACTION: Player A sells a 10% share, Rails selects (randomly) #2
ACTION: Player B buys a 10% share, Rails selects #2

On Reload the sequence can be (in 50% of the cases):
ACTION: Player A sells a 10% share, Rails selects (randomly) #1 (sells are 
stored by type)
ACTION: Player B buys a 10% share, Rails selects #2  (buys are stored by id), 
this moves a 10% share from A to B, leaving 10% in the pool!

This problem does not occur (at least it was not observed so far), but it can 
only be avoided by either not mixing referencing by id and by type or never 
use an unordered collection. 

It is mainly case B) that I want to protects us from, as an unordered 
collection seems a valid choice for interchangable objects.

But I agree that it might be the best to wait for the time, where the downward 
compatibility will be broken anyway.

Stefan



On Saturday 17 July 2010 13:55:35 you wrote:
> Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during CGR
> formation
> hangs game
> Date: Monday 21 June 2010
> From: Stefan Frey <ste...@we...>
> To: "Development list for Rails: an 18xx game"
> <rai...@li...>
>
> 1) The BuyCertificates action stores certificate by id
> 2) The SellShares action only stores percentages sold
>
> The main issue is mixing addressing interchangeable objects once by ids and
> in
> the other case by type. This can only work, if evey selection by type works
> deterministically (thus never from unordered collections etc.) and the undo
> mechanism strictly restores the previous ordering.
>
> Stefan
>
> [EV] IIRC, in a follow-up you suggested to always use certificate IDs in
> the share buying and selling action.
>
> However, there is a reason behind this difference. Whereas you always buy
> *certificates* (normally one), you don't sell certificates but *shares*.
> The share/certificate distinction makes no difference except in the case
> where you sell half a president's certificate.
> Say player A has a 20% presidency and player B has 2 10% shares. Player A
> can then sell a 10% share - even if he does not own a 10% certificate.
> That's why I think selling can be done in no other way than by selling
> *shares*.
>
> Although certificates are normally bought one by one, the 1830 brown zone
> case requires enabling more than one cert at a time. As you say, the cert
> type is passed around via its ID, but this ID is not actually used when the
> purchase is executed: one (or more) certs are then searched afresh in the
> selling portfolio.
>
> I have not yet fully grasped why you conclude that this difference between
> selling and buying logic did contribute to the Undo-caused save/restore
> problem that has (hopefully) just been fixed. Could it be the possibility
> that a share offered for buying is not the share actually bought (as
> explained above)? If so, that should be easy to fix: just buy the share
> with the ID that has been passed around, and then (in the brown case)
> search for additional shares if requested.
> (It might even have been that way originally; I vaguely remember having
> changed this to simplify the code - that might then have been a misguided
> simplification.)
>
> If there would be a real need (or strong wish) to align buying and selling
> on this aspect, I think we should go for using shares (rather than
> certificates) all the way. But I'm not yet convinced that there is a strong
> case for such a change. In any case, such a change would need careful
> precautions to avoid invalidating all current saved files.
>
> Erik

Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during CGRformation hangs game

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

Follow-up: I have added a generic method Util.addToList() to simplify the
object-moving-to-a-list-at-a-given-position code.

While doing this, I realised that Undo does not yet identically restores all
affected lists.
For instance, in Portfolio.addCertificate(), three lists are updated when a
certificate is added: 
- an overall list of certs,
- a map of lists of certs per company,
- a map of lists of certs per type.

To fix that, I'm now passing down an int array, with the location in each
list from which the objects are removed.

Erik.

-----Original Message-----
From: Erik Vos [mailto:eri...@xs...] 
Sent: Saturday 17 July 2010 13:11
To: 'Development list for Rails: an 18xx game'
Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during
CGRformation hangs game

I have fixed this problem by ensuring that undoing any ObjectMove will
always restore the original stack order.

This covers most object types; I think only price token moves are not
included as these follow a different paradigm, but in that case stack order
restoration had already been dealt with previously. 

The case in question now works correctly. I have also tested against a
number of longish test cases, and these all work. My testing revealed
another bug, where price tokens moving upwards vanished in the empty upper
left corner of the 1835 stock chart. That bug is now also fixed. 

I'll will have another look at ObjectMoves, because I think the code can be
simplified by providing simpler way to find in which List any Moveable
object is held by its owner. Perhaps price token moves can then also be
rewritten as ObjectMoves.

I'll discuss another point raised below by Stefan in a next post.

Erik.


-----Original Message-----
From: ste...@we... [mailto:ste...@we...] 
Sent: Tuesday 13 July 2010 23:35
To: Erik Vos
Subject: Fwd: Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during CGR
formation hangs game

Fowarding test case for sequenc problem.

----------  Forwarded Message  ----------

Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during CGR
formation 
hangs game
Date: Monday 21 June 2010
From: Stefan Frey <ste...@we...>
To: "Development list for Rails: an 18xx game" 
<rai...@li...>

Erik:
Just some follow-up to the issue. I explain it with an example, as it 
might be an instructive case to remember for potential issues with the
undo-function in Rails.

This bug is easily reproducible under simplified conditions. I attach the
save 
file for the example.

There are several steps involved (see example file)
A) Owner of AR (player David, owns 50%) sells a (single) certificate
B) Undo this action
C) Player A sells a (single) certificate again
D) Other player (Alice) buys that share from the pool
E) Save Game: 
Until then everything looks fine: David owns 40%. Alice owns 10%
F) Reload game: 
Now David owns only 30%, Alice owns 10%, the Pool has 10%!

What happened internally: You have to be aware, that certificates are 
internally identified by ids. Assume that David has single certificates 
called AR-1 to AR-3.

A) David sells 10% certificate (assume that this is certificate AR-1)
B) Undo that action (now AR-1 comes to the bottom of his certificates)
C) David sells 10% again, but now this is certificate AR-2
D) Alice buys AR-2 from the pool
E) save only saves actions, which were not undone (thus actions C and D)
F) on the reload for C) AR-1 gets sold to the Pool, but in D) Alice still
buys 
AR-2, but the previous owner is now not the Pool, but David!

The reason is a combination of issues:
1) The BuyCertificates action stores certificate by id
2) The SellShares action only stores percentages sold
3) The Undoing of share moves does not keep the order of certificates

By changing any of the three the problem can be solved.
The main issue is mixing addressing interchangeable objects once by ids and
in 
the other case by type. This can only work, if evey selection by type works 
deterministically (thus never from unordered collections etc.) and the undo 
mechanism strictly restores the previous ordering.

Stefan



----------------------------------------------------------------------------
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1851 - Operating Company can't sell a share twicein one turn

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

I agree with Brett, that in general a specific option might be the path to 
follow.

To not forget the original intention of the bug report:

I have fixed the bug that prevented the selling of several shares (hasSold 
instead of hasBought check in TreasuryShareRound). This activates the correct 
check that prevents selling after buying.

Stefan

On Friday 16 July 2010 22:47:37 brett lentz wrote:
> On Fri, Jul 16, 2010 at 12:39 PM, Erik Vos <eri...@xs...> wrote:
> > In Rails, all sell *actions* of shares of the same company (without
> > intervening buy action) constitute one *transaction*, for the purpose of
> > price setting and/or price movement.
> >
> > The one game that necessitates this behaviour is 1835, where most
> > companies have both (non-president) 10% and 20%, or 5% and 10% share
> > certificates. The Rails selling mechanic allows selling only one such
> > share unit type in one *action*. So if you want to sell one 5% share and
> > one 10% share of PR at the same price, two actions are required to make
> > one transaction.
> >
> > That's the main reason behind this behaviour. And yes, it precludes
> > repeated selling in one turn at a lower price after each action, as some
> > people would like to have it. We could add an option that allows this,
> > but that option, when selected, would have a probably unwanted side
> > effect on 1835.
>
> I would like to see this option exist, but only for games that allow
> it. Perhaps a game-specific XML option is the way to go here?
>
> > Erik.
>
> ---Brett.
>
> > -----Original Message-----
> > From: Phil Davies [mailto:de...@gm...]
> > Sent: Friday 16 July 2010 10:28
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] 1851 - Operating Company can't sell a share
> > twicein one turn
> >
> > I don't believe there is a general consensus among all players but I
> > would like to think that the prevailing opinion is that in games where
> > selling a 'block' of shares causes a price drop, you cannot sell 1,
> > then sell 1, then sell 1 without passing in between and allowing other
> > people to react.  If you specifically want to sell to drop the price
> > and are happy to take the hit then you have to sell, let the other
> > players have a turn each to react, then sell again.
> >
> > Now, this refers to stock round actions and 1851 where a company is
> > selling/buying is an operating round action.  It's not clear from the
> > rules I agree but the way we always play these games face to face is
> > that each company gets one 'transaction', that is either sell or buy,
> > and if you can do as many certs as you like in that transaction.  We
> > mostly apply this to EU.
> >
> > This is only really an issue when you drop one row per block, that
> > doesn't happen in 1851, so despite the fact that the 'correct' way of
> > doing it would be to just choose to sell all the shares you want in
> > the first transaction, someone could theoretically sell 1, sell 1,
> > sell 1 and it won't make any difference to the gamestate than selling
> > 3 in one transaction, so in this case it should be allowed (despite
> > the fact that the user could just click 'undo' then sell the correct
> > number of shares as a faster way of doing it.  I'm just trying to
> > think of what makes a more pleasant user experience, they shouldn't
> > really be left confused because they didn't spot the dropdown box on
> > the sell screen
> >
> > Phil
> >
> > On 15 July 2010 22:49, Stefan Frey <ste...@we...> wrote:
> >> A current open bug report for 1851:
> >>> When I try to sell a second company share during that company's
> >>> operating round, Rails says I can't sell after buying. This appears to
> >>> be inconsistent with the rules.
> >>
> >> refers to the fact that it is not possible to sell other shares from the
> >> Treasury after a first sell transaction (and the error message is
> >
> > confusing).
> >
> >> Question is, similar to the discussion we had previously on selling in
> >> separate transactions but same player turn in 1835, 1830 and 1870:
> >>
> >> Should the second transaction use the initial price at the start of the
> >> players turn (thus identical to the one used for the first transaction)
> >> or the reduced price taking the the stock market reaction into account?
> >>
> >> I have not found a ruling in 1851, thus I am inclined to follow the
> >
> > current
> >
> >> standard implementation in Rails (identical to the first transaction),
> >> however - if I remember correctly - there was no general consensus for
> >
> > this
> >
> >> (at least for 1830).
> >>
> >> Stefan
> >
> > -------------------------------------------------------------------------
> >--- --
> >
> >> This SF.net email is sponsored by Sprint
> >> What will you do first with EVO, the first 4G phone?
> >> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > -------------------------------------------------------------------------
> >--- --
> > This SF.net email is sponsored by Sprint
> > What will you do first with EVO, the first 4G phone?
> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> > -------------------------------------------------------------------------
> >----- This SF.net email is sponsored by Sprint
> > What will you do first with EVO, the first 4G phone?
> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ---------------------------------------------------------------------------
>--- This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Added prototype configuration UI

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

Erik:
this seems to be an example of the Java paradigm: 
write once, debug everywhere...

So the first questions are:
* What was your configured setup? Did you use specific config file or did you 
use the standard my.properties?

* Is the 18xx.log created in the current working directory as specified in the 
log4j.properties. Maybe you have different settings for the log4j.properties 
part than in default my.properties: 

Short explanation:
- I separated the log4j settings from all the other Rails settings, as I 
assume that the log4j should not be edited by the user via a GUI.
I can add a command line argument, that allows to pipe in a different log4j 
settings file.

Next questions:
* In my.properties the report options are all deactivated, thus on my PC the 
report file is not saved. It again seems that the 

Further explanation on the config mechanism:
* The attributes, helptext etc. of the config options are defined in 
data/properties.xml

* Configuration settings are collected as profiles, which are still Properties 
objects. There is a two layer structure: Default profiles, which ship with 
Rails .jar (which provides standard settings for pbem and ftp play) and user 
profiles, which collect user adjustments of the default profiles.

* (A list of) Available user and default profiles are stored in 
default.profiles (stored in the jar) and user.profiles (which are itself 
Properties objects)

I have updated the repo to my current setup, which works well on my PC.
Keep me updated, what is the current state for you.

Sorry for the unconvience, but I think it is better to find problems early, 
than implementing something for a long time, which will not work on the other 
OSs

Stefan

On Saturday 17 July 2010 22:18:59 Erik Vos wrote:
> Apart from the recovery error message that I mentioned earlier today, I'm
> noticing a few more oddities since this morning:
>
> - the 18xx.log file suddenly appears in a different location than before.
>
> - during initialisation, the log shows an exception like:
> 2010-07-17 09:44:45 DEBUG  Report pathname is log/1889_01_20100717.log
> (ReportBuffer openReportFile 120)
> 2010-07-17 09:44:45 ERROR  Cannot open file log/1889_01_20100717.log
> (ReportBuffer openReportFile 126)
> java.io.FileNotFoundException: log\1889_01_20100717.log (The system cannot
> find the path specified)
> 	at java.io.FileOutputStream.open(Native Method)
> 	at java.io.FileOutputStream.<init>(Unknown Source)
> 	at java.io.FileOutputStream.<init>(Unknown Source)
> 	at java.io.FileWriter.<init>(Unknown Source)
> 	at rails.game.ReportBuffer.openReportFile(ReportBuffer.java:124)
>
> >From the above 2 points. it looks like the working directory has changed
> > or
>
> something.
>
> - my.properties suddenly appears to be declared legacy (well, that must be
> intentional ;)
>
> - I found a new file log4j.properties, which (if I understand the current
> Config code right) is now mandatory to get logging started. Or not so?
>
> BTW So far I have always run Rails via GameTest (now that's legacy!). Just
> checked RunGame, which seems to do the job as well for me.  But that
> doesn't change the above findings.
>
> Erik.
>
>
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Friday 16 July 2010 23:18
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] Added prototype configuration UI
>
> I have added some bits of an initial configuration user interface.
> It should support the requirements discussed (it will allow to define both
> default profiles and user ajdusted profiles) and the UI will be adjustable
> via a xml file.
> It can be accessed from the Status Window => Config.
> Be aware that there is not much to see yet, but Rails still supports the
> definition of a user provided configfile via -Dconfigfile.
> I hope that everything else still works fine.
> Stefan
>
> ---------------------------------------------------------------------------
>- --
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ---------------------------------------------------------------------------
>--- This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Added prototype configuration UI

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

Apart from the recovery error message that I mentioned earlier today, I'm
noticing a few more oddities since this morning:

- the 18xx.log file suddenly appears in a different location than before.

- during initialisation, the log shows an exception like:
2010-07-17 09:44:45 DEBUG  Report pathname is log/1889_01_20100717.log
(ReportBuffer openReportFile 120) 
2010-07-17 09:44:45 ERROR  Cannot open file log/1889_01_20100717.log
(ReportBuffer openReportFile 126) 
java.io.FileNotFoundException: log\1889_01_20100717.log (The system cannot
find the path specified)
	at java.io.FileOutputStream.open(Native Method)
	at java.io.FileOutputStream.<init>(Unknown Source)
	at java.io.FileOutputStream.<init>(Unknown Source)
	at java.io.FileWriter.<init>(Unknown Source)
	at rails.game.ReportBuffer.openReportFile(ReportBuffer.java:124)

>From the above 2 points. it looks like the working directory has changed or
something.

- my.properties suddenly appears to be declared legacy (well, that must be
intentional ;)

- I found a new file log4j.properties, which (if I understand the current
Config code right) is now mandatory to get logging started. Or not so?

BTW So far I have always run Rails via GameTest (now that's legacy!). Just
checked RunGame, which seems to do the job as well for me.  But that doesn't
change the above findings.

Erik.


-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Friday 16 July 2010 23:18
To: Development list for Rails: an 18xx game
Subject: [Rails-devel] Added prototype configuration UI

I have added some bits of an initial configuration user interface. 
It should support the requirements discussed (it will allow to define both 
default profiles and user ajdusted profiles) and the UI will be adjustable 
via a xml file.
It can be accessed from the Status Window => Config. 
Be aware that there is not much to see yet, but Rails still supports the 
definition of a user provided configfile via -Dconfigfile.
I hope that everything else still works fine.
Stefan

----------------------------------------------------------------------------
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Simple patch to add revenue for privates onto theInfo menu

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

Good patch, Phil. I have applied it. 
(Don't understand why this didn't occur to me ;-))
Erik.

-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Friday 16 July 2010 18:08
To: Development list for Rails: an 18xx game
Subject: [Rails-devel] Simple patch to add revenue for privates onto theInfo
menu

Subject says it all really...not a massive change but one I've found
myself wanting

Phil

[Rails-devel] Recovery failure message

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

Stefan,

Since you have added the autosave feature I'm always getting the following
message when starting a game or loading a saved file:
"Recovery save failed, reason: file renaming not possible." This does not
inhibit running, but somewhat annoying it is.

I only can get rid of it by setting the property save.recovery.active=no
(which I'd rather have the default, but I suppose that's just me).

Erik.

Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during CGR formation hangs game

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

Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during CGR
formation 
hangs game
Date: Monday 21 June 2010
From: Stefan Frey <ste...@we...>
To: "Development list for Rails: an 18xx game" 
<rai...@li...>

1) The BuyCertificates action stores certificate by id
2) The SellShares action only stores percentages sold

The main issue is mixing addressing interchangeable objects once by ids and
in 
the other case by type. This can only work, if evey selection by type works 
deterministically (thus never from unordered collections etc.) and the undo 
mechanism strictly restores the previous ordering.

Stefan

[EV] IIRC, in a follow-up you suggested to always use certificate IDs in the
share buying and selling action.

However, there is a reason behind this difference. Whereas you always buy
*certificates* (normally one), you don't sell certificates but *shares*. The
share/certificate distinction makes no difference except in the case where
you sell half a president's certificate. 
Say player A has a 20% presidency and player B has 2 10% shares. Player A
can then sell a 10% share - even if he does not own a 10% certificate.
That's why I think selling can be done in no other way than by selling
*shares*.

Although certificates are normally bought one by one, the 1830 brown zone
case requires enabling more than one cert at a time. As you say, the cert
type is passed around via its ID, but this ID is not actually used when the
purchase is executed: one (or more) certs are then searched afresh in the
selling portfolio. 

I have not yet fully grasped why you conclude that this difference between
selling and buying logic did contribute to the Undo-caused save/restore
problem that has (hopefully) just been fixed. Could it be the possibility
that a share offered for buying is not the share actually bought (as
explained above)? If so, that should be easy to fix: just buy the share with
the ID that has been passed around, and then (in the brown case) search for
additional shares if requested. 
(It might even have been that way originally; I vaguely remember having
changed this to simplify the code - that might then have been a misguided
simplification.)

If there would be a real need (or strong wish) to align buying and selling
on this aspect, I think we should go for using shares (rather than
certificates) all the way. But I'm not yet convinced that there is a strong
case for such a change. In any case, such a change would need careful
precautions to avoid invalidating all current saved files. 

Erik

Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during CGR formation hangs game

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

I have fixed this problem by ensuring that undoing any ObjectMove will
always restore the original stack order.

This covers most object types; I think only price token moves are not
included as these follow a different paradigm, but in that case stack order
restoration had already been dealt with previously. 

The case in question now works correctly. I have also tested against a
number of longish test cases, and these all work. My testing revealed
another bug, where price tokens moving upwards vanished in the empty upper
left corner of the 1835 stock chart. That bug is now also fixed. 

I'll will have another look at ObjectMoves, because I think the code can be
simplified by providing simpler way to find in which List any Moveable
object is held by its owner. Perhaps price token moves can then also be
rewritten as ObjectMoves.

I'll discuss another point raised below by Stefan in a next post.

Erik.


-----Original Message-----
From: ste...@we... [mailto:ste...@we...] 
Sent: Tuesday 13 July 2010 23:35
To: Erik Vos
Subject: Fwd: Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during CGR
formation hangs game

Fowarding test case for sequenc problem.

----------  Forwarded Message  ----------

Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during CGR
formation 
hangs game
Date: Monday 21 June 2010
From: Stefan Frey <ste...@we...>
To: "Development list for Rails: an 18xx game" 
<rai...@li...>

Erik:
Just some follow-up to the issue. I explain it with an example, as it 
might be an instructive case to remember for potential issues with the
undo-function in Rails.

This bug is easily reproducible under simplified conditions. I attach the
save 
file for the example.

There are several steps involved (see example file)
A) Owner of AR (player David, owns 50%) sells a (single) certificate
B) Undo this action
C) Player A sells a (single) certificate again
D) Other player (Alice) buys that share from the pool
E) Save Game: 
Until then everything looks fine: David owns 40%. Alice owns 10%
F) Reload game: 
Now David owns only 30%, Alice owns 10%, the Pool has 10%!

What happened internally: You have to be aware, that certificates are 
internally identified by ids. Assume that David has single certificates 
called AR-1 to AR-3.

A) David sells 10% certificate (assume that this is certificate AR-1)
B) Undo that action (now AR-1 comes to the bottom of his certificates)
C) David sells 10% again, but now this is certificate AR-2
D) Alice buys AR-2 from the pool
E) save only saves actions, which were not undone (thus actions C and D)
F) on the reload for C) AR-1 gets sold to the Pool, but in D) Alice still
buys 
AR-2, but the previous owner is now not the Pool, but David!

The reason is a combination of issues:
1) The BuyCertificates action stores certificate by id
2) The SellShares action only stores percentages sold
3) The Undoing of share moves does not keep the order of certificates

By changing any of the three the problem can be solved.
The main issue is mixing addressing interchangeable objects once by ids and
in 
the other case by type. This can only work, if evey selection by type works 
deterministically (thus never from unordered collections etc.) and the undo 
mechanism strictly restores the previous ordering.

Stefan

Re: [Rails-devel] 1851 - Operating Company can't sell a share twice in one turn

[NetGamer <net...@tw...>]

I filed this bug. Phil hit the nail on the head - I didn't catch there 
being a drop down to allow selecting more than one share to put in the 
pool at once and was expecting to be able to repeat the action - as 
desired.

To the other point that was raised around the net impact being the same: 
1851 ruleset is a bit different but is intended to be more friendly to 
new players. Selling off a treasury share one at a time during one's 
operating round would be in the spirit of the design - more friendly.

-Ron

Phil Davies wrote:
> I don't believe there is a general consensus among all players but I
> would like to think that the prevailing opinion is that in games where
> selling a 'block' of shares causes a price drop, you cannot sell 1,
> then sell 1, then sell 1 without passing in between and allowing other
> people to react.  If you specifically want to sell to drop the price
> and are happy to take the hit then you have to sell, let the other
> players have a turn each to react, then sell again.
>
> Now, this refers to stock round actions and 1851 where a company is
> selling/buying is an operating round action.  It's not clear from the
> rules I agree but the way we always play these games face to face is
> that each company gets one 'transaction', that is either sell or buy,
> and if you can do as many certs as you like in that transaction.  We
> mostly apply this to EU.
>
> This is only really an issue when you drop one row per block, that
> doesn't happen in 1851, so despite the fact that the 'correct' way of
> doing it would be to just choose to sell all the shares you want in
> the first transaction, someone could theoretically sell 1, sell 1,
> sell 1 and it won't make any difference to the gamestate than selling
> 3 in one transaction, so in this case it should be allowed (despite
> the fact that the user could just click 'undo' then sell the correct
> number of shares as a faster way of doing it.  I'm just trying to
> think of what makes a more pleasant user experience, they shouldn't
> really be left confused because they didn't spot the dropdown box on
> the sell screen
>
> Phil
>
> On 15 July 2010 22:49, Stefan Frey <ste...@we...> wrote:
>   
>> A current open bug report for 1851:
>>     
>>> When I try to sell a second company share during that company's operating
>>> round, Rails says I can't sell after buying. This appears to be
>>> inconsistent with the rules.
>>>       
>> refers to the fact that it is not possible to sell other shares from the
>> Treasury after a first sell transaction (and the error message is confusing).
>>
>> Question is, similar to the discussion we had previously on selling in
>> separate transactions but same player turn in 1835, 1830 and 1870:
>>
>> Should the second transaction use the initial price at the start of the
>> players turn (thus identical to the one used for the first transaction) or
>> the reduced price taking the the stock market reaction into account?
>>
>> I have not found a ruling in 1851, thus I am inclined to follow the current
>> standard implementation in Rails (identical to the first transaction),
>> however - if I remember correctly - there was no general consensus for this
>> (at least for 1830).
>>
>> Stefan
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>     
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>   

Re: [Rails-devel] 1851 - Operating Company can't sell a sharetwicein one turn

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

On Fri, Jul 16, 2010 at 3:53 PM, Erik Vos <eri...@xs...> wrote:
>> We could add an option that allows this, but that option,
>> when selected, would have a probably unwanted side effect on 1835.
>>
>
> I would like to see this option exist, but only for games that allow
> it.
>
> [EV] Meaning: all games except 1835?

For now, I think that's true.  It may not remain true as more games
are implemented.

> Erik.

---Brett.

Re: [Rails-devel] 1851 - Operating Company can't sell a sharetwicein one turn

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

> We could add an option that allows this, but that option,
> when selected, would have a probably unwanted side effect on 1835.
>

I would like to see this option exist, but only for games that allow
it. 

[EV] Meaning: all games except 1835?

Erik.

[Rails-devel] Added prototype configuration UI

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

I have added some bits of an initial configuration user interface. 
It should support the requirements discussed (it will allow to define both 
default profiles and user ajdusted profiles) and the UI will be adjustable 
via a xml file.
It can be accessed from the Status Window => Config. 
Be aware that there is not much to see yet, but Rails still supports the 
definition of a user provided configfile via -Dconfigfile.
I hope that everything else still works fine.
Stefan