rails-devel — List for discussion of Rails development

Re: [Rails-devel] 1856 rules error on forced purchases

[Games on t. B. <gam...@gm...>]

I agree with Aliza. I've only played a handful of games in person, but
I've played dozens online with Rails. It is essentially how I've
learned to play the games. I never knew that about 1856.

-Tim



On Sun, Mar 20, 2011 at 5:53 PM, Aliza Panitz <ali...@gm...> wrote:
> Given the growing number of people who play on Rails and don't
> actually read the rules, I think that prohibiting illegal play ought
> to take a higher priority.
>
> On Sun, Mar 20, 2011 at 7:25 AM, Erik Vos <eri...@xs...> wrote:
>> I have ignored this aspect thus far.  All games currently follow the 1830
>> rules.
>> AFAIK this does not prohibit valid play, so going into this level of detail
>> has not had a high priority until now. But I'll agree that it has to be done
>> one day.
>>
>> Erik.
>>
>>> -----Oorspronkelijk bericht-----
>>> Van: Aliza Panitz [mailto:ali...@gm...]
>>> Verzonden: vrijdag 18 maart 2011 22:34
>>> Aan: Development list for Rails: an 18xx game
>>> Onderwerp: [Rails-devel] 1856 rules error on forced purchases
>>>
>>> The 1856 rules say:
>>>
>>> =====================
>>> When the president is forced to contribute to the purchase of a train, the
>>> following special rules govern the transaction:
>>>
>>> Only one train may be purchased.
>>> The train must be purchased from the open market or the bank and may not
>>> be purchased from another company.
>>> The train purchased must be the cheapest available from the open market
>>> and the bank.
>>> =====================
>>>
>>> However, a play-forward of a game I'm in has Rails telling a company
>>> president that they may contribute cash up to the face value of the train
>> in
>>> question when making a forced purchase from another company.
>>>
>>> Nope, this isn't 1830 :-)
>>>
>>>  - Aliza
>>>
>>>
>> ----------------------------------------------------------------------------
>> --
>>> Colocation vs. Managed Hosting
>>> A question and answer guide to determining the best fit for your
>>> organization - today and in the future.
>>> http://p.sf.net/sfu/internap-sfd2d
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Colocation vs. Managed Hosting
>> A question and answer guide to determining the best fit
>> for your organization - today and in the future.
>> http://p.sf.net/sfu/internap-sfd2d
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 1856 rules error on forced purchases

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

Given the growing number of people who play on Rails and don't
actually read the rules, I think that prohibiting illegal play ought
to take a higher priority.

On Sun, Mar 20, 2011 at 7:25 AM, Erik Vos <eri...@xs...> wrote:
> I have ignored this aspect thus far.  All games currently follow the 1830
> rules.
> AFAIK this does not prohibit valid play, so going into this level of detail
> has not had a high priority until now. But I'll agree that it has to be done
> one day.
>
> Erik.
>
>> -----Oorspronkelijk bericht-----
>> Van: Aliza Panitz [mailto:ali...@gm...]
>> Verzonden: vrijdag 18 maart 2011 22:34
>> Aan: Development list for Rails: an 18xx game
>> Onderwerp: [Rails-devel] 1856 rules error on forced purchases
>>
>> The 1856 rules say:
>>
>> =====================
>> When the president is forced to contribute to the purchase of a train, the
>> following special rules govern the transaction:
>>
>> Only one train may be purchased.
>> The train must be purchased from the open market or the bank and may not
>> be purchased from another company.
>> The train purchased must be the cheapest available from the open market
>> and the bank.
>> =====================
>>
>> However, a play-forward of a game I'm in has Rails telling a company
>> president that they may contribute cash up to the face value of the train
> in
>> question when making a forced purchase from another company.
>>
>> Nope, this isn't 1830 :-)
>>
>>  - Aliza
>>
>>
> ----------------------------------------------------------------------------
> --
>> Colocation vs. Managed Hosting
>> A question and answer guide to determining the best fit for your
>> organization - today and in the future.
>> http://p.sf.net/sfu/internap-sfd2d
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 1856 rules error on forced purchases

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

I have ignored this aspect thus far.  All games currently follow the 1830
rules.
AFAIK this does not prohibit valid play, so going into this level of detail
has not had a high priority until now. But I'll agree that it has to be done
one day.

Erik.

> -----Oorspronkelijk bericht-----
> Van: Aliza Panitz [mailto:ali...@gm...]
> Verzonden: vrijdag 18 maart 2011 22:34
> Aan: Development list for Rails: an 18xx game
> Onderwerp: [Rails-devel] 1856 rules error on forced purchases
> 
> The 1856 rules say:
> 
> =====================
> When the president is forced to contribute to the purchase of a train, the
> following special rules govern the transaction:
> 
> Only one train may be purchased.
> The train must be purchased from the open market or the bank and may not
> be purchased from another company.
> The train purchased must be the cheapest available from the open market
> and the bank.
> =====================
> 
> However, a play-forward of a game I'm in has Rails telling a company
> president that they may contribute cash up to the face value of the train
in
> question when making a forced purchase from another company.
> 
> Nope, this isn't 1830 :-)
> 
>  - Aliza
> 
>
----------------------------------------------------------------------------
--
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit for your
> organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] 1856 rules error on forced purchases

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

The 1856 rules say:

=====================
When the president is forced to contribute to the purchase of a train,
the following special rules govern the transaction:

Only one train may be purchased.
The train must be purchased from the open market or the bank and may
not be purchased from another company.
The train purchased must be the cheapest available from the open
market and the bank.
=====================

However, a play-forward of a game I'm in has Rails telling a company
president that they may contribute cash up to the face value of the
train in question when making a forced purchase from another company.

Nope, this isn't 1830 :-)

 - Aliza

Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price

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

I once wrote a piece of software that compiled clean the first time,
performed the desired and intended function, and had no bugs.  (~200
lines of source, IIRC.)

Once.

In my 25-year career.

 - Aliza

On Fri, Mar 18, 2011 at 8:31 AM, Erik Vos <eri...@xs...> wrote:
> Thanks. But we all know that bug-free software is a contradiction in
> terms...
> Erik.
>
>> -----Oorspronkelijk bericht-----
>> Van: Justin Rebelo [mailto:jus...@gm...]
>> Verzonden: donderdag 17 maart 2011 22:38
>> Aan: Development list for Rails: an 18xx game
>> Onderwerp: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price
>>
>> Good show, Erik. This must be one of the only, if not _the_ only
> outstanding
>> 1856 issue I'm aware of.
>>
>> On 3/17/11, Erik Vos <eri...@xs...> wrote:
>> > Indeed. The special code to handle 5% CGR sales in stock rounds had
>> > not been applied to (emergency) share selling rounds. It now is.
>> >
>> > Erik.
>> >
>> >> -----Oorspronkelijk bericht-----
>> >> Van: Aliza Panitz [mailto:ali...@gm...]
>> >> Verzonden: zaterdag 12 maart 2011 17:41
>> >> Aan: Development list for Rails: an 18xx game
>> >> CC: Erik Vos
>> >> Onderwerp: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock
>> >> price
>> >>
>> >> I've just run into the same problem in Rails 1.4.1and filed bug
>> >> 3207870
>> >>
>> >> On Thu, Mar 25, 2010 at 4:27 PM, Erik Vos <eri...@xs...> wrote:
>> >> > Never mind, I could reproduce the problem as described below, and
>> >> > have fixed it.
>> >> > Can’t upload it now (SVN seems down) so that will be done tomorrow.
>> >> >
>> >> > Erik.
>> >> >
>> >> > -----Original Message-----
>> >> > From: Erik Vos [mailto:eri...@xs...]
>> >> > Sent: Friday 26 March 2010 00:00
>> >> > To: 'Development list for Rails: an 18xx game'; 'Aliza Panitz'
>> >> > Subject: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock
>> >> > price
>> >> >
>> >> > Ah, you mean that sales of 15% and 5% have added up?
>> >> > If that is what has happened, I think I know what has caused this.
>> >> > A saved file would of course help a lot...
>> >> >
>> >> > Erik.
>> >> >
>> >> >
>> >> >
>> >> > -----Original Message-----
>> >> > From: Joshua Gottesman [mailto:jos...@gm...]
>> >> > Sent: Thursday 25 March 2010 22:56
>> >> > To: Aliza Panitz
>> >> > Cc: Development list for Rails: an 18xx game
>> >> > Subject: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock
>> >> > price
>> >> >
>> >> > Yeah, I didn't even notice that.  I just expected it to keep the
>> >> > price the same.  I suspect what happened is it counted your 15% and
>> >> > held the
>> >> > 1/2 share and then combined that with my 1/2 share for another
>> >> > price drop.  Which is incorrect.
>> >> >
>> >> > On Thu, Mar 25, 2010 at 2:54 PM, Aliza Panitz
>> >> > <ali...@gm...>
>> >> > wrote:
>> >> >> Rails 1.2.2 bug:
>> >> >>
>> >> >> Selling a single 5% share of the CGR to the pool should not have
>> >> >> changed the stock price.
>> >> >>
>> >> >> To quote the rules:
>> >> >>
>> >> >> ==============
>> >> >> The share value tokens move:
>> >> >>
>> >> >> Down one row for each full 10% share sold either during a stock
>> >> >> round or during a forced sale by a company president. The sale of
>> >> >> a single 5% share does not affect the share value token. Sales of
>> >> >> multiple 5% shares move the share value token ==============
>> >> >>
>> >> >> To quote the game report:
>> >> >> ]  Joshua sells a 5% share of CGR to Pool for $90.
>> >> >> ] CGR price goes from $90(E2) to $80(E3).
>> >> >>
>> >> >>
>> >> >> I'll file an official bug later if nobody else gets to it first.
>> >> >>
>> >> >>  - Aliza
>> >> >>
>> >> >> 2010/3/25 Joshua Gottesman <jos...@gm...>:
>> >> >> - Hide quoted text -
>> >> >>> ==================
>> >> >>> Start of Stock Round 6
>> >> >>> ==================
>> >> >>> Aliza has the Priority Deal
>> >> >>>
>> >> >>> Aliza sells 3 5% shares (15%) of CGR to Pool for $300.
>> >> >>> CGR price goes from $100(E1) to $90(E2).
>> >> >>> Aliza starts GT at $100 and pays $200 for 2 shares (20%) to Bank
>> >> >>> Joshua sells a 5% share of CGR to Pool for $90.
>> >> >>> CGR price goes from $90(E2) to $80(E3).
>> >> >>> Joshua starts TGB at $100 and pays $200 for 2 shares (20%) to
>> >> >>> Bank
>> >> >>>
>> >> >>
>> >
>> >
>> > ----------------------------------------------------------------------
>> > --------
>> > Colocation vs. Managed Hosting
>> > A question and answer guide to determining the best fit for your
>> > organization - today and in the future.
>> > http://p.sf.net/sfu/internap-sfd2d
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>>
>>
> ----------------------------------------------------------------------------
> --
>> Colocation vs. Managed Hosting
>> A question and answer guide to determining the best fit for your
>> organization - today and in the future.
>> http://p.sf.net/sfu/internap-sfd2d
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Making Rails more suited to fast interactive play.

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

----- Original Message -----
> Each to their own of course, just providing my personal opinions :)
> 
> I think we can generally agree that intrusiveness is bad (since if you
> are using it real-time, you are paying attention anyway ...

   Actually that is not, at least in my case, totally true.  While I'll keep Rails open on one screen on my other screen I'll be checking email, surfing the web, or even trying to figure out the Rails code and how to modify it.  :-)   Some sort of notification -- audible or flashing of the screen, or even a pop-up to catch the corner of my eye -- is handy.  Otherwise I have to manually check the status.    Of course for people who don't want the popup then it should be able to be turned off.

   In many ways this is like email or twitter or IM.  You don't want to be glued to your email/twitter/IM screen waiting for the next message.  On the other hand you often want to be notified in a timely manner that something is happening -- thus a pop or something on the notification bar is desired.  Yet there are also times when you just want to drop out and not be notified that a new message is waiting for you.

   Basically I think that we all agree that if there are popups implemented then they should be able to be toggled.  I just do not want to see the idea of popups disappear entirely.

-- Rick

Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price

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

Thanks. But we all know that bug-free software is a contradiction in
terms...
Erik.

> -----Oorspronkelijk bericht-----
> Van: Justin Rebelo [mailto:jus...@gm...]
> Verzonden: donderdag 17 maart 2011 22:38
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price
> 
> Good show, Erik. This must be one of the only, if not _the_ only
outstanding
> 1856 issue I'm aware of.
> 
> On 3/17/11, Erik Vos <eri...@xs...> wrote:
> > Indeed. The special code to handle 5% CGR sales in stock rounds had
> > not been applied to (emergency) share selling rounds. It now is.
> >
> > Erik.
> >
> >> -----Oorspronkelijk bericht-----
> >> Van: Aliza Panitz [mailto:ali...@gm...]
> >> Verzonden: zaterdag 12 maart 2011 17:41
> >> Aan: Development list for Rails: an 18xx game
> >> CC: Erik Vos
> >> Onderwerp: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock
> >> price
> >>
> >> I've just run into the same problem in Rails 1.4.1and filed bug
> >> 3207870
> >>
> >> On Thu, Mar 25, 2010 at 4:27 PM, Erik Vos <eri...@xs...> wrote:
> >> > Never mind, I could reproduce the problem as described below, and
> >> > have fixed it.
> >> > Can’t upload it now (SVN seems down) so that will be done tomorrow.
> >> >
> >> > Erik.
> >> >
> >> > -----Original Message-----
> >> > From: Erik Vos [mailto:eri...@xs...]
> >> > Sent: Friday 26 March 2010 00:00
> >> > To: 'Development list for Rails: an 18xx game'; 'Aliza Panitz'
> >> > Subject: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock
> >> > price
> >> >
> >> > Ah, you mean that sales of 15% and 5% have added up?
> >> > If that is what has happened, I think I know what has caused this.
> >> > A saved file would of course help a lot...
> >> >
> >> > Erik.
> >> >
> >> >
> >> >
> >> > -----Original Message-----
> >> > From: Joshua Gottesman [mailto:jos...@gm...]
> >> > Sent: Thursday 25 March 2010 22:56
> >> > To: Aliza Panitz
> >> > Cc: Development list for Rails: an 18xx game
> >> > Subject: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock
> >> > price
> >> >
> >> > Yeah, I didn't even notice that.  I just expected it to keep the
> >> > price the same.  I suspect what happened is it counted your 15% and
> >> > held the
> >> > 1/2 share and then combined that with my 1/2 share for another
> >> > price drop.  Which is incorrect.
> >> >
> >> > On Thu, Mar 25, 2010 at 2:54 PM, Aliza Panitz
> >> > <ali...@gm...>
> >> > wrote:
> >> >> Rails 1.2.2 bug:
> >> >>
> >> >> Selling a single 5% share of the CGR to the pool should not have
> >> >> changed the stock price.
> >> >>
> >> >> To quote the rules:
> >> >>
> >> >> ==============
> >> >> The share value tokens move:
> >> >>
> >> >> Down one row for each full 10% share sold either during a stock
> >> >> round or during a forced sale by a company president. The sale of
> >> >> a single 5% share does not affect the share value token. Sales of
> >> >> multiple 5% shares move the share value token ==============
> >> >>
> >> >> To quote the game report:
> >> >> ]  Joshua sells a 5% share of CGR to Pool for $90.
> >> >> ] CGR price goes from $90(E2) to $80(E3).
> >> >>
> >> >>
> >> >> I'll file an official bug later if nobody else gets to it first.
> >> >>
> >> >>  - Aliza
> >> >>
> >> >> 2010/3/25 Joshua Gottesman <jos...@gm...>:
> >> >> - Hide quoted text -
> >> >>> ==================
> >> >>> Start of Stock Round 6
> >> >>> ==================
> >> >>> Aliza has the Priority Deal
> >> >>>
> >> >>> Aliza sells 3 5% shares (15%) of CGR to Pool for $300.
> >> >>> CGR price goes from $100(E1) to $90(E2).
> >> >>> Aliza starts GT at $100 and pays $200 for 2 shares (20%) to Bank
> >> >>> Joshua sells a 5% share of CGR to Pool for $90.
> >> >>> CGR price goes from $90(E2) to $80(E3).
> >> >>> Joshua starts TGB at $100 and pays $200 for 2 shares (20%) to
> >> >>> Bank
> >> >>>
> >> >>
> >
> >
> > ----------------------------------------------------------------------
> > --------
> > Colocation vs. Managed Hosting
> > A question and answer guide to determining the best fit for your
> > organization - today and in the future.
> > http://p.sf.net/sfu/internap-sfd2d
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> 
>
----------------------------------------------------------------------------
--
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit for your
> organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Making Rails more suited to fast interactive play.

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

Each to their own of course, just providing my personal opinions :)

I think we can generally agree that intrusiveness is bad (since if you
are using it real-time, you are paying attention anyway and the popups
would be annoying for those who aren't quite playing at fully
real-time speeds), also the ability to suspend polling (covered by
Erik's point 1 I believe) so that you can try out scenarios is also
nice to have.

Phil

On 18 March 2011 12:58, Chris Shaffer <chr...@gm...> wrote:
> I'm fine with having this as streamlined pbem, but my main interest is in
> having it support real-time play.
> --
> Chris
>
> Please consider the environment before printing this e-mail.
>
>
> On Fri, Mar 18, 2011 at 3:45 AM, Phil Davies <de...@gm...> wrote:
>>
>> I'd definitely favour the least intrusive approach, anything that
>> could steal focus is considerably annoying and this is treated
>> differently across different OSes.  Certainly if you can turn on or
>> off notifications that would be nice, I'm prone to playing in spare
>> moments so the ability to just bring the screen up and see if it's my
>> turn yet rather than being prompted for it would be great, I
>> definitely see this more as 'streamlined pbem' rather than an attempt
>> to do proper realtime play (which will be better suited to a proper
>> client/server architecture)
>>
>> Phil
>>
>> On 18 March 2011 01:56, Rick Westerman <wes...@pu...> wrote:
>> >   Lots of interesting comments on this proposal.  Erik's willingness to
>> > implement this -- in some form and then make it better -- is greatly
>> > appreciated.
>> >
>> >   My gaming partner and I looked over Erik's proposal and it seems fine
>> > to us.  Further refinements could include a 'poke' option -- a way to remind
>> > a person that it is his turn (although I see no way to do this given the
>> > current Rails method of sharing files; it seems more doable in a
>> > client-server type of arrangement.)   Another refinement might be a way to
>> > do messaging among the players -- although once again this seems more
>> > suitable for client-server.)
>> >
>> >   Another suggestion would be to have rapid checking for new files and
>> > then slowing down later.  In other words in immediately after submitting
>> > one's turn then checking every 10 seconds (as an example) may not be too
>> > often.  On the other hand if the other players are taking time to complete
>> > their turns, then checking every 30 seconds or so should be fine.   We are
>> > thinking of those sometimes interminable stock rounds that can occur where
>> > is it might be "player A pass", "player B pass", "player C" pass, "player D
>> > do something", "player A pass" and so on until "player D" runs out of things
>> > to do.  If the time delay between each player is 30 seconds then the SR
>> > could take a long time.
>> >
>> >
>> >   As for the following.
>> >
>> >
>> > ----- Chris wrote: -----
>> >> Actually, I would be fine with Brett's more graceful approach. My
>> >> answer was that a popup would suffice, not that it is preferred. I'd
>> >> rather have the notification area solution, as long as it only bugged
>> >> me when it was my turn.
>> >
>> >  Bugging when it is person's turn and being silent (or at least quietly
>> > in the log file) when it is not is important.
>> >
>> >
>> > Thanks again,
>> >
>> > --
>> > Rick
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Colocation vs. Managed Hosting
>> > A question and answer guide to determining the best fit
>> > for your organization - today and in the future.
>> > http://p.sf.net/sfu/internap-sfd2d
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Colocation vs. Managed Hosting
>> A question and answer guide to determining the best fit
>> for your organization - today and in the future.
>> http://p.sf.net/sfu/internap-sfd2d
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] Making Rails more suited to fast interactive play.

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

I'm fine with having this as streamlined pbem, but my main interest is in
having it support real-time play.

--
Chris

Please consider the environment before printing this e-mail.


On Fri, Mar 18, 2011 at 3:45 AM, Phil Davies <de...@gm...> wrote:

> I'd definitely favour the least intrusive approach, anything that
> could steal focus is considerably annoying and this is treated
> differently across different OSes.  Certainly if you can turn on or
> off notifications that would be nice, I'm prone to playing in spare
> moments so the ability to just bring the screen up and see if it's my
> turn yet rather than being prompted for it would be great, I
> definitely see this more as 'streamlined pbem' rather than an attempt
> to do proper realtime play (which will be better suited to a proper
> client/server architecture)
>
> Phil
>
> On 18 March 2011 01:56, Rick Westerman <wes...@pu...> wrote:
> >   Lots of interesting comments on this proposal.  Erik's willingness to
> implement this -- in some form and then make it better -- is greatly
> appreciated.
> >
> >   My gaming partner and I looked over Erik's proposal and it seems fine
> to us.  Further refinements could include a 'poke' option -- a way to remind
> a person that it is his turn (although I see no way to do this given the
> current Rails method of sharing files; it seems more doable in a
> client-server type of arrangement.)   Another refinement might be a way to
> do messaging among the players -- although once again this seems more
> suitable for client-server.)
> >
> >   Another suggestion would be to have rapid checking for new files and
> then slowing down later.  In other words in immediately after submitting
> one's turn then checking every 10 seconds (as an example) may not be too
> often.  On the other hand if the other players are taking time to complete
> their turns, then checking every 30 seconds or so should be fine.   We are
> thinking of those sometimes interminable stock rounds that can occur where
> is it might be "player A pass", "player B pass", "player C" pass, "player D
> do something", "player A pass" and so on until "player D" runs out of things
> to do.  If the time delay between each player is 30 seconds then the SR
> could take a long time.
> >
> >
> >   As for the following.
> >
> >
> > ----- Chris wrote: -----
> >> Actually, I would be fine with Brett's more graceful approach. My
> >> answer was that a popup would suffice, not that it is preferred. I'd
> >> rather have the notification area solution, as long as it only bugged
> >> me when it was my turn.
> >
> >  Bugging when it is person's turn and being silent (or at least quietly
> in the log file) when it is not is important.
> >
> >
> > Thanks again,
> >
> > --
> > Rick
> >
> >
> ------------------------------------------------------------------------------
> > Colocation vs. Managed Hosting
> > A question and answer guide to determining the best fit
> > for your organization - today and in the future.
> > http://p.sf.net/sfu/internap-sfd2d
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Making Rails more suited to fast interactive play.

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

I'd definitely favour the least intrusive approach, anything that
could steal focus is considerably annoying and this is treated
differently across different OSes.  Certainly if you can turn on or
off notifications that would be nice, I'm prone to playing in spare
moments so the ability to just bring the screen up and see if it's my
turn yet rather than being prompted for it would be great, I
definitely see this more as 'streamlined pbem' rather than an attempt
to do proper realtime play (which will be better suited to a proper
client/server architecture)

Phil

On 18 March 2011 01:56, Rick Westerman <wes...@pu...> wrote:
>   Lots of interesting comments on this proposal.  Erik's willingness to implement this -- in some form and then make it better -- is greatly appreciated.
>
>   My gaming partner and I looked over Erik's proposal and it seems fine to us.  Further refinements could include a 'poke' option -- a way to remind a person that it is his turn (although I see no way to do this given the current Rails method of sharing files; it seems more doable in a client-server type of arrangement.)   Another refinement might be a way to do messaging among the players -- although once again this seems more suitable for client-server.)
>
>   Another suggestion would be to have rapid checking for new files and then slowing down later.  In other words in immediately after submitting one's turn then checking every 10 seconds (as an example) may not be too often.  On the other hand if the other players are taking time to complete their turns, then checking every 30 seconds or so should be fine.   We are thinking of those sometimes interminable stock rounds that can occur where is it might be "player A pass", "player B pass", "player C" pass, "player D do something", "player A pass" and so on until "player D" runs out of things to do.  If the time delay between each player is 30 seconds then the SR could take a long time.
>
>
>   As for the following.
>
>
> ----- Chris wrote: -----
>> Actually, I would be fine with Brett's more graceful approach. My
>> answer was that a popup would suffice, not that it is preferred. I'd
>> rather have the notification area solution, as long as it only bugged
>> me when it was my turn.
>
>  Bugging when it is person's turn and being silent (or at least quietly in the log file) when it is not is important.
>
>
> Thanks again,
>
> --
> Rick
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Making Rails more suited to fast interactive play.

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

   Lots of interesting comments on this proposal.  Erik's willingness to implement this -- in some form and then make it better -- is greatly appreciated. 

   My gaming partner and I looked over Erik's proposal and it seems fine to us.  Further refinements could include a 'poke' option -- a way to remind a person that it is his turn (although I see no way to do this given the current Rails method of sharing files; it seems more doable in a client-server type of arrangement.)   Another refinement might be a way to do messaging among the players -- although once again this seems more suitable for client-server.)

   Another suggestion would be to have rapid checking for new files and then slowing down later.  In other words in immediately after submitting one's turn then checking every 10 seconds (as an example) may not be too often.  On the other hand if the other players are taking time to complete their turns, then checking every 30 seconds or so should be fine.   We are thinking of those sometimes interminable stock rounds that can occur where is it might be "player A pass", "player B pass", "player C" pass, "player D do something", "player A pass" and so on until "player D" runs out of things to do.  If the time delay between each player is 30 seconds then the SR could take a long time.  


   As for the following.


----- Chris wrote: -----
> Actually, I would be fine with Brett's more graceful approach. My
> answer was that a popup would suffice, not that it is preferred. I'd
> rather have the notification area solution, as long as it only bugged
> me when it was my turn.

  Bugging when it is person's turn and being silent (or at least quietly in the log file) when it is not is important.

 
Thanks again,

-- 
Rick

Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price

[Justin R. <jus...@gm...>]

Good show, Erik. This must be one of the only, if not _the_ only
outstanding 1856 issue I'm aware of.

On 3/17/11, Erik Vos <eri...@xs...> wrote:
> Indeed. The special code to handle 5% CGR sales in stock rounds had not been
> applied to (emergency) share selling rounds. It now is.
>
> Erik.
>
>> -----Oorspronkelijk bericht-----
>> Van: Aliza Panitz [mailto:ali...@gm...]
>> Verzonden: zaterdag 12 maart 2011 17:41
>> Aan: Development list for Rails: an 18xx game
>> CC: Erik Vos
>> Onderwerp: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price
>>
>> I've just run into the same problem in Rails 1.4.1and filed bug 3207870
>>
>> On Thu, Mar 25, 2010 at 4:27 PM, Erik Vos <eri...@xs...> wrote:
>> > Never mind, I could reproduce the problem as described below, and have
>> > fixed it.
>> > Can’t upload it now (SVN seems down) so that will be done tomorrow.
>> >
>> > Erik.
>> >
>> > -----Original Message-----
>> > From: Erik Vos [mailto:eri...@xs...]
>> > Sent: Friday 26 March 2010 00:00
>> > To: 'Development list for Rails: an 18xx game'; 'Aliza Panitz'
>> > Subject: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price
>> >
>> > Ah, you mean that sales of 15% and 5% have added up?
>> > If that is what has happened, I think I know what has caused this.
>> > A saved file would of course help a lot...
>> >
>> > Erik.
>> >
>> >
>> >
>> > -----Original Message-----
>> > From: Joshua Gottesman [mailto:jos...@gm...]
>> > Sent: Thursday 25 March 2010 22:56
>> > To: Aliza Panitz
>> > Cc: Development list for Rails: an 18xx game
>> > Subject: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price
>> >
>> > Yeah, I didn't even notice that.  I just expected it to keep the price
>> > the same.  I suspect what happened is it counted your 15% and held the
>> > 1/2 share and then combined that with my 1/2 share for another price
>> > drop.  Which is incorrect.
>> >
>> > On Thu, Mar 25, 2010 at 2:54 PM, Aliza Panitz <ali...@gm...>
>> > wrote:
>> >> Rails 1.2.2 bug:
>> >>
>> >> Selling a single 5% share of the CGR to the pool should not have
>> >> changed the stock price.
>> >>
>> >> To quote the rules:
>> >>
>> >> ==============
>> >> The share value tokens move:
>> >>
>> >> Down one row for each full 10% share sold either during a stock round
>> >> or during a forced sale by a company president. The sale of a single
>> >> 5% share does not affect the share value token. Sales of multiple 5%
>> >> shares move the share value token ==============
>> >>
>> >> To quote the game report:
>> >> ]  Joshua sells a 5% share of CGR to Pool for $90.
>> >> ] CGR price goes from $90(E2) to $80(E3).
>> >>
>> >>
>> >> I'll file an official bug later if nobody else gets to it first.
>> >>
>> >>  - Aliza
>> >>
>> >> 2010/3/25 Joshua Gottesman <jos...@gm...>:
>> >> - Hide quoted text -
>> >>> ==================
>> >>> Start of Stock Round 6
>> >>> ==================
>> >>> Aliza has the Priority Deal
>> >>>
>> >>> Aliza sells 3 5% shares (15%) of CGR to Pool for $300.
>> >>> CGR price goes from $100(E1) to $90(E2).
>> >>> Aliza starts GT at $100 and pays $200 for 2 shares (20%) to Bank
>> >>> Joshua sells a 5% share of CGR to Pool for $90.
>> >>> CGR price goes from $90(E2) to $80(E3).
>> >>> Joshua starts TGB at $100 and pays $200 for 2 shares (20%) to Bank
>> >>>
>> >>
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price

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

Indeed. The special code to handle 5% CGR sales in stock rounds had not been
applied to (emergency) share selling rounds. It now is.

Erik.

> -----Oorspronkelijk bericht-----
> Van: Aliza Panitz [mailto:ali...@gm...]
> Verzonden: zaterdag 12 maart 2011 17:41
> Aan: Development list for Rails: an 18xx game
> CC: Erik Vos
> Onderwerp: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price
> 
> I've just run into the same problem in Rails 1.4.1and filed bug 3207870
> 
> On Thu, Mar 25, 2010 at 4:27 PM, Erik Vos <eri...@xs...> wrote:
> > Never mind, I could reproduce the problem as described below, and have
> > fixed it.
> > Can’t upload it now (SVN seems down) so that will be done tomorrow.
> >
> > Erik.
> >
> > -----Original Message-----
> > From: Erik Vos [mailto:eri...@xs...]
> > Sent: Friday 26 March 2010 00:00
> > To: 'Development list for Rails: an 18xx game'; 'Aliza Panitz'
> > Subject: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price
> >
> > Ah, you mean that sales of 15% and 5% have added up?
> > If that is what has happened, I think I know what has caused this.
> > A saved file would of course help a lot...
> >
> > Erik.
> >
> >
> >
> > -----Original Message-----
> > From: Joshua Gottesman [mailto:jos...@gm...]
> > Sent: Thursday 25 March 2010 22:56
> > To: Aliza Panitz
> > Cc: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price
> >
> > Yeah, I didn't even notice that.  I just expected it to keep the price
> > the same.  I suspect what happened is it counted your 15% and held the
> > 1/2 share and then combined that with my 1/2 share for another price
> > drop.  Which is incorrect.
> >
> > On Thu, Mar 25, 2010 at 2:54 PM, Aliza Panitz <ali...@gm...>
> > wrote:
> >> Rails 1.2.2 bug:
> >>
> >> Selling a single 5% share of the CGR to the pool should not have
> >> changed the stock price.
> >>
> >> To quote the rules:
> >>
> >> ==============
> >> The share value tokens move:
> >>
> >> Down one row for each full 10% share sold either during a stock round
> >> or during a forced sale by a company president. The sale of a single
> >> 5% share does not affect the share value token. Sales of multiple 5%
> >> shares move the share value token ==============
> >>
> >> To quote the game report:
> >> ]  Joshua sells a 5% share of CGR to Pool for $90.
> >> ] CGR price goes from $90(E2) to $80(E3).
> >>
> >>
> >> I'll file an official bug later if nobody else gets to it first.
> >>
> >>  - Aliza
> >>
> >> 2010/3/25 Joshua Gottesman <jos...@gm...>:
> >> - Hide quoted text -
> >>> ==================
> >>> Start of Stock Round 6
> >>> ==================
> >>> Aliza has the Priority Deal
> >>>
> >>> Aliza sells 3 5% shares (15%) of CGR to Pool for $300.
> >>> CGR price goes from $100(E1) to $90(E2).
> >>> Aliza starts GT at $100 and pays $200 for 2 shares (20%) to Bank
> >>> Joshua sells a 5% share of CGR to Pool for $90.
> >>> CGR price goes from $90(E2) to $80(E3).
> >>> Joshua starts TGB at $100 and pays $200 for 2 shares (20%) to Bank
> >>>
> >>

Re: [Rails-devel] Making Rails more suited to fast interactive play.

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

Only the map/OR window currently has a notification area. You would want to
see your currently active window on top when it is your turn again.
Erik.

> -----Oorspronkelijk bericht-----
> Van: Chris Shaffer [mailto:chr...@gm...]
> Verzonden: donderdag 17 maart 2011 21:35
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] Making Rails more suited to fast interactive
> play.
> 
> Actually, I would be fine with Brett's more graceful approach.  My answer
> was that a popup would suffice, not that it is preferred.  I'd rather have
the
> notification area solution, as long as it only bugged me when it was my
turn.
> 
> --
> Chris
> 
> Please consider the environment before printing this e-mail.
> 
> 
> 
> On Thu, Mar 17, 2011 at 12:51 PM, Erik Vos <eri...@xs...> wrote:
> > I'll see what can be done while working on it. Let's first make it do
the job,
> and then make it better.
> > As Brett and Chris seem to be on opposite ends of a scale that measures
> the level-of-disturbance scale they expect when getting a turn, I'll
probably
> start with staying in the middle with the simplest solution (just the
popup).
> >
> > Erik.
> >
> >> -----Oorspronkelijk bericht-----
> >> Van: brett lentz [mailto:bre...@gm...]
> >> Verzonden: donderdag 17 maart 2011 19:33
> >> Aan: Development list for Rails: an 18xx game
> >> Onderwerp: Re: [Rails-devel] Making Rails more suited to fast
> >> interactive play.
> >>
> >> As a basic rule, I'm very opposed to popups that disrupt the flow of
> >> the UI and force the user's attention away from whatever they're
> >> doing. I don't like to assume that we'll know what the user wants to
> >> be doing whenever the pop-up is set to be fired.
> >>
> >> Rather than a pop-up, perhaps we can have something in the log or
> >> status areas?
> >>
> >> ---Brett.
> >>
> >>
> >>
> >> On Thu, Mar 17, 2011 at 10:11 AM, Chris Shaffer
> >> <chr...@gm...>
> >> wrote:
> >> > I didn't notice that you mentioned a popup in the quoted section at
> >> > the top of your email.  There's nothing about a popup in the
> >> > numbered procedure list (items 1-4).  A popup is probably
> >> > sufficient, but audible alarms and/or flashing task bar would be
> appreciated.
> >> >
> >> > If you can't use the new style report window during polling, that
> >> > would be a big loss.  I would expect to use the time while others
> >> > are taking their turn to plan mine, and reviewing previous actions
> >> > is part of that.  Maybe a button to say "I'm planning, don't make any
> saves"
> >> > would solve this?
> >> >
> >> > Would it be possible to have an option for polling to only load a
> >> > game when it is my action, and have a further option for the the
> >> > popup to ask "it's your turn, are you ready to load the new file?"
> >> >
> >> > --
> >> > Chris
> >> >
> >> > Please consider the environment before printing this e-mail.
> >> >
> >> >
> >> >
> >> > On Thu, Mar 17, 2011 at 8:08 AM, Erik Vos <eri...@xs...> wrote:
> >> >> That’s a lot of requests!  Thanks for thinking through all these
> >> >> consequences.
> >> >>
> >> >> Some comments below.
> >> >>
> >> >> Erik.
> >> >>
> >> >>
> >> >>
> >> >> Van: Chris Shaffer [mailto:chr...@gm...]
> >> >> Verzonden: donderdag 17 maart 2011 15:09
> >> >> Aan: Development list for Rails: an 18xx game
> >> >> Onderwerp: Re: [Rails-devel] Making Rails more suited to fast
> >> >> interactive play.
> >> >>
> >> >>
> >> >>
> >> >> This may not be possible, but I'd like some options to allow
> >> >> players to keep control of their version of the game and prevent
> >> >> loading a new file if the polling shows it's someone else's turn.
> >> >> I imagine it would be annoying to be looking at the stock market
> >> >> or be reviewing the game log, and suddenly the game loads a new
> >> >> file and it's not even my turn yet.  In the event this isn't
> >> >> possible, can we at least ensure that the window positions are
> >> >> remembered, so if I'm looking at the stock market on a small
> >> >> laptop screen, it isn't suddenly replaced with
> >> the map because an auto-load occurred?
> >> >>
> >> >>
> >> >>
> >> >> EV: A ‘suspend polling’ menu item should be easy to add.
> >> >>
> >> >>
> >> >>
> >> >> Perhaps let the polling interval be player configurable?
> >> >>
> >> >>
> >> >>
> >> >> EV: I already proposed that.
> >> >>
> >> >>
> >> >>
> >> >> When reviewing the log, if a player backs up and starts stepping
> >> >> through it, we need to be sure this activity doesn't generate save
files.
> >> >>
> >> >> EV: Not sure, but I think we cannot allow stepping through the
> >> >> new-style report window during polling.  Perhaps we have to fix
> >> >> the report window, to what it was the old way.  Or is flipping the
> >> >> report
> >> window too slow?
> >> >>
> >> >>
> >> >>
> >> >> Will there be a configurable visual indicator (flashing? noise?)
> >> >> to tell me that the polling has discovered it is my turn?  So I
> >> >> could turn off the audible alarm if I'm sitting at my computer
> >> >> real time, but turn it on when I'm running to the kitchen to make
> coffee?
> >> >>
> >> >>
> >> >>
> >> >> EV: I already proposed a popup. Not sure if sound is possible in a
> >> >> platform-neutral way (I have no experience with programming sound).
> >> >>
> >> >>
> >> >>
> >> >> And the task bar would flash to let me know it's my turn when I'm
> >> >> checking my email.
> >> >>
> >> >>
> >> >>
> >> >> EV: Isn’t that too platform-dependent? I would have no clue how to
> >> >> do that anyway.
> >> >>
> >> >>
> >> >>
> >> >> ------------------------------------------------------------------
> >> >> ---
> >> >> ---------
> >> >> Colocation vs. Managed Hosting
> >> >> A question and answer guide to determining the best fit for your
> >> >> organization - today and in the future.
> >> >> http://p.sf.net/sfu/internap-sfd2d
> >> >> _______________________________________________
> >> >> Rails-devel mailing list
> >> >> Rai...@li...
> >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >> >>
> >> >>
> >> >
> >> > -------------------------------------------------------------------
> >> > ---
> >> > --------
> >> > Colocation vs. Managed Hosting
> >> > A question and answer guide to determining the best fit for your
> >> > organization - today and in the future.
> >> > http://p.sf.net/sfu/internap-sfd2d
> >> > _______________________________________________
> >> > Rails-devel mailing list
> >> > Rai...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> ---------
> >> Colocation vs. Managed Hosting
> >> A question and answer guide to determining the best fit for your
> >> organization - today and in the future.
> >> http://p.sf.net/sfu/internap-sfd2d
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> > ----------------------------------------------------------------------
> > --------
> > Colocation vs. Managed Hosting
> > A question and answer guide to determining the best fit for your
> > organization - today and in the future.
> > http://p.sf.net/sfu/internap-sfd2d
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> 
>
----------------------------------------------------------------------------
--
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit for your
> organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Making Rails more suited to fast interactive play.

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

Actually, I would be fine with Brett's more graceful approach.  My
answer was that a popup would suffice, not that it is preferred.  I'd
rather have the notification area solution, as long as it only bugged
me when it was my turn.

--
Chris

Please consider the environment before printing this e-mail.



On Thu, Mar 17, 2011 at 12:51 PM, Erik Vos <eri...@xs...> wrote:
> I'll see what can be done while working on it. Let's first make it do the job, and then make it better.
> As Brett and Chris seem to be on opposite ends of a scale that measures the level-of-disturbance scale they expect when getting a turn, I'll probably start with staying in the middle with the simplest solution (just the popup).
>
> Erik.
>
>> -----Oorspronkelijk bericht-----
>> Van: brett lentz [mailto:bre...@gm...]
>> Verzonden: donderdag 17 maart 2011 19:33
>> Aan: Development list for Rails: an 18xx game
>> Onderwerp: Re: [Rails-devel] Making Rails more suited to fast interactive
>> play.
>>
>> As a basic rule, I'm very opposed to popups that disrupt the flow of the UI
>> and force the user's attention away from whatever they're doing. I don't like
>> to assume that we'll know what the user wants to be doing whenever the
>> pop-up is set to be fired.
>>
>> Rather than a pop-up, perhaps we can have something in the log or status
>> areas?
>>
>> ---Brett.
>>
>>
>>
>> On Thu, Mar 17, 2011 at 10:11 AM, Chris Shaffer <chr...@gm...>
>> wrote:
>> > I didn't notice that you mentioned a popup in the quoted section at
>> > the top of your email.  There's nothing about a popup in the numbered
>> > procedure list (items 1-4).  A popup is probably sufficient, but
>> > audible alarms and/or flashing task bar would be appreciated.
>> >
>> > If you can't use the new style report window during polling, that
>> > would be a big loss.  I would expect to use the time while others are
>> > taking their turn to plan mine, and reviewing previous actions is part
>> > of that.  Maybe a button to say "I'm planning, don't make any saves"
>> > would solve this?
>> >
>> > Would it be possible to have an option for polling to only load a game
>> > when it is my action, and have a further option for the the popup to
>> > ask "it's your turn, are you ready to load the new file?"
>> >
>> > --
>> > Chris
>> >
>> > Please consider the environment before printing this e-mail.
>> >
>> >
>> >
>> > On Thu, Mar 17, 2011 at 8:08 AM, Erik Vos <eri...@xs...> wrote:
>> >> That’s a lot of requests!  Thanks for thinking through all these
>> >> consequences.
>> >>
>> >> Some comments below.
>> >>
>> >> Erik.
>> >>
>> >>
>> >>
>> >> Van: Chris Shaffer [mailto:chr...@gm...]
>> >> Verzonden: donderdag 17 maart 2011 15:09
>> >> Aan: Development list for Rails: an 18xx game
>> >> Onderwerp: Re: [Rails-devel] Making Rails more suited to fast
>> >> interactive play.
>> >>
>> >>
>> >>
>> >> This may not be possible, but I'd like some options to allow players
>> >> to keep control of their version of the game and prevent loading a
>> >> new file if the polling shows it's someone else's turn.  I imagine it
>> >> would be annoying to be looking at the stock market or be reviewing
>> >> the game log, and suddenly the game loads a new file and it's not
>> >> even my turn yet.  In the event this isn't possible, can we at least
>> >> ensure that the window positions are remembered, so if I'm looking at
>> >> the stock market on a small laptop screen, it isn't suddenly replaced with
>> the map because an auto-load occurred?
>> >>
>> >>
>> >>
>> >> EV: A ‘suspend polling’ menu item should be easy to add.
>> >>
>> >>
>> >>
>> >> Perhaps let the polling interval be player configurable?
>> >>
>> >>
>> >>
>> >> EV: I already proposed that.
>> >>
>> >>
>> >>
>> >> When reviewing the log, if a player backs up and starts stepping
>> >> through it, we need to be sure this activity doesn't generate save files.
>> >>
>> >> EV: Not sure, but I think we cannot allow stepping through the
>> >> new-style report window during polling.  Perhaps we have to fix the
>> >> report window, to what it was the old way.  Or is flipping the report
>> window too slow?
>> >>
>> >>
>> >>
>> >> Will there be a configurable visual indicator (flashing? noise?) to
>> >> tell me that the polling has discovered it is my turn?  So I could
>> >> turn off the audible alarm if I'm sitting at my computer real time,
>> >> but turn it on when I'm running to the kitchen to make coffee?
>> >>
>> >>
>> >>
>> >> EV: I already proposed a popup. Not sure if sound is possible in a
>> >> platform-neutral way (I have no experience with programming sound).
>> >>
>> >>
>> >>
>> >> And the task bar would flash to let me know it's my turn when I'm
>> >> checking my email.
>> >>
>> >>
>> >>
>> >> EV: Isn’t that too platform-dependent? I would have no clue how to do
>> >> that anyway.
>> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> ---------
>> >> Colocation vs. Managed Hosting
>> >> A question and answer guide to determining the best fit for your
>> >> organization - today and in the future.
>> >> http://p.sf.net/sfu/internap-sfd2d
>> >> _______________________________________________
>> >> Rails-devel mailing list
>> >> Rai...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >>
>> >>
>> >
>> > ----------------------------------------------------------------------
>> > --------
>> > Colocation vs. Managed Hosting
>> > A question and answer guide to determining the best fit for your
>> > organization - today and in the future.
>> > http://p.sf.net/sfu/internap-sfd2d
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>>
>> ------------------------------------------------------------------------------
>> Colocation vs. Managed Hosting
>> A question and answer guide to determining the best fit for your
>> organization - today and in the future.
>> http://p.sf.net/sfu/internap-sfd2d
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Making Rails more suited to fast interactive play.

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

I'll see what can be done while working on it. Let's first make it do the job, and then make it better.  
As Brett and Chris seem to be on opposite ends of a scale that measures the level-of-disturbance scale they expect when getting a turn, I'll probably start with staying in the middle with the simplest solution (just the popup). 

Erik.

> -----Oorspronkelijk bericht-----
> Van: brett lentz [mailto:bre...@gm...]
> Verzonden: donderdag 17 maart 2011 19:33
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] Making Rails more suited to fast interactive
> play.
> 
> As a basic rule, I'm very opposed to popups that disrupt the flow of the UI
> and force the user's attention away from whatever they're doing. I don't like
> to assume that we'll know what the user wants to be doing whenever the
> pop-up is set to be fired.
> 
> Rather than a pop-up, perhaps we can have something in the log or status
> areas?
> 
> ---Brett.
> 
> 
> 
> On Thu, Mar 17, 2011 at 10:11 AM, Chris Shaffer <chr...@gm...>
> wrote:
> > I didn't notice that you mentioned a popup in the quoted section at
> > the top of your email.  There's nothing about a popup in the numbered
> > procedure list (items 1-4).  A popup is probably sufficient, but
> > audible alarms and/or flashing task bar would be appreciated.
> >
> > If you can't use the new style report window during polling, that
> > would be a big loss.  I would expect to use the time while others are
> > taking their turn to plan mine, and reviewing previous actions is part
> > of that.  Maybe a button to say "I'm planning, don't make any saves"
> > would solve this?
> >
> > Would it be possible to have an option for polling to only load a game
> > when it is my action, and have a further option for the the popup to
> > ask "it's your turn, are you ready to load the new file?"
> >
> > --
> > Chris
> >
> > Please consider the environment before printing this e-mail.
> >
> >
> >
> > On Thu, Mar 17, 2011 at 8:08 AM, Erik Vos <eri...@xs...> wrote:
> >> That’s a lot of requests!  Thanks for thinking through all these
> >> consequences.
> >>
> >> Some comments below.
> >>
> >> Erik.
> >>
> >>
> >>
> >> Van: Chris Shaffer [mailto:chr...@gm...]
> >> Verzonden: donderdag 17 maart 2011 15:09
> >> Aan: Development list for Rails: an 18xx game
> >> Onderwerp: Re: [Rails-devel] Making Rails more suited to fast
> >> interactive play.
> >>
> >>
> >>
> >> This may not be possible, but I'd like some options to allow players
> >> to keep control of their version of the game and prevent loading a
> >> new file if the polling shows it's someone else's turn.  I imagine it
> >> would be annoying to be looking at the stock market or be reviewing
> >> the game log, and suddenly the game loads a new file and it's not
> >> even my turn yet.  In the event this isn't possible, can we at least
> >> ensure that the window positions are remembered, so if I'm looking at
> >> the stock market on a small laptop screen, it isn't suddenly replaced with
> the map because an auto-load occurred?
> >>
> >>
> >>
> >> EV: A ‘suspend polling’ menu item should be easy to add.
> >>
> >>
> >>
> >> Perhaps let the polling interval be player configurable?
> >>
> >>
> >>
> >> EV: I already proposed that.
> >>
> >>
> >>
> >> When reviewing the log, if a player backs up and starts stepping
> >> through it, we need to be sure this activity doesn't generate save files.
> >>
> >> EV: Not sure, but I think we cannot allow stepping through the
> >> new-style report window during polling.  Perhaps we have to fix the
> >> report window, to what it was the old way.  Or is flipping the report
> window too slow?
> >>
> >>
> >>
> >> Will there be a configurable visual indicator (flashing? noise?) to
> >> tell me that the polling has discovered it is my turn?  So I could
> >> turn off the audible alarm if I'm sitting at my computer real time,
> >> but turn it on when I'm running to the kitchen to make coffee?
> >>
> >>
> >>
> >> EV: I already proposed a popup. Not sure if sound is possible in a
> >> platform-neutral way (I have no experience with programming sound).
> >>
> >>
> >>
> >> And the task bar would flash to let me know it's my turn when I'm
> >> checking my email.
> >>
> >>
> >>
> >> EV: Isn’t that too platform-dependent? I would have no clue how to do
> >> that anyway.
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> ---------
> >> Colocation vs. Managed Hosting
> >> A question and answer guide to determining the best fit for your
> >> organization - today and in the future.
> >> http://p.sf.net/sfu/internap-sfd2d
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >>
> >>
> >
> > ----------------------------------------------------------------------
> > --------
> > Colocation vs. Managed Hosting
> > A question and answer guide to determining the best fit for your
> > organization - today and in the future.
> > http://p.sf.net/sfu/internap-sfd2d
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> 
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit for your
> organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Making Rails more suited to fast interactive play.

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

As a basic rule, I'm very opposed to popups that disrupt the flow of
the UI and force the user's attention away from whatever they're
doing. I don't like to assume that we'll know what the user wants to
be doing whenever the pop-up is set to be fired.

Rather than a pop-up, perhaps we can have something in the log or status areas?

---Brett.



On Thu, Mar 17, 2011 at 10:11 AM, Chris Shaffer <chr...@gm...> wrote:
> I didn't notice that you mentioned a popup in the quoted section at
> the top of your email.  There's nothing about a popup in the numbered
> procedure list (items 1-4).  A popup is probably sufficient, but
> audible alarms and/or flashing task bar would be appreciated.
>
> If you can't use the new style report window during polling, that
> would be a big loss.  I would expect to use the time while others are
> taking their turn to plan mine, and reviewing previous actions is part
> of that.  Maybe a button to say "I'm planning, don't make any saves"
> would solve this?
>
> Would it be possible to have an option for polling to only load a game
> when it is my action, and have a further option for the the popup to
> ask "it's your turn, are you ready to load the new file?"
>
> --
> Chris
>
> Please consider the environment before printing this e-mail.
>
>
>
> On Thu, Mar 17, 2011 at 8:08 AM, Erik Vos <eri...@xs...> wrote:
>> That’s a lot of requests!  Thanks for thinking through all these
>> consequences.
>>
>> Some comments below.
>>
>> Erik.
>>
>>
>>
>> Van: Chris Shaffer [mailto:chr...@gm...]
>> Verzonden: donderdag 17 maart 2011 15:09
>> Aan: Development list for Rails: an 18xx game
>> Onderwerp: Re: [Rails-devel] Making Rails more suited to fast interactive
>> play.
>>
>>
>>
>> This may not be possible, but I'd like some options to allow players to keep
>> control of their version of the game and prevent loading a new file if the
>> polling shows it's someone else's turn.  I imagine it would be annoying to
>> be looking at the stock market or be reviewing the game log, and suddenly
>> the game loads a new file and it's not even my turn yet.  In the event this
>> isn't possible, can we at least ensure that the window positions are
>> remembered, so if I'm looking at the stock market on a small laptop screen,
>> it isn't suddenly replaced with the map because an auto-load occurred?
>>
>>
>>
>> EV: A ‘suspend polling’ menu item should be easy to add.
>>
>>
>>
>> Perhaps let the polling interval be player configurable?
>>
>>
>>
>> EV: I already proposed that.
>>
>>
>>
>> When reviewing the log, if a player backs up and starts stepping through it,
>> we need to be sure this activity doesn't generate save files.
>>
>> EV: Not sure, but I think we cannot allow stepping through the new-style
>> report window during polling.  Perhaps we have to fix the report window, to
>> what it was the old way.  Or is flipping the report window too slow?
>>
>>
>>
>> Will there be a configurable visual indicator (flashing? noise?) to tell me
>> that the polling has discovered it is my turn?  So I could turn off the
>> audible alarm if I'm sitting at my computer real time, but turn it on when
>> I'm running to the kitchen to make coffee?
>>
>>
>>
>> EV: I already proposed a popup. Not sure if sound is possible in a
>> platform-neutral way (I have no experience with programming sound).
>>
>>
>>
>> And the task bar would flash to let me know it's my turn when I'm checking
>> my email.
>>
>>
>>
>> EV: Isn’t that too platform-dependent? I would have no clue how to do that
>> anyway.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Colocation vs. Managed Hosting
>> A question and answer guide to determining the best fit
>> for your organization - today and in the future.
>> http://p.sf.net/sfu/internap-sfd2d
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Making Rails more suited to fast interactive play.

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

I didn't notice that you mentioned a popup in the quoted section at
the top of your email.  There's nothing about a popup in the numbered
procedure list (items 1-4).  A popup is probably sufficient, but
audible alarms and/or flashing task bar would be appreciated.

If you can't use the new style report window during polling, that
would be a big loss.  I would expect to use the time while others are
taking their turn to plan mine, and reviewing previous actions is part
of that.  Maybe a button to say "I'm planning, don't make any saves"
would solve this?

Would it be possible to have an option for polling to only load a game
when it is my action, and have a further option for the the popup to
ask "it's your turn, are you ready to load the new file?"

--
Chris

Please consider the environment before printing this e-mail.



On Thu, Mar 17, 2011 at 8:08 AM, Erik Vos <eri...@xs...> wrote:
> That’s a lot of requests!  Thanks for thinking through all these
> consequences.
>
> Some comments below.
>
> Erik.
>
>
>
> Van: Chris Shaffer [mailto:chr...@gm...]
> Verzonden: donderdag 17 maart 2011 15:09
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] Making Rails more suited to fast interactive
> play.
>
>
>
> This may not be possible, but I'd like some options to allow players to keep
> control of their version of the game and prevent loading a new file if the
> polling shows it's someone else's turn.  I imagine it would be annoying to
> be looking at the stock market or be reviewing the game log, and suddenly
> the game loads a new file and it's not even my turn yet.  In the event this
> isn't possible, can we at least ensure that the window positions are
> remembered, so if I'm looking at the stock market on a small laptop screen,
> it isn't suddenly replaced with the map because an auto-load occurred?
>
>
>
> EV: A ‘suspend polling’ menu item should be easy to add.
>
>
>
> Perhaps let the polling interval be player configurable?
>
>
>
> EV: I already proposed that.
>
>
>
> When reviewing the log, if a player backs up and starts stepping through it,
> we need to be sure this activity doesn't generate save files.
>
> EV: Not sure, but I think we cannot allow stepping through the new-style
> report window during polling.  Perhaps we have to fix the report window, to
> what it was the old way.  Or is flipping the report window too slow?
>
>
>
> Will there be a configurable visual indicator (flashing? noise?) to tell me
> that the polling has discovered it is my turn?  So I could turn off the
> audible alarm if I'm sitting at my computer real time, but turn it on when
> I'm running to the kitchen to make coffee?
>
>
>
> EV: I already proposed a popup. Not sure if sound is possible in a
> platform-neutral way (I have no experience with programming sound).
>
>
>
> And the task bar would flash to let me know it's my turn when I'm checking
> my email.
>
>
>
> EV: Isn’t that too platform-dependent? I would have no clue how to do that
> anyway.
>
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] Making Rails more suited to fast interactive play.

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

On Thu, Mar 17, 2011 at 8:08 AM, Erik Vos <eri...@xs...> wrote:
>> This may not be possible, but I'd like some options to allow players to keep
>> control of their version of the game and prevent loading a new file if the
>> polling shows it's someone else's turn.  I imagine it would be annoying to
>> be looking at the stock market or be reviewing the game log, and suddenly
>> the game loads a new file and it's not even my turn yet.  In the event this
>> isn't possible, can we at least ensure that the window positions are
>> remembered, so if I'm looking at the stock market on a small laptop screen,
>> it isn't suddenly replaced with the map because an auto-load occurred?
>>
>>
>>
> EV: A ‘suspend polling’ menu item should be easy to add.
>

This might be easiest if the polling is implemented in a separate
thread from the main game. That will minimize its ability to block
redrawing and undo/redo.

---Brett.

Re: [Rails-devel] Making Rails more suited to fast interactive play.

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

That's a lot of requests!  Thanks for thinking through all these
consequences.

Some comments below.

Erik.

 

Van: Chris Shaffer [mailto:chr...@gm...] 
Verzonden: donderdag 17 maart 2011 15:09
Aan: Development list for Rails: an 18xx game
Onderwerp: Re: [Rails-devel] Making Rails more suited to fast interactive
play.

 

This may not be possible, but I'd like some options to allow players to keep
control of their version of the game and prevent loading a new file if the
polling shows it's someone else's turn.  I imagine it would be annoying to
be looking at the stock market or be reviewing the game log, and suddenly
the game loads a new file and it's not even my turn yet.  In the event this
isn't possible, can we at least ensure that the window positions are
remembered, so if I'm looking at the stock market on a small laptop screen,
it isn't suddenly replaced with the map because an auto-load occurred?

 

EV: A 'suspend polling' menu item should be easy to add.

 

Perhaps let the polling interval be player configurable?

 

EV: I already proposed that.

 

When reviewing the log, if a player backs up and starts stepping through it,
we need to be sure this activity doesn't generate save files.


EV: Not sure, but I think we cannot allow stepping through the new-style
report window during polling.  Perhaps we have to fix the report window, to
what it was the old way.  Or is flipping the report window too slow?

 

Will there be a configurable visual indicator (flashing? noise?) to tell me
that the polling has discovered it is my turn?  So I could turn off the
audible alarm if I'm sitting at my computer real time, but turn it on when
I'm running to the kitchen to make coffee?  

 

EV: I already proposed a popup. Not sure if sound is possible in a
platform-neutral way (I have no experience with programming sound).

 

And the task bar would flash to let me know it's my turn when I'm checking
my email.

 

EV: Isn't that too platform-dependent? I would have no clue how to do that
anyway.

 

Re: [Rails-devel] Buying trains

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

That's not valid XML, but I understand what you mean.  You probably refer to
the 18EU minor free 2-trains. An extra 'sellable="no"' attribute would fix
such a train.

An important difference is, however, that that the 1825 built-in trains are
expensive and must be paid for before these trains can run.

I suppose it will become a mix of XML and some special code in
PublicCompany_1825.

 

Erik.

 

Van: Chris Shaffer [mailto:chr...@gm...] 
Verzonden: donderdag 17 maart 2011 14:58
Aan: Development list for Rails: an 18xx game
Onderwerp: Re: [Rails-devel] Buying trains

 

For built in trains, which also exist in the 18MEX minors, how about
<BuyFromCompany="no"/>.


--
Chris

Please consider the environment before printing this e-mail.



On Thu, Mar 17, 2011 at 4:20 AM, Erik Vos <eri...@xs...> wrote:

My remarks on train buying in Rails (see inclusion below) came hidden behind
a post on a different topic, which is probably why these remarks has not
drawn any attention.
It's about how to incorporate complex features like double-sided train cards
(like the 2/1G in 18VA) and trains that come with privates (18GA). I would
add now: built-in trains, as some 1825 minors have.

The new TrainCertificate objects would normally be hidden and created
automatically from existing XML code like
       <Train name="2" majorStops="2" cost="80" amount="6" />

For double-sided trains I would propose something like (for 18VA):
       <TrainCertificate name="2/1G" cost="100" quantity="6">
               <Train name="2" majorStops="2"/>
               <Train name="1G" majorStops="1">
                       <Score towns="yes"/>
               </Train>
       </TrainCertificate>
Perhaps one or more additional attributes could to be added to denote Mine
and CMD access and scoring details, but actually I think these details are
so game-specific that these might as well be hardcoded.  In any case, I
leave that to Stefan Frey to decide and work out.

In the above case, the price is in the <TrainCertificate> tag, but in 18Scan
it will be in the <Train> tags because there the two trains on one card have
different prices.
(And I would replace the ambiguous 'amount' by the explicit 'quantity'
throughout. Perhaps also 'cost' by 'price'?).

I'm not yet sure how to incorporate the 18GA OSR special property (extra
2-train).  It's not a SpecialProperty in the Rails sense of the word, as
it's invocation isn't a separate user action; it happens automatically at
some point, as a side effect of another action.

Part of the new approach to train buying would be, that new Train objects
are created when acquired by a company, not at the start of the game. That
nicely fits with how the 18GA OSR SP works.
The extra 2-train creation could be entirely hardcoded,  or we could add a
TrainCertificate to the <StartPacket><Item> or the <Company> tags.  I'm
looking for a solution that would also cover the built-in trains of some
1825 minors.

I'm also not yet sure if this approach will keep old saved files backwards
compatible, although that would be a goal.  But at some point we'll have to
bite the bullet.

Ideas welcome. Otherwise I'll work it out by myself (later).

Erik.

> -----Oorspronkelijk bericht-----> Van: Erik Vos
[mailto:eri...@xs...]
> As an example, I've already concluded that my suggestion to Adam about the
> 18GA OSR free 2-train is too simple and will not work that way.  And there
is
> another looming problem with trains: the two-way train certificates as
exist
> in e.g. 18VA and 18Scan.  My current thinking is that we need to separate
> buyable trains from actual trains throughout. The former could be named
> TrainCertificates. For example: an 18Scan 4/3+3-train certificate would
then
> be linked to two actual trains.  At buying time, the player must decide
which
> train is actually bought, and that train is acquired by the company; the
other
> one is lost.  Similarly in 18GA, a extra 2-train certificate would not
normally be
> buyable, but be linked to the OCR private.
> Once this idea has been programmed, all usual cases would still be
> configurable in the XML.  For 18GA, extra Java programming will then be
> required only to accomplish the automatic transfer of the train, either to
the
> company or to the scrapheap, at the time that the private is bought by a
> company (even that could be made configurable, but I'm reluctant to add
> code to the generic code base that's applicable to one game only).




----------------------------------------------------------------------------
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

 

Re: [Rails-devel] Making Rails more suited to fast interactive play.

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

This may not be possible, but I'd like some options to allow players to keep
control of their version of the game and prevent loading a new file if the
polling shows it's someone else's turn.  I imagine it would be annoying to
be looking at the stock market or be reviewing the game log, and suddenly
the game loads a new file and it's not even my turn yet.  In the event this
isn't possible, can we at least ensure that the window positions are
remembered, so if I'm looking at the stock market on a small laptop screen,
it isn't suddenly replaced with the map because an auto-load occurred?

Perhaps let the polling interval be player configurable?

When reviewing the log, if a player backs up and starts stepping through it,
we need to be sure this activity doesn't generate save files.

Will there be a configurable visual indicator (flashing? noise?) to tell me
that the polling has discovered it is my turn?  So I could turn off the
audible alarm if I'm sitting at my computer real time, but turn it on when
I'm running to the kitchen to make coffee?  And the task bar would flash to
let me know it's my turn when I'm checking my email.

--
Chris

Please consider the environment before printing this e-mail.


On Thu, Mar 17, 2011 at 5:15 AM, Erik Vos <eri...@xs...> wrote:

> > -----Oorspronkelijk bericht-----
> > Van: Erik Vos [mailto:eri...@xs...]
>
> > This should not be too difficult to do. The trigger would not be any
> button,
> > but just a change of who has the turn.
> > Every, say, 30 seconds Rails could check for new files, load these, and
> display
> > the results. A popup would signal your next turn.
> >
> > I'll try to write down a more detailed specification shortly.
>
> Here it is.
>
> 1. Autosave/load is activated by checking a menu option. Steps 2 and 3
> apply
> only if this option has been activated.
>
> 2. Every time that an active player loses the turn, the following is done:
> 2a. A saved file is written to the default location (the first time the
> usual popup will ask for it) and with the usual filename:
> <prefix>_<timestamp>_<player>.rails.
> 2b. The name of this file is written into another (new) file, named
> <prefix>.last_rails.
> 2c. Rails goes into polling mode. (Ideally, all actions should be
> prohibited
> except Quit and perhaps some more).
>
> 3. In polling mode, Rails regularly reads the .last_rails file to check if
> the filename has changed. The interval is configurable (default 30 secs?).
> If a new filename is found:
> 3a. This file is read and processed in the same way as Reload does it.
> 3b. Rails checks if the player has got the turn. If so, polling mode is
> suspended, and normal operation resumes. Otherwise, polling mode continues.
>
> 4. When Rails is restarted for an ongoing game, the last saved file must be
> loaded manually. Autosave/load can only be activated after that. If the
> local player does not have the turn, Rails will enter polling mode at that
> point.
>
> Notes:
> 1. Normally, each game should use a separate directory.  In theory it
> should
> be possible to run multiple games in one directory, if each game is given a
> unique <prefix> at the *first* save action, but this is not recommended.
> 2. Repeated reloading during polling mode ensures that actions by other
> players show up with a reasonable delay.
> 3. It does not matter if a saved file is missed because the interval is
> longer than the time between two saves by other players. Each saved file
> contains the whole game history.
>
> Comments welcome.
>
> Erik.
>
>
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Buying trains

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

For built in trains, which also exist in the 18MEX minors, how about
<BuyFromCompany="no"/>.

--
Chris

Please consider the environment before printing this e-mail.


On Thu, Mar 17, 2011 at 4:20 AM, Erik Vos <eri...@xs...> wrote:

> My remarks on train buying in Rails (see inclusion below) came hidden
> behind
> a post on a different topic, which is probably why these remarks has not
> drawn any attention.
> It's about how to incorporate complex features like double-sided train
> cards
> (like the 2/1G in 18VA) and trains that come with privates (18GA). I would
> add now: built-in trains, as some 1825 minors have.
>
> The new TrainCertificate objects would normally be hidden and created
> automatically from existing XML code like
>        <Train name="2" majorStops="2" cost="80" amount="6" />
>
> For double-sided trains I would propose something like (for 18VA):
>        <TrainCertificate name="2/1G" cost="100" quantity="6">
>                <Train name="2" majorStops="2"/>
>                <Train name="1G" majorStops="1">
>                        <Score towns="yes"/>
>                </Train>
>        </TrainCertificate>
> Perhaps one or more additional attributes could to be added to denote Mine
> and CMD access and scoring details, but actually I think these details are
> so game-specific that these might as well be hardcoded.  In any case, I
> leave that to Stefan Frey to decide and work out.
>
> In the above case, the price is in the <TrainCertificate> tag, but in
> 18Scan
> it will be in the <Train> tags because there the two trains on one card
> have
> different prices.
> (And I would replace the ambiguous 'amount' by the explicit 'quantity'
> throughout. Perhaps also 'cost' by 'price'?).
>
> I'm not yet sure how to incorporate the 18GA OSR special property (extra
> 2-train).  It's not a SpecialProperty in the Rails sense of the word, as
> it's invocation isn't a separate user action; it happens automatically at
> some point, as a side effect of another action.
>
> Part of the new approach to train buying would be, that new Train objects
> are created when acquired by a company, not at the start of the game. That
> nicely fits with how the 18GA OSR SP works.
> The extra 2-train creation could be entirely hardcoded,  or we could add a
> TrainCertificate to the <StartPacket><Item> or the <Company> tags.  I'm
> looking for a solution that would also cover the built-in trains of some
> 1825 minors.
>
> I'm also not yet sure if this approach will keep old saved files backwards
> compatible, although that would be a goal.  But at some point we'll have to
> bite the bullet.
>
> Ideas welcome. Otherwise I'll work it out by myself (later).
>
> Erik.
>
> > -----Oorspronkelijk bericht-----> Van: Erik Vos
> [mailto:eri...@xs...]
> > As an example, I've already concluded that my suggestion to Adam about
> the
> > 18GA OSR free 2-train is too simple and will not work that way.  And
> there
> is
> > another looming problem with trains: the two-way train certificates as
> exist
> > in e.g. 18VA and 18Scan.  My current thinking is that we need to separate
> > buyable trains from actual trains throughout. The former could be named
> > TrainCertificates. For example: an 18Scan 4/3+3-train certificate would
> then
> > be linked to two actual trains.  At buying time, the player must decide
> which
> > train is actually bought, and that train is acquired by the company; the
> other
> > one is lost.  Similarly in 18GA, a extra 2-train certificate would not
> normally be
> > buyable, but be linked to the OCR private.
> > Once this idea has been programmed, all usual cases would still be
> > configurable in the XML.  For 18GA, extra Java programming will then be
> > required only to accomplish the automatic transfer of the train, either
> to
> the
> > company or to the scrapheap, at the time that the private is bought by a
> > company (even that could be made configurable, but I'm reluctant to add
> > code to the generic code base that's applicable to one game only).
>
>
>
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Making Rails more suited to fast interactive play.

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

> -----Oorspronkelijk bericht-----
> Van: Erik Vos [mailto:eri...@xs...]

> This should not be too difficult to do. The trigger would not be any
button,
> but just a change of who has the turn.
> Every, say, 30 seconds Rails could check for new files, load these, and
display
> the results. A popup would signal your next turn.
> 
> I'll try to write down a more detailed specification shortly.

Here it is.

1. Autosave/load is activated by checking a menu option. Steps 2 and 3 apply
only if this option has been activated.

2. Every time that an active player loses the turn, the following is done:
2a. A saved file is written to the default location (the first time the
usual popup will ask for it) and with the usual filename:
<prefix>_<timestamp>_<player>.rails.
2b. The name of this file is written into another (new) file, named
<prefix>.last_rails.
2c. Rails goes into polling mode. (Ideally, all actions should be prohibited
except Quit and perhaps some more).

3. In polling mode, Rails regularly reads the .last_rails file to check if
the filename has changed. The interval is configurable (default 30 secs?).
If a new filename is found:
3a. This file is read and processed in the same way as Reload does it.
3b. Rails checks if the player has got the turn. If so, polling mode is
suspended, and normal operation resumes. Otherwise, polling mode continues.

4. When Rails is restarted for an ongoing game, the last saved file must be
loaded manually. Autosave/load can only be activated after that. If the
local player does not have the turn, Rails will enter polling mode at that
point.

Notes:
1. Normally, each game should use a separate directory.  In theory it should
be possible to run multiple games in one directory, if each game is given a
unique <prefix> at the *first* save action, but this is not recommended.
2. Repeated reloading during polling mode ensures that actions by other
players show up with a reasonable delay.
3. It does not matter if a saved file is missed because the interval is
longer than the time between two saves by other players. Each saved file
contains the whole game history.

Comments welcome.

Erik.

Re: [Rails-devel] Buying trains

[Bill R. <ro...@gm...>]

On 2011-03-17, at 19:20 , Erik Vos wrote:
> For double-sided trains I would propose something like (for 18VA):
> 	<TrainCertificate name="2/1G" cost="100" quantity="6">
> 		<Train name="2" majorStops="2"/>
> 		<Train name="1G" majorStops="1">
> 			<Score towns="yes"/>
> 		</Train>
> 	</TrainCertificate>
> Perhaps one or more additional attributes could to be added to denote Mine
> and CMD access and scoring details, but actually I think these details are
> so game-specific that these might as well be hardcoded.  In any case, I
> leave that to Stefan Frey to decide and work out.
> 
> In the above case, the price is in the <TrainCertificate> tag, but in 18Scan
> it will be in the <Train> tags because there the two trains on one card have
> different prices.
> (And I would replace the ambiguous 'amount' by the explicit 'quantity'
> throughout. Perhaps also 'cost' by 'price'?).

As the person working on 1848 (I'm more or less done the XML), I would very much appreciate the ability to define two-sided trains in XML, since 1848 has trains of the form N / N+ where one side is a standard N train, but the other (slightly more expensive) side allows calling at one extra gauge change marker.  I agree with the notion that various special features (i.e. the fact that a + train in 1848 may make one extra stop at a gauge change marker) may as well be hardcoded into game-specific code.

Bill