Menu
▾
▴
rails-devel
|
From: Stefan F. <ste...@we...> - 2012-04-08 22:47:03
|
Arne:
I can confirm the bug, thanks for catching it.
The rules for obsolescence are different for 18AL (the previous game
for which obsolete trains where implemented), which rusts the trains for
the company which triggers the phase change.
Erik:
I suggest to add a field to GameParameters "ObsoleteTrainFor" with
values {"all", "exceptTriggering"}
I prefer a GameParameter to a Train Attribute here because mixing
different obsolescence rules in one game is very unlikely to occur.
I can implement that, if you do not prefer to do it yourself.
Stefan
On 04/07/2012 08:07 PM, Arne Östlund wrote:
> Hi
>
> We are playing 1830 Coalfields, when following occured:
>
> /Hi Arne and all
>
> I just noticed that Rails has taken away the N&W’s obsolete 2 train. According to the version of the Reading rules that I have, rusted trains get to run one more time even for the company that buys the train that causes the rusting.
>
>>From Alan Moon’s article in Avalon Hill's periodical GENERAL volume 23, issue 6.
> Train Changes:
> a. Add one more "4" train.
> b. Use the Optional "6" train.
> c. Diesels now cost $750 with a trade-in engine, or $900 without.
> d. Trains that become obsolete are not removed until after the owning corporation's next operating turn. For example: Player A buys the first "4" train making all "2" trains obsolete; Player A, who owns a "2" train, does not have to remove it until after his next operating turn. And if Player A owns a "2" train, he would not have to remove it until after his next turn of operation.
> Is that how you all understand the rules?
>
> John/
>
>
> Save file attached.
>
>
> Regards,
>
> ArneÖstlund
>
>
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
>
>
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
|
|
From: Erik V. <eri...@xs...> - 2012-04-08 22:50:28
|
Stefan,
If you like to do it, please go ahead. It's equal to me.
Erik.
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Monday, April 09, 2012 12:45 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Bug in 1830 Coalfields.
>
> Arne:
> I can confirm the bug, thanks for catching it.
>
> The rules for obsolescence are different for 18AL (the previous game for
> which obsolete trains where implemented), which rusts the trains for the
> company which triggers the phase change.
>
> Erik:
> I suggest to add a field to GameParameters "ObsoleteTrainFor" with values
> {"all", "exceptTriggering"}
>
> I prefer a GameParameter to a Train Attribute here because mixing
different
> obsolescence rules in one game is very unlikely to occur.
>
> I can implement that, if you do not prefer to do it yourself.
>
> Stefan
>
>
> On 04/07/2012 08:07 PM, Arne Östlund wrote:
> > Hi
> >
> > We are playing 1830 Coalfields, when following occured:
> >
> > /Hi Arne and all
> >
> > I just noticed that Rails has taken away the N&Ws obsolete 2 train.
> According to the version of the Reading rules that I have, rusted trains
get to
> run one more time even for the company that buys the train that causes the
> rusting.
> >
> >>From Alan Moons article in Avalon Hill's periodical GENERAL volume 23,
> issue 6.
> > Train Changes:
> > a. Add one more "4" train.
> > b. Use the Optional "6" train.
> > c. Diesels now cost $750 with a trade-in engine, or $900 without.
> > d. Trains that become obsolete are not removed until after the
owning
> corporation's next operating turn. For example: Player A buys the first
"4"
> train making all "2" trains obsolete; Player A, who owns a "2" train, does
not
> have to remove it until after his next operating turn. And if Player A
owns a
> "2" train, he would not have to remove it until after his next turn of
> operation.
> > Is that how you all understand the rules?
> >
> > John/
> >
> >
> > Save file attached.
> >
> >
> > Regards,
> >
> > ArneÖstlund
> >
> >
> >
> > ----------------------------------------------------------------------
> > -------- For Developers, A Lot Can Happen In A Second.
> > Boundary is the first to Know...and Tell You.
> > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> > http://p.sf.net/sfu/Boundary-d2dvs2
> >
> >
> >
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
----------------------------------------------------------------------------
--
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
|
|
From: Stefan F. <ste...@we...> - 2012-04-09 09:24:51
|
Erik:
sure as I already found out where it occurs, most likely it is easier
for me to achieve that. And it is still some of the places where I am
currently getting adjusted to Rails 2.0 setup due to my changes to
Portfolio :-)
However I still have a question open:
There is currently reporting to the ReportWindow about trains rusting
and trains getting obsolete (only about trains rusting after being
obsolete before). There are messages "TrainsObsolete" and "TrainsRusted"
in LocalisedText which do not occur in the java code, only
"TrainsObsoleteRusted".
I suspect this is not a required feature, however I still want to make
sure that I do not break something.
Stefan
On 04/09/2012 12:50 AM, Erik Vos wrote:
> Stefan,
> If you like to do it, please go ahead. It's equal to me.
> Erik.
>
>> -----Original Message-----
>> From: Stefan Frey [mailto:ste...@we...]
>> Sent: Monday, April 09, 2012 12:45 AM
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] Bug in 1830 Coalfields.
>>
>> Arne:
>> I can confirm the bug, thanks for catching it.
>>
>> The rules for obsolescence are different for 18AL (the previous game for
>> which obsolete trains where implemented), which rusts the trains for the
>> company which triggers the phase change.
>>
>> Erik:
>> I suggest to add a field to GameParameters "ObsoleteTrainFor" with values
>> {"all", "exceptTriggering"}
>>
>> I prefer a GameParameter to a Train Attribute here because mixing
> different
>> obsolescence rules in one game is very unlikely to occur.
>>
>> I can implement that, if you do not prefer to do it yourself.
>>
>> Stefan
>>
>>
>> On 04/07/2012 08:07 PM, Arne Östlund wrote:
>>> Hi
>>>
>>> We are playing 1830 Coalfields, when following occured:
>>>
>>> /Hi Arne and all
>>>
>>> I just noticed that Rails has taken away the N&W’s obsolete 2 train.
>> According to the version of the Reading rules that I have, rusted trains
> get to
>> run one more time even for the company that buys the train that causes the
>> rusting.
>>>
>>> > From Alan Moon’s article in Avalon Hill's periodical GENERAL volume 23,
>> issue 6.
>>> Train Changes:
>>> a. Add one more "4" train.
>>> b. Use the Optional "6" train.
>>> c. Diesels now cost $750 with a trade-in engine, or $900 without.
>>> d. Trains that become obsolete are not removed until after the
> owning
>> corporation's next operating turn. For example: Player A buys the first
> "4"
>> train making all "2" trains obsolete; Player A, who owns a "2" train, does
> not
>> have to remove it until after his next operating turn. And if Player A
> owns a
>> "2" train, he would not have to remove it until after his next turn of
>> operation.
>>> Is that how you all understand the rules?
>>>
>>> John/
>>>
>>>
>>> Save file attached.
>>>
>>>
>>> Regards,
>>>
>>> ArneÖstlund
>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> -------- For Developers, A Lot Can Happen In A Second.
>>> Boundary is the first to Know...and Tell You.
>>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>>> http://p.sf.net/sfu/Boundary-d2dvs2
>>>
>>>
>>>
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>>
> ----------------------------------------------------------------------------
> --
>> For Developers, A Lot Can Happen In A Second.
>> Boundary is the first to Know...and Tell You.
>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>> http://p.sf.net/sfu/Boundary-d2dvs2
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
|
|
From: Erik V. <eri...@xs...> - 2012-04-09 21:02:48
|
> However I still have a question open: > > There is currently reporting to the ReportWindow about trains rusting and > trains getting obsolete (only about trains rusting after being obsolete > before). There are messages "TrainsObsolete" and "TrainsRusted" > in LocalisedText which do not occur in the java code, only > "TrainsObsoleteRusted". > > I suspect this is not a required feature, however I still want to make sure that > I do not break something. I would certainly expect that the "TrainsObsolete" and "TrainsRusted" messages would appear in the Game Report, and I'm sure that this had been the case in the past. In all likelihood these messages have fallen by the wayside during my Phase/Train management code reorganization of last year. My suggestion is to reintroduce these messages, probably in TrainManager.rustTrainType(), and possibly augmented as per the needs of 1830 Coalfields. Erik. |
|
From: Stefan F. <ste...@we...> - 2012-04-09 16:34:55
|
Follow-up:
I have pushed my current implementation to sourceforge, branch rails1.7.x
I have added new messages to indicate both rusting of trains and trains
get obsolete, the message for obsolescence depends on the method chosen.
Those changes make all test cases temporarily fail, as soon as I have go
the ok for the new messages from Erik, I will update the reference files
for the test cases.
Implementation details:
I have added the feature as an attribute "obsoleteTrainFor"to
TrainManager tag in Game.xml, which appears to me the better location
than GameParameter as I considered before.
Possible values are documented on the wiki page for Game.xml.
Current settings are
ALL for 1830 coalfield and readings variants
EXCEPT_TRIGGERING for 18TN and 18AL
I have tested that it works for 18TN, however there is no test case that
lets the 4 train get obsolete for 18AL. If someone could send me a game
save file that gets beyond that phase, please send it to me directly.
Stefan
Erik:
sure as I already found out where it occurs, most likely it is easier
for me to achieve that. And it is still some of the places where I am
currently getting adjusted to Rails 2.0 setup due to my changes to
Portfolio :-)
However I still have a question open:
There is currently reporting to the ReportWindow about trains rusting
and trains getting obsolete (only about trains rusting after being
obsolete before). There are messages "TrainsObsolete" and "TrainsRusted"
in LocalisedText which do not occur in the java code, only
"TrainsObsoleteRusted".
I suspect this is not a required feature, however I still want to make
sure that I do not break something.
Stefan
On 04/09/2012 12:50 AM, Erik Vos wrote:
> Stefan,
> If you like to do it, please go ahead. It's equal to me.
> Erik.
>
>> -----Original Message-----
>> From: Stefan Frey [mailto:ste...@we...]
>> Sent: Monday, April 09, 2012 12:45 AM
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] Bug in 1830 Coalfields.
>>
>> Arne:
>> I can confirm the bug, thanks for catching it.
>>
>> The rules for obsolescence are different for 18AL (the previous game for
>> which obsolete trains where implemented), which rusts the trains for the
>> company which triggers the phase change.
>>
>> Erik:
>> I suggest to add a field to GameParameters "ObsoleteTrainFor" with values
>> {"all", "exceptTriggering"}
>>
>> I prefer a GameParameter to a Train Attribute here because mixing
> different
>> obsolescence rules in one game is very unlikely to occur.
>>
>> I can implement that, if you do not prefer to do it yourself.
>>
>> Stefan
>>
>>
>> On 04/07/2012 08:07 PM, Arne Östlund wrote:
>>> Hi
>>>
>>> We are playing 1830 Coalfields, when following occured:
>>>
>>> /Hi Arne and all
>>>
>>> I just noticed that Rails has taken away the N&W’s obsolete 2 train.
>> According to the version of the Reading rules that I have, rusted trains
> get to
>> run one more time even for the company that buys the train that causes the
>> rusting.
>>>
>>> > From Alan Moon’s article in Avalon Hill's periodical GENERAL volume 23,
>> issue 6.
>>> Train Changes:
>>> a. Add one more "4" train.
>>> b. Use the Optional "6" train.
>>> c. Diesels now cost $750 with a trade-in engine, or $900 without.
>>> d. Trains that become obsolete are not removed until after the
> owning
>> corporation's next operating turn. For example: Player A buys the first
> "4"
>> train making all "2" trains obsolete; Player A, who owns a "2" train, does
> not
>> have to remove it until after his next operating turn. And if Player A
> owns a
>> "2" train, he would not have to remove it until after his next turn of
>> operation.
>>> Is that how you all understand the rules?
>>>
>>> John/
>>>
>>>
>>> Save file attached.
>>>
>>>
>>> Regards,
>>>
>>> ArneÖstlund
>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> -------- For Developers, A Lot Can Happen In A Second.
>>> Boundary is the first to Know...and Tell You.
>>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>>> http://p.sf.net/sfu/Boundary-d2dvs2
>>>
>>>
>>>
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>>
> ----------------------------------------------------------------------------
> --
>> For Developers, A Lot Can Happen In A Second.
>> Boundary is the first to Know...and Tell You.
>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>> http://p.sf.net/sfu/Boundary-d2dvs2
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel
|
|
From: Mike B. <com...@ip...> - 2012-04-10 17:49:59
Attachments:
18AL_20120409_1821_AL2.rails
|
If you still need it, here's a complete 18AL game. Mike Bourke Campaign Mastery http://www.campaignmastery.com Co-author, Assassins Amulet http://www.legaciescampaignsetting.com -----Original Message----- From: Stefan Frey [mailto:ste...@we...] Sent: Tuesday, 10 April 2012 2:33 AM To: Development list for Rails: an 18xx game Subject: Re: [Rails-devel] Bug in 1830 Coalfields. Follow-up: I have pushed my current implementation to sourceforge, branch rails1.7.x I have added new messages to indicate both rusting of trains and trains get obsolete, the message for obsolescence depends on the method chosen. Those changes make all test cases temporarily fail, as soon as I have go the ok for the new messages from Erik, I will update the reference files for the test cases. Implementation details: I have added the feature as an attribute "obsoleteTrainFor"to TrainManager tag in Game.xml, which appears to me the better location than GameParameter as I considered before. Possible values are documented on the wiki page for Game.xml. Current settings are ALL for 1830 coalfield and readings variants EXCEPT_TRIGGERING for 18TN and 18AL I have tested that it works for 18TN, however there is no test case that lets the 4 train get obsolete for 18AL. If someone could send me a game save file that gets beyond that phase, please send it to me directly. Stefan Erik: sure as I already found out where it occurs, most likely it is easier for me to achieve that. And it is still some of the places where I am currently getting adjusted to Rails 2.0 setup due to my changes to Portfolio :-) However I still have a question open: There is currently reporting to the ReportWindow about trains rusting and trains getting obsolete (only about trains rusting after being obsolete before). There are messages "TrainsObsolete" and "TrainsRusted" in LocalisedText which do not occur in the java code, only "TrainsObsoleteRusted". I suspect this is not a required feature, however I still want to make sure that I do not break something. Stefan On 04/09/2012 12:50 AM, Erik Vos wrote: > Stefan, > If you like to do it, please go ahead. It's equal to me. > Erik. > >> -----Original Message----- >> From: Stefan Frey [mailto:ste...@we...] >> Sent: Monday, April 09, 2012 12:45 AM >> To: Development list for Rails: an 18xx game >> Subject: Re: [Rails-devel] Bug in 1830 Coalfields. >> >> Arne: >> I can confirm the bug, thanks for catching it. >> >> The rules for obsolescence are different for 18AL (the previous game for >> which obsolete trains where implemented), which rusts the trains for the >> company which triggers the phase change. >> >> Erik: >> I suggest to add a field to GameParameters "ObsoleteTrainFor" with values >> {"all", "exceptTriggering"} >> >> I prefer a GameParameter to a Train Attribute here because mixing > different >> obsolescence rules in one game is very unlikely to occur. >> >> I can implement that, if you do not prefer to do it yourself. >> >> Stefan >> >> >> On 04/07/2012 08:07 PM, Arne Östlund wrote: >>> Hi >>> >>> We are playing 1830 Coalfields, when following occured: >>> >>> /Hi Arne and all >>> >>> I just noticed that Rails has taken away the N&Ws obsolete 2 train. >> According to the version of the Reading rules that I have, rusted trains > get to >> run one more time even for the company that buys the train that causes the >> rusting. >>> >>> > From Alan Moons article in Avalon Hill's periodical GENERAL volume 23, >> issue 6. >>> Train Changes: >>> a. Add one more "4" train. >>> b. Use the Optional "6" train. >>> c. Diesels now cost $750 with a trade-in engine, or $900 without. >>> d. Trains that become obsolete are not removed until after the > owning >> corporation's next operating turn. For example: Player A buys the first > "4" >> train making all "2" trains obsolete; Player A, who owns a "2" train, does > not >> have to remove it until after his next operating turn. And if Player A > owns a >> "2" train, he would not have to remove it until after his next turn of >> operation. >>> Is that how you all understand the rules? >>> >>> John/ >>> >>> >>> Save file attached. >>> >>> >>> Regards, >>> >>> ArneÖstlund >>> >>> >>> >>> ---------------------------------------------------------------------- >>> -------- For Developers, A Lot Can Happen In A Second. >>> Boundary is the first to Know...and Tell You. >>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >>> http://p.sf.net/sfu/Boundary-d2dvs2 >>> >>> >>> >>> _______________________________________________ >>> Rails-devel mailing list >>> Rai...@li... >>> https://lists.sourceforge.net/lists/listinfo/rails-devel >> >> >> > ---------------------------------------------------------------------------- > -- >> For Developers, A Lot Can Happen In A Second. >> Boundary is the first to Know...and Tell You. >> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >> http://p.sf.net/sfu/Boundary-d2dvs2 >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > > ---------------------------------------------------------------------------- -- > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel ---------------------------------------------------------------------------- -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel ---------------------------------------------------------------------------- -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Stefan F. <ste...@we...> - 2012-04-12 09:59:29
|
Mike: yes thanks, it did indeed help, as it confirmed that rusting still works as intended in 18AL. Stefan On 04/10/2012 07:49 PM, Mike Bourke wrote: > If you still need it, here's a complete 18AL game. > > Mike Bourke > Campaign Mastery http://www.campaignmastery.com > Co-author, Assassin’s Amulet http://www.legaciescampaignsetting.com > > -----Original Message----- > From: Stefan Frey [mailto:ste...@we...] > Sent: Tuesday, 10 April 2012 2:33 AM > To: Development list for Rails: an 18xx game > Subject: Re: [Rails-devel] Bug in 1830 Coalfields. > > Follow-up: > I have pushed my current implementation to sourceforge, branch rails1.7.x > > I have added new messages to indicate both rusting of trains and trains > get obsolete, the message for obsolescence depends on the method chosen. > Those changes make all test cases temporarily fail, as soon as I have go > the ok for the new messages from Erik, I will update the reference files > for the test cases. > > Implementation details: > I have added the feature as an attribute "obsoleteTrainFor"to > TrainManager tag in Game.xml, which appears to me the better location > than GameParameter as I considered before. > > Possible values are documented on the wiki page for Game.xml. > > Current settings are > ALL for 1830 coalfield and readings variants > EXCEPT_TRIGGERING for 18TN and 18AL > > I have tested that it works for 18TN, however there is no test case that > lets the 4 train get obsolete for 18AL. If someone could send me a game > save file that gets beyond that phase, please send it to me directly. > > Stefan > > > Erik: > sure as I already found out where it occurs, most likely it is easier > for me to achieve that. And it is still some of the places where I am > currently getting adjusted to Rails 2.0 setup due to my changes to > Portfolio :-) > > However I still have a question open: > > There is currently reporting to the ReportWindow about trains rusting > and trains getting obsolete (only about trains rusting after being > obsolete before). There are messages "TrainsObsolete" and "TrainsRusted" > in LocalisedText which do not occur in the java code, only > "TrainsObsoleteRusted". > > I suspect this is not a required feature, however I still want to make > sure that I do not break something. > > Stefan > > On 04/09/2012 12:50 AM, Erik Vos wrote: >> Stefan, >> If you like to do it, please go ahead. It's equal to me. >> Erik. >> >>> -----Original Message----- >>> From: Stefan Frey [mailto:ste...@we...] >>> Sent: Monday, April 09, 2012 12:45 AM >>> To: Development list for Rails: an 18xx game >>> Subject: Re: [Rails-devel] Bug in 1830 Coalfields. >>> >>> Arne: >>> I can confirm the bug, thanks for catching it. >>> >>> The rules for obsolescence are different for 18AL (the previous game for >>> which obsolete trains where implemented), which rusts the trains for the >>> company which triggers the phase change. >>> >>> Erik: >>> I suggest to add a field to GameParameters "ObsoleteTrainFor" with values >>> {"all", "exceptTriggering"} >>> >>> I prefer a GameParameter to a Train Attribute here because mixing >> different >>> obsolescence rules in one game is very unlikely to occur. >>> >>> I can implement that, if you do not prefer to do it yourself. >>> >>> Stefan >>> >>> >>> On 04/07/2012 08:07 PM, Arne Östlund wrote: >>>> Hi >>>> >>>> We are playing 1830 Coalfields, when following occured: >>>> >>>> /Hi Arne and all >>>> >>>> I just noticed that Rails has taken away the N&W’s obsolete 2 train. >>> According to the version of the Reading rules that I have, rusted trains >> get to >>> run one more time even for the company that buys the train that causes > the >>> rusting. >>>> >>>>> From Alan Moon’s article in Avalon Hill's periodical GENERAL volume > 23, >>> issue 6. >>>> Train Changes: >>>> a. Add one more "4" train. >>>> b. Use the Optional "6" train. >>>> c. Diesels now cost $750 with a trade-in engine, or $900 without. >>>> d. Trains that become obsolete are not removed until after the >> owning >>> corporation's next operating turn. For example: Player A buys the first >> "4" >>> train making all "2" trains obsolete; Player A, who owns a "2" train, > does >> not >>> have to remove it until after his next operating turn. And if Player A >> owns a >>> "2" train, he would not have to remove it until after his next turn of >>> operation. >>>> Is that how you all understand the rules? >>>> >>>> John/ >>>> >>>> >>>> Save file attached. >>>> >>>> >>>> Regards, >>>> >>>> ArneÖstlund >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> -------- For Developers, A Lot Can Happen In A Second. >>>> Boundary is the first to Know...and Tell You. >>>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >>>> http://p.sf.net/sfu/Boundary-d2dvs2 >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rails-devel mailing list >>>> Rai...@li... >>>> https://lists.sourceforge.net/lists/listinfo/rails-devel >>> >>> >>> >> > ---------------------------------------------------------------------------- >> -- >>> For Developers, A Lot Can Happen In A Second. >>> Boundary is the first to Know...and Tell You. >>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >>> http://p.sf.net/sfu/Boundary-d2dvs2 >>> _______________________________________________ >>> Rails-devel mailing list >>> Rai...@li... >>> https://lists.sourceforge.net/lists/listinfo/rails-devel >> >> >> > ---------------------------------------------------------------------------- > -- >> For Developers, A Lot Can Happen In A Second. >> Boundary is the first to Know...and Tell You. >> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >> http://p.sf.net/sfu/Boundary-d2dvs2 >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > > ---------------------------------------------------------------------------- > -- > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > ---------------------------------------------------------------------------- > -- > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > --- > avast! Antivirus: Outbound message clean. > Virus Database (VPS): 120410-1, 10/04/2012 > Tested on: 11/04/2012 3:49:01 AM > avast! - copyright (c) 1988-2012 AVAST Software. > http://www.avast.com > > > > > > > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > > > > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X