rails-devel — List for discussion of Rails development

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

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

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
>

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

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

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.

Erik.

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

[Rails-devel] Simple patch to add revenue for privates onto the Info menu

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

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

Phil

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

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

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
>

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

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

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

Re: [Rails-devel] Two bug fixes - questions to Erik

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

Erik:
there was a test case for the sequence problem attached some time ago. 
I have forwarded that e-mail to you directly.

Stefan

Just some (random) thoughts on Tokens:
Going forward I think we can leverage on the TokenHolder interface. A helpful 
thing would be to register all TokenHolders to a TokenManager. This would for 
example allow to find all BaseTokens for RevenueCalculation. 

Maybe we could add for each Token a kind of workflow definition in XML, which 
defines possible TokenHolder locations and possible transitions between them:

For example:
* In standard games BaseTokens start in PublicCompanies portfolios and move to 
City locations. 
* Some BonusTokens start with PrivateCompanies move to PublicCompanies and 
then to MapHex locatons.


On Tuesday 13 July 2010 20:54:05 Erik Vos wrote:
> See below [EV2]
>
> > - From the code it seems that defining certificate types might help.
> >
> > [EV] You mean different types for 5% and 10% shares? Or what else? On
>
> first
>
> > sight I don't see much value in that.
>
> In the code you twice (once for buying and selling) extract those shares
> that
> have common properties. Certificates currently differ only for percentages
> (or
> number shares), certificate counts and president property.
>
> It would be easier to refactor that into if there would be a
> certificateTypes.
> Or one could proxy that by a getCertificateTypes(), which returns a list of
> certificates, which represent the different classes.
>
> But the main value lies in the for Rails typical two-tier structure, where
> a
>
> type of something is configured first and then instances are created
> derived
>
> from the type (like TrainType, CompanyType) etc. I am much in favor of that
> approach as it allows a lot of flexibility going foward.
>
> [EV2] My thinking was, that certificates of *one* company only differ in
> share percentage and presidency, and these differences can easily be
> represented by just two attributes. In several games, train types and
> company types have many more and more profound differences. That's why I
> don't see that much added value in certificate types. But I'm not at all
> opposed to such refactoring.
>
> > - The Buy action (still) do not store the certificate ids, if more than
>
> one
>
> > certificate is sold. The sell action does not store the ids at all. The
> > same
> >
> > is true for the Exchange for Share action. This poses the risk of reload
> > errors especially after undos.
> >
> > [EV] I remember you have discussed this before, but I haven't yet managed
> > to understand what exact problem storing certificate IDs would fix. Does
> > this relate to the known problem that items in lists are generally moved
>
> to
>
> > a different position after an undo? That shouldn't be difficult to fix,
>
> but
>
> > I haven't yet got to it. Pending that generic solution, I have fixed a
> > few apparent cases; there may be others, but I haven't any good examples.
>
> Sorry I thought you had mentioned that you already implemented that (but
> this
> referred to the brown stock spaces).
> Yes it is an alternative solution for the reload problems after undo.
>
> Advantages:
> A) It does not require the protection of order of the interchangable
> objects,
> which is somehow counterintuitive.
> B) It allows the use of HashMaps/HashSets to store the interchangable
> objects.
>
> But implementing both is the best protection, especially for future
> extensions, as - if I remember correctly - you need the order protection
> for
>
> the portfolio certificates already to keep the certificate ordering of the
> IPO stack in 1835
>
> I could give it a try, but it might break the savefile compatability. If
> that
> is the case it should be moved to a later release.
>
> [EV2] In any case, sequence preservation is high on my next-to-do list (the
> main obstacle being a lack of test cases).
>
> > [EV] There already is the concept of "off-station" tokens, which e.g.
> > applies to the 18AL coalfield token. Please note, that the code carefully
> > distinguishes between "base tokens" and "bonus tokens". Not sure how much
> > value the existing TokenI interface really has, but there many other
> > useless interfaces that I would rather ditch than this one.
>
> That is exactly the problem  TokenI: It is not totally useless (like some
> others. :-)), but still most of the time baseTokens and bonusTokens are
> treated separately. I was wondering for example, if I could replace the
> TokenI variables/methods for cities with a BaseToken signature and Rails
> would work identical: Or same question reverse: Is there a use case that
> requires a storage a BonusToken in a city object using the city's tokens
> variable?
>
> [EV2] Don't think so (though you can never know what creative 18xx
> designers will invent next year), but the reverse does occur. In 1870, base
> tokens can appear (without functional change) in off-station locations, so
> for that purpose alone I think we would need something like TokenI to
> specify the contents of off-station  spots on tiles, because in other games
> BonusTokens may appear on such tiles. 18FL is a bit different in that base
> tokens may metamorphose into BonusTokens (hotels) - or one could say: that
> game's tokens have a dual nature: another case for TokenI?
> In general I would have no problem to change TokenI into BaseToken or
> BonusToken wherever appropriate - I'm just not so sure if we can rely upon
> our current understanding of appropriateness.
>
> 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] Two bug fixes - questions to Erik

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

See below [EV2]

> - From the code it seems that defining certificate types might help. 

> [EV] You mean different types for 5% and 10% shares? Or what else? On
first
> sight I don't see much value in that.

In the code you twice (once for buying and selling) extract those shares
that 
have common properties. Certificates currently differ only for percentages
(or 
number shares), certificate counts and president property. 

It would be easier to refactor that into if there would be a
certificateTypes. 
Or one could proxy that by a getCertificateTypes(), which returns a list of 
certificates, which represent the different classes.

But the main value lies in the for Rails typical two-tier structure, where a

type of something is configured first and then instances are created derived

from the type (like TrainType, CompanyType) etc. I am much in favor of that 
approach as it allows a lot of flexibility going foward.

[EV2] My thinking was, that certificates of *one* company only differ in
share percentage and presidency, and these differences can easily be
represented by just two attributes. In several games, train types and
company types have many more and more profound differences. That's why I
don't see that much added value in certificate types. But I'm not at all
opposed to such refactoring.

>
> - The Buy action (still) do not store the certificate ids, if more than
one
> certificate is sold. The sell action does not store the ids at all. The
> same
>
> is true for the Exchange for Share action. This poses the risk of reload
> errors especially after undos.
>
> [EV] I remember you have discussed this before, but I haven't yet managed
> to understand what exact problem storing certificate IDs would fix. Does
> this relate to the known problem that items in lists are generally moved
to
> a different position after an undo? That shouldn't be difficult to fix,
but
> I haven't yet got to it. Pending that generic solution, I have fixed a few
> apparent cases; there may be others, but I haven't any good examples.

Sorry I thought you had mentioned that you already implemented that (but
this 
referred to the brown stock spaces).
Yes it is an alternative solution for the reload problems after undo.

Advantages:
A) It does not require the protection of order of the interchangable
objects, 
which is somehow counterintuitive.  
B) It allows the use of HashMaps/HashSets to store the interchangable
objects.

But implementing both is the best protection, especially for future 
extensions, as - if I remember correctly - you need the order protection for

the portfolio certificates already to keep the certificate ordering of the 
IPO stack in 1835

I could give it a try, but it might break the savefile compatability. If
that 
is the case it should be moved to a later release.

[EV2] In any case, sequence preservation is high on my next-to-do list (the
main obstacle being a lack of test cases). 

> [EV] There already is the concept of "off-station" tokens, which e.g.
> applies to the 18AL coalfield token. Please note, that the code carefully
> distinguishes between "base tokens" and "bonus tokens". Not sure how much
> value the existing TokenI interface really has, but there many other
> useless interfaces that I would rather ditch than this one.

That is exactly the problem  TokenI: It is not totally useless (like some 
others. :-)), but still most of the time baseTokens and bonusTokens are 
treated separately. I was wondering for example, if I could replace the 
TokenI variables/methods for cities with a BaseToken signature and Rails 
would work identical: Or same question reverse: Is there a use case that 
requires a storage a BonusToken in a city object using the city's tokens 
variable?

[EV2] Don't think so (though you can never know what creative 18xx designers
will invent next year), but the reverse does occur. In 1870, base tokens can
appear (without functional change) in off-station locations, so for that
purpose alone I think we would need something like TokenI to specify the
contents of off-station  spots on tiles, because in other games BonusTokens
may appear on such tiles. 18FL is a bit different in that base tokens may
metamorphose into BonusTokens (hotels) - or one could say: that game's
tokens have a dual nature: another case for TokenI? 
In general I would have no problem to change TokenI into BaseToken or
BonusToken wherever appropriate - I'm just not so sure if we can rely upon
our current understanding of appropriateness. 

Erik.

Re: [Rails-devel] Two bug fixes - questions to Erik

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

Erik,
seems that the amount of luck was not sufficient to beat the best team
of tne WorldCup. But coming home as second is not too bad.
Answers to the non-THB issues below.
Stefan

Quick answers see below:
> 3010534: 1856 1/2 share from limit can't buy 5% share of CGR
> - The reason was that the call to the certification limit test did not
> consider the certificate count (1/2 here), assuming that each certificate
> counts full.
>
> [EV] The easy fix would be to use the cert.count. Any problems with that?
Did that, no problem.

>
> - From the code it seems that defining certificate types might help. 

> [EV] You mean different types for 5% and 10% shares? Or what else? On first
> sight I don't see much value in that.

In the code you twice (once for buying and selling) extract those shares that 
have common properties. Certificates currently differ only for percentages (or 
number shares), certificate counts and president property. 

It would be easier to refactor that into if there would be a certificateTypes. 
Or one could proxy that by a getCertificateTypes(), which returns a list of 
certificates, which represent the different classes.

But the main value lies in the for Rails typical two-tier structure, where a 
type of something is configured first and then instances are created derived 
from the type (like TrainType, CompanyType) etc. I am much in favor of that 
approach as it allows a lot of flexibility going foward.

>
> - The Buy action (still) do not store the certificate ids, if more than one
> certificate is sold. The sell action does not store the ids at all. The
> same
>
> is true for the Exchange for Share action. This poses the risk of reload
> errors especially after undos.
>
> [EV] I remember you have discussed this before, but I haven't yet managed
> to understand what exact problem storing certificate IDs would fix. Does
> this relate to the known problem that items in lists are generally moved to
> a different position after an undo? That shouldn't be difficult to fix, but
> I haven't yet got to it. Pending that generic solution, I have fixed a few
> apparent cases; there may be others, but I haven't any good examples.

Sorry I thought you had mentioned that you already implemented that (but this 
referred to the brown stock spaces).
Yes it is an alternative solution for the reload problems after undo.

Advantages:
A) It does not require the protection of order of the interchangable objects, 
which is somehow counterintuitive.  
B) It allows the use of HashMaps/HashSets to store the interchangable objects.

But implementing both is the best protection, especially for future 
extensions, as - if I remember correctly - you need the order protection for 
the portfolio certificates already to keep the certificate ordering of the 
IPO stack in 1835

I could give it a try, but it might break the savefile compatability. If that 
is the case it should be moved to a later release.

> [EV] There already is the concept of "off-station" tokens, which e.g.
> applies to the 18AL coalfield token. Please note, that the code carefully
> distinguishes between "base tokens" and "bonus tokens". Not sure how much
> value the existing TokenI interface really has, but there many other
> useless interfaces that I would rather ditch than this one.

That is exactly the problem  TokenI: It is not totally useless (like some 
others. :-)), but still most of the time baseTokens and bonusTokens are 
treated separately. I was wondering for example, if I could replace the 
TokenI variables/methods for cities with a BaseToken signature and Rails 
would work identical: Or same question reverse: Is there a use case that 
requires a storage a BonusToken in a city object using the city's tokens 
variable?

>
> [EV] I would consider destination tokens as base tokens which (temporarily)
> can be placed in an off-station location, but that would IMO not change
> their base token character. Nevertheless I totally agree that this is a
> hard one, which may require some rethinking on how tokens will be handled,
> in particular in the UI. It's one reason that 1870 is not that high on my
> wish list (another one being that I have never played 1870).

1870 is a good next target, as it requires some interesting concepts, but is 
still not too far away from 1830.

[Rails-devel] 1856 THB home hex (Hamilton) blocked or not?

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

> 3025465: 1856. THB token spot blocked inappropriately

> [EV] Hmm, I have always thought that the same token laying rules would
> apply to the THB home hex (Hamilton) as to the Erie home hex in 1830, and
> so I have implemented it identically. But I see that the 1856 rules are
> silent on this point, and can't find any clarifications either. Is it
> indeed generally agreed that another company may lay a token in Hamilton
> before the THB does?

Erik,
thanks for catching this ambiguity. I thought you intended that behavior as 
for the Erie compatability an unlaidHomeBlocksTokens="yes" for Hamilton was 
missing.

I checked the rules before the fix and it seemed that the indicate that a 
token can be laid. As there is no special rule for THB as for the Erie in 
1830, it falls back to the standard spec:
"In the starting city for a company that has not yet started, a company cannot 
place a station marker on the last available space (if an extra space becomes 
available later, the station marker may then be placed)."
Seems the question is if the two cities on the OO tile are considered as one 
entity.
The 1856 FAQ of Steve Thomas is also quiet on this topic.

At least the group, which filed the bug, considers the Hamilton hex not 
completely blocked. Does anyone of the 1856 experts (I am not) have a 
definite answer or should we escalate the question to the 18xx yahoo list?

Stefan

Re: [Rails-devel] Two bug fixes - questions to Erik

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

Stefan,

Some responses below.

Erik. 

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Sunday 11 July 2010 19:21
To: Development list for Rails: an 18xx game
Subject: [Rails-devel] Two bug fixes - questions to Erik

Erik:
two quick fixes of reported bugs and a few comments/questions related to
this:

3010534: 1856 1/2 share from limit can't buy 5% share of CGR
- The reason was that the call to the certification limit test did not 
consider the certificate count (1/2 here), assuming that each certificate 
counts full.

[EV] The easy fix would be to use the cert.count. Any problems with that?

- From the code it seems that defining certificate types might help. Then it

would be easier to group the certificates available in the pool or the 
player's portfolios. Other games might even have more variation. 

[EV] You mean different types for 5% and 10% shares? Or what else? On first
sight I don't see much value in that.

- The Buy action (still) do not store the certificate ids, if more than one 
certificate is sold. The sell action does not store the ids at all. The same

is true for the Exchange for Share action. This poses the risk of reload 
errors especially after undos.

[EV] I remember you have discussed this before, but I haven't yet managed to
understand what exact problem storing certificate IDs would fix. Does this
relate to the known problem that items in lists are generally moved to a
different position after an undo? That shouldn't be difficult to fix, but I
haven't yet got to it. Pending that generic solution, I have fixed a few
apparent cases; there may be others, but I haven't any good examples.

3025465: 1856. THB token spot blocked inappropriately 
- Here the case of a non-blocking home base on OO-Tiles was not accounted
for. 
Fixed that now by changing the home city to null as long as the home city is

not selected. Adjusted the paint method in GUIHex to find a free slot to 
paint the home company name on.

[EV] Hmm, I have always thought that the same token laying rules would apply
to the THB home hex (Hamilton) as to the Erie home hex in 1830, and so I
have implemented it identically. But I see that the 1856 rules are silent on
this point, and can't find any clarifications either. Is it indeed generally
agreed that another company may lay a token in Hamilton before the THB does?

- I always wonder, if the token methods and the token variables in city are 
restricted to BaseTokens only or if they can hold any type of Tokens (as the

TokenI signature suggests). If the latter is the case some methods might not

work as intended, for example hasTokenSlotsLeft().
Sometimes it seems that the common interface TokenI creates more confusion 
than it saves code, as most of the time Base and BonusTokens are handled in 
separate methods anyhow. 

[EV] There already is the concept of "off-station" tokens, which e.g.
applies to the 18AL coalfield token. Please note, that the code carefully
distinguishes between "base tokens" and "bonus tokens". Not sure how much
value the existing TokenI interface really has, but there many other useless
interfaces that I would rather ditch than this one.

- Going forward thinking about 1870 which has DestinationTokens, which
behave 
in some respect like BaseTokens and in other like BonusTokens, things do not

get easier in the near future. A general token class, which allows to 
configure the behavior of tokens and define TokenTypes might be an 
alternative, but requires lot of refactoring. But then the TokenI interface 
is helpful for a start with.

[EV] I would consider destination tokens as base tokens which (temporarily)
can be placed in an off-station location, but that would IMO not change
their base token character. Nevertheless I totally agree that this is a hard
one, which may require some rethinking on how tokens will be handled, in
particular in the UI. It's one reason that 1870 is not that high on my wish
list (another one being that I have never played 1870).

Curiuos, who wins the worldcup tonight ;-) Good luck for the Dutch team.

[EV] Thanks - we'll need it. High time to turn on the TV.

[Rails-devel] Two bug fixes - questions to Erik

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

Erik:
two quick fixes of reported bugs and a few comments/questions related to this:

3010534: 1856 1/2 share from limit can't buy 5% share of CGR
- The reason was that the call to the certification limit test did not 
consider the certificate count (1/2 here), assuming that each certificate 
counts full.

- From the code it seems that defining certificate types might help. Then it 
would be easier to group the certificates available in the pool or the 
player's portfolios. Other games might even have more variation. 

- The Buy action (still) do not store the certificate ids, if more than one 
certificate is sold. The sell action does not store the ids at all. The same 
is true for the Exchange for Share action. This poses the risk of reload 
errors especially after undos.

3025465: 1856. THB token spot blocked inappropriately 
- Here the case of a non-blocking home base on OO-Tiles was not accounted for. 
Fixed that now by changing the home city to null as long as the home city is 
not selected. Adjusted the paint method in GUIHex to find a free slot to 
paint the home company name on.

- I always wonder, if the token methods and the token variables in city are 
restricted to BaseTokens only or if they can hold any type of Tokens (as the 
TokenI signature suggests). If the latter is the case some methods might not 
work as intended, for example hasTokenSlotsLeft().
Sometimes it seems that the common interface TokenI creates more confusion 
than it saves code, as most of the time Base and BonusTokens are handled in 
separate methods anyhow. 

- Going forward thinking about 1870 which has DestinationTokens, which behave 
in some respect like BaseTokens and in other like BonusTokens, things do not 
get easier in the near future. A general token class, which allows to 
configure the behavior of tokens and define TokenTypes might be an 
alternative, but requires lot of refactoring. But then the TokenI interface 
is helpful for a start with.

Stefan

Curiuos, who wins the worldcup tonight ;-) Good luck for the Dutch team.

Re: [Rails-devel] 18EU minor initial sale round bugs

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

After some time:
The pass option at the bgeinning of the 18EU minor initial sale round is 
renamed to "decline to bid" for the first action of each player after the 
minor selection. After that "pass" is active (implying "decline to buy").

I took the opportunity to implement the long-standing feature-request for an 
autopass in the 18EU start round:
Anytime a player has not enough money to bid or buy, he passes automatically 
(or declines to bid or declines to increase his bid). 
Exception is the player after the selection of a minor as the first bid is 
processed by the user interface instead of the backend. Here the player still 
has to select NoBid.

This fix covers all game situations, where a player has only the option to 
pass. The other occasion I have tested is the 1830 type StartRound. The 
general StockRound is not effected (it allows both pass and autopass).
And it does not effect those cases, where players/companies have to  
choose "Done" (e.g. after an action in the StockRound or during ORs).

In principle this behavior could be generalized to those occasions above, but 
it might surprise players if their turn is skipped outside of the 
StartRounds.

The 1835 StartRound has its own autopass method implemented, which has a 
pop-up message supplied. 
So far I have not added a pop-up message box. It can be easily added, but this 
works a little bit against the intention of a game speed up. 
(Here and in some other occasions it would be nice to have a non-blocking 
information panel).

Stefan


On Friday 25 June 2010 22:51:02 Chris Shaffer wrote:
> I get the feeling we've already spent more time discussing it than it would
> have taken to implement it.
>
> At any rate, if any of the developers other than Erik would care to make
> the change, it would be appreciated.  I note that the UI is already
> complicated by the implementation of the "select, no bid" option and this
> would simply be extending that option to the following players.
>
> --
> Chris
>
> Please consider the environment before printing this e-mail.
>
> On Fri, Jun 25, 2010 at 1:39 PM, Erik Vos <eri...@xs...> wrote:
> >  I consider it an immaterial difference in rules wording, that does not
> > merit complicating the UI. But apparently opinions differ. I won't oppose
> > such a change, but I have better things to spend my time on.
> >
> > Erik.
> >
> >  ------------------------------
> > *From:* Chris Shaffer [mailto:chr...@gm...]
> > *Sent:* Friday 25 June 2010 22:22
> > *To:* Development list for Rails: an 18xx game
> > *Subject:* Re: [Rails-devel] 18EU minor initial sale round bugs
> >
> >   [EV] Indeed. I don't actually see why "Pass" would not cover "Decline
> > to
> >
> >> bid" as well. I don't see any need to make that distinction.
> >
> > It is problematic to explain rules when the interface does not match the
> > terminology in the rules.  "Pass" has a specific meaning that is
> > different from "decline to bid."
> >
> > I'm not sure why there would be resistance to having Rails match the game
> > rules?  What good reason could there be for desiring a conflict in
> > terminology?
> >
> > --
> > Chris
> >
> >
> >
> > -------------------------------------------------------------------------
> >----- 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

Re: [Rails-devel] autosave files

[Steve U. <ste...@gm...>]

1) is key for the less computer-literate among the Rails users.

Steve Undy
st...@ro...


On Thu, Jul 8, 2010 at 2:36 PM, Stefan Frey <ste...@we...> wrote:

> I agree, but currently none of the config/properties options can be
> adjusted
> by the GUI (as far as I know at least), thus I follow good practice here
> ;-)
>
> Serveral ways to improve the mechanism:
>
> 1) Create a UI to edit the configuration options
> 2) Store user adjustments
> 3) Provide ftf/pbem defaults properties
>
> 2) and 3) are easy to code as they are directly supported by the properties
> class. For 1) the tedious part is to enforce restrictions and provide help
> text.
>
> Stefan
>
>
> >
> > As a general rule, we should try to most options that affect loading,
> > saving, and gameplay into the GUI.
> >
> > Properties file options are great for development and "sensible"
> > defaults that few people will want to change.
> >
> > We can then have the GUI update the properties file with the updated
> > settings (if it doesn't already).
> >
> > > A possible solution for the conflicting "defaults" are predefined
> > > configuration files for ftf and pbem plays.
> > >
> > > Maybe even asking for the preferred configuration on the first startup?
> > >
> > > Stefan
> >
> > ---Brett.
> >
> >
> ---------------------------------------------------------------------------
> >--- 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] autosave files

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

I agree, but currently none of the config/properties options can be adjusted 
by the GUI (as far as I know at least), thus I follow good practice here ;-)

Serveral ways to improve the mechanism:

1) Create a UI to edit the configuration options
2) Store user adjustments
3) Provide ftf/pbem defaults properties

2) and 3) are easy to code as they are directly supported by the properties 
class. For 1) the tedious part is to enforce restrictions and provide help 
text.

Stefan


>
> As a general rule, we should try to most options that affect loading,
> saving, and gameplay into the GUI.
>
> Properties file options are great for development and "sensible"
> defaults that few people will want to change.
>
> We can then have the GUI update the properties file with the updated
> settings (if it doesn't already).
>
> > A possible solution for the conflicting "defaults" are predefined
> > configuration files for ftf and pbem plays.
> >
> > Maybe even asking for the preferred configuration on the first startup?
> >
> > Stefan
>
> ---Brett.
>
> ---------------------------------------------------------------------------
>--- 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] autosave files

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

Chris:
thanks for the further details.
My quick answers:
1) save.recovery.filepath should work relative as well, as all other folder 
instructions in my.properties
2) the current autosave is a recovery function intended for ftf play and 
avoids manual saves, thus adds functionality there
3) the idea for poor man's play is a little more than what is possible now: 
that each player has a running rails instance which synchronize automatically 
by exchanging (single) action update files via dropbox, thus avoiding a 
complete reload. 
Stefan


On Tuesday 06 July 2010 23:38:12 Chris Shaffer wrote:
> A couple of things.
>
> 1) Yes, the 18xx.log file is on Dropbox.
> 2) Some players, like me, use Rails from multiple computers with
> multiple operating systems.  Any file system that isn't relative to
> the current directory is problematic - the paths on my home Ubuntu
> machine, my work Mac laptop, my work Mac desktop and random borrowed
> or library computers are all different.
> 3) Many people share all the files on Dropbox - even the executable
> jar and properties files.  I know this is a security risk and not
> recommended, but it's a fact of life that it happens.
> 4) PBEM requires frequent saves anyway - between each player's
> actions.  The farthest you ever have to back up is one player action.
> Thus, autosave doesn't add any functionality that I can see.
> 5) Yes, some people use Dropbox as a poor man's online play already.
> If everyone is online, you can just watch as the files update and when
> your name shows up in the new filename, you know it is your turn.
>
> Not sure what you mean about asking for the preferred configuration on
> first startup, but if that means every time I launch Rails, it would
> be annoying.  I launch an instance of Rails for each action I take in
> pbem games.
>
> --
> Chris
>
> Please consider the environment before printing this e-mail.
>
> On Tue, Jul 6, 2010 at 2:26 PM, Stefan Frey <ste...@we...> wrote:
> > Jim & Chris,
> > thanks for your comments. Seems that the preferences for pbem and ftf
> > players differ substantially here. I am an example of the latter species
> > and I currently save frequently during ftf play (even if I had no problem
> > so far), which is a little annoying and would still require some
> > replaying.
> >
> > Options in the my.properties will be available:
> >
> > save.recovery.active
> > to activate/deactivate
> >
> > save.recovery.filepath=18xx_autosave.rails
> > to change filename/path information
> >
> > A possible solution for the conflicting "defaults" are predefined
> > configuration files for ftf and pbem plays.
> >
> > Maybe even asking for the preferred configuration on the first startup?
> >
> > Stefan
> >
> > PS: I assume that you currently have the working directory of Rails set
> > to the dropbox folder? Is the 18xx.log file also generated there? In
> > principle this would leak information to other players as well.
> > On the other hand the autosave file would allow an easy synch as you only
> > have to restore the game from that file. Maybe one should consider
> > dropbox as a possible "poor man" solution for online play?
> >
> > On Tuesday 06 July 2010 01:25:28 Jim Black wrote:
> >> Stefan wrote:
> >> > I added a simple autosave and game recovery mechanism. ...
> >> > The current defaults activate autosave and
> >> > stores a 18xx_autosave.rails file in the current working directory.
> >>
> >> Auto-saving files to the current-working directory is problematic for
> >> pbem games, where players inevitably open the pbem game from a shared
> >> dropbox folder.
> >>
> >> When autosave files appear by magic, it reveals all
> >> temporary/session-level analysis to other players, in real time (by
> >> constantly saving temp-files in the dropbox).
> >>
> >> For this reason, I think it's a pretty undesirable feature (unless Rails
> >> can become more clever about distinguishing shared/game folders, from
> >> personal/config folders, which it doesn't do well imho) ....
> >>
> >> regards,
> >>  - jim
> >>
> >>
> >>
> >> ------------------------------------------------------------------------
> >>--- --- 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] autosave files

[Jim B. <ji...@ko...>]

Stefan asked-
> I assume that you currently have the working directory of Rails set 
> to the  dropbox folder? Is the 18xx.log file also generated there? 
> In principle this would leak information to other players as well.

No- I cant/never launch rails from the dropbox folder, because that's so fundamentally insecure.  

Instead, I use a script that sets my directory (elsewhere) and launches rails from a consistent folder 'near' my dropbox (in the file browse).   

None of the players I play with run from the shared directory, so we never see spurious 18xx.log files.  Once, I did see one- but it was from another game (which I wasn't playing), and it made me realize this would be a security problem with autosave files.

Btw, you're absolutely right that the desired defaults are very, very different for the two user/player types (real-time, vs pbem)- the idea of having two different command names, that distinguish rtp vs pbem Rails, is an excellent one- with different package commands/defaults/jars/etc.    (For reasons like these folder issues, and, to stay consistent with players that are not tech-savvy- we just can't use my.properties config tweaks at all, in practice, for stuff like this- a separate command, with appropriate defaults, might circumvent all those current problems with my.properties for typical pbem (most especially- these subtle, but profound, side effects of current/working-directory issues).

Thanks for your comments, consideration and feedback.

best,
 - jim

On Tuesday 06 July 2010 01:25:28 Jim Black wrote:
> Stefan wrote:
>> I added a simple autosave and game recovery mechanism. ...
>> The current defaults activate autosave and
>> stores a 18xx_autosave.rails file in the current working directory.
> 
> Auto-saving files to the current-working directory is problematic for pbem
> games, where players inevitably open the pbem game from a shared dropbox
> folder.
> 
> When autosave files appear by magic, it reveals all temporary/session-level
> analysis to other players, in real time (by constantly saving temp-files in
> the dropbox).
> 
> For this reason, I think it's a pretty undesirable feature (unless Rails
> can become more clever about distinguishing shared/game folders, from
> personal/config folders, which it doesn't do well imho) ....
> 
> regards,
> - jim
> 
> 
> 
> ---------------------------------------------------------------------------
> --- 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





------------------------------

Message: 4
Date: Tue, 6 Jul 2010 14:38:12 -0700
From: Chris Shaffer <chr...@gm...>
Subject: Re: [Rails-devel] autosave files
To: "Development list for Rails: an 18xx game"
	<rai...@li...>
Message-ID:
	<AAN...@ma...>
Content-Type: text/plain; charset=ISO-8859-1

A couple of things.

1) Yes, the 18xx.log file is on Dropbox.
2) Some players, like me, use Rails from multiple computers with
multiple operating systems.  Any file system that isn't relative to
the current directory is problematic - the paths on my home Ubuntu
machine, my work Mac laptop, my work Mac desktop and random borrowed
or library computers are all different.
3) Many people share all the files on Dropbox - even the executable
jar and properties files.  I know this is a security risk and not
recommended, but it's a fact of life that it happens.
4) PBEM requires frequent saves anyway - between each player's
actions.  The farthest you ever have to back up is one player action.
Thus, autosave doesn't add any functionality that I can see.
5) Yes, some people use Dropbox as a poor man's online play already.
If everyone is online, you can just watch as the files update and when
your name shows up in the new filename, you know it is your turn.

Not sure what you mean about asking for the preferred configuration on
first startup, but if that means every time I launch Rails, it would
be annoying.  I launch an instance of Rails for each action I take in
pbem games.

--
Chris

Please consider the environment before printing this e-mail.



On Tue, Jul 6, 2010 at 2:26 PM, Stefan Frey <ste...@we...> wrote:
> Jim & Chris,
> thanks for your comments. Seems that the preferences for pbem and ftf players
> differ substantially here. I am an example of the latter species and I
> currently save frequently during ftf play (even if I had no problem so far),
> which is a little annoying and would still require some replaying.
> 
> Options in the my.properties will be available:
> 
> save.recovery.active
> to activate/deactivate
> 
> save.recovery.filepath=18xx_autosave.rails
> to change filename/path information
> 
> A possible solution for the conflicting "defaults" are predefined
> configuration files for ftf and pbem plays.
> 
> Maybe even asking for the preferred configuration on the first startup?
> 
> Stefan
> 
> PS: I assume that you currently have the working directory of Rails set to the
> dropbox folder? Is the 18xx.log file also generated there? In principle this
> would leak information to other players as well.
> On the other hand the autosave file would allow an easy synch as you only have
> to restore the game from that file. Maybe one should consider dropbox as a
> possible "poor man" solution for online play?
> 
> On Tuesday 06 July 2010 01:25:28 Jim Black wrote:
>> Stefan wrote:
>>> I added a simple autosave and game recovery mechanism. ...
>>> The current defaults activate autosave and
>>> stores a 18xx_autosave.rails file in the current working directory.
>> 
>> Auto-saving files to the current-working directory is problematic for pbem
>> games, where players inevitably open the pbem game from a shared dropbox
>> folder.
>> 
>> When autosave files appear by magic, it reveals all temporary/session-level
>> analysis to other players, in real time (by constantly saving temp-files in
>> the dropbox).
>> 
>> For this reason, I think it's a pretty undesirable feature (unless Rails
>> can become more clever about distinguishing shared/game folders, from
>> personal/config folders, which it doesn't do well imho) ....
>> 
>> regards,
>> ?- jim
>> 
>> 
>> 
>> ---------------------------------------------------------------------------
>> --- 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
> 



------------------------------

Message: 5
Date: Tue, 6 Jul 2010 14:40:47 -0700
From: Chris Shaffer <chr...@gm...>
Subject: Re: [Rails-devel] autosave files
To: "Development list for Rails: an 18xx game"
	<rai...@li...>
Message-ID:
	<AAN...@ma...>
Content-Type: text/plain; charset=ISO-8859-1

p.s. I think what Jim was getting at is that in pbem, it is common
practice to play a game forward, taking other player's turns, just to
see the outcome of a certain action or set of actions.  Then, once a
course of action has been decided, you exit without saving, launch
again, and take your one action.  As you play through perhaps entire
operating rounds and stock rounds to see how the trains will fall out,
to see how the CGR formation will occur, or whatever, a series of
autosaves exposes a lot of potential "thinking ahead" information.  It
also potentially confuses people because they see all the saves and
think it is their turn to act.

--
Chris

Please consider the environment before printing this e-mail.



On Tue, Jul 6, 2010 at 2:38 PM, Chris Shaffer <chr...@gm...> wrote:
> A couple of things.
> 
> 1) Yes, the 18xx.log file is on Dropbox.
> 2) Some players, like me, use Rails from multiple computers with
> multiple operating systems. ?Any file system that isn't relative to
> the current directory is problematic - the paths on my home Ubuntu
> machine, my work Mac laptop, my work Mac desktop and random borrowed
> or library computers are all different.
> 3) Many people share all the files on Dropbox - even the executable
> jar and properties files. ?I know this is a security risk and not
> recommended, but it's a fact of life that it happens.
> 4) PBEM requires frequent saves anyway - between each player's
> actions. ?The farthest you ever have to back up is one player action.
> Thus, autosave doesn't add any functionality that I can see.
> 5) Yes, some people use Dropbox as a poor man's online play already.
> If everyone is online, you can just watch as the files update and when
> your name shows up in the new filename, you know it is your turn.
> 
> Not sure what you mean about asking for the preferred configuration on
> first startup, but if that means every time I launch Rails, it would
> be annoying. ?I launch an instance of Rails for each action I take in
> pbem games.
> 
> --
> Chris
> 
> Please consider the environment before printing this e-mail.
> 
> 
> 
> On Tue, Jul 6, 2010 at 2:26 PM, Stefan Frey <ste...@we...> wrote:
>> Jim & Chris,
>> thanks for your comments. Seems that the preferences for pbem and ftf players
>> differ substantially here. I am an example of the latter species and I
>> currently save frequently during ftf play (even if I had no problem so far),
>> which is a little annoying and would still require some replaying.
>> 
>> Options in the my.properties will be available:
>> 
>> save.recovery.active
>> to activate/deactivate
>> 
>> save.recovery.filepath=18xx_autosave.rails
>> to change filename/path information
>> 
>> A possible solution for the conflicting "defaults" are predefined
>> configuration files for ftf and pbem plays.
>> 
>> Maybe even asking for the preferred configuration on the first startup?
>> 
>> Stefan
>> 
>> PS: I assume that you currently have the working directory of Rails set to the
>> dropbox folder? Is the 18xx.log file also generated there? In principle this
>> would leak information to other players as well.
>> On the other hand the autosave file would allow an easy synch as you only have
>> to restore the game from that file. Maybe one should consider dropbox as a
>> possible "poor man" solution for online play?
>> 
>> On Tuesday 06 July 2010 01:25:28 Jim Black wrote:
>>> Stefan wrote:
>>>> I added a simple autosave and game recovery mechanism. ...
>>>> The current defaults activate autosave and
>>>> stores a 18xx_autosave.rails file in the current working directory.
>>> 
>>> Auto-saving files to the current-working directory is problematic for pbem
>>> games, where players inevitably open the pbem game from a shared dropbox
>>> folder.
>>> 
>>> When autosave files appear by magic, it reveals all temporary/session-level
>>> analysis to other players, in real time (by constantly saving temp-files in
>>> the dropbox).
>>> 
>>> For this reason, I think it's a pretty undesirable feature (unless Rails
>>> can become more clever about distinguishing shared/game folders, from
>>> personal/config folders, which it doesn't do well imho) ....
>>> 
>>> regards,
>>> ?- jim
>>> 
>>> 
>>> 
>>> ---------------------------------------------------------------------------
>>> --- 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
>> 
> 



------------------------------

Message: 6
Date: Tue, 6 Jul 2010 22:05:18 +0000
From: brett lentz <bre...@gm...>
Subject: Re: [Rails-devel] autosave files
To: "Development list for Rails: an 18xx game"
	<rai...@li...>
Message-ID:
	<AAN...@ma...>
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jul 6, 2010 at 9:26 PM, Stefan Frey <ste...@we...> wrote:
> Options in the my.properties will be available:
> 
> save.recovery.active
> to activate/deactivate
> 
> save.recovery.filepath=18xx_autosave.rails
> to change filename/path information
> 


As a general rule, we should try to most options that affect loading,
saving, and gameplay into the GUI.

Properties file options are great for development and "sensible"
defaults that few people will want to change.

We can then have the GUI update the properties file with the updated
settings (if it doesn't already).


> A possible solution for the conflicting "defaults" are predefined
> configuration files for ftf and pbem plays.
> 
> Maybe even asking for the preferred configuration on the first startup?
> 
> Stefan
> 


---Brett.



------------------------------

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


End of Rails-devel Digest, Vol 33, Issue 7
******************************************

Re: [Rails-devel] autosave files

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

On Tue, Jul 6, 2010 at 9:26 PM, Stefan Frey <ste...@we...> wrote:
> Options in the my.properties will be available:
>
> save.recovery.active
> to activate/deactivate
>
> save.recovery.filepath=18xx_autosave.rails
> to change filename/path information
>


As a general rule, we should try to most options that affect loading,
saving, and gameplay into the GUI.

Properties file options are great for development and "sensible"
defaults that few people will want to change.

We can then have the GUI update the properties file with the updated
settings (if it doesn't already).


> A possible solution for the conflicting "defaults" are predefined
> configuration files for ftf and pbem plays.
>
> Maybe even asking for the preferred configuration on the first startup?
>
> Stefan
>


---Brett.

Re: [Rails-devel] autosave files

[Chris S. <chr...@gm...>]

p.s. I think what Jim was getting at is that in pbem, it is common
practice to play a game forward, taking other player's turns, just to
see the outcome of a certain action or set of actions.  Then, once a
course of action has been decided, you exit without saving, launch
again, and take your one action.  As you play through perhaps entire
operating rounds and stock rounds to see how the trains will fall out,
to see how the CGR formation will occur, or whatever, a series of
autosaves exposes a lot of potential "thinking ahead" information.  It
also potentially confuses people because they see all the saves and
think it is their turn to act.

--
Chris

Please consider the environment before printing this e-mail.



On Tue, Jul 6, 2010 at 2:38 PM, Chris Shaffer <chr...@gm...> wrote:
> A couple of things.
>
> 1) Yes, the 18xx.log file is on Dropbox.
> 2) Some players, like me, use Rails from multiple computers with
> multiple operating systems.  Any file system that isn't relative to
> the current directory is problematic - the paths on my home Ubuntu
> machine, my work Mac laptop, my work Mac desktop and random borrowed
> or library computers are all different.
> 3) Many people share all the files on Dropbox - even the executable
> jar and properties files.  I know this is a security risk and not
> recommended, but it's a fact of life that it happens.
> 4) PBEM requires frequent saves anyway - between each player's
> actions.  The farthest you ever have to back up is one player action.
> Thus, autosave doesn't add any functionality that I can see.
> 5) Yes, some people use Dropbox as a poor man's online play already.
> If everyone is online, you can just watch as the files update and when
> your name shows up in the new filename, you know it is your turn.
>
> Not sure what you mean about asking for the preferred configuration on
> first startup, but if that means every time I launch Rails, it would
> be annoying.  I launch an instance of Rails for each action I take in
> pbem games.
>
> --
> Chris
>
> Please consider the environment before printing this e-mail.
>
>
>
> On Tue, Jul 6, 2010 at 2:26 PM, Stefan Frey <ste...@we...> wrote:
>> Jim & Chris,
>> thanks for your comments. Seems that the preferences for pbem and ftf players
>> differ substantially here. I am an example of the latter species and I
>> currently save frequently during ftf play (even if I had no problem so far),
>> which is a little annoying and would still require some replaying.
>>
>> Options in the my.properties will be available:
>>
>> save.recovery.active
>> to activate/deactivate
>>
>> save.recovery.filepath=18xx_autosave.rails
>> to change filename/path information
>>
>> A possible solution for the conflicting "defaults" are predefined
>> configuration files for ftf and pbem plays.
>>
>> Maybe even asking for the preferred configuration on the first startup?
>>
>> Stefan
>>
>> PS: I assume that you currently have the working directory of Rails set to the
>> dropbox folder? Is the 18xx.log file also generated there? In principle this
>> would leak information to other players as well.
>> On the other hand the autosave file would allow an easy synch as you only have
>> to restore the game from that file. Maybe one should consider dropbox as a
>> possible "poor man" solution for online play?
>>
>> On Tuesday 06 July 2010 01:25:28 Jim Black wrote:
>>> Stefan wrote:
>>> > I added a simple autosave and game recovery mechanism. ...
>>> > The current defaults activate autosave and
>>> > stores a 18xx_autosave.rails file in the current working directory.
>>>
>>> Auto-saving files to the current-working directory is problematic for pbem
>>> games, where players inevitably open the pbem game from a shared dropbox
>>> folder.
>>>
>>> When autosave files appear by magic, it reveals all temporary/session-level
>>> analysis to other players, in real time (by constantly saving temp-files in
>>> the dropbox).
>>>
>>> For this reason, I think it's a pretty undesirable feature (unless Rails
>>> can become more clever about distinguishing shared/game folders, from
>>> personal/config folders, which it doesn't do well imho) ....
>>>
>>> regards,
>>>  - jim
>>>
>>>
>>>
>>> ---------------------------------------------------------------------------
>>>--- 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] autosave files

[Chris S. <chr...@gm...>]

A couple of things.

1) Yes, the 18xx.log file is on Dropbox.
2) Some players, like me, use Rails from multiple computers with
multiple operating systems.  Any file system that isn't relative to
the current directory is problematic - the paths on my home Ubuntu
machine, my work Mac laptop, my work Mac desktop and random borrowed
or library computers are all different.
3) Many people share all the files on Dropbox - even the executable
jar and properties files.  I know this is a security risk and not
recommended, but it's a fact of life that it happens.
4) PBEM requires frequent saves anyway - between each player's
actions.  The farthest you ever have to back up is one player action.
Thus, autosave doesn't add any functionality that I can see.
5) Yes, some people use Dropbox as a poor man's online play already.
If everyone is online, you can just watch as the files update and when
your name shows up in the new filename, you know it is your turn.

Not sure what you mean about asking for the preferred configuration on
first startup, but if that means every time I launch Rails, it would
be annoying.  I launch an instance of Rails for each action I take in
pbem games.

--
Chris

Please consider the environment before printing this e-mail.



On Tue, Jul 6, 2010 at 2:26 PM, Stefan Frey <ste...@we...> wrote:
> Jim & Chris,
> thanks for your comments. Seems that the preferences for pbem and ftf players
> differ substantially here. I am an example of the latter species and I
> currently save frequently during ftf play (even if I had no problem so far),
> which is a little annoying and would still require some replaying.
>
> Options in the my.properties will be available:
>
> save.recovery.active
> to activate/deactivate
>
> save.recovery.filepath=18xx_autosave.rails
> to change filename/path information
>
> A possible solution for the conflicting "defaults" are predefined
> configuration files for ftf and pbem plays.
>
> Maybe even asking for the preferred configuration on the first startup?
>
> Stefan
>
> PS: I assume that you currently have the working directory of Rails set to the
> dropbox folder? Is the 18xx.log file also generated there? In principle this
> would leak information to other players as well.
> On the other hand the autosave file would allow an easy synch as you only have
> to restore the game from that file. Maybe one should consider dropbox as a
> possible "poor man" solution for online play?
>
> On Tuesday 06 July 2010 01:25:28 Jim Black wrote:
>> Stefan wrote:
>> > I added a simple autosave and game recovery mechanism. ...
>> > The current defaults activate autosave and
>> > stores a 18xx_autosave.rails file in the current working directory.
>>
>> Auto-saving files to the current-working directory is problematic for pbem
>> games, where players inevitably open the pbem game from a shared dropbox
>> folder.
>>
>> When autosave files appear by magic, it reveals all temporary/session-level
>> analysis to other players, in real time (by constantly saving temp-files in
>> the dropbox).
>>
>> For this reason, I think it's a pretty undesirable feature (unless Rails
>> can become more clever about distinguishing shared/game folders, from
>> personal/config folders, which it doesn't do well imho) ....
>>
>> regards,
>>  - jim
>>
>>
>>
>> ---------------------------------------------------------------------------
>>--- 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] autosave files

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

Jim & Chris,
thanks for your comments. Seems that the preferences for pbem and ftf players
differ substantially here. I am an example of the latter species and I 
currently save frequently during ftf play (even if I had no problem so far), 
which is a little annoying and would still require some replaying. 

Options in the my.properties will be available:

save.recovery.active
to activate/deactivate

save.recovery.filepath=18xx_autosave.rails
to change filename/path information

A possible solution for the conflicting "defaults" are predefined 
configuration files for ftf and pbem plays.

Maybe even asking for the preferred configuration on the first startup?

Stefan

PS: I assume that you currently have the working directory of Rails set to the 
dropbox folder? Is the 18xx.log file also generated there? In principle this 
would leak information to other players as well.
On the other hand the autosave file would allow an easy synch as you only have 
to restore the game from that file. Maybe one should consider dropbox as a 
possible "poor man" solution for online play?

On Tuesday 06 July 2010 01:25:28 Jim Black wrote:
> Stefan wrote:
> > I added a simple autosave and game recovery mechanism. ...
> > The current defaults activate autosave and
> > stores a 18xx_autosave.rails file in the current working directory.
>
> Auto-saving files to the current-working directory is problematic for pbem
> games, where players inevitably open the pbem game from a shared dropbox
> folder.
>
> When autosave files appear by magic, it reveals all temporary/session-level
> analysis to other players, in real time (by constantly saving temp-files in
> the dropbox).
>
> For this reason, I think it's a pretty undesirable feature (unless Rails
> can become more clever about distinguishing shared/game folders, from
> personal/config folders, which it doesn't do well imho) ....
>
> regards,
>  - jim
>
>
>
> ---------------------------------------------------------------------------
>--- 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] autosave files

[Chris S. <chr...@gm...>]

I'd like to be able to disable autosave, and to have it off by default.

--
Chris

Please consider the environment before printing this e-mail.



On Mon, Jul 5, 2010 at 4:25 PM, Jim Black <ji...@ko...> wrote:
>
> Stefan wrote:
>> I added a simple autosave and game recovery mechanism. ...
>> The current defaults activate autosave and
>> stores a 18xx_autosave.rails file in the current working directory.
>
> Auto-saving files to the current-working directory is problematic for pbem games, where players inevitably open the pbem game from a shared dropbox folder.
>
> When autosave files appear by magic, it reveals all temporary/session-level analysis to other players, in real time (by constantly saving temp-files in the dropbox).
>
> For this reason, I think it's a pretty undesirable feature (unless Rails can become more clever about distinguishing shared/game folders, from personal/config folders, which it doesn't do well imho) ....
>
> regards,
>  - jim
>
>
>
> ------------------------------------------------------------------------------
> 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
>

[Rails-devel] autosave files

[Jim B. <ji...@ko...>]

Stefan wrote:  
> I added a simple autosave and game recovery mechanism. ...  
> The current defaults activate autosave and 
> stores a 18xx_autosave.rails file in the current working directory.

Auto-saving files to the current-working directory is problematic for pbem games, where players inevitably open the pbem game from a shared dropbox folder.

When autosave files appear by magic, it reveals all temporary/session-level analysis to other players, in real time (by constantly saving temp-files in the dropbox).  

For this reason, I think it's a pretty undesirable feature (unless Rails can become more clever about distinguishing shared/game folders, from personal/config folders, which it doesn't do well imho) .... 

regards,
 - jim

[Rails-devel] Rails autosave / game recovery

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

In response to a feature request I added a simple autosave and game recovery 
mechanism. 

After each (completed) player activity, the autosave file is updated. 
On game start, there is a new button: "Recover previous game", which will 
automatically start from the autosave file. 
This should also allow to recover on power outage or other reasons for 
quitting Rails without saving.

Caveat: The autosave file can be effected by the reload problems of game 
situations with lots of undos. But those situations are becoming less and 
less frequent.

Autosave can be configured in my.properties. The current defaults activate 
autosave and stores a 18xx_autosave.rails file in the current working 
directory. 

Current defaults are:
save.recovery.active=yes
save.recovery.filepath=18xx_autosave.rails

Due to the small size of the rails save files and the speed of harddisks now, 
a complete save file is stored every time. The old one is renamed with the 
(additonal) extension ".bak".

Testing on a Windows system is appreciated. I tried to discover and report 
problems to the user, thus trying to switch autosave to read only folder 
would be a good test.

Stefan

Re: [Rails-devel] Trigger implementation / bug-fix release?

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

Erik,
sorry for not providing satisfying answers to your q's.
I will try a little better, but not too much, as I am currently more concerned 
about my sequence proposal.
And even more words might not replace a working example.
More comments see below,
Stefan


On Monday 05 July 2010 21:13:55 Erik Vos wrote:
> Stefan,
>
> You haven't yet answered my questions. Are you going to register the
> triggers with every single newly created move of a type? If not, how does a
> Move/MoveSet know what to trigger, and how can it find the objects to
> trigger without such explicit registration?
>

It works the way around (at least half way): All Moves are already register 
themselves with the current MoveSet. The MoveSet (or the MoveStack) then 
forwards those to the TriggerManager (for separation from the Move classes - 
by your request). The triggers register themselves on creation (preferably 
from XML via the standard Rails mechanisms) to the TriggerManager only. Thus 
there is only a one time/one place register necessary.

> Another question: how do you prevent infinite loops? Moves that trigger
> actions that create more moves that...

The mechanism (as any other with a similar intention) cannot prevent infinite 
loops: Only the logic of the triggers themselves can do this.
But your suggested observer mechanisms can easily create infinite loops as 
well: Think about a maphex change which causes the observer to change the 
maphex again. Only if the observer itself decides to stop the loop at some 
time, the infinite loop is broken. 

>
> I still don't like this level mixing at all.
>
> Moves already can trigger Observables to update their observers, but that
> is for one simple, limited, low-level use only. I would like to keep the
> actual game logic at the Manager/Round (i.e. upper) level.

I disagree here: In my perception moves (at least a substantial subset of 
them) are part of the game logic.  Putting everything into Manager/Rounds 
puts a too strong burden on those (see the other mail). 

And the trigger mechanism explicitly addresses those cases, where low-level 
changes activate other (high)-level actions. Every tile lay (regardless who 
did it) can activate the destination run, any additional share might float a 
company.

>
> Erik.
>
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Monday 05 July 2010 00:25
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] Trigger implementation / bug-fix release?
>
> [changed Subject]
>
> Erik:
> thanks for your suggestion: At the point of my first proposal I had no
> clear
>
> preference whether to observe the Model/State objects directly or to link
> with the Move objects which define their changes. In the latter case I use
> the
> existing link of all Moves to the MoveSet and have the MoveSet updating the
> triggerable objects. Here the triggerable objects are observers to the
> MoveSet. To keep things decoupled the MoveSet can forward the notification
> of
> the triggerable objects to the TriggerManager.
>
> I started to look into several use cases besides checking for destination
> run
> routes and it seems that in all cases the Move mechanism offers advantages.
>
> The important difference can be seen in your suggestion below: In a sense
> you
> recreate the TileMove information again: The TileMove activates the MapHex
> update and this update is then observed by the MapManager, which then
> triggers the route check. Why not have the TileMove directly (via MoveSet
> which every Move calls anyhow) trigger the route check?
>
> Other advantages here is that the TileMove is more specific than the MapHex
> updates (which include changes of tokens as well) and it requires that the
> MapManager registers itself as observer of all MapHexes. The second
> advantage
> of the Move objects are the fact that they contain additional
> information/attributes about the change and can be used for further
> filtering.
>
> With my current idea (in mind) the MoveSet object would forward each Move
> to
>
> the TriggerManager. A trigger can either be fully hardcoded or be
> partially/fully configured in XML: Either only the Move class (and
> additional
> variables to be checked) are defined or even the method to be called can be
> configured. In the latter case the concrete trigger sequence is coded in
> XML.
>
> All of this is still only preliminary as I am currently focused on
> providing a
> prototype implementation of the sequence model.
>
> I do not know, what the current state of your changes are, but from my
> point
>
> of view a bug-fix release soon would be nice, before the start of more
> drastic changes.
>
> Stefan
>
> On Sunday 27 June 2010 17:08:58 Erik Vos wrote:
> > Thinking about it, I realised that such a trigger mechanism already
> > exists and is widely used in Rails: the Observer pattern.
> > All States and several other object types are also ModelObjects, which
> > extends Observable, so any other object implementing Observer can
> > register at any State to be informed about any value changes.
> > This is mainly used to update the UI, but IIRC there are already some
> > server-internal Observer/Observable pairs.
> >
> > I think this existing mechanism fulfills your need, and it works at the
> > proper level (using States/ModelObjects in stead of Moves).
> >
> > In the example case of destination checks: each MapHex is an Observable
> > that updates its Observers (which currently only are the corresponding
> > GUIHex objects) each time a new tile is laid. If MapManager would
> > register itself with any MapHex it is creating (this isn't done yet), it
> > will get called on every tile lay, passing the new tile and its rotation
> > (perhaps the hex id should be added).
> > So, whenever called, the MapManager can inititate any destination checks
>
> or
>
> > anything else that is needed.
> >
> > Erik.
> >
> > -----Original Message-----
> > From: Erik Vos [mailto:eri...@xs...]
> > Sent: Sunday 27 June 2010 00:33
> > To: 'Development list for Rails: an 18xx game'
> > Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3
> > --undoduringCGRformationhangs game
> >
> > * My own first idea was to use a specific trigger interface and require
> > triggers to be explicitly defined. But I realized that the moves are
> > excellent triggers and the Moveset a very good place to pass the
> > messages. Moveset could still delegate the task to a TriggerManager, if a
> > better separation is required.
> >
> > And I want low-level triggers, to avoid that every (high-level)
> > implementation
> > has to remember to call the trigger.
> >
> > [EV] I still don't like at all to use the Move/MoveSets. I'd much prefer
>
> to
>
> > keep these clean.
> > How are you going to tell an object Move that it is a trigger and what it
> > must call if it is? Or should all object moves always call all
> > triggerables, or the TriggerManager (and how can it find that one)? I
> > completely don't understand how you see this working, and what's the
> > benefit of using the Moves.
> >
> > Take the example: A candidate in the long run ist the function that
> > checks if
> > a company is floated. Every (high-level) method that moves shares out of
> > IPO
> >
> > has to check if the company has floated. If the trigger is used, this is
> > done
> > automatically. This would also cover special cases in games, which are
> > not yet implemented.
> >
> > [EV] What is exactly registering to what in this example? And what is
> > triggering what? And how can both the registerer and the triggerer find
> > their callees?
> >
> > 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
>
>
> ---------------------------------------------------------------------------
>--- 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] Price tokens change order when moving up.

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

Erik,
seems to be a day of disagreements ;-)
But this makes discussion interesting and fruitful.
For the time being it is not mission-critical, where the sorting is done.
Mainly I was not happy about more things moved into those classes, which I 
would prefer to be smaller (more details below).
Stefan

On a general perspective:

From the perspective of a developer coming late to the project the GameManager 
and Round classes seems overloaded or even bloated already.
And it is much easier to guess that the operating order of public companies is 
defined by the PublicCompany class (and as it defines an ordering most likely 
as a comparator) instead of the GameManager. You (might) know everything by 
heart, but this makes it more difficult for the others.

I have to admit that most of my recent suggestions all intend to break those 
large classes into smaller pieces to allow easier and safer modifications.
Seems that we are moving in opposite directions here. 

Another admission: I already defined comparators for the Player and Company 
classes to have the GameReport sequence unique for the automated testing. 
There is even a class, which defines a sorting related to classes which all 
implement a common interface CashHolder (rails.util.SequenceUtil)
The latter would also be a place to put the sorting instead of the GameManager 
class.

On the specific task on hand:

My idea was to move only the ordering logic to the comparator (and if no price 
is yet defined put those at the end of sequence) and then have the specific 
methods only apply the filtering for floated companies.

By no means I did intend to suggest to move the filtering to the comparator, 
which is not possible as you rightly observe.

And on the company hierachy: 
I read the discussion (some years ago in the archive). I agree, I might have 
been even more drastic: Maybe one should even not have separate private and 
public companies classes (think about those operating privates in 1846). Even 
the fact that companies can operate or be purchased could be configured by 
attributes instead of defined by class (names).
I agree that in this case (as in many other cases like e.g. trains) the 
specific features should be configurable. If one wants to separate those 
features in different classes I would prefer composition instead of 
inheritance.

On Monday 05 July 2010 22:06:52 Erik Vos wrote:
> Stefan,
>
> I'm afraid this does not sound like a very good idea to me.
>
> AFAIK, a comparator requires *every* instance to be comparable. And
> non-started companies without a price aren't really well comparable for
> defining operating order purposes.
>
> Defining operating order (there are now two methods doing that, for
> different purposes and with different output) does not only require
> sorting, but also prior selection of the objects eligible for ordering.
>
> Yes, I realize that my new getCompaniesInRunningOrder() method does order
> *all* companies (contrary to everything I have said above), but (thinking
> about it) that's probably rather a bug than a feature. For now it works,
> but I don't consider it durable. In all likelihood the current logic will
> need major changes when adding games like 1837 and 1844 with their many
> different company types. And for such purposes I'd rather subclass
> GameManager (which must be done anyway in most new games) than
> PublicCompany.*
>
> Another consideration: recent developments increasingly force me to move
> logic out of the 'static' objects (companies, trains, tiles etc.) and into
> the 'dynamic' Manager/Round objects. Your proposal goes somewhat in the
> opposite direction.
>
> Erik.
>
> * That's a separate subject. Company class hierarchies have been discussed
> before in this forum. That might be a good idea if Java would support
> multiple inheritance, but it doesn't. There are too many company types with
> different mixtures of special features, and I have given up of thinking
> about catching these in hierarchies.
>
> -----Original Message-----
> From: Stefan Frey (web.de) [mailto:ste...@we...]
> Sent: Sunday 04 July 2010 23:46
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Price tokens change order when moving up.
>
> Erik:
> do you mind if I move the definition of running order into the
> PublicCompany
>
> class and define a Comparator?
>
> I can still keep the new method in the GameManager, but the change would
> later
> simplify the migration to the new sequence model.
>
> Stefan
>
> On Sunday 04 July 2010 22:57:26 Erik Vos wrote:
> > (Switching to the proper group)
> > This has been fixed now - in Subversion!
> >
> > Erik.
> >
> >
> >   _____
> >
> > From: 18...@ya... [mailto:18...@ya...] On Behalf Of
> > John A. Tamplin
> > Sent: Friday 02 July 2010 00:17
> > To: 18...@ya...
> > Subject: Re: [18xx] par value marker movement
> >
> >
> >
> >
> > On Thu, Jul 1, 2010 at 3:43 PM, Erik Vos <eri...@xs...
> >
> > <mailto:erik.vos%40xs4all.nl> > wrote:
> > > At the end of the SR, the companies are scanned for being sold out in
>
> the
>
> > > order in which they appear in the Game Status window. Any upward token
> > > moves
> > > are then executed in that order and follow the normal move rules. So I
> > > suspect that the token order gets reversed only if a 'lower' company
> > > token is on top of a 'higher' one. Or it could be the reverse...:-)
> > > Indeed we need
> > > a saved file to prove that.
> > > In any case, I would encourage to file it as a bug, so it will get
>
> proper
>
> > > attention at some point.
> >
> > The tokens are supposed to be processed in market order, which winds up
> > preserving the same stacking.
>
> ---------------------------------------------------------------------------
>- --
> 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