rails-devel — List for discussion of Rails development

[Rails-devel] Phase management

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

I have started with implementing my plan to refactor phase management. It's
my intention that the old and new ways to configure phases will keep
existing in parallel for a while, so that I can use 18TN as a guinea pig
without affecting other games.  Not sure if that's going to work, but we'll
see.

Phase actions have not been done yet, so the only effect is that the 18TN
game status will now show Phase 3½ and 6½ where applicable. The 4-train
obsolescence still works the old way. 
(I found to my surprise that obsolescence was still configured for the 2-
and 3-trains as well.  I have removed that now).

Game.xml now has 

        <TrainType name="3" majorStops="3" cost="180" quantity="5">
	<NewPhase phaseName="3"/>   <!-- trainIndex defaults to "1"-->
	<NewPhase phaseName="3½" trainIndex="4"/>
        </TrainType>

and

        <TrainType name="6" majorStops="6" cost="630" quantity="2"
rustedTrain="3">
                <NewPhase phaseName="6"/>
                <NewPhase phaseName="6½" trainIndex="2"/>
                <Sub index="2" rustedTrain="4"/>
        </TrainType>

The "rustedTrain" attributes and the <Sub> tag will be removed as further
implementation proceeds.

Erik.

Re: [Rails-devel] Refactored loading code

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

I've been using it successfully, it seems to work fairly well, the
only difficulty I've had has been a social one unfortunately, in that
it's difficult to persuade other people I play with to keep the game
window open and use the autoplay system.  Certainly for pbem games,
most seem to prefer to use the reload feature manually rather than the
autoreload, so I've not had a chance to test it in anger.

On 6 July 2011 10:04, Erik Vos <eri...@xs...> wrote:
> I can report that even Autosave/load still works (as far as it ever did).
> But, as I have not got any feedback yet on this new feature, its further
> development doesn't have a high priority for me right now.
>
> Erik.
>
>> -----Oorspronkelijk bericht-----
>> Van: Stefan Frey [mailto:ste...@we...]
>> Verzonden: woensdag 6 juli 2011 7:45
>> Aan: Development list for Rails: an 18xx game
>> Onderwerp: Re: [Rails-devel] Refactored loading code
>>
>> Further steps on refactoring:
>>
>> There is a new class that combines all fields required for gameIO into
>> rails.util.gameData and renamed the gameLoader into gameFileIO as it now
>> combines load and save functions.
>>
>> Please do some further checks on your own that load and save still works
> as
>> intended in all situations.
>>
>> One little bit is still missing: ListAndFixSavedFile is not able to save
> games
>> currently, only loading.
>>
>> Stefan
>>
>> On Tuesday, July 05, 2011 07:59:49 pm brett lentz wrote:
>> > I was actually thinking something similar this weekend...
>> >
>> > No objections here. :-)
>> >
>> > ---Brett.
>> >
>> > On Tue, Jul 5, 2011 at 10:49 AM, Erik Vos <eri...@xs...> wrote:
>> > > Ah, good stuff.  I was already occasionally running into problems
>> > > with loading files into ListAndFixSavedFiles.
>> > >
>> > > As you may or may not have noticed, since some time I'm pretty
>> > > meticulously creating entries in the Wiki Change Log for all my
>> > > commits (except very trivial ones).  I don't know if I can expect
>> > > the same from Brett and you (as we have seen earlier today, I'm not
>> > > really the right person to request discipline). In any case, I have
>> > > just created simple entries for the recent commits 1602-1604 by the
>> > > two of you.  Feel free to  correct or expand.
>> > >
>> > > As for packaging, I would prefer to reserve rails.util for Rails
>> > > classes only, and put all external main programs into tools.  That
>> > > would mean that ListAndFixSavedFiles should move from rails.util to
>> > > tools. Any objections?
>> > >
>> > > I just noticed that we have TWO Util classes, one in rails.util and
>> > > one in tools.  Does anyone know a good reason for that duplication?
>> > >  Otherwise I would propose to merge the two into rails.util.Util.
>> > >
>> > > Erik.
>> > >
>> > >> -----Oorspronkelijk bericht-----
>> > >> Van: Stefan Frey [mailto:ste...@we...]
>> > >> Verzonden: dinsdag 5 juli 2011 19:11
>> > >> Aan: 'Development list for Rails: an 18xx game'
>> > >> Onderwerp: [Rails-devel] Refactored loading code
>> > >>
>> > >> Brett & Erik,
>> > >> some time ago I started to refactor the game loading code in one
>> > >> class to
>> > >
>> > > get
>> > >
>> > >> the ListAndFixSavedFiles utility adjusted to the new comments.
>> > >>
>> > >> To avoid more incompatibilities from the started refactoring from
>> > >> Brett
>> > >
>> > > now I
>> > >
>> > >> thought to adjust the code to include the new reload functionality
>> > >> of Erik
>> > >
>> > > to
>> > >
>> > >> be able to commit those changes.
>> > >>
>> > >> Nearly all loading functionality has been moved to a new GameLoader
>> > >> class
>> > >
>> > > in
>> > >
>> > >> rails.util package. The load function in Game, GameManager and
>> > >> ListAndFixSavedFiles now all make use of a a GameLoader object.
>> > >>
>> > >> I have also added a line to the reload error message that asks the
>> > >> user to submit the corrupt save file to the Rails user list for bug
>> > >> tracking. If
>> > >
>> > > you think
>> > >
>> > >> that is not a good idea, simply remove that text from
>> > >> LocalisedProperties.
>> > >>
>> > >> Stefan
>> > >
>> > > --------------------------------------------------------------------
>> > > -----
>> > > --- --
>> > >
>> > >> All of the data generated in your IT infrastructure is seriously
>> > >> valuable. Why? It contains a definitive record of application
>> > >> performance, security threats, fraudulent activity, and more.
>> > >> Splunk takes this data and makes sense of it. IT sense. And common
>> sense.
>> > >> http://p.sf.net/sfu/splunk-d2d-c2
>> > >> _______________________________________________
>> > >> Rails-devel mailing list
>> > >> Rai...@li...
>> > >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> > >
>> > > --------------------------------------------------------------------
>> > > -----
>> > > ----- All of the data generated in your IT infrastructure is
>> > > seriously valuable. Why? It contains a definitive record of
>> > > application performance, security threats, fraudulent activity, and
>> > > more. Splunk takes this data and makes sense of it. IT sense. And
>> common sense.
>> > > http://p.sf.net/sfu/splunk-d2d-c2
>> > > _______________________________________________
>> > > Rails-devel mailing list
>> > > Rai...@li...
>> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>> > ----------------------------------------------------------------------
>> > -----
>> > --- All of the data generated in your IT infrastructure is seriously
>> > valuable. Why? It contains a definitive record of application
>> > performance, security threats, fraudulent activity, and more. Splunk
>> > takes this data and makes sense of it. IT sense. And common sense.
>> > http://p.sf.net/sfu/splunk-d2d-c2
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
> ----------------------------------------------------------------------------
> --
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Refactored loading code

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

This makes me raise another question that has been on my mind for a long
time: should we partially refactor the rails.game package into smaller
subpackages?
Examples: rails.game.round for all Round (sub)classes, rails.game.train,
rails.game.map (hexes and tiles), perhaps others.  

I don't have strong feelings about it, it's just that rails.game is growing
a bit largish.

Erik.

> -----Oorspronkelijk bericht-----
> Van: brett lentz [mailto:bre...@gm...]
> Verzonden: dinsdag 5 juli 2011 19:39
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] Refactored loading code
> 
> That looks good to me.
> 
> My overall goal with my refactoring is to remove the need for the
rails.game
> package to know about lower-level details, such as XML parsing.
> 
> Moving the classes that need to know about how to load/save game files
> outside of rails.game.* aligns very well with this goal. :-)
> 
> ---Brett.
> 
> 
> 
> On Tue, Jul 5, 2011 at 10:11 AM, Stefan Frey <ste...@we...> wrote:
> > Brett & Erik,
> > some time ago I started to refactor the game loading code in one class
> > to get the ListAndFixSavedFiles utility adjusted to the new comments.
> >
> > To avoid more incompatibilities from the started refactoring from
> > Brett now I thought to adjust the code to include the new reload
> > functionality of Erik to be able to commit those changes.
> >
> > Nearly all loading functionality has been moved to a new GameLoader
> > class in rails.util package. The load function in Game, GameManager
> > and ListAndFixSavedFiles now all make use of a a GameLoader object.
> >
> > I have also added a line to the reload error message that asks the
> > user to submit the corrupt save file to the Rails user list for bug
> > tracking. If you think that is not a good idea, simply remove that
> > text from LocalisedProperties.
> >
> > Stefan
> >
> 
>
----------------------------------------------------------------------------
--
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Refactored loading code

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

I can report that even Autosave/load still works (as far as it ever did).  
But, as I have not got any feedback yet on this new feature, its further
development doesn't have a high priority for me right now.

Erik.

> -----Oorspronkelijk bericht-----
> Van: Stefan Frey [mailto:ste...@we...]
> Verzonden: woensdag 6 juli 2011 7:45
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] Refactored loading code
> 
> Further steps on refactoring:
> 
> There is a new class that combines all fields required for gameIO into
> rails.util.gameData and renamed the gameLoader into gameFileIO as it now
> combines load and save functions.
> 
> Please do some further checks on your own that load and save still works
as
> intended in all situations.
> 
> One little bit is still missing: ListAndFixSavedFile is not able to save
games
> currently, only loading.
> 
> Stefan
> 
> On Tuesday, July 05, 2011 07:59:49 pm brett lentz wrote:
> > I was actually thinking something similar this weekend...
> >
> > No objections here. :-)
> >
> > ---Brett.
> >
> > On Tue, Jul 5, 2011 at 10:49 AM, Erik Vos <eri...@xs...> wrote:
> > > Ah, good stuff.  I was already occasionally running into problems
> > > with loading files into ListAndFixSavedFiles.
> > >
> > > As you may or may not have noticed, since some time I'm pretty
> > > meticulously creating entries in the Wiki Change Log for all my
> > > commits (except very trivial ones).  I don't know if I can expect
> > > the same from Brett and you (as we have seen earlier today, I'm not
> > > really the right person to request discipline). In any case, I have
> > > just created simple entries for the recent commits 1602-1604 by the
> > > two of you.  Feel free to  correct or expand.
> > >
> > > As for packaging, I would prefer to reserve rails.util for Rails
> > > classes only, and put all external main programs into tools.  That
> > > would mean that ListAndFixSavedFiles should move from rails.util to
> > > tools. Any objections?
> > >
> > > I just noticed that we have TWO Util classes, one in rails.util and
> > > one in tools.  Does anyone know a good reason for that duplication?
> > >  Otherwise I would propose to merge the two into rails.util.Util.
> > >
> > > Erik.
> > >
> > >> -----Oorspronkelijk bericht-----
> > >> Van: Stefan Frey [mailto:ste...@we...]
> > >> Verzonden: dinsdag 5 juli 2011 19:11
> > >> Aan: 'Development list for Rails: an 18xx game'
> > >> Onderwerp: [Rails-devel] Refactored loading code
> > >>
> > >> Brett & Erik,
> > >> some time ago I started to refactor the game loading code in one
> > >> class to
> > >
> > > get
> > >
> > >> the ListAndFixSavedFiles utility adjusted to the new comments.
> > >>
> > >> To avoid more incompatibilities from the started refactoring from
> > >> Brett
> > >
> > > now I
> > >
> > >> thought to adjust the code to include the new reload functionality
> > >> of Erik
> > >
> > > to
> > >
> > >> be able to commit those changes.
> > >>
> > >> Nearly all loading functionality has been moved to a new GameLoader
> > >> class
> > >
> > > in
> > >
> > >> rails.util package. The load function in Game, GameManager and
> > >> ListAndFixSavedFiles now all make use of a a GameLoader object.
> > >>
> > >> I have also added a line to the reload error message that asks the
> > >> user to submit the corrupt save file to the Rails user list for bug
> > >> tracking. If
> > >
> > > you think
> > >
> > >> that is not a good idea, simply remove that text from
> > >> LocalisedProperties.
> > >>
> > >> Stefan
> > >
> > > --------------------------------------------------------------------
> > > -----
> > > --- --
> > >
> > >> All of the data generated in your IT infrastructure is seriously
> > >> valuable. Why? It contains a definitive record of application
> > >> performance, security threats, fraudulent activity, and more.
> > >> Splunk takes this data and makes sense of it. IT sense. And common
> sense.
> > >> http://p.sf.net/sfu/splunk-d2d-c2
> > >> _______________________________________________
> > >> Rails-devel mailing list
> > >> Rai...@li...
> > >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> > >
> > > --------------------------------------------------------------------
> > > -----
> > > ----- All of the data generated in your IT infrastructure is
> > > seriously valuable. Why? It contains a definitive record of
> > > application performance, security threats, fraudulent activity, and
> > > more. Splunk takes this data and makes sense of it. IT sense. And
> common sense.
> > > http://p.sf.net/sfu/splunk-d2d-c2
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > ----------------------------------------------------------------------
> > -----
> > --- All of the data generated in your IT infrastructure is seriously
> > valuable. Why? It contains a definitive record of application
> > performance, security threats, fraudulent activity, and more. Splunk
> > takes this data and makes sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-d2d-c2
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
>
----------------------------------------------------------------------------
--
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Refactored loading code

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

Further steps on refactoring:

There is a new class that combines all fields required for gameIO into 
rails.util.gameData and renamed the gameLoader into gameFileIO as it now 
combines load and save functions.

Please do some further checks on your own that load and save still works as 
intended in all situations.

One little bit is still missing: ListAndFixSavedFile is not able to save games 
currently, only loading.

Stefan

On Tuesday, July 05, 2011 07:59:49 pm brett lentz wrote:
> I was actually thinking something similar this weekend...
> 
> No objections here. :-)
> 
> ---Brett.
> 
> On Tue, Jul 5, 2011 at 10:49 AM, Erik Vos <eri...@xs...> wrote:
> > Ah, good stuff.  I was already occasionally running into problems with
> > loading files into ListAndFixSavedFiles.
> > 
> > As you may or may not have noticed, since some time I'm pretty
> > meticulously creating entries in the Wiki Change Log for all my commits
> > (except very trivial ones).  I don't know if I can expect the same from
> > Brett and you (as we have seen earlier today, I'm not really the right
> > person to request discipline). In any case, I have just created simple
> > entries for the recent commits 1602-1604 by the two of you.  Feel free
> > to  correct or expand.
> > 
> > As for packaging, I would prefer to reserve rails.util for Rails classes
> > only, and put all external main programs into tools.  That would mean
> > that ListAndFixSavedFiles should move from rails.util to tools. Any
> > objections?
> > 
> > I just noticed that we have TWO Util classes, one in rails.util and one
> > in tools.  Does anyone know a good reason for that duplication?
> >  Otherwise I would propose to merge the two into rails.util.Util.
> > 
> > Erik.
> > 
> >> -----Oorspronkelijk bericht-----
> >> Van: Stefan Frey [mailto:ste...@we...]
> >> Verzonden: dinsdag 5 juli 2011 19:11
> >> Aan: 'Development list for Rails: an 18xx game'
> >> Onderwerp: [Rails-devel] Refactored loading code
> >> 
> >> Brett & Erik,
> >> some time ago I started to refactor the game loading code in one class
> >> to
> > 
> > get
> > 
> >> the ListAndFixSavedFiles utility adjusted to the new comments.
> >> 
> >> To avoid more incompatibilities from the started refactoring from Brett
> > 
> > now I
> > 
> >> thought to adjust the code to include the new reload functionality of
> >> Erik
> > 
> > to
> > 
> >> be able to commit those changes.
> >> 
> >> Nearly all loading functionality has been moved to a new GameLoader
> >> class
> > 
> > in
> > 
> >> rails.util package. The load function in Game, GameManager and
> >> ListAndFixSavedFiles now all make use of a a GameLoader object.
> >> 
> >> I have also added a line to the reload error message that asks the user
> >> to submit the corrupt save file to the Rails user list for bug
> >> tracking. If
> > 
> > you think
> > 
> >> that is not a good idea, simply remove that text from
> >> LocalisedProperties.
> >> 
> >> Stefan
> > 
> > -------------------------------------------------------------------------
> > --- --
> > 
> >> All of the data generated in your IT infrastructure is seriously
> >> valuable. Why? It contains a definitive record of application
> >> performance, security threats, fraudulent activity, and more. Splunk
> >> takes this data and makes sense of it. IT sense. And common sense.
> >> http://p.sf.net/sfu/splunk-d2d-c2
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> > 
> > -------------------------------------------------------------------------
> > ----- All of the data generated in your IT infrastructure is seriously
> > valuable. Why? It contains a definitive record of application
> > performance, security threats, fraudulent activity, and more. Splunk
> > takes this data and makes sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-d2d-c2
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- All of the data generated in your IT infrastructure is seriously
> valuable. Why? It contains a definitive record of application performance,
> security threats, fraudulent activity, and more. Splunk takes this data
> and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Train management & dual trains

[Scott P. <sc...@re...>]

I attached a few--I have more that were not quite played to completion
that passed.

On Tue, Jul 5, 2011 at 6:03 AM, Phil Davies <de...@gm...> wrote:
> If you need more save files of games played to completion, I can
> always provide more.

Re: [Rails-devel] Refactored loading code

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

I was actually thinking something similar this weekend...

No objections here. :-)

---Brett.


On Tue, Jul 5, 2011 at 10:49 AM, Erik Vos <eri...@xs...> wrote:
> Ah, good stuff.  I was already occasionally running into problems with
> loading files into ListAndFixSavedFiles.
>
> As you may or may not have noticed, since some time I'm pretty meticulously
> creating entries in the Wiki Change Log for all my commits (except very
> trivial ones).  I don't know if I can expect the same from Brett and you (as
> we have seen earlier today, I'm not really the right person to request
> discipline). In any case, I have just created simple entries for the recent
> commits 1602-1604 by the two of you.  Feel free to  correct or expand.
>
> As for packaging, I would prefer to reserve rails.util for Rails classes
> only, and put all external main programs into tools.  That would mean that
> ListAndFixSavedFiles should move from rails.util to tools. Any objections?
>
> I just noticed that we have TWO Util classes, one in rails.util and one in
> tools.  Does anyone know a good reason for that duplication?  Otherwise I
> would propose to merge the two into rails.util.Util.
>
> Erik.
>
>> -----Oorspronkelijk bericht-----
>> Van: Stefan Frey [mailto:ste...@we...]
>> Verzonden: dinsdag 5 juli 2011 19:11
>> Aan: 'Development list for Rails: an 18xx game'
>> Onderwerp: [Rails-devel] Refactored loading code
>>
>> Brett & Erik,
>> some time ago I started to refactor the game loading code in one class to
> get
>> the ListAndFixSavedFiles utility adjusted to the new comments.
>>
>> To avoid more incompatibilities from the started refactoring from Brett
> now I
>> thought to adjust the code to include the new reload functionality of Erik
> to
>> be able to commit those changes.
>>
>> Nearly all loading functionality has been moved to a new GameLoader class
> in
>> rails.util package. The load function in Game, GameManager and
>> ListAndFixSavedFiles now all make use of a a GameLoader object.
>>
>> I have also added a line to the reload error message that asks the user to
>> submit the corrupt save file to the Rails user list for bug tracking. If
> you think
>> that is not a good idea, simply remove that text from LocalisedProperties.
>>
>> Stefan
>>
>>
> ----------------------------------------------------------------------------
> --
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Refactored loading code

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

Ah, good stuff.  I was already occasionally running into problems with
loading files into ListAndFixSavedFiles.

As you may or may not have noticed, since some time I'm pretty meticulously
creating entries in the Wiki Change Log for all my commits (except very
trivial ones).  I don't know if I can expect the same from Brett and you (as
we have seen earlier today, I'm not really the right person to request
discipline). In any case, I have just created simple entries for the recent
commits 1602-1604 by the two of you.  Feel free to  correct or expand.

As for packaging, I would prefer to reserve rails.util for Rails classes
only, and put all external main programs into tools.  That would mean that
ListAndFixSavedFiles should move from rails.util to tools. Any objections?  

I just noticed that we have TWO Util classes, one in rails.util and one in
tools.  Does anyone know a good reason for that duplication?  Otherwise I
would propose to merge the two into rails.util.Util.

Erik.

> -----Oorspronkelijk bericht-----
> Van: Stefan Frey [mailto:ste...@we...]
> Verzonden: dinsdag 5 juli 2011 19:11
> Aan: 'Development list for Rails: an 18xx game'
> Onderwerp: [Rails-devel] Refactored loading code
> 
> Brett & Erik,
> some time ago I started to refactor the game loading code in one class to
get
> the ListAndFixSavedFiles utility adjusted to the new comments.
> 
> To avoid more incompatibilities from the started refactoring from Brett
now I
> thought to adjust the code to include the new reload functionality of Erik
to
> be able to commit those changes.
> 
> Nearly all loading functionality has been moved to a new GameLoader class
in
> rails.util package. The load function in Game, GameManager and
> ListAndFixSavedFiles now all make use of a a GameLoader object.
> 
> I have also added a line to the reload error message that asks the user to
> submit the corrupt save file to the Rails user list for bug tracking. If
you think
> that is not a good idea, simply remove that text from LocalisedProperties.
> 
> Stefan
> 
>
----------------------------------------------------------------------------
--
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Refactored loading code

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

That looks good to me.

My overall goal with my refactoring is to remove the need for the
rails.game package to know about lower-level details, such as XML
parsing.

Moving the classes that need to know about how to load/save game files
outside of rails.game.* aligns very well with this goal. :-)

---Brett.



On Tue, Jul 5, 2011 at 10:11 AM, Stefan Frey <ste...@we...> wrote:
> Brett & Erik,
> some time ago I started to refactor the game loading code in one class to get
> the ListAndFixSavedFiles utility adjusted to the new comments.
>
> To avoid more incompatibilities from the started refactoring from Brett now I
> thought to adjust the code to include the new reload functionality of Erik to
> be able to commit those changes.
>
> Nearly all loading functionality has been moved to a new GameLoader class in
> rails.util package. The load function in Game, GameManager and
> ListAndFixSavedFiles now all make use of a a GameLoader object.
>
> I have also added a line to the reload error message that asks the user to
> submit the corrupt save file to the Rails user list for bug tracking. If you
> think that is not a good idea, simply remove that text from
> LocalisedProperties.
>
> Stefan
>

[Rails-devel] Refactored loading code

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

Brett & Erik,
some time ago I started to refactor the game loading code in one class to get 
the ListAndFixSavedFiles utility adjusted to the new comments.

To avoid more incompatibilities from the started refactoring from Brett now I 
thought to adjust the code to include the new reload functionality of Erik to 
be able to commit those changes.

Nearly all loading functionality has been moved to a new GameLoader class in 
rails.util package. The load function in Game, GameManager and 
ListAndFixSavedFiles now all make use of a a GameLoader object.

I have also added a line to the reload error message that asks the user to 
submit the corrupt save file to the Rails user list for bug tracking. If you 
think that is not a good idea, simply remove that text from 
LocalisedProperties.

Stefan

Re: [Rails-devel] Train management & dual trains

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

If you need more save files of games played to completion, I can
always provide more.

On 5 July 2011 12:01, Erik Vos <eri...@xs...> wrote:
> Stefan,
>
> Wasn't it the case that all or most of the old tests did no longer work?  Or
> have you fixed that in the meantime?
>
> Obviously, the value of regression testing hinges upon the correctness and
> reach of the test set, and I didn't have a high opinion of our original set
> on both accounts.
> If I remember correctly, soon after you created this test set, I found it
> starting to fall apart, and I apologize for not having spent any effort to
> fix it while you were away. To me, JUnit testing was new, and I'm still not
> used to it.
>
> However, I agree that it's a good thing to have and use such a test set, so
> I'll have another look at it. A good and complete Wiki page would definitely
> help a lot.
>
> As to the test set, I think this should be a mix of complete games and
> specially constructed test cases.  I only can provide the latter, as I don't
> use Rails for playing myself.
> Scott Petersen has recently (22 June) reported that he had successfully run
> a series of complete games of various kinds after I had done the Train
> management changes.  Perhaps Scott could be persuaded to make his files
> available for regression testing?
>
> I will try to familiarize myself again with this stuff, and then try to
> select some useful test cases for addition to the set. The name of such
> specially constructed saved files should somehow indicate their purpose.
>
> Erik.
>
>> -----Oorspronkelijk bericht-----
>> Van: Stefan Frey [mailto:ste...@we...]
>> Verzonden: dinsdag 5 juli 2011 7:47
>> Aan: Development list for Rails: an 18xx game
>> Onderwerp: Re: [Rails-devel] Train management & dual trains
>>
>> Erik:
>> sorry I forgot to reply to your question on automated tests recently:
>> The test cases are dependent on the game report, but the can be
>> reinitialized easily by a few mouse clicks (see the document before).
>> So the short answer: No the test cases do not depend on minor detail
>> changes, as long as the use case is followed. And they can easily be
>> reinitialized again, but all bugs that got in in the mean time will stay
>> undetected.
>>
>> Thus the use case for changes in the game report is:
>> A) Check that all test cases report green.
>> B) Make the code change that alters the game report.
>> {C) All test cases will report red.}
>> D) Reinitialize all test cases by selecting the root test directory.
>> {E) All test cases will report green.}
>>
>> This is not required if you change only the text in LocalizedProperties,
> as the
>> test is language independent.
>>
>> However after you ignored the test cases for so long (and I did not run
> the
>> tests myself), that I wanted to figure out first, why the did not run at
> all.
>> And it can always be related to changes in the game report or due to
>> undetected bugs.
>>
>> But as the report changed the undetected bugs (if there are any left) will
> stay
>> undetected, as I will simply reinitialize the test cases and all will show
> green
>> again.
>>
>> I still hope I could convince you to use the tests, as they are the only
> chance
>> to capture bugs especially for those games which are not implemented by
>> yourself (as in the 1889 example before).
>>
>> Stefan
>>
>>
>> >
>> > I can't remember any such change, so I can't give a specific reason,
>> > but it's well possible that I have done that at some point.
>> > However, if our test cases are dependent on such details, I'm not very
>> > happy about that.
>> > Improvements must remain possible. Very recently I added a report line
>> > about President's cash contributed in  emergency train buying - this
>> > was completely unreported so far.
>> >
>> > I suspect that by now many old test cases will appear to be out of
>> > date for other reasons too.  Almost all of my 18EU cases are invalid
>> > and must be edited because one redundant Skip action had been removed
>> > at some point.  I suppose we should revisit that whole test set.
>> > That's a separate subproject in its own right...
>> >
>> > I attach two test cases that I have used intensively to test the train
>> > management changes against. These two cases cover a lot of ground.
>> > Unfortunately, the 18EU map is wrong because it still originates from
>> > the time before I rotated tile #4, so all these tiles are shown
>> > oriented wrongly. Again, this applies to most of my 18EU test cases. I
>> > suppose I will have to write a special conversion program to fix that...
>> >
>> > > There is one (non-official) test however, that already stops with a
>> >
>> > null-point
>> >
>> > > exception on buying a train. Save file is attached.
>> >
>> > That's caused by a bug in the 1830 Pere Marquette configuration. The
>> > 6-train releases a 7-train, which is not defined for that variant.
>> > This bug must have crept in while recently adding many other variants.
>> > I don't have the PM rules, but from your original commit I conclude,
>> > that PM has no 7-train, so I have fixed it accordingly.  I have also
>> > added checks to catch such misfits during XML parsing.
>> >
>> > Erik.
>>
>>
> ----------------------------------------------------------------------------
> --
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Train management & dual trains

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

Stefan,

Wasn't it the case that all or most of the old tests did no longer work?  Or
have you fixed that in the meantime?

Obviously, the value of regression testing hinges upon the correctness and
reach of the test set, and I didn't have a high opinion of our original set
on both accounts. 
If I remember correctly, soon after you created this test set, I found it
starting to fall apart, and I apologize for not having spent any effort to
fix it while you were away. To me, JUnit testing was new, and I'm still not
used to it. 

However, I agree that it's a good thing to have and use such a test set, so
I'll have another look at it. A good and complete Wiki page would definitely
help a lot.

As to the test set, I think this should be a mix of complete games and
specially constructed test cases.  I only can provide the latter, as I don't
use Rails for playing myself. 
Scott Petersen has recently (22 June) reported that he had successfully run
a series of complete games of various kinds after I had done the Train
management changes.  Perhaps Scott could be persuaded to make his files
available for regression testing?  

I will try to familiarize myself again with this stuff, and then try to
select some useful test cases for addition to the set. The name of such
specially constructed saved files should somehow indicate their purpose.

Erik.
  
> -----Oorspronkelijk bericht-----
> Van: Stefan Frey [mailto:ste...@we...]
> Verzonden: dinsdag 5 juli 2011 7:47
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] Train management & dual trains
> 
> Erik:
> sorry I forgot to reply to your question on automated tests recently:
> The test cases are dependent on the game report, but the can be
> reinitialized easily by a few mouse clicks (see the document before).
> So the short answer: No the test cases do not depend on minor detail
> changes, as long as the use case is followed. And they can easily be
> reinitialized again, but all bugs that got in in the mean time will stay
> undetected.
> 
> Thus the use case for changes in the game report is:
> A) Check that all test cases report green.
> B) Make the code change that alters the game report.
> {C) All test cases will report red.}
> D) Reinitialize all test cases by selecting the root test directory.
> {E) All test cases will report green.}
> 
> This is not required if you change only the text in LocalizedProperties,
as the
> test is language independent.
> 
> However after you ignored the test cases for so long (and I did not run
the
> tests myself), that I wanted to figure out first, why the did not run at
all.
> And it can always be related to changes in the game report or due to
> undetected bugs.
> 
> But as the report changed the undetected bugs (if there are any left) will
stay
> undetected, as I will simply reinitialize the test cases and all will show
green
> again.
> 
> I still hope I could convince you to use the tests, as they are the only
chance
> to capture bugs especially for those games which are not implemented by
> yourself (as in the 1889 example before).
> 
> Stefan
> 
> 
> >
> > I can't remember any such change, so I can't give a specific reason,
> > but it's well possible that I have done that at some point.
> > However, if our test cases are dependent on such details, I'm not very
> > happy about that.
> > Improvements must remain possible. Very recently I added a report line
> > about President's cash contributed in  emergency train buying - this
> > was completely unreported so far.
> >
> > I suspect that by now many old test cases will appear to be out of
> > date for other reasons too.  Almost all of my 18EU cases are invalid
> > and must be edited because one redundant Skip action had been removed
> > at some point.  I suppose we should revisit that whole test set.
> > That's a separate subproject in its own right...
> >
> > I attach two test cases that I have used intensively to test the train
> > management changes against. These two cases cover a lot of ground.
> > Unfortunately, the 18EU map is wrong because it still originates from
> > the time before I rotated tile #4, so all these tiles are shown
> > oriented wrongly. Again, this applies to most of my 18EU test cases. I
> > suppose I will have to write a special conversion program to fix that...
> >
> > > There is one (non-official) test however, that already stops with a
> >
> > null-point
> >
> > > exception on buying a train. Save file is attached.
> >
> > That's caused by a bug in the 1830 Pere Marquette configuration. The
> > 6-train releases a 7-train, which is not defined for that variant.
> > This bug must have crept in while recently adding many other variants.
> > I don't have the PM rules, but from your original commit I conclude,
> > that PM has no 7-train, so I have fixed it accordingly.  I have also
> > added checks to catch such misfits during XML parsing.
> >
> > Erik.
> 
>
----------------------------------------------------------------------------
--
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Token.init() and SpecialProperty.init()

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

Brett-
again I am disagreeing with you that this code was redundant, it was essential 
to get the game (integration) tests running. The redundant code was the 
initialization of the 

However I agree that static class variables are evil for any kind of testing.
The ids of the tokens should have done from a controller/manager object 
instead of a static class. 

As it is an all or nothing thing here you will either leave all tests working 
again (after re-init) or none, thus I am happy to see

To test this you should re-initialize the test after applying your code 
changes and then change the report output somehow and see if the tests are 
still working.

Unfortunately this will make any change from two weeks ago until your fix 
untestable, so I hope for a soon completion of the refactoring.

Stefan



On Tuesday, July 05, 2011 09:35:43 am brett lentz wrote:
> Stefan -
> 
> Unfortunately, it's simply not possible to leave those .init() methods
> in place. They were part of a key area of the Game class I've been
> reworking. If you take a look at the current state of the Game and
> ComponentManager classes, you should already be able to see
> improvements in the constructors. There is a clear reduction in
> complexity, as well as several static variables and methods have
> already been made unnecessary. This simplification should, in the end,
> make unit testing easier.
> 
> While I agree that breaking the tests is sub-optimal, I disagree with
> you that we should leave redundant code around merely to prevent unit
> tests from breaking. I think we all agree that the preferred solution
> is to remove the static typing.
> 
> I'm hoping to have time over the next few days to continue reworking
> much of the initialization code that caused the over-abundance of
> static declarations. As I'm doing this, I'll take a look at the
> existing tests and try to ensure as many of them stay usable as
> possible.
> 
> ---Brett.
> 
> On Mon, Jul 4, 2011 at 10:26 PM, Stefan Frey <ste...@we...> wrote:
> > Brett:
> > sorry to object: This code is necessary to run the integration tests.
> > It is a workaround to run multiple tests in sequence without starting a
> > new JVM. As Erik mentions this is related to the fact that it uses
> > static class variables.
> > 
> > I have attached again the document (from March 2010) on testing, which
> > include more details on pitfalls to avoid.
> > I will move that to the Wiki as soon as I have more time to do that.
> > 
> > Can I ask you to reverse that change, as I have too many changes in my
> > workspace, which are not ready for a commit?
> > 
> > Thanks in advance,
> > 
> > Stefan
> > 
> > On Tuesday, July 05, 2011 12:04:24 am brett lentz wrote:
> >> Excellent. Then that's what I'll do. :-)
> >> 
> >> ---Brett.
> >> 
> >> On Mon, Jul 4, 2011 at 1:58 PM, Erik Vos <eri...@xs...> wrote:
> >> > No, you're not missing any deep thoughts here. Of course one of these
> >> > initializations is completely redundant.  Can't tell how it became
> >> > this way - I suppose one day I have overlooked it while doing some
> >> > refactoring.
> >> > 
> >> > The bad news that these indexes are static.  These should IMO be moved
> >> > to some instance in the object creation chain.
> >> > 
> >> > Erik.
> >> > 
> >> >> -----Oorspronkelijk bericht-----
> >> >> Van: brett lentz [mailto:bre...@gm...]
> >> >> Verzonden: maandag 4 juli 2011 22:12
> >> >> Aan: Development list for Rails: an 18xx game
> >> >> Onderwerp: [Rails-devel] Token.init() and SpecialProperty.init()
> >> >> 
> >> >> I'm positive I'm missing something here.
> >> >> 
> >> >> In both Token and SpecialProperty, we're defining some static class
> >> > 
> >> > variables,
> >> > 
> >> >> such as:
> >> >> 
> >> >> private static int index = 0;
> >> >> 
> >> >> Then, in the init() method, we're re-defaulting it to the same value
> >> >> we've already declared, such as:
> >> >> 
> >> >>     // initialize the special properties static variables
> >> >>     public static void init() {
> >> >>         tokenMap = new HashMap<String, TokenI>();
> >> >>         index = 0;
> >> >>         log.debug("Init token static variables");
> >> >>     }
> >> >> 
> >> >> 
> >> >> Why is this necessary? Is the defined default value insufficient in
> >> >> some
> >> > 
> >> > way
> >> > 
> >> >> that isn't immediately obvious?
> >> >> 
> >> >> ---Brett.
> >> > 
> >> > ----------------------------------------------------------------------
> >> > --- --- --
> >> > 
> >> >> All of the data generated in your IT infrastructure is seriously
> >> >> valuable. Why? It contains a definitive record of application
> >> >> performance, security threats, fraudulent activity, and more. Splunk
> >> >> takes this data and makes sense of it. IT sense. And common sense.
> >> >> http://p.sf.net/sfu/splunk-d2d-c2
> >> >> _______________________________________________
> >> >> Rails-devel mailing list
> >> >> Rai...@li...
> >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >> > 
> >> > ----------------------------------------------------------------------
> >> > --- ----- All of the data generated in your IT infrastructure is
> >> > seriously valuable. Why? It contains a definitive record of
> >> > application performance, security threats, fraudulent activity, and
> >> > more. Splunk takes this data and makes sense of it. IT sense. And
> >> > common sense. http://p.sf.net/sfu/splunk-d2d-c2
> >> > _______________________________________________
> >> > Rails-devel mailing list
> >> > Rai...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >> 
> >> ------------------------------------------------------------------------
> >> --- --- All of the data generated in your IT infrastructure is seriously
> >> valuable. Why? It contains a definitive record of application
> >> performance, security threats, fraudulent activity, and more. Splunk
> >> takes this data and makes sense of it. IT sense. And common sense.
> >> http://p.sf.net/sfu/splunk-d2d-c2
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> > 
> > -------------------------------------------------------------------------
> > ----- All of the data generated in your IT infrastructure is seriously
> > valuable. Why? It contains a definitive record of application
> > performance, security threats, fraudulent activity, and more. Splunk
> > takes this data and makes sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-d2d-c2
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- All of the data generated in your IT infrastructure is seriously
> valuable. Why? It contains a definitive record of application performance,
> security threats, fraudulent activity, and more. Splunk takes this data
> and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Token.init() and SpecialProperty.init()

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

Stefan -

Unfortunately, it's simply not possible to leave those .init() methods
in place. They were part of a key area of the Game class I've been
reworking. If you take a look at the current state of the Game and
ComponentManager classes, you should already be able to see
improvements in the constructors. There is a clear reduction in
complexity, as well as several static variables and methods have
already been made unnecessary. This simplification should, in the end,
make unit testing easier.

While I agree that breaking the tests is sub-optimal, I disagree with
you that we should leave redundant code around merely to prevent unit
tests from breaking. I think we all agree that the preferred solution
is to remove the static typing.

I'm hoping to have time over the next few days to continue reworking
much of the initialization code that caused the over-abundance of
static declarations. As I'm doing this, I'll take a look at the
existing tests and try to ensure as many of them stay usable as
possible.

---Brett.



On Mon, Jul 4, 2011 at 10:26 PM, Stefan Frey <ste...@we...> wrote:
> Brett:
> sorry to object: This code is necessary to run the integration tests.
> It is a workaround to run multiple tests in sequence without starting a new
> JVM. As Erik mentions this is related to the fact that it uses static class
> variables.
>
> I have attached again the document (from March 2010) on testing, which include
> more details on pitfalls to avoid.
> I will move that to the Wiki as soon as I have more time to do that.
>
> Can I ask you to reverse that change, as I have too many changes in my
> workspace, which are not ready for a commit?
>
> Thanks in advance,
>
> Stefan
>
>
> On Tuesday, July 05, 2011 12:04:24 am brett lentz wrote:
>> Excellent. Then that's what I'll do. :-)
>>
>> ---Brett.
>>
>> On Mon, Jul 4, 2011 at 1:58 PM, Erik Vos <eri...@xs...> wrote:
>> > No, you're not missing any deep thoughts here. Of course one of these
>> > initializations is completely redundant.  Can't tell how it became this
>> > way - I suppose one day I have overlooked it while doing some
>> > refactoring.
>> >
>> > The bad news that these indexes are static.  These should IMO be moved to
>> > some instance in the object creation chain.
>> >
>> > Erik.
>> >
>> >> -----Oorspronkelijk bericht-----
>> >> Van: brett lentz [mailto:bre...@gm...]
>> >> Verzonden: maandag 4 juli 2011 22:12
>> >> Aan: Development list for Rails: an 18xx game
>> >> Onderwerp: [Rails-devel] Token.init() and SpecialProperty.init()
>> >>
>> >> I'm positive I'm missing something here.
>> >>
>> >> In both Token and SpecialProperty, we're defining some static class
>> >
>> > variables,
>> >
>> >> such as:
>> >>
>> >> private static int index = 0;
>> >>
>> >> Then, in the init() method, we're re-defaulting it to the same value
>> >> we've already declared, such as:
>> >>
>> >>     // initialize the special properties static variables
>> >>     public static void init() {
>> >>         tokenMap = new HashMap<String, TokenI>();
>> >>         index = 0;
>> >>         log.debug("Init token static variables");
>> >>     }
>> >>
>> >>
>> >> Why is this necessary? Is the defined default value insufficient in some
>> >
>> > way
>> >
>> >> that isn't immediately obvious?
>> >>
>> >> ---Brett.
>> >
>> > -------------------------------------------------------------------------
>> > --- --
>> >
>> >> All of the data generated in your IT infrastructure is seriously
>> >> valuable. Why? It contains a definitive record of application
>> >> performance, security threats, fraudulent activity, and more. Splunk
>> >> takes this data and makes sense of it. IT sense. And common sense.
>> >> http://p.sf.net/sfu/splunk-d2d-c2
>> >> _______________________________________________
>> >> Rails-devel mailing list
>> >> Rai...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>> > -------------------------------------------------------------------------
>> > ----- All of the data generated in your IT infrastructure is seriously
>> > valuable. Why? It contains a definitive record of application
>> > performance, security threats, fraudulent activity, and more. Splunk
>> > takes this data and makes sense of it. IT sense. And common sense.
>> > http://p.sf.net/sfu/splunk-d2d-c2
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>> ---------------------------------------------------------------------------
>> --- All of the data generated in your IT infrastructure is seriously
>> valuable. Why? It contains a definitive record of application performance,
>> security threats, fraudulent activity, and more. Splunk takes this data
>> and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] Train management & dual trains

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

Erik:
sorry I forgot to reply to your question on automated tests recently:
The test cases are dependent on the game report, but the can be reinitialized 
easily by a few mouse clicks (see the document before).
So the short answer: No the test cases do not depend on minor detail changes, 
as long as the use case is followed. And they can easily be reinitialized 
again, but all bugs that got in in the mean time will stay undetected.

Thus the use case for changes in the game report is:
A) Check that all test cases report green.
B) Make the code change that alters the game report.
{C) All test cases will report red.} 
D) Reinitialize all test cases by selecting the root test directory.
{E) All test cases will report green.}

This is not required if you change only the text in LocalizedProperties, as 
the test is language independent.

However after you ignored the test cases for so long (and I did not run the 
tests myself), that I wanted to figure out first, why the did not run at all. 
And it can always be related to changes in the game report or due to 
undetected bugs.

But as the report changed the undetected bugs (if there are any left) will 
stay undetected, as I will simply reinitialize the test cases and all will 
show green again.

I still hope I could convince you to use the tests, as they are the only 
chance to capture bugs especially for those games which are not implemented by 
yourself (as in the 1889 example before).

Stefan


> 
> I can't remember any such change, so I can't give a specific reason, but
> it's well possible that I have done that at some point.
> However, if our test cases are dependent on such details, I'm not very
> happy about that.
> Improvements must remain possible. Very recently I added a report line
> about President's cash contributed in  emergency train buying - this was
> completely unreported so far.
> 
> I suspect that by now many old test cases will appear to be out of date for
> other reasons too.  Almost all of my 18EU cases are invalid and must be
> edited because one redundant Skip action had been removed at some point.  I
> suppose we should revisit that whole test set. That's a separate subproject
> in its own right...
> 
> I attach two test cases that I have used intensively to test the train
> management changes against. These two cases cover a lot of ground.
> Unfortunately, the 18EU map is wrong because it still originates from the
> time before I rotated tile #4, so all these tiles are shown oriented
> wrongly. Again, this applies to most of my 18EU test cases. I suppose I
> will have to write a special conversion program to fix that...
> 
> > There is one (non-official) test however, that already stops with a
> 
> null-point
> 
> > exception on buying a train. Save file is attached.
> 
> That's caused by a bug in the 1830 Pere Marquette configuration. The
> 6-train releases a 7-train, which is not defined for that variant. This
> bug must have crept in while recently adding many other variants. I don't
> have the PM rules, but from your original commit I conclude, that PM has
> no 7-train, so I have fixed it accordingly.  I have also added checks to
> catch such misfits during XML parsing.
> 
> Erik.

Re: [Rails-devel] Token.init() and SpecialProperty.init()

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

Brett:
sorry to object: This code is necessary to run the integration tests.
It is a workaround to run multiple tests in sequence without starting a new 
JVM. As Erik mentions this is related to the fact that it uses static class 
variables.

I have attached again the document (from March 2010) on testing, which include 
more details on pitfalls to avoid.
I will move that to the Wiki as soon as I have more time to do that.

Can I ask you to reverse that change, as I have too many changes in my 
workspace, which are not ready for a commit?

Thanks in advance,

Stefan


On Tuesday, July 05, 2011 12:04:24 am brett lentz wrote:
> Excellent. Then that's what I'll do. :-)
> 
> ---Brett.
> 
> On Mon, Jul 4, 2011 at 1:58 PM, Erik Vos <eri...@xs...> wrote:
> > No, you're not missing any deep thoughts here. Of course one of these
> > initializations is completely redundant.  Can't tell how it became this
> > way - I suppose one day I have overlooked it while doing some
> > refactoring.
> > 
> > The bad news that these indexes are static.  These should IMO be moved to
> > some instance in the object creation chain.
> > 
> > Erik.
> > 
> >> -----Oorspronkelijk bericht-----
> >> Van: brett lentz [mailto:bre...@gm...]
> >> Verzonden: maandag 4 juli 2011 22:12
> >> Aan: Development list for Rails: an 18xx game
> >> Onderwerp: [Rails-devel] Token.init() and SpecialProperty.init()
> >> 
> >> I'm positive I'm missing something here.
> >> 
> >> In both Token and SpecialProperty, we're defining some static class
> > 
> > variables,
> > 
> >> such as:
> >> 
> >> private static int index = 0;
> >> 
> >> Then, in the init() method, we're re-defaulting it to the same value
> >> we've already declared, such as:
> >> 
> >>     // initialize the special properties static variables
> >>     public static void init() {
> >>         tokenMap = new HashMap<String, TokenI>();
> >>         index = 0;
> >>         log.debug("Init token static variables");
> >>     }
> >> 
> >> 
> >> Why is this necessary? Is the defined default value insufficient in some
> > 
> > way
> > 
> >> that isn't immediately obvious?
> >> 
> >> ---Brett.
> > 
> > -------------------------------------------------------------------------
> > --- --
> > 
> >> All of the data generated in your IT infrastructure is seriously
> >> valuable. Why? It contains a definitive record of application
> >> performance, security threats, fraudulent activity, and more. Splunk
> >> takes this data and makes sense of it. IT sense. And common sense.
> >> http://p.sf.net/sfu/splunk-d2d-c2
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> > 
> > -------------------------------------------------------------------------
> > ----- All of the data generated in your IT infrastructure is seriously
> > valuable. Why? It contains a definitive record of application
> > performance, security threats, fraudulent activity, and more. Splunk
> > takes this data and makes sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-d2d-c2
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- All of the data generated in your IT infrastructure is seriously
> valuable. Why? It contains a definitive record of application performance,
> security threats, fraudulent activity, and more. Splunk takes this data
> and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Token.init() and SpecialProperty.init()

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

Excellent. Then that's what I'll do. :-)

---Brett.



On Mon, Jul 4, 2011 at 1:58 PM, Erik Vos <eri...@xs...> wrote:
> No, you're not missing any deep thoughts here. Of course one of these
> initializations is completely redundant.  Can't tell how it became this way
> - I suppose one day I have overlooked it while doing some refactoring.
>
> The bad news that these indexes are static.  These should IMO be moved to
> some instance in the object creation chain.
>
> Erik.
>
>> -----Oorspronkelijk bericht-----
>> Van: brett lentz [mailto:bre...@gm...]
>> Verzonden: maandag 4 juli 2011 22:12
>> Aan: Development list for Rails: an 18xx game
>> Onderwerp: [Rails-devel] Token.init() and SpecialProperty.init()
>>
>> I'm positive I'm missing something here.
>>
>> In both Token and SpecialProperty, we're defining some static class
> variables,
>> such as:
>>
>> private static int index = 0;
>>
>> Then, in the init() method, we're re-defaulting it to the same value we've
>> already declared, such as:
>>
>>     // initialize the special properties static variables
>>     public static void init() {
>>         tokenMap = new HashMap<String, TokenI>();
>>         index = 0;
>>         log.debug("Init token static variables");
>>     }
>>
>>
>> Why is this necessary? Is the defined default value insufficient in some
> way
>> that isn't immediately obvious?
>>
>> ---Brett.
>>
>>
> ----------------------------------------------------------------------------
> --
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Token.init() and SpecialProperty.init()

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

No, you're not missing any deep thoughts here. Of course one of these
initializations is completely redundant.  Can't tell how it became this way
- I suppose one day I have overlooked it while doing some refactoring.

The bad news that these indexes are static.  These should IMO be moved to
some instance in the object creation chain. 

Erik.

> -----Oorspronkelijk bericht-----
> Van: brett lentz [mailto:bre...@gm...]
> Verzonden: maandag 4 juli 2011 22:12
> Aan: Development list for Rails: an 18xx game
> Onderwerp: [Rails-devel] Token.init() and SpecialProperty.init()
> 
> I'm positive I'm missing something here.
> 
> In both Token and SpecialProperty, we're defining some static class
variables,
> such as:
> 
> private static int index = 0;
> 
> Then, in the init() method, we're re-defaulting it to the same value we've
> already declared, such as:
> 
>     // initialize the special properties static variables
>     public static void init() {
>         tokenMap = new HashMap<String, TokenI>();
>         index = 0;
>         log.debug("Init token static variables");
>     }
> 
> 
> Why is this necessary? Is the defined default value insufficient in some
way
> that isn't immediately obvious?
> 
> ---Brett.
> 
>
----------------------------------------------------------------------------
--
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Token.init() and SpecialProperty.init()

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

I'm positive I'm missing something here.

In both Token and SpecialProperty, we're defining some static class
variables, such as:

private static int index = 0;

Then, in the init() method, we're re-defaulting it to the same value
we've already declared, such as:

    // initialize the special properties static variables
    public static void init() {
        tokenMap = new HashMap<String, TokenI>();
        index = 0;
        log.debug("Init token static variables");
    }


Why is this necessary? Is the defined default value insufficient in
some way that isn't immediately obvious?

---Brett.

[Rails-devel] Player worth bug

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

Fixed bug #3289557: player worth is not immediately updated when buying a
private.
This was reported for 1889, but it must have been a general problem.

It's possible that worth is now updated twice in some situations, but better
that than not at all.

Erik.

Re: [Rails-devel] Coalfields and states

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

Undoing the Coalfields buy action is now visible in the UI.

> > I agree that hashmapstate should be observable, however the rails
> > solution before that was neither.
> 
> OK, I'll see what I can do in the meantime to fix that.

HashMapState now extends ModelObject.  MapChange and RemoveFromMap now can
take the ModelObject it is changing, and on execute() and undo() the model
update() method is now called to update the Observers; this all works the
same way as ArrayListState already did.

The rights map now uses HashMapState directly. RightsModel has been removed.
The RightsModel getText() method has been moved to HashMapState. I hope that
the output will be usable for any future use of HashMapState that needs
Observers. 

I have also updated ModelObject.update() to return immediately if there are
no observers. This saves unnecessary overhead in constructing unused View
text, as would be the case with the other current use of HashMapState, which
is has no observers.

Erik.

Re: [Rails-devel] Refactoring XML Parsing.

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

Heh... I moved Format to MoneyFormatter because the only methods it
had were related to monetary formats. It seemed more descriptive to
name it something that described the full scope of what the class did.

We can rename it back if you want. I don't feel strongly about either name.

I agree that the ultimate goal is to reduce the number of static
methods and data types to facilitate network play.

---Brett.



On Sun, Jul 3, 2011 at 2:54 PM, Erik Vos <eri...@xs...> wrote:
> Just one little gripe: doesn't MoneyFormatter.money() sound a bit
> tautological?
>
> I once had refactored this very same method into  a class Format with a
> static method money() so that I had Format.money() - that sounds a lot
> better, at least to me. And not that longish.
>
> I had not applied the change to Format.money() because it didn't fix the
> real problem I have with Bank.format(): it's a static method. That precludes
> the multi-game server that we have foreseen for a far distant future. I'd
> rather have an instance method, accessible via our central broker: the
> GameManager. But we still had (and probably have) too many objects that need
> be able to format money but don't know about the GameManager, although I
> think that number is declining - I didn't check it recently. And in this
> frequently occurring case I'm reluctant to pay the overhead involved with
> GameManager.getInstance().
>
> Just my thoughts.
>
> Erik.
>
>> -----Oorspronkelijk bericht-----
>> Van: brett lentz [mailto:bre...@gm...]
>> Verzonden: zondag 3 juli 2011 22:12
>> Aan: Development list for Rails: an 18xx game
>> Onderwerp: [Rails-devel] Refactoring XML Parsing.
>>
>> I've just committed the first step in refactoring the XML parsing code.
> This is
>> something I started on quite a while ago (~3 years ago, wow.), but didn't
>> complete for various reasons. Today, I had some time to pick it back up
> and
>> work on it again.
>>
>> This first commit moves a few classes out of rails.util and into
>> rails.common.parser. I also make GameInfo a non-static class, create non-
>> static setters and getters. Finally, I've updated GameSetupWindow to cope
>> with the new non-static GameInfo.
>>
>> This commit also includes a couple of user-visible changes:
>>
>> * I've updated the Credits section in GamesList.xml to include a more
>> complete list of the people who've contributed code, art assets, or
>> documentation.
>> * I've made the user list always select "human" for the minimum number of
>> players. This should save everyone a couple mouse clicks when starting a
>> game.
>>
>> ---Brett.
>>
>>
> ----------------------------------------------------------------------------
> --
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Refactoring XML Parsing.

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

Just one little gripe: doesn't MoneyFormatter.money() sound a bit
tautological?  

I once had refactored this very same method into  a class Format with a
static method money() so that I had Format.money() - that sounds a lot
better, at least to me. And not that longish.

I had not applied the change to Format.money() because it didn't fix the
real problem I have with Bank.format(): it's a static method. That precludes
the multi-game server that we have foreseen for a far distant future. I'd
rather have an instance method, accessible via our central broker: the
GameManager. But we still had (and probably have) too many objects that need
be able to format money but don't know about the GameManager, although I
think that number is declining - I didn't check it recently. And in this
frequently occurring case I'm reluctant to pay the overhead involved with
GameManager.getInstance().  

Just my thoughts.

Erik.

> -----Oorspronkelijk bericht-----
> Van: brett lentz [mailto:bre...@gm...]
> Verzonden: zondag 3 juli 2011 22:12
> Aan: Development list for Rails: an 18xx game
> Onderwerp: [Rails-devel] Refactoring XML Parsing.
> 
> I've just committed the first step in refactoring the XML parsing code.
This is
> something I started on quite a while ago (~3 years ago, wow.), but didn't
> complete for various reasons. Today, I had some time to pick it back up
and
> work on it again.
> 
> This first commit moves a few classes out of rails.util and into
> rails.common.parser. I also make GameInfo a non-static class, create non-
> static setters and getters. Finally, I've updated GameSetupWindow to cope
> with the new non-static GameInfo.
> 
> This commit also includes a couple of user-visible changes:
> 
> * I've updated the Credits section in GamesList.xml to include a more
> complete list of the people who've contributed code, art assets, or
> documentation.
> * I've made the user list always select "human" for the minimum number of
> players. This should save everyone a couple mouse clicks when starting a
> game.
> 
> ---Brett.
> 
>
----------------------------------------------------------------------------
--
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Refactoring XML Parsing.

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

I've just committed the first step in refactoring the XML parsing
code. This is something I started on quite a while ago (~3 years ago,
wow.), but didn't complete for various reasons. Today, I had some time
to pick it back up and work on it again.

This first commit moves a few classes out of rails.util and into
rails.common.parser. I also make GameInfo a non-static class, create
non-static setters and getters. Finally, I've updated GameSetupWindow
to cope with the new non-static GameInfo.

This commit also includes a couple of user-visible changes:

* I've updated the Credits section in GamesList.xml to include a more
complete list of the people who've contributed code, art assets, or
documentation.
* I've made the user list always select "human" for the minimum number
of players. This should save everyone a couple mouse clicks when
starting a game.

---Brett.

Re: [Rails-devel] Running to and through stations

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

Good point.

type={major|minor|medium|halt|pass}  and whatever else might exist and have its own rules. 

> -----Oorspronkelijk bericht-----
> Van: Chris Shaffer [mailto:chr...@gm...]
> Verzonden: vrijdag 1 juli 2011 23:59
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] Running to and through stations
> 
> Will this proposal address halts, as in 1860, and distinguish them from small
> stations?
> 
> --
> Chris Shaffer
> 
> Please consider the environment before printing this email.
> 
> On Jul 1, 2011, at 2:19 PM, "Erik Vos" <eri...@xs...> wrote:
> 
> > Stefan (& others):
> >
> > I'm having another look at the station properties that we have
> > discussed a while ago.
> >
> > Let's first state what my approach would probably be.
> >
> > 1.  The City class will be renamed to HexStation, because that
> > describes best what it is: the relationship between a Station (a
> > potential train stop on a tile) and a Hex (where a tile with such a Station has
> been laid upon).
> > It is this relationship that defines an actual train stop.
> >
> > 2. The HexStation objects will provide you the station properties to
> > be discussed below.
> >
> > 3. The station properties can be defined in either MapHex (<Hex> in
> > Map.xml) or in Tile (<Tile> in TileSet.xml), or both; in the last
> > case, <Hex> takes precedence, as it is more specific.
> >
> > 4. In both places I propose to define these properties as a subtag
> > <Access> that has attributes that define the station properties. If
> > necessary, a restriction could be added to one station on a
> > multi-station tile, but I'm not aware of any cases where we would need
> > that (perhaps 1841 Venezia, but I think defaults would apply there).
> >
> > 5. Hex defaults can be defined per hex type (colour) in Map.xml and
> > Tile defaults can be defined per tile station type (town, city) in TileSet.xml.
> >
> > Now the question arises what attributes and values we need.  Your
> > approach was a bit different from mine - in fact part of it is exactly
> > orthogonal to mine.
> >
> > In a different thread I had already proposed the following two attributes:
> >
> > - runTo={no|yes|tokenOnly}.  "no" would apply to e.g. Birmingham in
> > 18AL before phase 4 and Elsaß-Lothringen in 1835 except in phase 2.
> "tokenOnly"
> > would apply to the 18Scan red cities. The "no" examples imply that
> > this property should be settable as a result of phase changes.  Would
> > that be helpful?
> >
> > - runThrough={no|yes|tokenOnly}. "no" would apply to e.g. standard
> > off-map areas, "tokenOnly" would apply to 1830 Altoona (PRR base).
> > Your values "RunThrough" and "NoAccess" for closedStationAllows
> > suggest that I should also add "always" (or "evenIfClosed") and
> > "notIfClosed", but do we really need these values? Where?
> >
> > I would think that runTo and runThrough would better describe the kind
> > of conditions that you would be looking for when you are constructing
> > routes, than the openStationAllows and closedStationAllows attributes
> > that you propose, but of course I may be wrong.  It's really up to you.
> >
> > Not mentioned by me before, but inspired by your proposal:
> >
> > - loop={yes|no}. This defines whether one train may visit a hex/tile
> > more than once. This would replace your station naming proposal. I
> > think this is simpler.
> >
> > - type={major|minor|medium} as you propose, except that I have added
> > medium, which appears in some games.  IMO this station type would be
> > train-independent; train-specific usage of station types is to be
> > defined per train type.  It could be useful in some cases where the
> > tile looks like a town, or is internally defined as a town (such as
> > most off-map areas), but is actually a non-tokenable city.
> >
> >
> > Finally two questions about your proposal:
> >
> > 1. Is there any semantic difference between runFrom and runTo? To me,
> > these words describe exactly the same aspects, at least in the 18xx
> > universe, where trains run directionless (perhaps I should say that "to" and
> "from"
> > are quantum-superimposed?).
> >
> > 2. Do we really need N/A?  I’d say:  if it does not matter, it does
> > not matter.
> >
> > Erik.
> >
> >
> >> -----Oorspronkelijk bericht-----
> >> Van: Stefan Frey [mailto:ste...@we...]
> >> Verzonden: woensdag 15 juni 2011 7:11
> >> Aan: 'Development list for Rails: an 18xx game'
> >> Onderwerp: Re: [Rails-devel] 1830 Reading
> >>
> >> Erik:
> >>
> >> is there any reason, why you put the driveThroughStation on map.xml
> >> instead in tile.xml, other than the one discusses previously, that
> > tiles.xml is
> >> not game specific?
> >>
> >> However the tiles you defined are (very) game specific already.
> >>
> >> Both from logical and implementation issues I would prefer to define
> >> attributes of stations in the station tag instead of the hex tag.
> >>
> >> Coalfields:
> >> For the coalfield hex a mechanism to buy the coalfield tokens is
> >> needed
> > first.
> >> Then it is easy to add the adjustment to the revenue calculator via
> >> the
> > static
> >> modifier approach similar to the bonus tokens.
> >>
> >> Stefan
> >>
> >> By the way:
> >>
> >> I have thought about similar issues in my mailing last year
> >> (04/29/10) on "Changes to the Station objects", which cover some more
> >> cases due to a more general approach.
> >>
> >> A) Each station adds the following (additional) attributes:
> >>
> >> tokenAllows = {RunThrough, RunFrom, NoAccess, N/A} If a token is laid
> >> it allows to run through, to run from or no access?
> >>
> >> openStationAllows = {RunThrough, RunTo, NoAccess, N/A} If a token is
> >> laid
> > it
> >> allows to run through, to run to or none?
> >>
> >> closedStationAllows = {RunThrough, RunTo, NoAccess, N/A} If the
> >> station is fully tokened and the company does not own a token there,
> >> what are the possibilities?
> >>
> >> To allow an easier definition I suggest to use station type
> >> definitions
> > like the
> >> company types etc.
> >>
> >> A station is closed if the number of tokens equals the number of
> >> slots, otherwise it is open.
> >>
> >> By this definition a town is always closed, but by setting
> > closedStationAllows
> >> to RunThrough that is not an issue.
> >>
> >> B) Different off-board locations:
> >> There is a substantial variation of different kind of off-board locations.
> >> There are at least four cases, may be more.
> >>
> >> 1) Standard off-board locations (as in 1830) The off-board areas act
> >> as
> > sinks
> >> for all companies.
> >> No tokens allowed.
> >> (tokenAllows = N/A, openStationAllows = N/A, closedStationAllows =
> >> RunTo)
> >>
> >> 2) Tokenable off-board locations (example: SP base in 1870) A base
> >> token
> > can
> >> be layed in at least one of the areas.
> >> The rules claim that off-board areas are still sink for all
> >> companies,
> > except for
> >> the company with a token which can start a train there.
> >> But it cannot run its trains through the hex (thus SP cannot have the
> >> same train enter from NE and then continue to the E).
> >>
> >> (tokenAllows = RunFrom, openStationAllows = RunTo,
> >> closedStationAllows =
> >> RunTo)
> >>
> >> 3) Run-through off-board locations (as Hamburg in 18EU) A
> >> non-tokenable station (similar to towns), that allows running through it.
> >>
> >> (tokenAllows = N/A, openStationAllows = N/A, closedStationAllows =
> >> RunThrough)
> >>
> >> And another from an non-implemented game:
> >> 4) Tokenable run-to off-board locations (as in 18Scan) Here a
> >> base-token
> > is
> >> needed to run to the station.
> >>
> >> (tokenAllows = RunFrom, openStationAllows = NoAccess ,
> >> closedStationAllows =
> >> NoAccess)
> >>
> >> In  general a station is fully tokened if the nb of slots equals the
> >> nb of
> > tokens.
> >> This implies that (default) towns are fully tokened (0=0), but the
> >> fullyTokened attribute would be set to RunThrough.
> >>
> >> StationTypes should be added to provide defaults.
> >>
> >> C) Other new station attributes
> >> runStationType = {Major, Minor}
> >> Is it counted as city-type or town-type for plus-trains and
> > express-trains?
> >>
> >> name = {...}
> >> I would like to add is a "name" attribute for stations on tiles.
> >> Identical
> > names
> >> would imply that those stations are mutually exclusive for train runs.
> > They
> >> would be automatically added to the list of exclusions to the revenue
> >> calculator.
> >
> >
> > ----------------------------------------------------------------------
> > -------- All of the data generated in your IT infrastructure is
> > seriously valuable.
> > Why? It contains a definitive record of application performance,
> > security threats, fraudulent activity, and more. Splunk takes this
> > data and makes sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-d2d-c2
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel