Thread: [Rails-devel] Another train-buying related bug

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Brett,

Please wait with creating a new RC as a new bug has surfaced. I'll upload the fix when back at home.
I will also spend time to more rigorous testing of the train buying area.

Erik.

The problem mentioned (reported by Andrew Pullin) was that company treasure 
cash was not used in emergency train buying. 
This must have been another side effect of recent changes in that area.

I have also changed the following:

- Implemented a Feature Request from Chris Shaffer: when a train is bought 
from another company, to subtract the amount from the seller's "Cost" field 
in the OR panel as well as adding it to the buyer's Cost field.
I don't know if this change will appeal to everybody; I'm not even sure if I
like it myself.
But it was a simple one, and can easily be reverted or made optional.

- I have changed the colour of the impassable hex sides from black to blue.
First, it gives a better contrast with the also black tracks, and second,
the
impassability comes from water anyway.

- Fixed a problem that emergency train buying where share selling was
involved
could not be undone. The two actions (train buying and share selling) are
separately
stored and were not linked; they now are.

I'd say we are ready for rc4.

Erik.

  _____  

From: Eri...@gx... [mailto:Eri...@gx...] 
Sent: Thursday 26 November 2009 10:39
To: rai...@li...
Subject: [Rails-devel] Another train-buying related bug

Brett,

Please wait with creating a new RC as a new bug has surfaced. I'll upload
the fix when back at home.

I will also spend time to more rigorous testing of the train buying area.

Erik.

I'm not sure I like that particular solution to my enhancement request
either.  Ideally, what I'd like to see is one column for train purchases and
another column for train sales.

p.s. some impassable hexsides are from non-water sources, e.g. the cliff
slope in 18AL.  Blue is still a good color to distinguish from black though.

--
Chris

Please consider the environment before printing this e-mail.

On Thu, Nov 26, 2009 at 12:33 PM, Erik Vos <eri...@hc...> wrote:

>  The problem mentioned (reported by Andrew Pullin) was that company
> treasure
> cash was not used in emergency train buying.
> This must have been another side effect of recent changes in that area.
>
> I have also changed the following:
>
> - Implemented a Feature Request from Chris Shaffer: when a train is bought
> from another company, to subtract the amount from the seller's "Cost"
> field
> in the OR panel as well as adding it to the buyer's Cost field.
> I don't know if this change will appeal to everybody; I'm not even sure if
> I like it myself.
> But it was a simple one, and can easily be reverted or made optional.
>
> - I have changed the colour of the impassable hex sides from black to blue.
> First, it gives a better contrast with the also black tracks, and second,
> the
> impassability comes from water anyway.
>
> - Fixed a problem that emergency train buying where share selling was
> involved
> could not be undone. The two actions (train buying and share selling) are
> separately
> stored and were not linked; they now are.
>
> I'd say we are ready for rc4.
>
> Erik.
>
>  ------------------------------
> *From:* Eri...@gx... [mailto:Eri...@gx...]
> *Sent:* Thursday 26 November 2009 10:39
> *To:* rai...@li...
> *Subject:* [Rails-devel] Another train-buying related bug
>
>  Brett,
>
>
>
> Please wait with creating a new RC as a new bug has surfaced. I’ll upload
> the fix when back at home.
>
> I will also spend time to more rigorous testing of the train buying area.
>
>
>
> Erik.
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

The only problem with that is, trains are never sold. They're only bought.

So, in my mind having a "trains sold" column would only confuse people.

---Brett

On Nov 26, 2009 12:52 PM, "Chris Shaffer" <chr...@gm...> wrote:

I'm not sure I like that particular solution to my enhancement request
either.  Ideally, what I'd like to see is one column for train purchases and
another column for train sales.

p.s. some impassable hexsides are from non-water sources, e.g. the cliff
slope in 18AL.  Blue is still a good color to distinguish from black though.

--
Chris

Please consider the environment before printing this e-mail.

On Thu, Nov 26, 2009 at 12:33 PM, Erik Vos <eri...@hc...> wrote:

> > > The problem mentioned (reported by Andrew Pullin) was that company
> treasure > cash was not used ...
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

My biggest issue is that when someone transfers a train from one company to
another, I want to know about it.  Right now, that information is buried in
the text log.  It's one of the most important actions in many games and it's
something you would never fail to notice playing in-person or by the
traditional PBEM systems. However, in Rails, it is very easy to totally miss
that it happened.

So some solution that says "company A bought a train from company B" is
needed -- currently, all you get is "company A bought a train - maybe from
another company, maybe from the bank..." and you have to go dig in the log
to figure out what happened.

--
Chris

Please consider the environment before printing this e-mail.

On Thu, Nov 26, 2009 at 12:55 PM, brett lentz <wak...@gm...> wrote:

> The only problem with that is, trains are never sold. They're only bought.
>
> So, in my mind having a "trains sold" column would only confuse people.
>
> ---Brett
>
> On Nov 26, 2009 12:52 PM, "Chris Shaffer" <chr...@gm...> wrote:
>
> I'm not sure I like that particular solution to my enhancement request
> either.  Ideally, what I'd like to see is one column for train purchases and
> another column for train sales.
>
> p.s. some impassable hexsides are from non-water sources, e.g. the cliff
> slope in 18AL.  Blue is still a good color to distinguish from black though.
>
> --
> Chris
>
> Please consider the environment before printing this e-mail.
>
>
> On Thu, Nov 26, 2009 at 12:33 PM, Erik Vos <eri...@hc...> wrote:
>
>> > > The problem mentioned (reported by Andrew Pullin) was that company
>> treasure > cash was not used ...
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

In the Report Window these things are spelled out in detail: "PRR buys a
2-train from B&O for $200."
I wonder if it would help to have this window open rather than closed by
default?

Erik.

  _____  

From: Chris Shaffer [mailto:chr...@gm...] 
Sent: Thursday 26 November 2009 22:01
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Another train-buying related bug

My biggest issue is that when someone transfers a train from one company to
another, I want to know about it.  Right now, that information is buried in
the text log.  It's one of the most important actions in many games and it's
something you would never fail to notice playing in-person or by the
traditional PBEM systems. However, in Rails, it is very easy to totally miss
that it happened.

So some solution that says "company A bought a train from company B" is
needed -- currently, all you get is "company A bought a train - maybe from
another company, maybe from the bank..." and you have to go dig in the log
to figure out what happened.

--
Chris

Please consider the environment before printing this e-mail.

On Thu, Nov 26, 2009 at 12:55 PM, brett lentz <wak...@gm...> wrote:

The only problem with that is, trains are never sold. They're only bought.

So, in my mind having a "trains sold" column would only confuse people.

---Brett

On Nov 26, 2009 12:52 PM, "Chris Shaffer" <chr...@gm...> wrote:

I'm not sure I like that particular solution to my enhancement request
either.  Ideally, what I'd like to see is one column for train purchases and
another column for train sales.

p.s. some impassable hexsides are from non-water sources, e.g. the cliff
slope in 18AL.  Blue is still a good color to distinguish from black though.

--
Chris

Please consider the environment before printing this e-mail.

On Thu, Nov 26, 2009 at 12:33 PM, Erik Vos <eri...@hc...> wrote: 

> > The problem mentioned (reported by Andrew Pullin) was that company
treasure > cash was not used ...

----------------------------------------------------------------------------
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

----------------------------------------------------------------------------
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

----------------------------------------------------------------------------
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

That window is very hard to read.  It's long blocks of text, with no
separators.  It just doesn't even compare in usability to the data tables.

--
Chris

Please consider the environment before printing this e-mail.

On Thu, Nov 26, 2009 at 1:09 PM, Erik Vos <eri...@hc...> wrote:

>  In the Report Window these things are spelled out in detail: "PRR buys a
> 2-train from B&O for $200."
> I wonder if it would help to have this window open rather than closed by
> default?
>
> Erik.
>
>  ------------------------------
> *From:* Chris Shaffer [mailto:chr...@gm...]
> *Sent:* Thursday 26 November 2009 22:01
>
> *To:* Development list for Rails: an 18xx game
> *Subject:* Re: [Rails-devel] Another train-buying related bug
>
> My biggest issue is that when someone transfers a train from one company to
> another, I want to know about it.  Right now, that information is buried in
> the text log.  It's one of the most important actions in many games and it's
> something you would never fail to notice playing in-person or by the
> traditional PBEM systems. However, in Rails, it is very easy to totally miss
> that it happened.
>
> So some solution that says "company A bought a train from company B" is
> needed -- currently, all you get is "company A bought a train - maybe from
> another company, maybe from the bank..." and you have to go dig in the log
> to figure out what happened.
>
> --
> Chris
>
> Please consider the environment before printing this e-mail.
>
>
> On Thu, Nov 26, 2009 at 12:55 PM, brett lentz <wak...@gm...> wrote:
>
>> The only problem with that is, trains are never sold. They're only bought.
>>
>> So, in my mind having a "trains sold" column would only confuse people.
>>
>> ---Brett
>>
>>  On Nov 26, 2009 12:52 PM, "Chris Shaffer" <chr...@gm...>
>> wrote:
>>
>> I'm not sure I like that particular solution to my enhancement request
>> either.  Ideally, what I'd like to see is one column for train purchases and
>> another column for train sales.
>>
>> p.s. some impassable hexsides are from non-water sources, e.g. the cliff
>> slope in 18AL.  Blue is still a good color to distinguish from black though.
>>
>> --
>> Chris
>>
>> Please consider the environment before printing this e-mail.
>>
>>
>>  On Thu, Nov 26, 2009 at 12:33 PM, Erik Vos <eri...@hc...> wrote:
>>
>>> > > The problem mentioned (reported by Andrew Pullin) was that company
>>> treasure > cash was not used ...
>>>
>>> ------------------------------------------------------------------------------
>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>> 30-Day
>>> trial. Simplify your report design, integration and deployment - and
>>> focus on
>>> what you do best, core application coding. Discover what's new with
>>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

??
It's a step by step report of all game actions, exactly as I would do it in
a PBEM version.
I don't see what's so hard about it. An extra space between company OR turns
and better placement of the private payouts is all I can think of.

First thing I would do to check previous player's moves when it's my turn is
to look here.

Erik.

  _____  

From: Chris Shaffer [mailto:chr...@gm...] 
Sent: Thursday 26 November 2009 22:11
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Another train-buying related bug

That window is very hard to read.  It's long blocks of text, with no
separators.  It just doesn't even compare in usability to the data tables.

--
Chris

Please consider the environment before printing this e-mail.

On Thu, Nov 26, 2009 at 1:09 PM, Erik Vos <eri...@hc...> wrote:

In the Report Window these things are spelled out in detail: "PRR buys a
2-train from B&O for $200."
I wonder if it would help to have this window open rather than closed by
default?

Erik.

  _____  

From: Chris Shaffer [mailto:chr...@gm...] 
Sent: Thursday 26 November 2009 22:01 

To: Development list for Rails: an 18xx game

Subject: Re: [Rails-devel] Another train-buying related bug

My biggest issue is that when someone transfers a train from one company to
another, I want to know about it.  Right now, that information is buried in
the text log.  It's one of the most important actions in many games and it's
something you would never fail to notice playing in-person or by the
traditional PBEM systems. However, in Rails, it is very easy to totally miss
that it happened.

So some solution that says "company A bought a train from company B" is
needed -- currently, all you get is "company A bought a train - maybe from
another company, maybe from the bank..." and you have to go dig in the log
to figure out what happened.

--
Chris

Please consider the environment before printing this e-mail.

On Thu, Nov 26, 2009 at 12:55 PM, brett lentz <wak...@gm...> wrote:

The only problem with that is, trains are never sold. They're only bought.

So, in my mind having a "trains sold" column would only confuse people.

---Brett

On Nov 26, 2009 12:52 PM, "Chris Shaffer" <chr...@gm...> wrote:

I'm not sure I like that particular solution to my enhancement request
either.  Ideally, what I'd like to see is one column for train purchases and
another column for train sales.

p.s. some impassable hexsides are from non-water sources, e.g. the cliff
slope in 18AL.  Blue is still a good color to distinguish from black though.

--
Chris

Please consider the environment before printing this e-mail.

On Thu, Nov 26, 2009 at 12:33 PM, Erik Vos <eri...@hc...> wrote: 

> > The problem mentioned (reported by Andrew Pullin) was that company
treasure > cash was not used ...

----------------------------------------------------------------------------
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

----------------------------------------------------------------------------
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

----------------------------------------------------------------------------
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

----------------------------------------------------------------------------
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

So, a few suggestions for improvement in the Report Window.

1) It always opens to the top of the file. You have to scroll to the bottom
to begin.

2) There is no indication of when your own last action occurred.  You have
to scroll up, reading the text, to find an indication of what is "new."  In
PBEM, you get this information in packets of text as each company operates,
and it isn't mashed together with everything else that happened the entire
game.

3) Judicious use of bold and spacing would make it much easier to read.
Right now, each OR is one long string of text with only line breaks. It's
hard to see at a glance where a set of actions begins and ends.  We could
also use highlighting for particularly important actions - train purchases
in red, private purchases in yellow, etc.

4) In every PBEM I've ever played, we rely heavily on the spreadsheet to
give us at-a-glance information, which is nowhere near as accessible in the
text, whether that text is in the various emails or in the Rails Report
Window.

5) In every PBEM I have ever played, there is a "replay" mode (Vassal and
CyberBoard both have this) where you can watch what happened since your last
turn.  This gives you visual indications of which tiles have been laid, what
movements occurred on the stock market, etc.

To be honest, the combination of 4 and 5 means that I virtually never read
the text summaries that are sent in PBEM games.  They are only used (by me)
for debugging when there are problems.  I can almost always assess the
situation at a glance by watching the replay and glancing at the
spreadsheet.

--
Chris

Please consider the environment before printing this e-mail.

On Thu, Nov 26, 2009 at 1:32 PM, Erik Vos <eri...@hc...> wrote:

>  ??
> It's a step by step report of all game actions, exactly as I would do it in
> a PBEM version.
> I don't see what's so hard about it. An extra space between company OR
> turns
> and better placement of the private payouts is all I can think of.
>
> First thing I would do to check previous player's moves when it's my turn
> is to look here.
>
> Erik.
>
>  ------------------------------
> *From:* Chris Shaffer [mailto:chr...@gm...]
> *Sent:* Thursday 26 November 2009 22:11
>
> *To:* Development list for Rails: an 18xx game
> *Subject:* Re: [Rails-devel] Another train-buying related bug
>
> That window is very hard to read.  It's long blocks of text, with no
> separators.  It just doesn't even compare in usability to the data tables.
>
> --
> Chris
>
> Please consider the environment before printing this e-mail.
>
>
> On Thu, Nov 26, 2009 at 1:09 PM, Erik Vos <eri...@hc...> wrote:
>
>>  In the Report Window these things are spelled out in detail: "PRR buys a
>> 2-train from B&O for $200."
>> I wonder if it would help to have this window open rather than closed by
>> default?
>>
>> Erik.
>>
>>  ------------------------------
>> *From:* Chris Shaffer [mailto:chr...@gm...]
>> *Sent:* Thursday 26 November 2009 22:01
>>
>> *To:* Development list for Rails: an 18xx game
>> *Subject:* Re: [Rails-devel] Another train-buying related bug
>>
>>   My biggest issue is that when someone transfers a train from one
>> company to another, I want to know about it.  Right now, that information is
>> buried in the text log.  It's one of the most important actions in many
>> games and it's something you would never fail to notice playing in-person or
>> by the traditional PBEM systems. However, in Rails, it is very easy to
>> totally miss that it happened.
>>
>> So some solution that says "company A bought a train from company B" is
>> needed -- currently, all you get is "company A bought a train - maybe from
>> another company, maybe from the bank..." and you have to go dig in the log
>> to figure out what happened.
>>
>> --
>> Chris
>>
>> Please consider the environment before printing this e-mail.
>>
>>
>> On Thu, Nov 26, 2009 at 12:55 PM, brett lentz <wak...@gm...> wrote:
>>
>>> The only problem with that is, trains are never sold. They're only
>>> bought.
>>>
>>> So, in my mind having a "trains sold" column would only confuse people.
>>>
>>> ---Brett
>>>
>>>  On Nov 26, 2009 12:52 PM, "Chris Shaffer" <chr...@gm...>
>>> wrote:
>>>
>>> I'm not sure I like that particular solution to my enhancement request
>>> either.  Ideally, what I'd like to see is one column for train purchases and
>>> another column for train sales.
>>>
>>> p.s. some impassable hexsides are from non-water sources, e.g. the cliff
>>> slope in 18AL.  Blue is still a good color to distinguish from black though.
>>>
>>> --
>>> Chris
>>>
>>> Please consider the environment before printing this e-mail.
>>>
>>>
>>>  On Thu, Nov 26, 2009 at 12:33 PM, Erik Vos <eri...@hc...> wrote:
>>>
>>>> > > The problem mentioned (reported by Andrew Pullin) was that company
>>>> treasure > cash was not used ...
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>>> 30-Day
>>>> trial. Simplify your report design, integration and deployment - and
>>>> focus on
>>>> what you do best, core application coding. Discover what's new with
>>>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>>> _______________________________________________
>>>> Rails-devel mailing list
>>>> Rai...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>> 30-Day
>>> trial. Simplify your report design, integration and deployment - and
>>> focus on
>>> what you do best, core application coding. Discover what's new with
>>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>> 30-Day
>>> trial. Simplify your report design, integration and deployment - and
>>> focus on
>>> what you do best, core application coding. Discover what's new with
>>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

So, a few suggestions for improvement in the Report Window.

1) It always opens to the top of the file. You have to scroll to the bottom
to begin.

Done. Next version will scroll down on reload.

2) There is no indication of when your own last action occurred.  You have
to scroll up, reading the text, to find an indication of what is "new."  In
PBEM, you get this information in packets of text as each company operates,
and it isn't mashed together with everything else that happened the entire
game.

Of course, but Rails is not specifically tailored for PBEM yet. The Report
window is a complete report (I plan to add Save and Print buttons to it)
that by nature contains everything.

3) Judicious use of bold and spacing would make it much easier to read.
Right now, each OR is one long string of text with only line breaks. It's
hard to see at a glance where a set of actions begins and ends.  We could
also use highlighting for particularly important actions - train purchases
in red, private purchases in yellow, etc.

What do you call a "set of actions"? A player turn?

4) In every PBEM I've ever played, we rely heavily on the spreadsheet to
give us at-a-glance information, which is nowhere near as accessible in the
text, whether that text is in the various emails or in the Rails Report
Window.

And? I what ways is such a spreadsheet different from what you see in the
Rails screens?
BTW as regards contents, the Rails UI is strongly inspired by Lemmi's
moderator.

5) In every PBEM I have ever played, there is a "replay" mode (Vassal and
CyberBoard both have this) where you can watch what happened since your last
turn.  This gives you visual indications of which tiles have been laid, what
movements occurred on the stock market, etc.

You have Undo/Redo to play with if you want. A feature to slowly replay from
the start or some other point would not be unthinkable.

To be honest, the combination of 4 and 5 means that I virtually never read
the text summaries that are sent in PBEM games.  They are only used (by me)
for debugging when there are problems.  I can almost always assess the
situation at a glance by watching the replay and glancing at the
spreadsheet.

Well, you sure have raised some food for thought.

p.s. it is very well documented that tables and graphics are easier to
assess "at a glance" than text.  In almost every case in Rails, perhaps with
the exception of stock round purchases, tables and graphics win out in the
usability question over text logs by a mile and a half.

Sure, but the UI is mainly intended to show the current status, whereas the
Report has the history. That's the way it is for now... 

Erik.

My response to this is that I would suggest that you remove some of the
information data table from the Map window and create a separate Table
window with the kind of information I'm describing. It's clear that one of
the barriers to adding information is that the Map window is cluttered with
a lot of information and adding columns/data to it is undesirable.

The Report Window is necessary and useful.  A few enhancements could make it
easier to read, but I'm not advocating doing away with it. I'm just
suggesting that data tables would be a good supplement, as would replay of
tiles.

p.s. Undo doesn't seem to work as I would expect.  I find the interaction
between Undo and Forced Undo a bit confusing.  Maybe it would be possible to
let someone double click the name of a company in the map window and then
step through that company's turn?  A set of actions is either a company turn
or once around the table in the stock round.  I'm used to seeing stock round
displays like this:

player A action
player B action
player C action

player A action
player B action
player C action

I hope everyone takes these as suggestions for improvement and not just as
criticisms of the current design.  I'm thrilled to have Rails available and
foresee that in the not-so-distant future it will entirely replace playing
by Vassal and CyberBoard for me.  It's great.

I'll admit to being someone who found Lemmi's Moderator display to be a bit
inferior to the spreadsheets that are available for play now.  Take a look
at this spreadsheet:

https://spreadsheets.google.com/ccc?key=0AqDz8TiDzvbXdFo0MlJ5b2diX21ISXNWWkhGMnc0QXc&hl=en

It shows at a glance what has happened during each operating round.
Admittedly, the information in the stock round tabs is less informative.
Take a look at the OR5a sheet.  You can see at a glance what each company
did with its money on the OR.  You can even double click the 740 amount paid
and see that Pac paid 300 for one train (presumably from the bank) and 440
for another, which must obviously have been from Mex.

--
Chris

Please consider the environment before printing this e-mail.

On Thu, Nov 26, 2009 at 2:20 PM, Erik Vos <eri...@hc...> wrote:

>  So, a few suggestions for improvement in the Report Window.
>
> 1) It always opens to the top of the file. You have to scroll to the bottom
> to begin.
>
> Done. Next version will scroll down on reload.
>
> 2) There is no indication of when your own last action occurred.  You have
> to scroll up, reading the text, to find an indication of what is "new."  In
> PBEM, you get this information in packets of text as each company operates,
> and it isn't mashed together with everything else that happened the entire
> game.
>
> Of course, but Rails is not specifically tailored for PBEM yet. The Report
> window is a complete report (I plan to add Save and Print buttons to it)
> that by nature contains everything.
>
> 3) Judicious use of bold and spacing would make it much easier to read.
> Right now, each OR is one long string of text with only line breaks. It's
> hard to see at a glance where a set of actions begins and ends.  We could
> also use highlighting for particularly important actions - train purchases
> in red, private purchases in yellow, etc.
>
> What do you call a "set of actions"? A player turn?
>
> 4) In every PBEM I've ever played, we rely heavily on the spreadsheet to
> give us at-a-glance information, which is nowhere near as accessible in the
> text, whether that text is in the various emails or in the Rails Report
> Window.
>
> And? I what ways is such a spreadsheet different from what you see in the
> Rails screens?
> BTW as regards contents, the Rails UI is strongly inspired by Lemmi's
> moderator.
>
> 5) In every PBEM I have ever played, there is a "replay" mode (Vassal and
> CyberBoard both have this) where you can watch what happened since your last
> turn.  This gives you visual indications of which tiles have been laid, what
> movements occurred on the stock market, etc.
>
> You have Undo/Redo to play with if you want. A feature to slowly replay
> from the start or some other point would not be unthinkable.
>
> To be honest, the combination of 4 and 5 means that I virtually never read
> the text summaries that are sent in PBEM games.  They are only used (by me)
> for debugging when there are problems.  I can almost always assess the
> situation at a glance by watching the replay and glancing at the
> spreadsheet.
>
> Well, you sure have raised some food for thought.
>
> p.s. it is very well documented that tables and graphics are easier to
> assess "at a glance" than text.  In almost every case in Rails, perhaps with
> the exception of stock round purchases, tables and graphics win out in the
> usability question over text logs by a mile and a half.
> Sure, but the UI is mainly intended to show the current status, whereas the
> Report has the history. That's the way it is for now...
>
> Erik.
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

p.s. it is very well documented that tables and graphics are easier to
assess "at a glance" than text.  In almost every case in Rails, perhaps with
the exception of stock round purchases, tables and graphics win out in the
usability question over text logs by a mile and a half.

--
Chris

Please consider the environment before printing this e-mail.

On Thu, Nov 26, 2009 at 1:32 PM, Erik Vos <eri...@hc...> wrote:

>  ??
> It's a step by step report of all game actions, exactly as I would do it in
> a PBEM version.
> I don't see what's so hard about it. An extra space between company OR
> turns
> and better placement of the private payouts is all I can think of.
>
> First thing I would do to check previous player's moves when it's my turn
> is to look here.
>
> Erik.
>

And I don't want to add columns that are not really needed. 
In fact all these "cost" columns are on the bottom of my list of things
necessary.

Erik.

  _____  

From: brett lentz [mailto:wak...@gm...] 
Sent: Thursday 26 November 2009 21:56
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Another train-buying related bug

The only problem with that is, trains are never sold. They're only bought.

So, in my mind having a "trains sold" column would only confuse people.

---Brett

On Nov 26, 2009 12:52 PM, "Chris Shaffer" <chr...@gm...> wrote:

I'm not sure I like that particular solution to my enhancement request
either.  Ideally, what I'd like to see is one column for train purchases and
another column for train sales.

p.s. some impassable hexsides are from non-water sources, e.g. the cliff
slope in 18AL.  Blue is still a good color to distinguish from black though.

--
Chris

Please consider the environment before printing this e-mail.

On Thu, Nov 26, 2009 at 12:33 PM, Erik Vos <eri...@hc...> wrote: 

> > The problem mentioned (reported by Andrew Pullin) was that company
treasure > cash was not used ...

----------------------------------------------------------------------------
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

----------------------------------------------------------------------------
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

At a glance? Hmm... but I suppose you'll get accustomed to it pretty soon
;-) 
Basically the speadsheet looks like the Game Status window turned 90
degrees, and with detailed OR info added.
Putting copies of all that with extra info in yet another window is doable. 
But I doubt if such a window would be easy to use for entering moves (also
given the limitations of Java Swing),
so I guess the current windows would need to stay for that purpose.

BTW the double-clicking didn't work for me.

The Rails architecture is based upon the idea that one day we will have a
central server, where the game engine runs, which also has all the data.
Each player has a client showing the UI. And there might be a (playing or
non-playing) moderator also having a client. 
Players can only undo their own moves, only the moderator can undo across
player turns.
Hence the difference between Undo and Forced Undo.

But I'm afraid we are still pretty far away from a full implementation of
that idea.
In the current version it is rather a pain to have this player/moderator
difference, so perhaps it would be better to remove it for the time being.

Erik.

  _____  

From: Chris Shaffer [mailto:chr...@gm...] 
Sent: Thursday 26 November 2009 23:37
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Another train-buying related bug

My response to this is that I would suggest that you remove some of the
information data table from the Map window and create a separate Table
window with the kind of information I'm describing. It's clear that one of
the barriers to adding information is that the Map window is cluttered with
a lot of information and adding columns/data to it is undesirable.

The Report Window is necessary and useful.  A few enhancements could make it
easier to read, but I'm not advocating doing away with it. I'm just
suggesting that data tables would be a good supplement, as would replay of
tiles.

p.s. Undo doesn't seem to work as I would expect.  I find the interaction
between Undo and Forced Undo a bit confusing.  Maybe it would be possible to
let someone double click the name of a company in the map window and then
step through that company's turn?  A set of actions is either a company turn
or once around the table in the stock round.  I'm used to seeing stock round
displays like this:

player A action
player B action
player C action

player A action
player B action
player C action

I hope everyone takes these as suggestions for improvement and not just as
criticisms of the current design.  I'm thrilled to have Rails available and
foresee that in the not-so-distant future it will entirely replace playing
by Vassal and CyberBoard for me.  It's great.

I'll admit to being someone who found Lemmi's Moderator display to be a bit
inferior to the spreadsheets that are available for play now.  Take a look
at this spreadsheet:

https://spreadsheets.google.com/ccc?key=0AqDz8TiDzvbXdFo0MlJ5b2diX21ISXNWWkh
GMnc0QXc
<https://spreadsheets.google.com/ccc?key=0AqDz8TiDzvbXdFo0MlJ5b2diX21ISXNWWk
hGMnc0QXc&hl=en> &hl=en

It shows at a glance what has happened during each operating round.
Admittedly, the information in the stock round tabs is less informative.
Take a look at the OR5a sheet.  You can see at a glance what each company
did with its money on the OR.  You can even double click the 740 amount paid
and see that Pac paid 300 for one train (presumably from the bank) and 440
for another, which must obviously have been from Mex.

--
Chris

Please consider the environment before printing this e-mail.

On Thu, Nov 26, 2009 at 2:20 PM, Erik Vos <eri...@hc...> wrote:

So, a few suggestions for improvement in the Report Window.

1) It always opens to the top of the file. You have to scroll to the bottom
to begin.

Done. Next version will scroll down on reload.

2) There is no indication of when your own last action occurred.  You have
to scroll up, reading the text, to find an indication of what is "new."  In
PBEM, you get this information in packets of text as each company operates,
and it isn't mashed together with everything else that happened the entire
game.

Of course, but Rails is not specifically tailored for PBEM yet. The Report
window is a complete report (I plan to add Save and Print buttons to it)
that by nature contains everything.

3) Judicious use of bold and spacing would make it much easier to read.
Right now, each OR is one long string of text with only line breaks. It's
hard to see at a glance where a set of actions begins and ends.  We could
also use highlighting for particularly important actions - train purchases
in red, private purchases in yellow, etc.

What do you call a "set of actions"? A player turn?

4) In every PBEM I've ever played, we rely heavily on the spreadsheet to
give us at-a-glance information, which is nowhere near as accessible in the
text, whether that text is in the various emails or in the Rails Report
Window.

And? I what ways is such a spreadsheet different from what you see in the
Rails screens?
BTW as regards contents, the Rails UI is strongly inspired by Lemmi's
moderator.

5) In every PBEM I have ever played, there is a "replay" mode (Vassal and
CyberBoard both have this) where you can watch what happened since your last
turn.  This gives you visual indications of which tiles have been laid, what
movements occurred on the stock market, etc.

You have Undo/Redo to play with if you want. A feature to slowly replay from
the start or some other point would not be unthinkable.

To be honest, the combination of 4 and 5 means that I virtually never read
the text summaries that are sent in PBEM games.  They are only used (by me)
for debugging when there are problems.  I can almost always assess the
situation at a glance by watching the replay and glancing at the
spreadsheet.

Well, you sure have raised some food for thought.

p.s. it is very well documented that tables and graphics are easier to
assess "at a glance" than text.  In almost every case in Rails, perhaps with
the exception of stock round purchases, tables and graphics win out in the
usability question over text logs by a mile and a half.

Sure, but the UI is mainly intended to show the current status, whereas the
Report has the history. That's the way it is for now... 

Erik.

----------------------------------------------------------------------------
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

I sent you a personal invitation to edit the spreadsheet.  That should let
you double click anywhere there is a formula (all the salmon colored cells,
for example) and see the underlying formula.

--
Chris

Please consider the environment before printing this e-mail.

On Thu, Nov 26, 2009 at 3:09 PM, Erik Vos <eri...@hc...> wrote:

>  At a glance? Hmm... but I suppose you'll get accustomed to it pretty soon
> ;-)
> Basically the speadsheet looks like the Game Status window turned 90
> degrees, and with detailed OR info added.
> Putting copies of all that with extra info in yet another window is doable.
>
> But I doubt if such a window would be easy to use for entering moves (also
> given the limitations of Java Swing),
> so I guess the current windows would need to stay for that purpose.
>
> BTW the double-clicking didn't work for me.
>
> The Rails architecture is based upon the idea that one day we will have a
> central server, where the game engine runs, which also has all the data.
> Each player has a client showing the UI. And there might be a (playing or
> non-playing) moderator also having a client.
> Players can only undo their own moves, only the moderator can undo across
> player turns.
> Hence the difference between Undo and Forced Undo.
>
> But I'm afraid we are still pretty far away from a full implementation of
> that idea.
> In the current version it is rather a pain to have this player/moderator
> difference, so perhaps it would be better to remove it for the time being.
>
> Erik.
>
>  ------------------------------
> *From:* Chris Shaffer [mailto:chr...@gm...]
> *Sent:* Thursday 26 November 2009 23:37
>
> *To:* Development list for Rails: an 18xx game
> *Subject:* Re: [Rails-devel] Another train-buying related bug
>
> My response to this is that I would suggest that you remove some of the
> information data table from the Map window and create a separate Table
> window with the kind of information I'm describing. It's clear that one of
> the barriers to adding information is that the Map window is cluttered with
> a lot of information and adding columns/data to it is undesirable.
>
> The Report Window is necessary and useful.  A few enhancements could make
> it easier to read, but I'm not advocating doing away with it. I'm just
> suggesting that data tables would be a good supplement, as would replay of
> tiles.
>
> p.s. Undo doesn't seem to work as I would expect.  I find the interaction
> between Undo and Forced Undo a bit confusing.  Maybe it would be possible to
> let someone double click the name of a company in the map window and then
> step through that company's turn?  A set of actions is either a company turn
> or once around the table in the stock round.  I'm used to seeing stock round
> displays like this:
>
> player A action
> player B action
> player C action
>
> player A action
> player B action
> player C action
>
> I hope everyone takes these as suggestions for improvement and not just as
> criticisms of the current design.  I'm thrilled to have Rails available and
> foresee that in the not-so-distant future it will entirely replace playing
> by Vassal and CyberBoard for me.  It's great.
>
> I'll admit to being someone who found Lemmi's Moderator display to be a bit
> inferior to the spreadsheets that are available for play now.  Take a look
> at this spreadsheet:
>
>
> https://spreadsheets.google.com/ccc?key=0AqDz8TiDzvbXdFo0MlJ5b2diX21ISXNWWkhGMnc0QXc&hl=en
>
> It shows at a glance what has happened during each operating round.
> Admittedly, the information in the stock round tabs is less informative.
> Take a look at the OR5a sheet.  You can see at a glance what each company
> did with its money on the OR.  You can even double click the 740 amount paid
> and see that Pac paid 300 for one train (presumably from the bank) and 440
> for another, which must obviously have been from Mex.
>
> --
> Chris
>
> Please consider the environment before printing this e-mail.
>
>
> On Thu, Nov 26, 2009 at 2:20 PM, Erik Vos <eri...@hc...> wrote:
>
>>  So, a few suggestions for improvement in the Report Window.
>>
>> 1) It always opens to the top of the file. You have to scroll to the
>> bottom to begin.
>>
>> Done. Next version will scroll down on reload.
>>
>> 2) There is no indication of when your own last action occurred.  You have
>> to scroll up, reading the text, to find an indication of what is "new."  In
>> PBEM, you get this information in packets of text as each company operates,
>> and it isn't mashed together with everything else that happened the entire
>> game.
>>
>> Of course, but Rails is not specifically tailored for PBEM yet. The Report
>> window is a complete report (I plan to add Save and Print buttons to it)
>> that by nature contains everything.
>>
>> 3) Judicious use of bold and spacing would make it much easier to read.
>> Right now, each OR is one long string of text with only line breaks. It's
>> hard to see at a glance where a set of actions begins and ends.  We could
>> also use highlighting for particularly important actions - train purchases
>> in red, private purchases in yellow, etc.
>>
>> What do you call a "set of actions"? A player turn?
>>
>> 4) In every PBEM I've ever played, we rely heavily on the spreadsheet to
>> give us at-a-glance information, which is nowhere near as accessible in the
>> text, whether that text is in the various emails or in the Rails Report
>> Window.
>>
>> And? I what ways is such a spreadsheet different from what you see in the
>> Rails screens?
>> BTW as regards contents, the Rails UI is strongly inspired by Lemmi's
>> moderator.
>>
>> 5) In every PBEM I have ever played, there is a "replay" mode (Vassal and
>> CyberBoard both have this) where you can watch what happened since your last
>> turn.  This gives you visual indications of which tiles have been laid, what
>> movements occurred on the stock market, etc.
>>
>> You have Undo/Redo to play with if you want. A feature to slowly replay
>> from the start or some other point would not be unthinkable.
>>
>> To be honest, the combination of 4 and 5 means that I virtually never read
>> the text summaries that are sent in PBEM games.  They are only used (by me)
>> for debugging when there are problems.  I can almost always assess the
>> situation at a glance by watching the replay and glancing at the
>> spreadsheet.
>>
>> Well, you sure have raised some food for thought.
>>
>> p.s. it is very well documented that tables and graphics are easier to
>> assess "at a glance" than text.  In almost every case in Rails, perhaps with
>> the exception of stock round purchases, tables and graphics win out in the
>> usability question over text logs by a mile and a half.
>> Sure, but the UI is mainly intended to show the current status, whereas
>> the Report has the history. That's the way it is for now...
>>
>> Erik.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>