rails-devel — List for discussion of Rails development

Re: [Rails-devel] Versioning

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

My comments on the issues discussed:

Auto-Update:
I do not think that is possible and/or wise to do from inside Rails.
Colossus (the titan game) supports the Java Webstart option. It still requires 
the installation of Webstart first and this could fail on some systems as 
well. However new releases of Webstart are less frequent compared to Rails.

Versions and pbem:
From my knowledge of the code Erik always emphasizes the backward (code) 
compatibility of the Rails save files.
As the game files are simply the stack of player's actions most issues arise 
if a bug fix that either restricts the strategy space (by preventing 
previously possible but illegal moves) or requires an additional activity of 
a player.
Thus I would recommend upgrading to newer versions of Rails even for 
in-progress pbem as from that point on you benefit from the bug-fixes of the 
more recent versions. And I hope that the number of bugs fixed exceeds those 
created with each release.

Regression tests:
see my next e-mail, which went out to the users list last week, but did not 
make it to the devel list: save files of Rails (pbem) games are helpful to 
indicate upcoming version conflicts.

Stefan


On Monday 29 March 2010 18:40:27 brett lentz wrote:
> Chris -
>
> I agree. An auto-update feature would be nice to have.
>
> It should go on the to-do list.
>
> ---Brett.
>
> On Mon, Mar 29, 2010 at 9:37 AM, Chris Shaffer <chr...@gm...> 
wrote:
> > I concur with Jim. It took scheduling a long distance phone call with
> > a 3 hour time difference just to get Rails installed on one less-than-
> > tech-savvy friend's home computer. He won't upgrade unless it is
> > impossible to play and it will almost certainly require another round
> > of me talking on the phone and saying "after you clicked that button,
> > what does it say?". When CyberBoard forced an upgrade recently, I
> > learned that his install of that program was 5 years out of date.
> >
> > Meanwhile, I update every time there is a new release.
> >
> > p.s. It would be nice to have an in game check for and install updates
> > feature.
> >
> > --
> > Chris Shaffer
> >
> > Please consider the environment before printing this email.
> >
> > On Mar 29, 2010, at 9:27 AM, Jim Black <ji...@ko...> wrote:
> >> Brett,
> >>
> >> My post was titled "Versioning".
> >>
> >> In my reading, your comments below speak primarily to code
> >> stability, and relative priorities of gaming bugs vs new titles.
> >>
> >> My comments weren't critical of Rails' stability, in general- and,
> >> regardless- I think the new regression suites are critical, and will
> >> make a profound improvement here anyway.
> >>
> >> Rather- I'm saying (a) it's very common for pbem tables to upgrade
> >> Rails during a game, and, (b) it's very common for pbem users to be
> >> running different versions of Rails /at the same time, at the same
> >> table/.
> >>
> >> It would be useful if the Rails discussions, priorities, etc, simply
> >> recognized this plain fact.
> >>
> >> Do with it, what you will- but, please- don't suggest most pbem
> >> rails games are played start-to-finish by all the players with one
> >> rails version; it's simply untrue.  Further- in my view, this leads
> >> to simply ungrounded conclusions about the Rails user experience.
> >>
> >> - jim
> >>
> >>> Jim -
> >>>
> >>> I think you're missing the point.
> >>>
> >>> Each of us volunteers their time to the development of this project.
> >>> The hours we dedicate are finite and limited.
> >>>
> >>> So, it's simply a question of how we spend that time.
> >>>
> >>> We certainly could spend that time making slow, deliberate, careful
> >>> changes that don't break save file compatibility and doing the
> >>> time-intensive regression testing to ensure that's the case.
> >>>
> >>> But... why would we? How does it help us achieve our goal of being
> >>> able to support playing as many 18xx games electronically as we can?
> >>>
> >>> If we do things that way, it would take us literally years to
> >>> implement any new feature because we'd need to painstakingly test
> >>> every nook and cranny of the code to make sure those changes didn't
> >>> break anything.
> >>>
> >>> Now, I'm not saying we shouldn't ever test anything. Stefan has
> >>> done a
> >>> great job improving our ability to test saved games.
> >>>
> >>> My point is, our time is limited and we must choose where to spend
> >>> that time.
> >>>
> >>> The whole point of the e-mail you're quoting is that my
> >>> recommendation
> >>> on how to spend our limited time is to spend it on developing new
> >>> features, implementing new games, and generally getting Rails into
> >>> the
> >>> state we'd like it to be in. The price we pay for focusing more on
> >>> new
> >>> development is that we will not be able to spend as much time on
> >>> minimizing breakage.
> >>>
> >>> It's frustrating to hit a bug and have it tank your game. I
> >>> understand
> >>> this, perhaps more intimately than you're giving me credit. However,
> >>> we can't be all things to everyone. Trade-offs and sacrifices are
> >>> necessary if we want to get anything done.
> >>>
> >>> ---Brett.
> >>
> >> =
> >> ---
> >> ---
> >> ---
> >> ---------------------------------------------------------------------
> >> Download Intel&#174; Parallel Studio Eval
> >> Try the new software tools for yourself. Speed compiling, find bugs
> >> proactively, and fine-tune applications for parallel performance.
> >> See why Intel Parallel Studio got high marks during beta.
> >> http://p.sf.net/sfu/intel-sw-dev
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > -------------------------------------------------------------------------
> >----- Download Intel&#174; Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ---------------------------------------------------------------------------
>--- Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Versioning

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

Chris -

I agree. An auto-update feature would be nice to have.

It should go on the to-do list.

---Brett.


On Mon, Mar 29, 2010 at 9:37 AM, Chris Shaffer <chr...@gm...> wrote:
> I concur with Jim. It took scheduling a long distance phone call with
> a 3 hour time difference just to get Rails installed on one less-than-
> tech-savvy friend's home computer. He won't upgrade unless it is
> impossible to play and it will almost certainly require another round
> of me talking on the phone and saying "after you clicked that button,
> what does it say?". When CyberBoard forced an upgrade recently, I
> learned that his install of that program was 5 years out of date.
>
> Meanwhile, I update every time there is a new release.
>
> p.s. It would be nice to have an in game check for and install updates
> feature.
>
> --
> Chris Shaffer
>
> Please consider the environment before printing this email.
>
> On Mar 29, 2010, at 9:27 AM, Jim Black <ji...@ko...> wrote:
>
>> Brett,
>>
>> My post was titled "Versioning".
>>
>> In my reading, your comments below speak primarily to code
>> stability, and relative priorities of gaming bugs vs new titles.
>>
>> My comments weren't critical of Rails' stability, in general- and,
>> regardless- I think the new regression suites are critical, and will
>> make a profound improvement here anyway.
>>
>> Rather- I'm saying (a) it's very common for pbem tables to upgrade
>> Rails during a game, and, (b) it's very common for pbem users to be
>> running different versions of Rails /at the same time, at the same
>> table/.
>>
>> It would be useful if the Rails discussions, priorities, etc, simply
>> recognized this plain fact.
>>
>> Do with it, what you will- but, please- don't suggest most pbem
>> rails games are played start-to-finish by all the players with one
>> rails version; it's simply untrue.  Further- in my view, this leads
>> to simply ungrounded conclusions about the Rails user experience.
>>
>> - jim
>>
>>
>>
>>>
>>> Jim -
>>>
>>> I think you're missing the point.
>>>
>>> Each of us volunteers their time to the development of this project.
>>> The hours we dedicate are finite and limited.
>>>
>>> So, it's simply a question of how we spend that time.
>>>
>>> We certainly could spend that time making slow, deliberate, careful
>>> changes that don't break save file compatibility and doing the
>>> time-intensive regression testing to ensure that's the case.
>>>
>>> But... why would we? How does it help us achieve our goal of being
>>> able to support playing as many 18xx games electronically as we can?
>>>
>>> If we do things that way, it would take us literally years to
>>> implement any new feature because we'd need to painstakingly test
>>> every nook and cranny of the code to make sure those changes didn't
>>> break anything.
>>>
>>> Now, I'm not saying we shouldn't ever test anything. Stefan has
>>> done a
>>> great job improving our ability to test saved games.
>>>
>>> My point is, our time is limited and we must choose where to spend
>>> that time.
>>>
>>> The whole point of the e-mail you're quoting is that my
>>> recommendation
>>> on how to spend our limited time is to spend it on developing new
>>> features, implementing new games, and generally getting Rails into
>>> the
>>> state we'd like it to be in. The price we pay for focusing more on
>>> new
>>> development is that we will not be able to spend as much time on
>>> minimizing breakage.
>>>
>>> It's frustrating to hit a bug and have it tank your game. I
>>> understand
>>> this, perhaps more intimately than you're giving me credit. However,
>>> we can't be all things to everyone. Trade-offs and sacrifices are
>>> necessary if we want to get anything done.
>>>
>>> ---Brett.
>> =
>> ---
>> ---
>> ---
>> ---------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Versioning

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

Jim -

My comments were mainly about what we, as a small, volunteer-based dev
team can support.

We can't really support games that are played across versions. While
most of the time it'll work, there are going to be versions that don't
work together very well, or at all.

If we try to provide support for games involving multiple versions,
inevitably we'll end up spending significant amounts of time
re-discovering old issues where the solution is to upgrade.

I understand what you're saying, and to some extent, I agree with you.
I can't dictate how people use our software and I'm not about to try.

However, what I _can_ do is provide guidelines for best practices and
what to expect when asking for help.

---Brett.


On Mon, Mar 29, 2010 at 9:27 AM, Jim Black <ji...@ko...> wrote:
> Brett,
>
> My post was titled "Versioning".
>
> In my reading, your comments below speak primarily to code stability, and relative priorities of gaming bugs vs new titles.
>
> My comments weren't critical of Rails' stability, in general- and, regardless- I think the new regression suites are critical, and will make a profound improvement here anyway.
>
> Rather- I'm saying (a) it's very common for pbem tables to upgrade Rails during a game, and, (b) it's very common for pbem users to be running different versions of Rails /at the same time, at the same table/.
>
> It would be useful if the Rails discussions, priorities, etc, simply recognized this plain fact.
>
> Do with it, what you will- but, please- don't suggest most pbem rails games are played start-to-finish by all the players with one rails version; it's simply untrue.  Further- in my view, this leads to simply ungrounded conclusions about the Rails user experience.
>
>  - jim
>
>
>
>>
>> Jim -
>>
>> I think you're missing the point.
>>
>> Each of us volunteers their time to the development of this project.
>> The hours we dedicate are finite and limited.
>>
>> So, it's simply a question of how we spend that time.
>>
>> We certainly could spend that time making slow, deliberate, careful
>> changes that don't break save file compatibility and doing the
>> time-intensive regression testing to ensure that's the case.
>>
>> But... why would we? How does it help us achieve our goal of being
>> able to support playing as many 18xx games electronically as we can?
>>
>> If we do things that way, it would take us literally years to
>> implement any new feature because we'd need to painstakingly test
>> every nook and cranny of the code to make sure those changes didn't
>> break anything.
>>
>> Now, I'm not saying we shouldn't ever test anything. Stefan has done a
>> great job improving our ability to test saved games.
>>
>> My point is, our time is limited and we must choose where to spend that time.
>>
>> The whole point of the e-mail you're quoting is that my recommendation
>> on how to spend our limited time is to spend it on developing new
>> features, implementing new games, and generally getting Rails into the
>> state we'd like it to be in. The price we pay for focusing more on new
>> development is that we will not be able to spend as much time on
>> minimizing breakage.
>>
>> It's frustrating to hit a bug and have it tank your game. I understand
>> this, perhaps more intimately than you're giving me credit. However,
>> we can't be all things to everyone. Trade-offs and sacrifices are
>> necessary if we want to get anything done.
>>
>> ---Brett.
> =
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Versioning

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

I concur with Jim. It took scheduling a long distance phone call with  
a 3 hour time difference just to get Rails installed on one less-than- 
tech-savvy friend's home computer. He won't upgrade unless it is  
impossible to play and it will almost certainly require another round  
of me talking on the phone and saying "after you clicked that button,  
what does it say?". When CyberBoard forced an upgrade recently, I  
learned that his install of that program was 5 years out of date.

Meanwhile, I update every time there is a new release.

p.s. It would be nice to have an in game check for and install updates  
feature.

--
Chris Shaffer

Please consider the environment before printing this email.

On Mar 29, 2010, at 9:27 AM, Jim Black <ji...@ko...> wrote:

> Brett,
>
> My post was titled "Versioning".
>
> In my reading, your comments below speak primarily to code  
> stability, and relative priorities of gaming bugs vs new titles.
>
> My comments weren't critical of Rails' stability, in general- and,  
> regardless- I think the new regression suites are critical, and will  
> make a profound improvement here anyway.
>
> Rather- I'm saying (a) it's very common for pbem tables to upgrade  
> Rails during a game, and, (b) it's very common for pbem users to be  
> running different versions of Rails /at the same time, at the same  
> table/.
>
> It would be useful if the Rails discussions, priorities, etc, simply  
> recognized this plain fact.
>
> Do with it, what you will- but, please- don't suggest most pbem  
> rails games are played start-to-finish by all the players with one  
> rails version; it's simply untrue.  Further- in my view, this leads  
> to simply ungrounded conclusions about the Rails user experience.
>
> - jim
>
>
>
>>
>> Jim -
>>
>> I think you're missing the point.
>>
>> Each of us volunteers their time to the development of this project.
>> The hours we dedicate are finite and limited.
>>
>> So, it's simply a question of how we spend that time.
>>
>> We certainly could spend that time making slow, deliberate, careful
>> changes that don't break save file compatibility and doing the
>> time-intensive regression testing to ensure that's the case.
>>
>> But... why would we? How does it help us achieve our goal of being
>> able to support playing as many 18xx games electronically as we can?
>>
>> If we do things that way, it would take us literally years to
>> implement any new feature because we'd need to painstakingly test
>> every nook and cranny of the code to make sure those changes didn't
>> break anything.
>>
>> Now, I'm not saying we shouldn't ever test anything. Stefan has  
>> done a
>> great job improving our ability to test saved games.
>>
>> My point is, our time is limited and we must choose where to spend  
>> that time.
>>
>> The whole point of the e-mail you're quoting is that my  
>> recommendation
>> on how to spend our limited time is to spend it on developing new
>> features, implementing new games, and generally getting Rails into  
>> the
>> state we'd like it to be in. The price we pay for focusing more on  
>> new
>> development is that we will not be able to spend as much time on
>> minimizing breakage.
>>
>> It's frustrating to hit a bug and have it tank your game. I  
>> understand
>> this, perhaps more intimately than you're giving me credit. However,
>> we can't be all things to everyone. Trade-offs and sacrifices are
>> necessary if we want to get anything done.
>>
>> ---Brett.
> =
> --- 
> --- 
> --- 
> ---------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Versioning

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

Brett,

My post was titled "Versioning".   

In my reading, your comments below speak primarily to code stability, and relative priorities of gaming bugs vs new titles. 

My comments weren't critical of Rails' stability, in general- and, regardless- I think the new regression suites are critical, and will make a profound improvement here anyway.

Rather- I'm saying (a) it's very common for pbem tables to upgrade Rails during a game, and, (b) it's very common for pbem users to be running different versions of Rails /at the same time, at the same table/.

It would be useful if the Rails discussions, priorities, etc, simply recognized this plain fact.   

Do with it, what you will- but, please- don't suggest most pbem rails games are played start-to-finish by all the players with one rails version; it's simply untrue.  Further- in my view, this leads to simply ungrounded conclusions about the Rails user experience. 

 - jim



> 
> Jim -
> 
> I think you're missing the point.
> 
> Each of us volunteers their time to the development of this project.
> The hours we dedicate are finite and limited.
> 
> So, it's simply a question of how we spend that time.
> 
> We certainly could spend that time making slow, deliberate, careful
> changes that don't break save file compatibility and doing the
> time-intensive regression testing to ensure that's the case.
> 
> But... why would we? How does it help us achieve our goal of being
> able to support playing as many 18xx games electronically as we can?
> 
> If we do things that way, it would take us literally years to
> implement any new feature because we'd need to painstakingly test
> every nook and cranny of the code to make sure those changes didn't
> break anything.
> 
> Now, I'm not saying we shouldn't ever test anything. Stefan has done a
> great job improving our ability to test saved games.
> 
> My point is, our time is limited and we must choose where to spend that time.
> 
> The whole point of the e-mail you're quoting is that my recommendation
> on how to spend our limited time is to spend it on developing new
> features, implementing new games, and generally getting Rails into the
> state we'd like it to be in. The price we pay for focusing more on new
> development is that we will not be able to spend as much time on
> minimizing breakage.
> 
> It's frustrating to hit a bug and have it tank your game. I understand
> this, perhaps more intimately than you're giving me credit. However,
> we can't be all things to everyone. Trade-offs and sacrifices are
> necessary if we want to get anything done.
> 
> ---Brett.
=

Re: [Rails-devel] Versioning

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

On Sun, Mar 28, 2010 at 10:38 AM, Jim Black <ji...@ko...> wrote:
>> If the number of safe files that we need to migrate forward to the new
>> format grows substantially, obviously we'll need to change this
>> strategy or develop tools to allow users to migrate save files. For
>> now, I'd just like to see bug fixes and new games/features take a
>> higher priority than save file compatibility.
>
> As a rails/pbem user, host, n00b trainer, and dedicated evangelist- most all outstanding Rails issues don't even /rank/, by comparison, with versioning, and ease-of install/configuration/upgrade/launch.
>
> I can understand that this is hard from the development side of the fence, really.
>
> Nonetheless- I strongly suspect that almost the /only/ users able to keep to one version for a whole game, successfully, are the ones on this list, that are running Rails directly from their shared dropbox folder, and then- only playing a title that was stabilized many months ago.  (eg 1830 18al 18eu).  We've all agreed this is an insecure approach- it's an expert/developer/insider solution, not a community solution.
>
> So, if you think most of your users /are/- or even, /can/- use the same rails version to complete a rails game, as they started with- it's simply not remotely close to the actual reality, in my experience.  It would really help the discussion- and rails' evolution- if you took this into honest account.
>
>  - jim

Jim -

I think you're missing the point.

Each of us volunteers their time to the development of this project.
The hours we dedicate are finite and limited.

So, it's simply a question of how we spend that time.

We certainly could spend that time making slow, deliberate, careful
changes that don't break save file compatibility and doing the
time-intensive regression testing to ensure that's the case.

But... why would we? How does it help us achieve our goal of being
able to support playing as many 18xx games electronically as we can?

If we do things that way, it would take us literally years to
implement any new feature because we'd need to painstakingly test
every nook and cranny of the code to make sure those changes didn't
break anything.

Now, I'm not saying we shouldn't ever test anything. Stefan has done a
great job improving our ability to test saved games.

My point is, our time is limited and we must choose where to spend that time.

The whole point of the e-mail you're quoting is that my recommendation
on how to spend our limited time is to spend it on developing new
features, implementing new games, and generally getting Rails into the
state we'd like it to be in. The price we pay for focusing more on new
development is that we will not be able to spend as much time on
minimizing breakage.

It's frustrating to hit a bug and have it tank your game. I understand
this, perhaps more intimately than you're giving me credit. However,
we can't be all things to everyone. Trade-offs and sacrifices are
necessary if we want to get anything done.

---Brett.

[Rails-devel] Versioning

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

Under  "Implementation levels", earlier, there were some comments I found profoundly discouraging:

> I think the assumption should just be to finish a
> game with the same version of Rails that started the game.

This, quite simply- has never happened in any pbem game I've played with rails.

If you really believe this is the current state of affairs, you should version-lock Rails to the save-files.  

But- we all know this would be completely unacceptable!

Why?  Because /everyone/ is upgrading their games, in progress.

Indeed, thankfully- the developers are at great pains to keep this working.  It's fundamental- we upgrade when possible, somewhere along the way.

Many of these games take /months/ pbem- that's a lifetime worth of Rails releases and critical bug fixes.


> The one concern I have with this is showstopper bugs.  If a group is playing
> a game, gets halfway through, and can't continue because of a bug, there
> should be some support for converting their game to the new version with the
> bugfix.

With every pbem game I've played with rails, either (a) bugs happened and forced an upgrade, or (b) users saved with a more recent version, and forced an upgrade.
  
> I'm not saying that we won't support users when they have
> problems.  We absolutely should and will. 
>
>  as developers, we shouldn't spend a lot of time
> trying to preserve backwards compatibility with old save formats. It's
> extra work that just doesn't buy us anything at this stage in rails'
> maturity.

In my opinion- as a 'user'- these two statements simply couldn't be more in opposition.

> If the number of safe files that we need to migrate forward to the new
> format grows substantially, obviously we'll need to change this
> strategy or develop tools to allow users to migrate save files. For
> now, I'd just like to see bug fixes and new games/features take a
> higher priority than save file compatibility.

As a rails/pbem user, host, n00b trainer, and dedicated evangelist- most all outstanding Rails issues don't even /rank/, by comparison, with versioning, and ease-of install/configuration/upgrade/launch.

I can understand that this is hard from the development side of the fence, really.

Nonetheless- I strongly suspect that almost the /only/ users able to keep to one version for a whole game, successfully, are the ones on this list, that are running Rails directly from their shared dropbox folder, and then- only playing a title that was stabilized many months ago.  (eg 1830 18al 18eu).  We've all agreed this is an insecure approach- it's an expert/developer/insider solution, not a community solution.

So, if you think most of your users /are/- or even, /can/- use the same rails version to complete a rails game, as they started with- it's simply not remotely close to the actual reality, in my experience.  It would really help the discussion- and rails' evolution- if you took this into honest account.

 - jim

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

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

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

----------------------------------------------------------------------------
--
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel


----------------------------------------------------------------------------
--
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
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...>]

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

----------------------------------------------------------------------------
--
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
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

[Joshua G. <jos...@gm...>]

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

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

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

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] Automatic route calculation

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

Orientation is (IIRC) an integer denoting the number of clockwise
rotations away from the default orientation of the image file we've
made.

We've got two styles of hexes, EWHex and NSHex, the difference being
whether the hex is oriented with two sides running horizontally
parallel, or vertically parallel.

Have a look through the Hex and MapHex classes. All of the rotational
math is in those classes and the EW/NS subclasses.

---Brett.



On Wed, Mar 24, 2010 at 7:26 PM, alexti <al...@sh...> wrote:
> Hi Stefan,
>
> Format you've suggested is fine. I don't see any problem reading it. I
> assume tile-ID is the same thing as tile# printed on real tiles? I may not
> have more exotic tiles defined, but that should be easy to add. How
> orientation is encoded (in terms of N,NE,NW,S,SE,SW notation)? I would
> also need map orientation (letters are column or rows and the "oddness" of
> map).
>
> Thanks,
> Alex.
>
> On Wed, 24 Mar 2010 13:56:32 -0600, Stefan Frey <ste...@we...> wrote:
>
>> Hi Alex,
>> my time constraints are similars to yours, thus do not expect anything
>> before
>> the we and even then not too much.
>>
>> I am still wondering how you convert our map layout into your graph
>> definition
>> (without manual work, especially with respect to tile orientation), but I
>> will leave that up to you.
>>
>> I can easily provide a list with
>> Map-ID, tile-ID, orientation
>>
>> as used internally by Rails.
>>
>> for example (orientation is random here)
>> A2, 9, 1
>> A4, 24, 2
>> A6, 8, 3
>> etc.
>>
>> Is that ok?
>>
>> Stefan
>>
>>
>>
>> On Wednesday 24 March 2010 04:52:14 alexti wrote:
>>> Hi Stefan,
>>>
>>> I like your idea. It makes sense that artificially complicated track
>>> layout with lack of station markers in a simpler game may create more
>>> difficult problem than the realistic scenario in a more complex game
>>> will.
>>>
>>> If you are volunteering to create such setup for 1870 I can try to build
>>> similar scenario for 1856 (with couple of diesels, for example). In what
>>> form can you export such setup? Something simple (for example
>>> comma-separated tile ids) will do. I won't have time to do it until the
>>> weekend though...
>>>
>>> Alex.
>>>
>>> On Tue, 23 Mar 2010 16:35:52 -0600, Stefan Frey <ste...@we...>
>>> wrote:
>>> > Alex:
>>> > Some more comments on a potential test for automatic route
>>> calculation:
>>> >
>>> > I think there is no need for one of the more "exotic" types (18US,
>>> 18C2C,
>>> > 1844) to create a (reasonable) difficult scenario.
>>> >
>>> > It is easy to create a quite involved track layout with maps and tiles
>>> > of one
>>> > of titles already implemented in Rails (for this even the partially
>>> > implemented 1835 or 1870 would work).
>>> >
>>> > Then rails could supply:
>>> >
>>> > * A map (here I mean the collection) with map hexes and tiles. From my
>>> > point
>>> > of view it is still open, how it is converted to the graph you need to
>>> > run
>>> > your algorithm.
>>> >
>>> > * The trains available to the one company could be easily changed. And
>>> > we can
>>> > make things more difficult by requesting scenarios, which are not
>>> > possible in
>>> > 1870: For example running a  8, 10 and 12 at once.
>>> >
>>> > * I think, that there is no need for tokens so far (either simply
>>> assume
>>> > that
>>> > there are none (which would allow even more connections than usual) or
>>> > create
>>> > a network that is usually available to one company after considering
>>> the
>>> > effects of tokening, if we want to built a more realistic test case).
>>> >
>>> > If no other wants to jump in, I would volunteer to create such a
>>> network
>>> > on
>>> > the 1870 map.
>>> >
>>> > Stefan
>>> >
>>> >> >> Perhaps it can be tested? There is no need to have complete
>>> support
>>> >>
>>> >> of
>>> >>
>>> >> >> such games in Rails to make experiment. We could create a graph
>>> >> >> representing "difficult case" and run algorithm on it.
>>> >> >
>>> >> > Yes, though it could take time to manually build the graph the way
>>> >>
>>> >> your
>>> >>
>>> >> > algorithm wants it.
>>> >> >
>>> >> >> > Some I would look at would be 18US, 18C2C (for sheer size and
>>> the
>>> >> >>
>>> >> >> ability
>>> >> >>
>>> >> >> > for a company to run lots of large trains), 1844 (which adds
>>> >>
>>> >> tunnels
>>> >>
>>> >> >> and
>>> >> >>
>>> >> >> > mountains that affect the route score), and 1860.
>>> >> >>
>>> >> >> Unfortunately, I don't own any of them :(
>>> >> >
>>> >> > The complete rules are available for at least 18US and 1844, and
>>> >>
>>> >> ps18xx
>>> >>
>>> >> > includes the map/tiles for all of them.
>>> >>
>>> >> Are there some cases you would consider examples of "difficult" ones
>>> >> that
>>> >> are available in some kind of format? From some PBEM games perhaps?
>>> It
>>> >> might be relatively easy to convert them into the graph I need. And
>>> it's
>>> >> difficult to get an impression of what realistic end game layout
>>> would
>>> >> be
>>> >> without playing the game.
>>> >
>>> >
>>> -------------------------------------------------------------------------
>>> >----- Download Intel&#174; Parallel Studio Eval
>>> > Try the new software tools for yourself. Speed compiling, find bugs
>>> > proactively, and fine-tune applications for parallel performance.
>>> > See why Intel Parallel Studio got high marks during beta.
>>> > http://p.sf.net/sfu/intel-sw-dev
>>> > _______________________________________________
>>> > Rails-devel mailing list
>>> > Rai...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Automatic route calculation

[alexti <al...@sh...>]

I guess I have side-stepped a lot of issues by doing all that logic on the  
graph rather than on the board description. Though the question of what  
tile can be used for upgrade is not solvable automatically - in some games  
specific upgrades are not permitted, even all the normal requirements are  
satisfied. And in other games strange "upgrades" are permitted (like  
replacing yellow town with yellow straight or curve in 1856). This has to  
be a part of the game's tile manifest.


On Wed, 24 Mar 2010 12:06:11 -0600, Dave Mitton <da...@mi...> wrote:

> I've built this code in my VB 1830 game years ago.
>
> You have to solve a lot of the problems to get this far, and the  
> information can
> be use to validate tile lays.
>
> Is that hex reachable? What tiles can I use? In what rotations? Does the  
> track
> connect? (permissive or strict upgrade rules?)
>
> There are many track connectivity, token location (look out for XX  
> tiles), and
> tile drawing issues to conquer just getting this much done.
>
> But I did it with a simple iteration and evaluation stack to flatten the
> recursion problem.
>
> (push the tokens; pop a location, mark connected edges; push edges it  
> connects
> to that is new, repeat)
>
> Without an route suggestor; you can then build a simple "connect the  
> dots" route
> interface that lets you point at a route on the map, it color's the  
> connecting
> track, and total's the revenue for you. Do it in a list for multiple  
> trains.
> That's as far as I got. The interface was buggy as heck, most due to  
> using lousy
> route list structures.
>
> Even with a route suggestor, the UI will get "interesting".
>
> Dave.
>
>
>
> Mar 24, 2010 01:25:51 PM, rai...@li... wrote:
>
> On Wed, Mar 24, 2010 at 10:20 AM, Aliza Panitz <ali...@gm...>  
> wrote:
>> This is something we could implement incrementally:
>>
>> (1) Have a button that users can click to highlight every bit of track
>> that their trains can reach from their tokens. This will be useful
>> even without route calculation, though it will require Rails to learn
>> about track, routes, tokens, etc.
>>
>> The algorithm I'm thinking of would be a simple flood-fill that gets
>> blocked by foreign tokens if the circles are filled.
>
>
> I agree. This is a great starting point.
>
> It provides useful information to players almost immediately, even
> before route calculation is feature complete.
>
> ---Brett.
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [Rails-devel] Automatic route calculation

[alexti <al...@sh...>]

Hi Stefan,

Format you've suggested is fine. I don't see any problem reading it. I  
assume tile-ID is the same thing as tile# printed on real tiles? I may not  
have more exotic tiles defined, but that should be easy to add. How  
orientation is encoded (in terms of N,NE,NW,S,SE,SW notation)? I would  
also need map orientation (letters are column or rows and the "oddness" of  
map).

Thanks,
Alex.

On Wed, 24 Mar 2010 13:56:32 -0600, Stefan Frey <ste...@we...> wrote:

> Hi Alex,
> my time constraints are similars to yours, thus do not expect anything  
> before
> the we and even then not too much.
>
> I am still wondering how you convert our map layout into your graph  
> definition
> (without manual work, especially with respect to tile orientation), but I
> will leave that up to you.
>
> I can easily provide a list with
> Map-ID, tile-ID, orientation
>
> as used internally by Rails.
>
> for example (orientation is random here)
> A2, 9, 1
> A4, 24, 2
> A6, 8, 3
> etc.
>
> Is that ok?
>
> Stefan
>
>
>
> On Wednesday 24 March 2010 04:52:14 alexti wrote:
>> Hi Stefan,
>>
>> I like your idea. It makes sense that artificially complicated track
>> layout with lack of station markers in a simpler game may create more
>> difficult problem than the realistic scenario in a more complex game  
>> will.
>>
>> If you are volunteering to create such setup for 1870 I can try to build
>> similar scenario for 1856 (with couple of diesels, for example). In what
>> form can you export such setup? Something simple (for example
>> comma-separated tile ids) will do. I won't have time to do it until the
>> weekend though...
>>
>> Alex.
>>
>> On Tue, 23 Mar 2010 16:35:52 -0600, Stefan Frey <ste...@we...>  
>> wrote:
>> > Alex:
>> > Some more comments on a potential test for automatic route  
>> calculation:
>> >
>> > I think there is no need for one of the more "exotic" types (18US,  
>> 18C2C,
>> > 1844) to create a (reasonable) difficult scenario.
>> >
>> > It is easy to create a quite involved track layout with maps and tiles
>> > of one
>> > of titles already implemented in Rails (for this even the partially
>> > implemented 1835 or 1870 would work).
>> >
>> > Then rails could supply:
>> >
>> > * A map (here I mean the collection) with map hexes and tiles. From my
>> > point
>> > of view it is still open, how it is converted to the graph you need to
>> > run
>> > your algorithm.
>> >
>> > * The trains available to the one company could be easily changed. And
>> > we can
>> > make things more difficult by requesting scenarios, which are not
>> > possible in
>> > 1870: For example running a  8, 10 and 12 at once.
>> >
>> > * I think, that there is no need for tokens so far (either simply  
>> assume
>> > that
>> > there are none (which would allow even more connections than usual) or
>> > create
>> > a network that is usually available to one company after considering  
>> the
>> > effects of tokening, if we want to built a more realistic test case).
>> >
>> > If no other wants to jump in, I would volunteer to create such a  
>> network
>> > on
>> > the 1870 map.
>> >
>> > Stefan
>> >
>> >> >> Perhaps it can be tested? There is no need to have complete  
>> support
>> >>
>> >> of
>> >>
>> >> >> such games in Rails to make experiment. We could create a graph
>> >> >> representing "difficult case" and run algorithm on it.
>> >> >
>> >> > Yes, though it could take time to manually build the graph the way
>> >>
>> >> your
>> >>
>> >> > algorithm wants it.
>> >> >
>> >> >> > Some I would look at would be 18US, 18C2C (for sheer size and  
>> the
>> >> >>
>> >> >> ability
>> >> >>
>> >> >> > for a company to run lots of large trains), 1844 (which adds
>> >>
>> >> tunnels
>> >>
>> >> >> and
>> >> >>
>> >> >> > mountains that affect the route score), and 1860.
>> >> >>
>> >> >> Unfortunately, I don't own any of them :(
>> >> >
>> >> > The complete rules are available for at least 18US and 1844, and
>> >>
>> >> ps18xx
>> >>
>> >> > includes the map/tiles for all of them.
>> >>
>> >> Are there some cases you would consider examples of "difficult" ones
>> >> that
>> >> are available in some kind of format? From some PBEM games perhaps?  
>> It
>> >> might be relatively easy to convert them into the graph I need. And  
>> it's
>> >> difficult to get an impression of what realistic end game layout  
>> would
>> >> be
>> >> without playing the game.
>> >
>> >  
>> -------------------------------------------------------------------------
>> >----- Download Intel&#174; Parallel Studio Eval
>> > Try the new software tools for yourself. Speed compiling, find bugs
>> > proactively, and fine-tune applications for parallel performance.
>> > See why Intel Parallel Studio got high marks during beta.
>> > http://p.sf.net/sfu/intel-sw-dev
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [Rails-devel] Automatic route calculation

[alexti <al...@sh...>]

I am not sure how much effort UI part is in it, but backend stuff is  
trivial. I am always trimming graph before running route calculations  
(obviously removing disconnected edges and also eliminating "hanging  
edges" (the edge that can not be used to reach anything of non-zero  
value)).

On Wed, 24 Mar 2010 11:20:22 -0600, Aliza Panitz <ali...@gm...>  
wrote:

> This is something we could implement incrementally:
>
> (1) Have a button that users can click to highlight every bit of track
> that their trains can reach from their tokens.  This will be useful
> even without route calculation, though it will require Rails to learn
> about track, routes, tokens, etc.
>
> The algorithm I'm thinking of would be a simple flood-fill that gets
> blocked by foreign tokens if the circles are filled.
>
> As a second stage it could limit itself to the length of the longest
> train the company has, though the flood-fill is useful even with
> imaginary infinite-length Diesels for showing where tokens can legally
> be placed.
>
> (2) Once you have the flood-fill area, then it reduces to a smaller
> map that can be worked with the tokenless algorithm described below.
>
> On Tue, Mar 23, 2010 at 8:52 PM, alexti <al...@sh...> wrote:
>> Hi Stefan,
>>
>> I like your idea. It makes sense that artificially complicated track
>> layout with lack of station markers in a simpler game may create more
>> difficult problem than the realistic scenario in a more complex game  
>> will.
>>
>> If you are volunteering to create such setup for 1870 I can try to build
>> similar scenario for 1856 (with couple of diesels, for example). In what
>> form can you export such setup? Something simple (for example
>> comma-separated tile ids) will do. I won't have time to do it until the
>> weekend though...
>>
>> Alex.
>>
>> On Tue, 23 Mar 2010 16:35:52 -0600, Stefan Frey <ste...@we...>  
>> wrote:
>>
>>> Alex:
>>> Some more comments on a potential test for automatic route calculation:
>>>
>>> I think there is no need for one of the more "exotic" types (18US,  
>>> 18C2C,
>>> 1844) to create a (reasonable) difficult scenario.
>>>
>>> It is easy to create a quite involved track layout with maps and tiles
>>> of one
>>> of titles already implemented in Rails (for this even the partially
>>> implemented 1835 or 1870 would work).
>>>
>>> Then rails could supply:
>>>
>>> * A map (here I mean the collection) with map hexes and tiles. From my
>>> point
>>> of view it is still open, how it is converted to the graph you need to
>>> run
>>> your algorithm.
>>>
>>> * The trains available to the one company could be easily changed. And
>>> we can
>>> make things more difficult by requesting scenarios, which are not
>>> possible in
>>> 1870: For example running a  8, 10 and 12 at once.
>>>
>>> * I think, that there is no need for tokens so far (either simply  
>>> assume
>>> that
>>> there are none (which would allow even more connections than usual) or
>>> create
>>> a network that is usually available to one company after considering  
>>> the
>>> effects of tokening, if we want to built a more realistic test case).
>>>
>>> If no other wants to jump in, I would volunteer to create such a  
>>> network
>>> on
>>> the 1870 map.
>>>
>>> Stefan
>>>
>>>
>>>>
>>>> >> Perhaps it can be tested? There is no need to have complete support
>>>> of
>>>> >> such games in Rails to make experiment. We could create a graph
>>>> >> representing "difficult case" and run algorithm on it.
>>>> >
>>>> > Yes, though it could take time to manually build the graph the way
>>>> your
>>>> > algorithm wants it.
>>>> >
>>>> >> > Some I would look at would be 18US, 18C2C (for sheer size and the
>>>> >>
>>>> >> ability
>>>> >>
>>>> >> > for a company to run lots of large trains), 1844 (which adds
>>>> tunnels
>>>> >>
>>>> >> and
>>>> >>
>>>> >> > mountains that affect the route score), and 1860.
>>>> >>
>>>> >> Unfortunately, I don't own any of them :(
>>>> >
>>>> > The complete rules are available for at least 18US and 1844, and
>>>> ps18xx
>>>> > includes the map/tiles for all of them.
>>>>
>>>> Are there some cases you would consider examples of "difficult" ones
>>>> that
>>>> are available in some kind of format? From some PBEM games perhaps? It
>>>> might be relatively easy to convert them into the graph I need. And  
>>>> it's
>>>> difficult to get an impression of what realistic end game layout would
>>>> be
>>>> without playing the game.
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel&#174; Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>> --
>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [Rails-devel] Automatic route calculation

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

Hi Alex,
my time constraints are similars to yours, thus do not expect anything before 
the we and even then not too much.

I am still wondering how you convert our map layout into your graph definition 
(without manual work, especially with respect to tile orientation), but I 
will leave that up to you.

I can easily provide a list with 
Map-ID, tile-ID, orientation

as used internally by Rails.

for example (orientation is random here)
A2, 9, 1
A4, 24, 2
A6, 8, 3
etc.

Is that ok?

Stefan



On Wednesday 24 March 2010 04:52:14 alexti wrote:
> Hi Stefan,
>
> I like your idea. It makes sense that artificially complicated track
> layout with lack of station markers in a simpler game may create more
> difficult problem than the realistic scenario in a more complex game will.
>
> If you are volunteering to create such setup for 1870 I can try to build
> similar scenario for 1856 (with couple of diesels, for example). In what
> form can you export such setup? Something simple (for example
> comma-separated tile ids) will do. I won't have time to do it until the
> weekend though...
>
> Alex.
>
> On Tue, 23 Mar 2010 16:35:52 -0600, Stefan Frey <ste...@we...> wrote:
> > Alex:
> > Some more comments on a potential test for automatic route calculation:
> >
> > I think there is no need for one of the more "exotic" types (18US, 18C2C,
> > 1844) to create a (reasonable) difficult scenario.
> >
> > It is easy to create a quite involved track layout with maps and tiles
> > of one
> > of titles already implemented in Rails (for this even the partially
> > implemented 1835 or 1870 would work).
> >
> > Then rails could supply:
> >
> > * A map (here I mean the collection) with map hexes and tiles. From my
> > point
> > of view it is still open, how it is converted to the graph you need to
> > run
> > your algorithm.
> >
> > * The trains available to the one company could be easily changed. And
> > we can
> > make things more difficult by requesting scenarios, which are not
> > possible in
> > 1870: For example running a  8, 10 and 12 at once.
> >
> > * I think, that there is no need for tokens so far (either simply assume
> > that
> > there are none (which would allow even more connections than usual) or
> > create
> > a network that is usually available to one company after considering the
> > effects of tokening, if we want to built a more realistic test case).
> >
> > If no other wants to jump in, I would volunteer to create such a network
> > on
> > the 1870 map.
> >
> > Stefan
> >
> >> >> Perhaps it can be tested? There is no need to have complete support
> >>
> >> of
> >>
> >> >> such games in Rails to make experiment. We could create a graph
> >> >> representing "difficult case" and run algorithm on it.
> >> >
> >> > Yes, though it could take time to manually build the graph the way
> >>
> >> your
> >>
> >> > algorithm wants it.
> >> >
> >> >> > Some I would look at would be 18US, 18C2C (for sheer size and the
> >> >>
> >> >> ability
> >> >>
> >> >> > for a company to run lots of large trains), 1844 (which adds
> >>
> >> tunnels
> >>
> >> >> and
> >> >>
> >> >> > mountains that affect the route score), and 1860.
> >> >>
> >> >> Unfortunately, I don't own any of them :(
> >> >
> >> > The complete rules are available for at least 18US and 1844, and
> >>
> >> ps18xx
> >>
> >> > includes the map/tiles for all of them.
> >>
> >> Are there some cases you would consider examples of "difficult" ones
> >> that
> >> are available in some kind of format? From some PBEM games perhaps? It
> >> might be relatively easy to convert them into the graph I need. And it's
> >> difficult to get an impression of what realistic end game layout would
> >> be
> >> without playing the game.
> >
> > -------------------------------------------------------------------------
> >----- Download Intel&#174; Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Automatic route calculation

[Dave M. <da...@mi...>]

<html><HEAD><LINK rel=stylesheet type=text/css href="/webmail/static/deg/css/wysiwyg-3451203449.css" media=all>
<META name=GENERATOR content="MSHTML 8.00.6001.18882"></HEAD>
<BODY>
<DIV>I've built this code in my VB 1830 game years ago.</DIV>
<DIV>&nbsp;</DIV>
<DIV>You have to solve a lot of the problems to get this far, and the information can be use to validate tile lays.</DIV>
<DIV>Is that hex reachable? &nbsp;What tiles can I use?&nbsp; In what rotations?&nbsp; Does the track connect? &nbsp;(permissive or strict upgrade rules?)</DIV>
<DIV>&nbsp;</DIV>
<DIV>There are many track connectivity, token location (look out for XX tiles), and tile drawing&nbsp;issues to conquer just getting this much done.</DIV>
<DIV>But I did it with a simple iteration and evaluation stack to flatten the recursion problem.</DIV>
<DIV>(push the tokens; pop a location, mark connected edges; push&nbsp;edges it connects to that is new, repeat)</DIV>
<DIV>&nbsp;</DIV>
<DIV>Without an route suggestor;&nbsp; you can then build a simple "connect the dots" route interface&nbsp;that lets you point at a route on the map, it color's the connecting track, and total's the revenue for you.&nbsp; Do it in a list for multiple trains.&nbsp;&nbsp; That's as far as I got.&nbsp; The interface was buggy as heck, most due to using lousy route list structures.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Even with a route suggestor, the UI will get "interesting".</DIV>
<DIV>&nbsp;</DIV>
<DIV>Dave.</DIV>
<DIV><BR><BR>Mar 24, 2010 01:25:51 PM, <A class="parsedEmail parsedEmail" href="mailto:rai...@li..." target=_blank>rai...@li...</A>&nbsp;wrote:<BR></DIV>
<BLOCKQUOTE style="BORDER-LEFT: rgb(102,153,204) 3px solid">On Wed, Mar 24, 2010 at 10:20 AM, Aliza Panitz &lt;<A class="parsedEmail parsedEmail parsedEmail" href="mailto:ali...@gm..." target=_blank>ali...@gm...</A>&gt; wrote:<BR>&gt; This is something we could implement incrementally:<BR>&gt;<BR>&gt; (1) Have a button that users can click to highlight every bit of track<BR>&gt; that their trains can reach from their tokens. &nbsp;This will be useful<BR>&gt; even without route calculation, though it will require Rails to learn<BR>&gt; about track, routes, tokens, etc.<BR>&gt;<BR>&gt; The algorithm I'm thinking of would be a simple flood-fill that gets<BR>&gt; blocked by foreign tokens if the circles are filled.<BR><BR><BR>I agree. This is a great starting point.<BR><BR>It provides useful information to players almost immediately, even<BR>before route calculation is feature complete.<BR><BR>---Brett.<BR><BR>------------------------------------------------------------------------------<BR>Download Intel® Parallel Studio Eval<BR>Try the new software tools for yourself. Speed compiling, find bugs<BR>proactively, and fine-tune applications for parallel performance.<BR>See why Intel Parallel Studio got high marks during beta.<BR><A class=parsedLink href="http://p.sf.net/sfu/intel-sw-dev" target=_blank>http://p.sf.net/sfu/intel-sw-dev</A><BR>_______________________________________________<BR>Rails-devel mailing list<BR><A class="parsedEmail parsedEmail parsedEmail" href="mailto:Rai...@li..." target=_blank>Rai...@li...</A><BR><A class=parsedLink href="http://https://lists.sourceforge.net/lists/listinfo/rails-devel" target=_blank>https://lists.sourceforge.net/lists/listinfo/rails-devel</A><BR></BLOCKQUOTE></BODY></html>

Re: [Rails-devel] Automatic route calculation

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

On Wed, Mar 24, 2010 at 10:20 AM, Aliza Panitz <ali...@gm...> wrote:
> This is something we could implement incrementally:
>
> (1) Have a button that users can click to highlight every bit of track
> that their trains can reach from their tokens.  This will be useful
> even without route calculation, though it will require Rails to learn
> about track, routes, tokens, etc.
>
> The algorithm I'm thinking of would be a simple flood-fill that gets
> blocked by foreign tokens if the circles are filled.


I agree. This is a great starting point.

It provides useful information to players almost immediately, even
before route calculation is feature complete.

---Brett.

Re: [Rails-devel] Automatic route calculation

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

This is something we could implement incrementally:

(1) Have a button that users can click to highlight every bit of track
that their trains can reach from their tokens.  This will be useful
even without route calculation, though it will require Rails to learn
about track, routes, tokens, etc.

The algorithm I'm thinking of would be a simple flood-fill that gets
blocked by foreign tokens if the circles are filled.

As a second stage it could limit itself to the length of the longest
train the company has, though the flood-fill is useful even with
imaginary infinite-length Diesels for showing where tokens can legally
be placed.

(2) Once you have the flood-fill area, then it reduces to a smaller
map that can be worked with the tokenless algorithm described below.

On Tue, Mar 23, 2010 at 8:52 PM, alexti <al...@sh...> wrote:
> Hi Stefan,
>
> I like your idea. It makes sense that artificially complicated track
> layout with lack of station markers in a simpler game may create more
> difficult problem than the realistic scenario in a more complex game will.
>
> If you are volunteering to create such setup for 1870 I can try to build
> similar scenario for 1856 (with couple of diesels, for example). In what
> form can you export such setup? Something simple (for example
> comma-separated tile ids) will do. I won't have time to do it until the
> weekend though...
>
> Alex.
>
> On Tue, 23 Mar 2010 16:35:52 -0600, Stefan Frey <ste...@we...> wrote:
>
>> Alex:
>> Some more comments on a potential test for automatic route calculation:
>>
>> I think there is no need for one of the more "exotic" types (18US, 18C2C,
>> 1844) to create a (reasonable) difficult scenario.
>>
>> It is easy to create a quite involved track layout with maps and tiles
>> of one
>> of titles already implemented in Rails (for this even the partially
>> implemented 1835 or 1870 would work).
>>
>> Then rails could supply:
>>
>> * A map (here I mean the collection) with map hexes and tiles. From my
>> point
>> of view it is still open, how it is converted to the graph you need to
>> run
>> your algorithm.
>>
>> * The trains available to the one company could be easily changed. And
>> we can
>> make things more difficult by requesting scenarios, which are not
>> possible in
>> 1870: For example running a  8, 10 and 12 at once.
>>
>> * I think, that there is no need for tokens so far (either simply assume
>> that
>> there are none (which would allow even more connections than usual) or
>> create
>> a network that is usually available to one company after considering the
>> effects of tokening, if we want to built a more realistic test case).
>>
>> If no other wants to jump in, I would volunteer to create such a network
>> on
>> the 1870 map.
>>
>> Stefan
>>
>>
>>>
>>> >> Perhaps it can be tested? There is no need to have complete support
>>> of
>>> >> such games in Rails to make experiment. We could create a graph
>>> >> representing "difficult case" and run algorithm on it.
>>> >
>>> > Yes, though it could take time to manually build the graph the way
>>> your
>>> > algorithm wants it.
>>> >
>>> >> > Some I would look at would be 18US, 18C2C (for sheer size and the
>>> >>
>>> >> ability
>>> >>
>>> >> > for a company to run lots of large trains), 1844 (which adds
>>> tunnels
>>> >>
>>> >> and
>>> >>
>>> >> > mountains that affect the route score), and 1860.
>>> >>
>>> >> Unfortunately, I don't own any of them :(
>>> >
>>> > The complete rules are available for at least 18US and 1844, and
>>> ps18xx
>>> > includes the map/tiles for all of them.
>>>
>>> Are there some cases you would consider examples of "difficult" ones
>>> that
>>> are available in some kind of format? From some PBEM games perhaps? It
>>> might be relatively easy to convert them into the graph I need. And it's
>>> difficult to get an impression of what realistic end game layout would
>>> be
>>> without playing the game.
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Automatic route calculation

[alexti <al...@sh...>]

Hi Stefan,

I like your idea. It makes sense that artificially complicated track  
layout with lack of station markers in a simpler game may create more  
difficult problem than the realistic scenario in a more complex game will.

If you are volunteering to create such setup for 1870 I can try to build  
similar scenario for 1856 (with couple of diesels, for example). In what  
form can you export such setup? Something simple (for example  
comma-separated tile ids) will do. I won't have time to do it until the  
weekend though...

Alex.

On Tue, 23 Mar 2010 16:35:52 -0600, Stefan Frey <ste...@we...> wrote:

> Alex:
> Some more comments on a potential test for automatic route calculation:
>
> I think there is no need for one of the more "exotic" types (18US, 18C2C,
> 1844) to create a (reasonable) difficult scenario.
>
> It is easy to create a quite involved track layout with maps and tiles  
> of one
> of titles already implemented in Rails (for this even the partially
> implemented 1835 or 1870 would work).
>
> Then rails could supply:
>
> * A map (here I mean the collection) with map hexes and tiles. From my  
> point
> of view it is still open, how it is converted to the graph you need to  
> run
> your algorithm.
>
> * The trains available to the one company could be easily changed. And  
> we can
> make things more difficult by requesting scenarios, which are not  
> possible in
> 1870: For example running a  8, 10 and 12 at once.
>
> * I think, that there is no need for tokens so far (either simply assume  
> that
> there are none (which would allow even more connections than usual) or  
> create
> a network that is usually available to one company after considering the
> effects of tokening, if we want to built a more realistic test case).
>
> If no other wants to jump in, I would volunteer to create such a network  
> on
> the 1870 map.
>
> Stefan
>
>
>>
>> >> Perhaps it can be tested? There is no need to have complete support  
>> of
>> >> such games in Rails to make experiment. We could create a graph
>> >> representing "difficult case" and run algorithm on it.
>> >
>> > Yes, though it could take time to manually build the graph the way  
>> your
>> > algorithm wants it.
>> >
>> >> > Some I would look at would be 18US, 18C2C (for sheer size and the
>> >>
>> >> ability
>> >>
>> >> > for a company to run lots of large trains), 1844 (which adds  
>> tunnels
>> >>
>> >> and
>> >>
>> >> > mountains that affect the route score), and 1860.
>> >>
>> >> Unfortunately, I don't own any of them :(
>> >
>> > The complete rules are available for at least 18US and 1844, and  
>> ps18xx
>> > includes the map/tiles for all of them.
>>
>> Are there some cases you would consider examples of "difficult" ones  
>> that
>> are available in some kind of format? From some PBEM games perhaps? It
>> might be relatively easy to convert them into the graph I need. And it's
>> difficult to get an impression of what realistic end game layout would  
>> be
>> without playing the game.
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [Rails-devel] Automated testing for Rails

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

On Tue, Mar 23, 2010 at 3:17 PM, Stefan Frey <ste...@we...> wrote:
> Brett,
> see my comments below.
> Stefan
>
>> Excellent. We've needed this for a while, and this is a good start.
>
> Thanks. I am happy to have that too, as it now easier to refactor classes.
>>
>> This is fine as a starting point, but it's not how most traditional
>> automated testing works.
>
> Yes and no. It is automated testing, but obviously it is not (traditiional)
> unit testing, but belongs to the class of integration or system tests. But
> all are equally important.
>

Agreed. I phrased it badly, but yes, we're saying the same things.

>>
>> One goal that I hope we work toward is building on this foundation by
>> developing unit and regression tests for each object that doesn't
>> require a save file.
>>
>> Ideally, we should be able to build out mock objects of most things.
>> If we can't, that might be an indicator that refactoring is needed. If
>> nothing else, it should spawn some javadoc about why the object is
>> difficult/impossible to test.
>>
>
> The major issue I see why people are reluctant to write unit tests for
> existing code in Rails currently, is that it is much work to do with no
> immediate reward. This is very similar to ask someone for writing
> documentation for existing code.
>

Yup.  Mostly I was pointing out that we have a starting point. We can
build on that incrementally.

I didn't mean to make it sound like you should do all of the work. It
was more that, now we can consider building tests as we touch old code
and/or as we write new code.

These things are always much easier if we tackle them a little bit at
a time, as we work on other things.

> For the integration tests above I could leverage on existing mechanisms:
> The action stack (already used for the save files) to replay games and the
> ReportBuffer, that collects the game report. Thus easy to do.
>
> My goal for working on this project is to use it for playing 18xx: That is the
> basis for all my contributions so far: We usually play with a real map =>
> nomap Mode. I want to be able to make corrections on the fly => correction
> actions. I like 1889 => 1889!
>
> And why the tests now? My next focus will be 1870. 1870 adds some weird stuff
> to the stockround. For this I would like to refactor this class to make it
> modular. Therefore I need refactoring support, thus the automated testing.
> Very simple.
>

That's totally okay by me. I'm not trying to suggest that you do it
differently.

Work on the things that interest you. That's how we've gotten this far. :-)

>> How about this:
>>
>> Save files: {game name}-{current round}-{unique identifier}.save
>> Index file: savegame-tests.txt
>> The save game will simply be something like 1870-OR5-1.save,
>> 1830-SR2-4.save, etc.
>
>
> The extension for the save files can be changed in test.properties, but I
> prefer the .rails extension to the .save (which could be anything).
>
> I would suggest then to reverse the order and add a game end indicator:
>
> {game name}_{unique identifier}_{current round}{[_e,_b]}
>
>  where e indicates normal end (bank out of money), b indicates bankrupt.
>
> Examples: 1830_4_sr2.rails, 1830_4_or7_e.rails, 1830_3_or5_b.rails
>


That's fine. I'm less concerned about the extension as I am about
trying to fit too much information into the file name.


>>
>> Then, the index file will track our notes about each saved game, and
>> what tests it applies to.  I think there's going to need to be more
>> information than can be contained within the filename itself.
>
>>
>> Alternately, we can have each saved game with it's own
>> {conventiion}.txt file that documents this, but that may be overkill.
>>
>> Of course, all of this should probably go under /test/savedgames, or
>> something similarly named and organized away from the rest of the
>> code.
>>
>
> That is how it is laid out: Root save directory can be changed in
> test.properties. Currently set to test/data
>

Perfect.  Sounds like you're on the right track. :-)

---Brett.

Re: [Rails-devel] Automatic route calculation

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

Alex:
Some more comments on a potential test for automatic route calculation:

I think there is no need for one of the more "exotic" types (18US, 18C2C, 
1844) to create a (reasonable) difficult scenario. 

It is easy to create a quite involved track layout with maps and tiles of one 
of titles already implemented in Rails (for this even the partially 
implemented 1835 or 1870 would work).  

Then rails could supply:

* A map (here I mean the collection) with map hexes and tiles. From my point 
of view it is still open, how it is converted to the graph you need to run 
your algorithm.

* The trains available to the one company could be easily changed. And we can 
make things more difficult by requesting scenarios, which are not possible in 
1870: For example running a  8, 10 and 12 at once.

* I think, that there is no need for tokens so far (either simply assume that 
there are none (which would allow even more connections than usual) or create 
a network that is usually available to one company after considering the 
effects of tokening, if we want to built a more realistic test case).

If no other wants to jump in, I would volunteer to create such a network on 
the 1870 map.

Stefan


>
> >> Perhaps it can be tested? There is no need to have complete support of
> >> such games in Rails to make experiment. We could create a graph
> >> representing "difficult case" and run algorithm on it.
> >
> > Yes, though it could take time to manually build the graph the way your
> > algorithm wants it.
> >
> >> > Some I would look at would be 18US, 18C2C (for sheer size and the
> >>
> >> ability
> >>
> >> > for a company to run lots of large trains), 1844 (which adds tunnels
> >>
> >> and
> >>
> >> > mountains that affect the route score), and 1860.
> >>
> >> Unfortunately, I don't own any of them :(
> >
> > The complete rules are available for at least 18US and 1844, and ps18xx
> > includes the map/tiles for all of them.
>
> Are there some cases you would consider examples of "difficult" ones that
> are available in some kind of format? From some PBEM games perhaps? It
> might be relatively easy to convert them into the graph I need. And it's
> difficult to get an impression of what realistic end game layout would be
> without playing the game.

Re: [Rails-devel] Automated testing for Rails

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

Brett,
see my comments below.
Stefan

> Excellent. We've needed this for a while, and this is a good start.

Thanks. I am happy to have that too, as it now easier to refactor classes.
>
> This is fine as a starting point, but it's not how most traditional
> automated testing works.

Yes and no. It is automated testing, but obviously it is not (traditiional) 
unit testing, but belongs to the class of integration or system tests. But 
all are equally important.

>
> One goal that I hope we work toward is building on this foundation by
> developing unit and regression tests for each object that doesn't
> require a save file.
>
> Ideally, we should be able to build out mock objects of most things.
> If we can't, that might be an indicator that refactoring is needed. If
> nothing else, it should spawn some javadoc about why the object is
> difficult/impossible to test.
>

The major issue I see why people are reluctant to write unit tests for 
existing code in Rails currently, is that it is much work to do with no 
immediate reward. This is very similar to ask someone for writing 
documentation for existing code.

For the integration tests above I could leverage on existing mechanisms: 
The action stack (already used for the save files) to replay games and the 
ReportBuffer, that collects the game report. Thus easy to do.

My goal for working on this project is to use it for playing 18xx: That is the 
basis for all my contributions so far: We usually play with a real map => 
nomap Mode. I want to be able to make corrections on the fly => correction 
actions. I like 1889 => 1889!

And why the tests now? My next focus will be 1870. 1870 adds some weird stuff 
to the stockround. For this I would like to refactor this class to make it 
modular. Therefore I need refactoring support, thus the automated testing. 
Very simple.

> How about this:
>
> Save files: {game name}-{current round}-{unique identifier}.save
> Index file: savegame-tests.txt
> The save game will simply be something like 1870-OR5-1.save,
> 1830-SR2-4.save, etc.


The extension for the save files can be changed in test.properties, but I 
prefer the .rails extension to the .save (which could be anything).

I would suggest then to reverse the order and add a game end indicator:

{game name}_{unique identifier}_{current round}{[_e,_b]}

 where e indicates normal end (bank out of money), b indicates bankrupt.

Examples: 1830_4_sr2.rails, 1830_4_or7_e.rails, 1830_3_or5_b.rails

>
> Then, the index file will track our notes about each saved game, and
> what tests it applies to.  I think there's going to need to be more
> information than can be contained within the filename itself.

>
> Alternately, we can have each saved game with it's own
> {conventiion}.txt file that documents this, but that may be overkill.
>
> Of course, all of this should probably go under /test/savedgames, or
> something similarly named and organized away from the rest of the
> code.
>

That is how it is laid out: Root save directory can be changed in 
test.properties. Currently set to test/data

Re: [Rails-devel] Automated testing for Rails

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

Erik:
- Reversing the tree makes sense. 

- For faked games there is the category test_cases.
For testing reasons it does not matter if revenues are faked, as long as the 
game runs through. I did the same: Testing game end is easy if you have one 
company pay out $20.000 in OR 2.

In any case it makes sense that you add your test save files yourself to the 
tree. 

And I promise that I will never trust any of your save files...

Stefan

On Tuesday 23 March 2010 21:18:21 Erik Vos wrote:
> Looks very good to me.
>
> I generally agree with your proposals. Just one remark: can't the tree
> hierarchy be better reversed?
> For what it's worth: I would tend to select a game first, then look what
> saved files/test cases exist for that game.
>
> And a warning: most of the saved files I have sent you off-list do NOT
> constitute valid games.
> The revenues have often been faked, either to construct a particular test
> case, or just because I was lazy.
> Never trust my saved files!
>
> Erik.
>
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Tuesday 23 March 2010 19:53
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] Automated testing for Rails
>
> I have added automated regression testing for Rails in CVS.
>
> How does it work:
> * For a set of Rails save files (which are known that they are correct)
> game
>
> reports are created and stored alongside with the save files.
> Then each time the tests are run, each game is replayed by Rails on the new
> code base and the game reports are compared to the stored ones.
>
> * Anytime a difference in the game reports occurs, this test reports the
> error
> and displays the first line, where the game reports deviate.
>
> More instructions and comments for developers see attached text file. In
> addition I have added an example report of a current test run.
>
> Stefan
>
> I have not uploaded my preliminary test suite so far, as I want to ask for
> opinion on the tree structure first.
>
> My proposal is:
>
> Convention for file names:
> {18xx}_{noMap - if used}_{author}_{nb of players}_{end round}_{end
> condition}_{special remarks}
>
> -> Bug reports
> The game name should include the bug number if possible.
> below that with categories, that still have to be defined.
>
> -> Finished games
> real plays
> below that with one folder for each 18xx
>
> -> Pbem games
> currently running pbem games
> below that with one folder for each 18xx
>
> -> Test cases
> hand crafted settings for specific testing
> below that with one folder for each 18xx
>
> -> Test games
> simulated games
> below that with one folder for each 18xx
>
>
>
> ---------------------------------------------------------------------------
>--- Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Automated testing for Rails

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

On Tue, Mar 23, 2010 at 11:52 AM, Stefan Frey <ste...@we...> wrote:
> I have added automated regression testing for Rails in CVS.

Excellent. We've needed this for a while, and this is a good start.

> How does it work:
> * For a set of Rails save files (which are known that they are correct) game
> reports are created and stored alongside with the save files.
> Then each time the tests are run, each game is replayed by Rails on the new
> code base and the game reports are compared to the stored ones.
>

This is fine as a starting point, but it's not how most traditional
automated testing works.

One goal that I hope we work toward is building on this foundation by
developing unit and regression tests for each object that doesn't
require a save file.

Ideally, we should be able to build out mock objects of most things.
If we can't, that might be an indicator that refactoring is needed. If
nothing else, it should spawn some javadoc about why the object is
difficult/impossible to test.

> My proposal is:
>
> Convention for file names:
> {18xx}_{noMap - if used}_{author}_{nb of players}_{end round}_{end
> condition}_{special remarks}

This filenaming convention is going to be very unwieldy.

How about this:

Save files: {game name}-{current round}-{unique identifier}.save
Index file: savegame-tests.txt

The save game will simply be something like 1870-OR5-1.save,
1830-SR2-4.save, etc.

Then, the index file will track our notes about each saved game, and
what tests it applies to.  I think there's going to need to be more
information than can be contained within the filename itself.

Alternately, we can have each saved game with it's own
{conventiion}.txt file that documents this, but that may be overkill.

Of course, all of this should probably go under /test/savedgames, or
something similarly named and organized away from the rest of the
code.

---Brett.